Token budgets are a delivery problem
Why AI coding spend spikes, why per-seat caps hit the wrong engineers, how per-task model routing and cost per merged PR work, and budget policies that don't punish the people getting value.
- SMSimran MalhotraCo-founder
5 min read
The token bill usually turns into a meeting around month three. Usage starts slow, a few engineers work out how to get real work done with agents, colleagues copy them, and the invoice climbs faster than anyone planned. Finance asks for a cap. Engineering asks what a cap does to the people who are now shipping more.
Uber is the public example. With about 5,000 engineers on Claude Code and Cursor and usage leaderboards in place, it used its annual AI-tools budget in roughly four months, then set a spending cap per engineer per tool and added a dashboard, according to press reports. Smaller teams tell the same story at a different scale. Engineering managers describe budgets going from unlimited to a fixed monthly amount per person after contractors ran the top model on trivial work.
We treat this as a delivery problem before it's a finance problem. Spend spikes because of how work is routed and run, and most of the fixes live in the workflow.
Where the tokens go
Spend concentrates in a few patterns. The largest model gets used for everything, including renaming a variable. Long sessions keep re-reading a huge context. Agents loop on red CI, trying fix after fix with half the repo loaded. Parallel sessions run overnight and nobody checks whether the first one went wrong. And a usage leaderboard, however well meant, rewards burning tokens. Agentic workflows can use anywhere from 10,000 to 500,000 tokens each, according to Dell and Zinnov's 2026 study of India GCCs, so a handful of runaway sessions can dominate a month.
Before setting any policy, export a month of usage and sort sessions by spend. The most expensive sessions tell you more than per-person totals do. You'll see which ones were a hard migration that earned its cost and which were an agent stuck in a loop at 2am.
Caps by seat, or routing by task
A per-seat cap is easy to explain and easy to enforce. It's also blunt. The engineers who hit it first are the heaviest users, and heavy users are often the ones getting the most done: the person running a framework migration, the one clearing a backlog of flaky tests. A flat cap tells them to stop just as the work is paying off, and tells the light users nothing at all.
Routing by task goes after the cause. Plan with a large model, implement with a smaller one, and review with a different model from the one that built. Planning is where judgement pays: reading the code, choosing between two or three approaches, writing the failing test that defines done. Once a person approves the plan, most implementation is typing to a spec, and a smaller model does it well at a fraction of the price. Keep the large model for planning, hard debugging and reviewing risky diffs.
Most tools now let you set this per task: plan mode on the large model, subagents or skills pinned to a smaller one, a review step that calls another provider. Put those defaults in the repo next to CLAUDE.md or AGENTS.md, so every engineer starts from the same routing instead of whatever they picked last week.
Then stop the loops. Our own workflow allows up to three fix rounds after review before the work goes to a person to adjudicate. The same idea works for red CI: after a set number of failed attempts, the agent stops and writes down what it tried. That one limit removes the most expensive kind of session there is.
Measure cost per merged PR
Total spend tells you the bill. Cost per merged PR tells you whether the bill bought anything. Take seat cost plus token spend for a team over a month, divide by the PRs that team merged, and track it next to lead time and change failure rate. Track spend on PRs that were opened and abandoned as well, since that's money with nothing to show for it.
An illustrative month for two teams:
| Team | Spend | Merged PRs | Cost per merged PR | Spend on abandoned PRs |
|---|---|---|---|---|
| Payments | $4,100 | 92 | $44.57 | 9% |
| Web app | $6,800 | 310 | $21.94 | 22% |
The web team spends more, gets far more merged per dollar, and throws away about a fifth of its spend. A per-seat cap would land on the web team and miss the actual issue, which is abandoned work. Asking why those PRs died (vague tickets, red CI loops, diffs too large to review) is a better use of the meeting than arguing about a lower limit.
Policies that don't punish the people getting value
Set budgets at team level, against what the team delivers. Use a soft cap that alerts the team lead at 80% and starts a conversation, and keep hard stops for runaway sessions only: a maximum number of turns, a maximum spend per session, a stop after repeated red CI. Give planned heavy work, like a migration or a test-suite rewrite, its own budget on the ticket, so the person doing it isn't rationed by an average. Drop usage leaderboards entirely. Cost shown next to outcome, per team, does the job a leaderboard was meant to do without rewarding volume.
This month, pull usage by team, divide it by merged PRs, and read the ten most expensive sessions before anyone changes a cap. Budget caps and routing are part of every coding-agent rollout we set up.