This was supposed to be a compactor.

The original idea was fairly small: tool calls and MCP calls can emit huge outputs. Use a cheaper or local model to compact those outputs before the harness adds them to conversation history and carries them through the rest of the workflow. Less repeated context, fewer tokens, smaller bill. That was the hope.

The experiment needed a reverse proxy. In typical side-project fashion, that proxy got over-engineered into a shared request model, a WASM plugin runtime, and SDKs.

The middleware became a project of its own.

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 someone else’s plugin run without 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. The architecture grew with the experiment, not from a perfectly formed platform strategy on 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 tested workload. That is narrower than “compaction never works,” but it was enough to change the project’s direction.

The experiment and its limitations are written up separately. Compaction stayed as an opt-in plugin. The proxy and plugin system became the focus.

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.

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.

Bring your workflow hacks.

A plugin can be a small, useful change to a coding-agent workflow: 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. Try bringing its reusable logic into a Torana plugin, so the next time you switch to another compatible harness, 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 →