DEV Community

Aniket
Aniket

Posted on

Why I built my coding-agent tooling as a local proxy instead of hooks

#go #ai #opensource #showdev

There are dozens of coding agents out there now, with a new one every other week.

Using them extensively, both at work and on side projects, I kept having ideas about the requests they send, how I could optimize them, or build around them to improve my workflows:

  • What if a small local model checked them for secrets first?
  • What if I could see where my tokens actually go?
  • What if old tool output could be trimmed before it's sent again?

The sensible move was to pick one tool like Claude Code or Codex CLI, build on that tool's hooks, and call it a day.

In true side project fashion, that's not what happened.

Torana: your agent, your machine, your rules. Coding tools on the left, Torana in the middle, model providers on the right

Where to put it

Every coding agent has its own extension point: hooks, config, plugins. Build the same idea on each, and you're maintaining four versions that break whenever one of the tools changes.

But they all have one thing in common: whatever tool you use, it ends up sending requests to a model over HTTP. So that's where I put it. Torana is a local proxy that sits between the agent and the model provider.

Pointing an agent at it is usually one environment variable. For Claude Code:

ANTHROPIC_BASE_URL="$(torana endpoint anthropic)" claude
Enter fullscreen mode Exit fullscreen mode

What that one decision forced

1. Build once, works in every tool. Since the proxy sees every request, anything built there works for Claude Code, Codex, OpenCode or Pi. The catch: they don't all speak the same API. Anthropic Messages, OpenAI Chat Completions and Responses all look different, so the proxy has to understand each format before anything can be built on top of it.

2. It has to run locally. The proxy sees everything: your code, your prompts, the files the agent reads, your keys. That's not something to send to someone else's server. Torana runs on your machine, and it's open source so you can check what it does.

3. It became a plugin system. I had more than one idea, so each idea is its own plugin. Plugins are compiled to WebAssembly, and you can write them in Go or Rust. A plugin that sees all your agent traffic shouldn't run just because it's installed, so nothing runs until you've reviewed its permissions and approved it.

What it cost

A proxy isn't free:

  • Each tool needs routing. Most take a base URL, but not all the same way. Codex, for example, needs its HTTP/SSE mode instead of websockets for plugins to see the responses.
  • Some things only the harness knows. A proxy sees requests, not the agent's UI. That's why Torana later grew an MCP server, so the agent can ask the proxy questions from inside the chat.
  • Prompt caching makes you careful. Change an old message, and the provider's cache for the whole conversation can be rebuilt. Any plugin that edits history has to pay for itself first.

What's next

Over the next few weeks I'll write up one decision at a time: what I built, why, and what it cost. MCP is next.

If you want to try it: https://torana.sh/?utm_source=devto&utm_medium=social&utm_content=origin-04 (open source: https://github.com/torana-edge/torana-edge)

If you've built tooling around coding agents: did you go per-tool, or find a common layer?

Top comments (0)