A year's AI budget.
Gone by April.
Uber rolled out Claude Code to its engineers in December 2025. By March, 84% of its developers used agentic coding.
In April, the CTO reported that the AI budget for the whole year was already used up. That does not mean the investment failed. It means spending outgrew the plan. Uber is not alone: ServiceNow burned through its annual budget for Anthropic coding tools in the first months of 2026, and adesso Switzerland reports that its token consumption grew roughly a hundredfold.
Why now? The usage data shows it. On OpenRouter, a service that routes requests to many model providers, 6 February 2026 was the last day on which people consumed more tokens than agents.
Since then, agentic usage has grown about 14×, and this is only the beginning. It is one platform, classified by usage signals, so it shows a direction rather than the whole market.
One exchange
The next call waits for a personMany calls per task
Tool results and checksMany tasks in parallel
Events and schedulesA chat is one exchange, and the next call waits for a person.
An agent runs a whole chain of calls for one task: it reads code, calls tools and checks results. For coding tasks, researchers measured roughly 1,000 times the tokens of a chat. This is the growth behind today's bills.
And it will keep growing. A factory runs many of these chains in parallel, triggered by events and schedules, around the clock. It can produce as many tokens as we let it, and factories are only getting started.
More output
≠ more revenue
Ten times the completed tickets is not ten times the revenue. What a company can spend on agents depends on revenue, other costs and margin, and that room does not grow with the factory's capacity.
So the goal is more useful work within that limit, which means reducing the cost of execution. An unnecessary task does not become useful by getting cheaper.
Take an illustrative month for an agent factory: on average 100 tasks a day, about 3,000 a month, at $30 per task, priced roughly at Opus 5 list prices.
That makes $90,000 a month. We will follow this receipt through every optimisation.
The bill has three parts. Input is everything sent to the model: instructions, code, history and tool results. Reasoning are the tokens the model generates while thinking. Other output is the answer, the code it writes and its tool requests.
Cast your vote: click the line you think is the largest. We resolve it after a look at the token volumes.
First the volumes. Almost all tokens are input: 24 billion of about 24.6 billion in our month.
Reasoning and other output are small by comparison. The scenario is even conservative: Stanford measured about 154 input tokens per output token for agentic coding, and Together AI sees typical coding agent requests with 80,000 to 100,000 input tokens and about 450 output tokens.
But input tokens are much cheaper than output tokens. So which line is the largest in dollars?
Input tokens are much cheaper, but at this volume they still make up 82.3% of the bill: $74,100 of $90,000.
Input is the largest line.
In software engineering, even a small change requires reading code, dependencies and tests.
The agent asks for code, and the tool result brings it into the conversation. Test results follow.
Every following request carries the full history. So input grows in two ways: more context, and the same context processed again on every call.
The repeated part at the start of each request, the prefix, can be cached. Without a cache, Opus 5 charges $5 per million input tokens, every time.
Writing the prefix to a 5 minute cache costs a little more, $6.25.
Reading it back on later calls costs only $0.50, 90% less. The 5 minute cache fits subagents and factories. A 1 hour cache costs twice the input price to write. It can pay off with longer pauses between turns, for example in interactive work, but only if the next call comes within the hour.
Assume an unoptimised setup that reads 55% of its input from cache. Those 13.2 billion tokens cost $6,600.
The remaining 10.8 billion tokens are written to cache at $6.25 per million: $67,500. Cache writes dominate the bill, although they are the smaller share of the input. To change that, look at the software that runs the agent.
Harness
The harness is the software that runs the agent loop, such as Claude Code, Codex or Pi. It assembles every request to the model: it defines the available tools, limits their output and manages the conversation history. That is why it has a large effect on caching, as the following example shows.
An example. Early in the session, the agent read config.ts with a timeout of 30.
Later, the file changes: the timeout is now 60. If the harness replaces the earlier file content in the conversation, the context stays small, the typical approach in the past. But the prefix changes at that point, so the cache for everything after it is invalidated and has to be written again.
If the harness appends the update as a new message instead, the old content stays in place. It is obsolete, but the cached prefix stays valid. Claude Code follows this pattern: it appends a change notice and reads the updated file when needed.
| Model | Task completion | Pi cost change |
|---|---|---|
| Opus 4.8 High effort | Claude Code 87% Pi 85% | −52% |
| GPT-5.5 Medium effort | Codex 80% Pi 83% | −35% |
Databricks compared coding agents on about 100 real pull requests, keeping model and effort the same and changing only the harness.
Pi completed about as many tasks as Claude Code and Codex, at 52% and 35% lower cost per task.
The point is not that one harness is better. Results can look different on your own codebase, so it pays to compare harnesses on your own work.
Across coding agents, the share of input served from cache ranges from 46% to 92%, and both ends of that range occur in practice.
The spread shows how much the setup matters for the bill.
Back to our example. With a better harness, the cache-read share rises from 55% to 90%, with the same token volumes.
Cheap cache reads go up, expensive cache writes fall. Reasoning and other output stay the same. The monthly total drops by 54%, from $90,000 to $41,700.
MCP servers add their tool descriptions to every request, even if the task never uses the tool. Loading tools on demand keeps requests small, and changing tool definitions invalidates the cache.
The context window does not have to be filled. Uber compacts conversations at 400k tokens, even where 1M would be available.
Cache reuse is not the only cost driver. Around the harness, further choices have a large effect on cost, for example which MCP tools are loaded into every request.
Or how much of the context window is actually filled before the conversation is compacted.
Both lower the bill with the same model and the same effort.
Effort
The second lever: how much work we ask the model to put into a response. Reasoning effort sets how much the model thinks before it answers, and with it how many tokens it produces.
Artificial Analysis ran the same benchmark with GPT-5 at four effort levels.
At high effort the model produced about 23 times the output tokens of minimal effort. Higher effort improved results, but at substantial cost. Medium is often good enough, and moving from high to medium roughly halves the reasoning tokens.
| Tool | Model | Default effort |
|---|---|---|
| Claude Code | Opus 5 | High |
| Pi | Opus 5 | Medium |
| Codex | GPT-6 Astra | Medium |
| Copilot CLI | Sonnet 4.6 | Medium |
It helps to know the defaults. Claude Code runs Opus 5 at high effort, Pi runs the same model at medium.
These are the defaults as of September 2026, and they change often: tomorrow they may look different. Saved settings, project settings and launch options can override them, so check what actually runs. And medium does not mean the same thing across models.
So far, our example ran at high effort. Uber adopted medium as the default for its interactive harnesses.
Doing the same halves the reasoning cost, with the same model and the same token prices. The total falls from $41,700 to $37,200.
Model
The third lever: which model does the work.
There are many models, each with its own strengths, weaknesses and price. The strong frontier models on the right cost many times more than the models on the left, and many of the cheaper ones are not bad at all.
A closer look at well-known models: the price of uncached input differs by a factor of 50.
Models differ in capability. But wherever a lower-priced model is good enough, that gap is a big opportunity, even between models with small capability differences.
Sonnet 5 costs $2 per million input tokens and $10 per million output tokens, Opus 4.8 costs $5 and $25. That is 60% less per token.
With similar strength, switching looks like a straightforward way to reduce the bill.
On Terminal-Bench 3.0, with both models running in Claude Code, Sonnet 5 cost $18.62 per run and Opus 4.8 $14.09: about 30% more.
The reason is volume. Sonnet used 3.4 times the tokens for the same tasks, while solving fewer. A lower token price does not guarantee a lower bill, so measure on your actual work.
One way to use cheaper models safely is by role. The planner investigates unclear failures and chooses the approach. It stays on a stronger model.
Bounded workers implement a clear specification. They can try a lower-priced model. Change the model, keep the effort fixed. Uber describes the same pattern and uses cheaper models for suitable subagent work.
In our example, the workers account for two thirds of the tokens.
We move them to a lower-priced model, GPT-5.6 Terra, and keep Opus prices for the remaining third. Same token mix, different prices: the total falls by another 38.4%, to $22,928.
Back to where we started: $90,000 a month.
Three changes brought it down to $22,928, 74.5% less: more cache reuse, less reasoning and lower prices for part of the work. And we can explain which change moved which part of the bill.
Switch the levers on and off to see what each one contributes. The scenario is illustrative. For your own setup: measure it, test it.
In April, Uber had used up its annual AI budget.
By August, Uber reported that AI spending had stabilised since April, while agent use kept growing: agentic requests grew 9.4 times between February and August. For a fixed model, the cost per 1,000 requests fell 34% from its peak. Uber improved cache reuse, set medium effort as the default, capped the context window at 400k tokens even for models that offer more, and used cheaper models for subagents, very much like our example.
So far, our example kept one model per role. But the same worker may rename a variable in one file.
The next task for that worker may be a refactoring across five services.
Both tasks get the same model, although they need very different levels of understanding, coordination and reasoning. The role gives a useful default. To go further, the model has to be chosen for each task: model routing.
Model routing
Choosing the model dynamically, for each task. Three common approaches: classification, escalation and nearest neighbours.
Classification decides from the task description alone.
A classifier sorts each task into predefined types, for example documentation or code.
Each type runs with the model that works best for it. This assumes that all tasks of a type need the same complexity and capabilities. It improves the choice, but in practice, tasks within one type usually differ a lot.
Escalation starts every task with a lower-priced model and lets a check decide whether the result is good enough.
If it is, the task is done at the lower price.
If not, a stronger model starts over, or the task escalates further. Then we pay for the earlier attempt and the check as well. The main problem: the check has to be very good.
Represent each task as an embedding and keep a library of past tasks with known results.
For a new task, look up the most similar ones.
If a lower-priced model solved those neighbours as well, it gets the task. Simple, and in routing benchmarks it matches or often beats far more complex learned routers.
Use a lower-cost model
where it is sufficient.
Task requirements differ widely.
So do model prices.
So model routing still holds a large potential: a lower-cost model where it is sufficient, a stronger one where it is needed. Making it reliable is the hard part.
Model selection and routing
for production LLM workloads
Model routing is still an open problem with a large potential. AI Router has been working on exactly that for three years, in production with customers since 2024.