We built Aitori because AI traffic is getting harder for companies to control.
When developers call an LLM API directly, the request can be routed through a gateway. But tools like Claude Desktop, ChatGPT app, claude.ai call the model from the vendor’s backend. There is no endpoint setting you can point to your proxy.
Aitori is an open-source local proxy that runs on the employee’s machine and intercepts traffic to selected AI applications.
It uses a per-device CA, similar to mitmproxy, to inspect model and MCP requests and forward them to a gateway. Traffic to other applications is left untouched.
Once you can see the traffic, it stops being a black box. You can log it, apply policy, route it, or do whatever else you would with AI traffic you control.
It's Apache-2.0, and the forwarding contract is documented so it works with any gateway, not just ours: https://github.com/truefoundry/aitori/
Try it: curl -fsSL https://raw.githubusercontent.com/truefoundry/aitori/main/in... | sh then sudo aitori up --ui
Around all day to answer any questions.
The linked demo opens TrussLab with a deliberately simple triangle frame and walks through its construction in real time, with narration. You can sit back and watch, orbit around the model without interrupting autoplay, pause or resume the build, or take over at any point and edit it yourself.
TrussLab grew out of my earlier work on SpaceDelta3D large-format delta printers and ultralight SpaceDrone quadcopter frames. At that time, the tooling was just a collection of Clojure scripts that I interacted with from a REPL to generate OpenSCAD models. The underlying idea is simple: use straight-cut tubes or rods made from metal, composites, or even wood for the long members carrying tension and compression, and 3D-print only the geometrically complex joints. Keeping the printed parts small reduces print time, failure risk, warping, and the cost of advanced materials. It worked surprisingly well in two very different domains, so I decided to generalize the approach into something more people could use: "print the complexity, buy the length."
The main difference from general-purpose CAD is that space-frame construction is TrussLab's native design model rather than a workflow layered on top. You work with the logical frame, the nodes and the links between them, while TrussLab tracks which links represent physical members and which are virtual construction geometry. It offsets straight-cut tubes to prevent interference and keeps the generated joints compact. Each printable joint is composed of reusable parametric building blocks called link attachments. Attachments bind to physical or virtual links and adapt to properties such as position, orientation, and tube radius. The attachment palette is not fixed: you can create your own in the built-in constructive solid geometry (CSG) editor and reuse them across frame designs.
Today, TrussLab exports printed parts as STL or 3MF, optionally including the physical members, plus a CSV bill of materials with a tube cut list. It does not yet export STEP; that is planned. The roadmap also includes structural integrity checks and importing read-only glTF geometry for fit checks and rendering.
I'd especially value feedback on what you would try to build with this approach and what missing capability, if any, would prevent you from doing so. I'm also happy to answer questions about the design model or implementation.