ToranaI wanted cheaper AI chats. I built a proxy instead.
The original idea was fairly small: use a cheaper model to shorten the history sent to a more expensive model. Less context, fewer tokens, smaller bill. That was the hope.
Somewhere along the way, I built a local reverse proxy, a shared request model, a WASM plugin runtime, and SDKs.
I may have got a little distracted.
I’ve always liked the part where I don’t know how it works yet.
I tried learning C and C++ when I was very young. I experimented with networking my Windows machine and smart TV over Wi-Fi so I could stream movies. I hopped between Linux distributions. A lot of the time I didn’t really know what I was doing. Getting something to work was how I found out.
That curiosity is still why I like software development. I enjoy writing code, but I also love thinking about how the pieces fit together: where a responsibility belongs, what an interface should expose, and what becomes possible once it exists.
Torana is a fairly good demonstration of both the upside and the scope-creep potential of that habit.
The middleware got interesting.
The compactor needed somewhere to intercept requests and change context. A proxy gave it that place, without making the experiment part of one particular coding agent.
Then came the questions. Could a different transformation use the same interface? Could a plugin work against a shared request model instead of implementing every provider format itself? Could I load someone else’s plugin without giving it unrestricted access to the host?
Those questions led to the architecture Torana has now: provider adapters, a common request representation, and Go or Rust plugins running as WASM guests. Plugins declare capabilities; the operator decides what to approve.
There was useful engineering in that detour. There was also overengineering. I’m not going to pretend I had a perfectly formed platform strategy from day one.
Smaller context didn’t automatically mean a smaller bill.
The economics were less cooperative than the first sketch suggested. Rewriting history can disturb a cached prefix. Calling a summarizer has a cost of its own. And removing information is easy; knowing that it will never matter again is harder.
The DeepSeek experiment did not establish reliable savings for the workload I tested. That is narrower than “compaction never works,” but it was enough to make me rethink what I was trying to launch.
The experiment and its limitations are written up separately. I kept the compaction work as an opt-in plugin. I shifted the project toward the proxy and plugin system.
So, what is Torana now?
Torana is an open-source, local-first reverse proxy for coding-agent traffic. You keep your agent and model, point a supported provider route at Torana, and choose what runs in between.
- Observe a session. See request activity, latency, model information, and reported token usage locally. Add the usage logger for a rotating record without conversation bodies.
- Change model-facing behavior. For example, use the tool governor to restrict the tool definitions the model sees. The coding agent still owns executing those tools.
- Try an idea as a plugin. Write Go or Rust against the shared request model, declare the capabilities you need, and approve the built plugin before enabling it.
Local-first means the proxy runs on your machine. Requests still go to your configured model provider, and plugins can use external services when you explicitly configure and approve them.
The compatibility page describes supported formats, harness connections, and the checks behind them.
I want to see what other people put in the middle.
The direction I’m excited about is a place to share small, useful changes to coding-agent workflows: a context policy for a particular kind of task, an adapter for an awkward tool schema, or a bit of observability that answers a question you keep having.
Maybe you’ve already built a tool or workflow hack for your favourite harness. I’d love to see you bring its reusable logic into a Torana plugin, so the next time you switch harnesses, you can take that work with you.
Request plugins work on Torana’s shared representation across compatible provider routes. Plugins can also expose discoverable local HTTP operations for tools and automation. Connect your harness to those operations through its supported invocation mechanism; the shared implementation lives in the plugin.
Try it on a coding task, or hack together a plugin for your own use case. Share what worked and what you built. Contributions don’t have to start with a runtime feature—a clear bug report or a better first-run explanation is useful too.
Try Torana locally → · Browse the plugins → · Read the source →