Uber Burned Its Whole 2026 Claude Code Budget by April. Here's What Its CTO Changed

Uber’s engineering organization spent its entire 2026 Claude Code budget by April. Not the quarter’s budget, the whole year’s. CTO Praveen Neppalli Naga went public with the number, and with what the company changed afterward, and it’s a rare, specific look at what happens after the AI-adoption honeymoon ends and someone has to reconcile the invoice.

The number that forced the conversation

“Tokenmaxxing” is the term Naga used for what Uber, and a lot of large engineering orgs, did through the first half of 2026: push AI tool adoption as hard as possible, sometimes tying it to performance evaluation, on the assumption that more usage was straightforwardly good. More engineers on frontier coding tools, more tokens consumed, more AI-assisted output. The assumption wasn’t unreasonable on its face. It also wasn’t measured against anything, which is how a twelve-month budget disappears in four.

The instructive part isn’t that it happened, unmanaged growth in a new spend category is a familiar story, it’s what Uber did in response. The obvious move would have been to cap usage and slow adoption back down. Instead, since January, the number of engineers using frontier AI tools at Uber has quadrupled, while the cost per token has declined. Usage went up. Cost efficiency went up with it. Those aren’t the same trend, and getting both moving in the direction you want at once is the actual story here.

The four levers, and why they’re the boring ones

Naga’s account names four specific changes:

Prompt caching, made to actually work. A lot of AI coding workflows re-send the same context, a large codebase excerpt, a system prompt, repeated instructions, on every call. Caching that context instead of reprocessing it at full price is one of the cheapest, least glamorous ways to cut the bill, and it’s often left unconfigured because it doesn’t show up as a feature anyone demos. We’ve covered the mechanics of this in more depth: the pattern generalizes well past any one vendor’s tooling.

Better default model selection. Not every task needs the most capable, most expensive model available. Routing routine work to a cheaper model by default, and reserving frontier models for tasks that actually need frontier capability, is a policy decision more than a technical one, and it requires someone to have actually looked at what tasks are running through the expensive path by habit rather than necessity.

Usage visibility for the people generating the cost. Cost was invisible to individual engineers before this, which meant nobody making a token-spending decision had any signal about what that decision cost. Once engineers could see their own usage, spending patterns changed without anyone mandating a cap. That’s a familiar effect in cost management generally: visibility alone changes behavior before enforcement does.

Open-weight models for tasks that don’t need a closed frontier model. Testing cheaper, self-hostable models for the slice of work where a frontier model was overkill rather than required. This isn’t a wholesale swap, it’s picking the right tool per task instead of defaulting every request to the most expensive option available.

None of these four are novel ideas. They’re the same cost-discipline playbook that applies to any infrastructure spend that grew faster than anyone was watching it. The reason they’re worth writing about now is that AI coding tools are new enough, and were adopted fast enough in most organizations, that most teams haven’t gotten around to applying this playbook yet. Uber ran the experiment at a scale that makes the result legible: usage and cost aren’t the same number, and treating them as one hides exactly the information you need to tell whether the spend is working.

What this means before your own budget alarm goes off

The Uber story is useful less as an Uber story than as a preview of a milestone most engineering orgs using AI coding tools haven’t hit yet: the point where usage has grown enough that nobody can confidently say what’s driving the bill. Teams that build in per-task model routing, cache configuration, and per-engineer usage visibility before that point tend to hit it as a planning exercise. Teams that don’t tend to hit it as a budget alert, the way Uber apparently did around April.

If your organization adopted AI coding tools broadly over the past several months and nobody currently owns the question of what’s driving spend, that’s the gap worth closing now, not after the number gets uncomfortable. It’s a smaller, cheaper version of the same discipline behind reducing LLM API costs in a production system generally, applied to the newer, less-watched category of spend that is AI-assisted engineering itself. Teams building this kind of cost governance into their AI adoption from the start, rather than retrofitting it, are the ones who get to keep the usage growth without the surprise.