Coding agents cost more than they should, and the reason is easy to miss. Most of the bill isn't the work. It's the agent searching your codebase, then re-sending everything it found on every step.
Bito is launching Governor today to go after that cost. Governor is a gateway and model router for coding agents like Claude Code, Cursor and Codex. It does two things. It sends each request to the right model based on the task in progress, not just the newest message. And it gives the agent the code it needs up front, so the agent spends far less time searching.
Bito says it has measured savings of 40% to 70% across about 10 enterprise customers. In one test at Privado, cost per task fell 48%, from $4.12 to $2.14, and every task still succeeded.
I asked Amar Goel, co-founder and CEO of Bito, how Governor works, where it falls short, and what developers can do this week to cut their own agent bills. Answers have been edited for length and clarity.
The Problem
Your white paper says 60% to 80% of agent session cost goes to context gathering. What did you see that led you to build Governor around that problem?
A coding agent works in steps. It searches the code and gets back 10 to 50 results. It reads one file, then another. Only then does it start to plan or answer your question.
Every result gets added to the conversation. On the next step, the whole conversation goes back to the model, because the model keeps no memory between requests. In one Claude Code session we measured, the agent's searches returned about 65,000 tokens of code. By the end, the session had processed about 6 million tokens. Nearly all of it was the same material, re-sent turn after turn.
Routing alone lowers the price of each token. But the agent still searches and re-sends just as much, so the biggest part of the bill stays the same. If a router leans harder on cheap models to make up the gap, quality drops, and developers spend the savings redoing the work. So we built Governor to cut both the price per token and the number of tokens.
Why do keyword-based routers like LiteLLM and Bifrost struggle with coding-agent traffic?
In a coding session, the message that starts the hardest work is often the shortest, like "looks good, implement this." Its meaning comes from the conversation before it.
LiteLLM and Bifrost both pick a model by scanning the newest message for keywords. We ran 12 typical coding-agent messages through LiteLLM's scorer. It sent 11 of them to the cheapest model, including a one-line request to refactor authentication code everywhere it's called. A better keyword list won't fix that, because the scorer never sees the task behind the message.
Here's what that costs. A strong model reads the code and writes a plan. The developer replies "go ahead." A keyword router sends the build step to the cheapest model. The code comes back weaker, the developer sends it back for fixes, and the savings go into the redo. Governor reads the "go ahead" together with the plan it approves, so the build goes to a model strong enough to do it.
How It Works
Walk me through what happens to a request from Claude Code once it hits Governor.
When a developer starts a new request, Governor's classifier reads it along with the task in progress. It places the request in a tier based on the kind of work and what a mistake would put at risk. The tier sets the model and reasoning level, drawn only from models the customer allows.
Before switching models, Governor checks the prompt cache. That's the discounted copy of the conversation the provider already holds. Switching means paying to rebuild it, so Governor switches only when the next few requests will save more than the rebuild costs.
When the agent needs to find code, Governor's code retrieval sub-agent does the search. The main agent gets a short answer with the file and line each fact came from.
Governor keeps a live index of a customer's repositories. Where does it live, and how do you handle teams with strict rules about source code?
The index lives wherever the customer runs Governor, in Bito's cloud or on-prem. It's a structural index of the code across every repository. We don't store the source code itself, and none of it is used to train a model.
Teams with strict rules run Governor on-prem. The index, the lookups and the routing decisions all stay inside their network. Model requests go out on the customer's own provider accounts and keys, the same calls their agents already make. So an on-prem deployment adds no new party that sees the code. Bito is SOC 2 Type II certified.
How does Governor decide whether a request is Simple, Medium, Complex or Reasoning? And what happens when it gets one wrong?
The classifier asks two questions. What kind of work is this, and what would a wrong answer put at risk? Clear, stated changes, including carrying out a plan already agreed to, go to Simple. Vague requests go to Reasoning, because the first job is figuring out what the developer wants. We tested hundreds of versions of that rubric against hand-labeled requests. Early versions put about 60% of requests in the right tier. The current one gets all of them right, across repeated runs.
When it's wrong, guardrails limit the damage. By default, Governor never routes to a model pricier than the one the developer asked for. If it can't place a request, the requested model answers. If the classifier fails partway through a turn, Governor keeps the current model. Teams can pin work, like keeping all planning on Opus. And every request records why it went where it went, so a bad call is easy to find.
Switching models mid-session throws away a paid-for cache. How does Governor decide when moving is worth it?
A warm cache can make the expensive model the cheaper choice. Reading a cached Opus 5.5 conversation costs $0.20 per million tokens. Sending the same conversation to Gemini Flash with nothing cached costs $0.75.
Over a longer stretch, the math can flip. In one 48-request implementation loop, paying once to warm the cheaper model's cache would have cut the cost by a third. The obvious answer is to forecast how long the conversation will run. That's very hard, though we're working on it.
So Governor asks a smaller question it can answer: will the next few requests pay back the cost of moving? It moves only when they will, so a wrong call costs at most a few requests' worth of savings. When we replayed real conversations, a forecast-based rule added 42% to the bill in one case where Governor's rule lost nothing.
The Results
The launch headline says 40% to 70% savings. Where does that range come from, and where should teams start?
We've measured results across about 10 enterprise customers so far. Savings vary because some customers pick Balanced and some pick Cost, and their workloads differ. The longer your coding sessions, the more you save. If you run a lot of short sessions, the savings are smaller. Some customers are getting around 80%, but we didn't want to overpromise.
Here's how the settings compare with Claude Code's default on Opus 5.5 in our long-session benchmark:
- Quality keeps the same score at 1.3x lower cost, about 23%, with sessions 12% faster.
- Balanced keeps 95% of the score at 1.9x lower cost, about 47%, with sessions 39% faster.
- Cost keeps 94% of the score at 7.1x lower cost, about 86%, with sessions 30% faster.
These are benchmark numbers, so treat them as a starting estimate for your own traffic.
I'd start every team in shadow mode, where Governor records what it would have done without changing anything. Then switch on Balanced with planning pinned to the strongest model. Planning is what everything else in a session builds on, so that's where the best model earns its price.
Tell me about the Privado test.
Privado builds a privacy engineering platform, and its developers work in Claude Code. They ran 40 of their own engineering tasks twice, once straight to the model and once through Governor. Same model, same agent setup, so Governor was the only variable.
Cost per task fell 48%, from $4.12 to $2.14. Every task succeeded both ways. With Governor, tasks finished 38% faster. The agent took half as many reasoning turns and made 53% fewer tool calls, because it spent far less time searching the code.
For the developers, nothing changed in how they worked. They kept their agent, their prompts and their workflow. The difference showed up in the bill and in how fast tasks came back.
The benchmarks are Bito's own. What should a skeptical engineering lead know?
We built both benchmarks so a model can only score well by doing the work. Our public study graded 1,800 answers from 30 models on 60 real engineering tasks. Twenty-six run on private code no model could have seen in training. Twenty-eight are graded by running the model's code, so an answer counts only if it works. The session benchmark uses long Claude Code sessions on proprietary code, graded against a written key. Identical sessions vary by 1.5 to 2 points, so we compare averages and read every session that falls well below.
Still, a skeptical lead should trust their own traffic over our numbers. Shadow mode shows what Governor would have done. A/B mode sends a small share of traffic around Governor, compares cost per task, and grades a daily sample with a judge from a different model provider than the one doing the work.
Where does a cheaper setting lose quality, and how should a team protect those steps?
The loss sits in specific steps, not across the whole session. In our benchmark, Balanced fell furthest behind on diagnosing a failure. It earned 67% of the available points on that step, against 90% for the Opus 5.5 default. Quality scored 93%. Cheaper settings also lost points when defending a design against pushback.
Teams can protect those steps by keeping them on the strongest model. Governor lets a team route specific kinds of work up, so diagnosis and design review stay on Opus while the rest of the session runs on Balanced.
Trade-offs and Limits
Code context adds a wait before the first answer. When does it pay off?
Code context takes about 30 seconds up front. But that time isn't new. In our benchmark, Opus 5.5 on its own spends 36 to 41 seconds grepping and reading code before it starts the real work. Governor does that research for the agent, and tasks finish much faster overall.
On one benchmark of real developer requests, including tracing an event through Kafka and planning a feature, the session took 8.5 minutes with code context versus 25 minutes without. The agent made 14 tool calls instead of 162.
It pays off least on short, well-defined tasks, where the agent already knows where to look. It also helps less on steps that depend on reading one edge case line by line. That's what we're working on next.
What doesn't Governor do well yet?
There are four things, and we list them in the paper. First, short tasks. Some levers, prompt guidance in particular, add a fixed overhead that cancels most of the saving on quick jobs. So the Quality setting costs about the same as today on short work.
Second, cache behavior on some providers. With certain cheap models, the cache rule kept nearly every request on the expensive model, which leaves little saving.
Third, Governor decides fresh at the start of each turn. It doesn't forecast where a session is heading, which would help it pick models earlier.
Fourth, it can capture what developers do after an answer, but using that to tune the rubric for each team is still a manual step.
Getting Started
What does setup look like?
It's a base URL change in your existing coding agent. Governor speaks the Anthropic and OpenAI APIs, so pointing Claude Code, Cursor or Codex at it is one environment variable. Requests keep their model, streaming and tool calls. It runs on the team's own provider keys, alongside any gateway they already use, in Bito's cloud or on-prem. For code context, the team connects the repositories Governor should index.
Shadow mode records from the first request. A team can be up and running in minutes.
Which agents and providers are supported, and how is Governor priced?
At launch, Governor works with Claude Code, Cursor, Codex, GitHub Copilot and Pi, plus any agent that calls the Anthropic or OpenAI APIs. It covers Anthropic, OpenAI, Gemini (including on Vertex), Grok and open-weight models, on the customer's own keys or through their existing gateway.
Pricing is usage-based, scaled to the size of the indexed codebase and the volume of routing requests. Model provider costs pass straight through, so the savings show up on the bills teams already pay. Every team starts with a free trial on its own agents.
If a developer wants to cut agent costs this week, with or without Governor, what's the first step?
Look at one long session from your team, token by token. Most teams find the bill is the conversation being re-sent, with the agent's own searches piling up, more than the work itself. Across our model research, cache reads were 77% of all tokens processed.
Then check the reasoning level your tools send. Most send the same level on every request. On our benchmark, lighter reasoning on Sonnet 5.5 saved 9% and kept 98% of the score. And keep planning on your strongest model, since everything after it builds on the plan.
With Governor, start with shadow mode on your own traffic.
The Takeaway
The useful idea here goes beyond routing. Most of a coding agent's bill comes from what it re-reads, not what it writes. Cut the searching and the re-sending, and the choice of model matters less. Bito's numbers are its own, so the right first move is the one Goel suggests: measure one session from your own team and see where the tokens go.