How Uber cut AI coding costs 52% — the playbook, applied

In August 2026 Uber published Running a Software Factory Efficiently at Uber Scale. The headline numbers: weekly active users of AI tooling up 7×, agentic requests up 9.4× — while cost per session fell 52% and cost per 1,000 requests fell 34%, measured with the model held constant. Total spend flattened while usage exploded.

No pricing negotiations. No usage caps. They removed tokens that bought nothing.

This is the most useful public document in agentic cost management, and it is worth reading in the original. What follows is the playbook distilled into the form an engineering organisation can act on: the equation that makes the levers visible, each lever with what it is worth and what it costs to adopt, the honest case against each one, and the order to do them in.

The equation that does the work

Uber decomposes every dollar of agent spend into six multiplying terms:

Spend = Users × Sessions/User × Turns/Session
      × Requests/Turn × Tokens/Request × Price/Token

The value of writing spend this way is that it separates the terms you want to grow from the terms you want to shrink. The first two are adoption — more engineers using agents, more often — and an organisation deploying AI tooling is trying to increase them on purpose. The last term belongs to the vendor and your procurement team. Everything Uber optimised lives in the middle three: the work an agent does for itself, on top of what an engineer asked for.

That framing matters because most cost conversations only ever reach the last term — “should we move to a cheaper model?” — while the middle terms are where sessions quietly get expensive. It also explains why total spend is a poor management metric: it moves when adoption moves, and adoption moving up is the outcome you paid for.

The corollary is the measurement discipline: hold the model constant. Uber’s numbers are stated that way deliberately. A cost-per-session figure that falls because traffic moved to a cheaper model tells you about substitution, not about waste, and the two need different decisions.

The levers, ranked by cost of adoption

What is striking about the playbook is how much of it is configuration rather than engineering:

Lever	What it does	Cost to adopt
Cheap model for subagents	Subagents do scoped work; they don’t need frontier reasoning	One default
Medium reasoning effort	Output tokens are the most expensive class, and thinking bills as output	One default
Compaction at 400K	Stop hauling a giant prefix on every turn	One default
1h cache TTL (interactive)	Idle gaps past 5 minutes force full-price prefix rebuilds	One setting
Tool search over preloaded schemas	100+ MCP tools add 50–70K tokens before the user types anything	Configuration
Code-mode skills	Run polling loops outside the model’s context	Days per skill

Five of the six are settings. That is the finding worth carrying: the first tranche of savings in an agentic fleet is not an engineering project, it is a decision about defaults and a way to apply them everywhere.

Cheap models for subagent traffic

A subagent runs scoped, mechanical work — search this tree, read these files, summarise this output — and it carries its own context window. Running that traffic on the frontier model is paying top rate for the least reasoning-dense work in the system.

What it is worth: the widest range of any lever, because it scales with how much of your traffic is subagent traffic. In fleets that have adopted agent teams it can be most of the bill: Anthropic documents agent teams using roughly 7× the tokens of a standard session when teammates run in plan mode.

The case against: a subagent that fails at its task gets retried by the parent, and two cheap attempts plus a frontier retry cost more than one frontier attempt. The lever is safe for retrieval and summarisation and needs evidence for anything that plans.

Reasoning effort matched to the task

Thinking tokens bill as output tokens — the most expensive class — and default budgets can run to tens of thousands of tokens per request. Effort is therefore a cost dial with a quality cost attached, which is exactly why it should be set per workload rather than globally.

The case against: the cheapest possible answer to a hard question is often the most expensive thing you can buy, because the engineer discards it and asks again. Lower effort belongs where the task is mechanical.

Cache TTL matched to how developers actually work

The cache lever has the largest ratio of any single setting, because the price spread inside prompt caching is 10× and the thing that decides which side you land on is a clock:

A cache read costs 0.1× the input rate. A prefix rebuilt after expiry costs the full rate to re-read, plus a write premium to cache it again. Interactive development is full of gaps longer than five minutes, and the default lifetime on an API key or a cloud provider is five minutes.

What it is worth: Uber’s fix — one hour for interactive sessions, five minutes for short-lived subagents — is one line of policy and removes a whole class of rebuild.

The case against, and it is real: the one-hour tier costs 2× to write against 1.25× for five minutes. On a session that never idles, that premium buys nothing — you pay 60% more on every write to insure against an interruption that does not come. The lever is worth money where sessions actually idle, which is a measurement question, not a preference. The honest form is to turn it on where the evidence says prefixes are being rebuilt after gaps, not everywhere.

Tool schemas out of the prefix

Tool definitions live in the context, and preloaded schemas are re-sent on every turn of every session. Uber measured the fix — tool search plus CLI-resolved tools — at roughly 50–70K tokens saved per session before any work happens.

This is the lever most teams do not know they are paying for, because the cost appears before the first prompt and never shows up as a slow or obviously expensive request. It is also the one that has moved fastest: Claude Code now defers MCP tool definitions by default, so for many fleets the question is whether an older configuration is still pinning them into context.

The case against: deferred tools cost a round trip when they are needed. For a workflow that uses the same three tools constantly, preloading them is correct.

Compaction before the context becomes the cost

Compaction summarises history so the conversation stops growing. It is the lever with the most subtlety, because compaction is itself expensive: the summarising request reads the conversation it is summarising, and it rewrites the prefix, which invalidates the cache beneath it.

The case against: compacting too eagerly pays the rebuild cost repeatedly and loses context the agent then re-derives — the worst of both. Compacting too late means every turn hauls a giant prefix. The setting is a threshold, and thresholds want measurement.

Code-mode skills

The only lever on the list that costs engineering days rather than a setting: move deterministic loops — polling, waiting, iterating over a list — out of the model’s context and into code the model calls once. It is also the one with no ceiling, because it removes requests entirely rather than making them cheaper.

What it took Uber to do this

The acknowledgments section of their post lists over thirty engineers. The stack behind the numbers includes a gateway fronting 1,000+ MCP servers, a private benchmark built from thousands of real PRs, a context graph with 24 million nodes, and a session analyzer that flags 16 distinct waste patterns with a dollar figure attached to each.

That is the honest catch in the playbook. The levers are simple; applying them fleet-wide, measuring the delta credibly, and keeping them applied as models and harnesses ship weekly is a platform team’s full-time job. A setting changed on one developer’s machine is a preference. The same setting applied to four hundred machines, kept in place through three harness releases, and shown to have moved cost per session by a measurable amount, is infrastructure.

What order should a normal organisation do this in?

Uber’s sequence is not the right sequence for a team without a platform group, because the first thing they had — measurement — is the thing most organisations skip. In rough order of return per unit of effort:

1. Get per-request records with model, token classes and a session id. Nothing below this line can be evaluated without it, and the vendor’s client-side figures are not it — they are computed locally, at list price, from one machine.
2. Split any spend change into volume and unit cost. Adoption growth and waste growth look identical on an invoice and want opposite responses.
3. Route subagent traffic to a cheaper model. Usually the largest single misallocation, and it is one default.
4. Set cache TTL from evidence of idle gaps, not as a blanket policy — the write premium is real.
5. Check what your fleet actually has configured for tool definitions and compaction. Defaults have moved; configurations pinned a year ago have not.
6. Then look at prompts and workflow. The individual-level advice is real, but it moves the smallest term and scales worst across a fleet.

Steps 3 through 5 are settings. The reason they are hard is not technical: it is that “apply a default to four hundred developers and prove it moved the number” is an organisational problem with a measurement problem inside it.

Applying it without the platform team

We built decost to be that platform team as a service: policies applied to Claude Code and Codex traffic in your own network, and a measurement engine that proves the delta the way a finance team would demand — same model mix, per-request counterfactuals, savings that under-claim rather than inflate. The four questions such a claim has to answer are in the number your developers see is not the number you pay, and the anatomy of the bill those policies act on is in what a coding-agent session actually costs.

The measured result is the product. If the levers above sound like your bill, start with a free spend audit — it reads your provider’s billing data and tells you what each lever is worth per year, before you install anything.

Frequently asked

Did Uber’s cost per session fall because they moved to cheaper models? No — they state the comparison with the model held constant, which is what makes the number meaningful. A cost reduction measured across a changing model mix cannot distinguish removed waste from substituted capability.

Is the 1-hour cache TTL always cheaper than the 5-minute one? No. The one-hour tier costs 2× the input rate to write against 1.25× for five minutes, so it only pays where prefixes actually survive gaps longer than five minutes and get read again. On continuously active sessions it is a 60% premium on every write for insurance you do not use.

How much of this applies to Codex rather than Claude Code? The equation and the levers apply to any agentic harness, because they describe how agents consume tokens rather than how one vendor bills them. The specific settings differ — the cache mechanics, the subagent model configuration and the compaction threshold all live in different places — but the middle three terms are the same three terms.

We only have a hundred developers. Is this worth the effort? The measurement is worth it at any size, because without it you cannot tell adoption from waste. The levers scale with spend rather than headcount: at Anthropic’s published $150–250 per developer per month, a hundred developers is $15–25K a month, and the first two settings typically address a double-digit percentage of it.

Where do the savings go once the easy levers are done? Into the terms that need engineering rather than configuration: fewer requests per turn through better tooling, smaller tool results, and deterministic work moved out of the model’s context entirely. That is where Uber’s code-mode skills sit, and it is the part with no ceiling.