From February to August 2026, weekly active users on Uber’s AI coding agents grew 7x. Weekly agent requests grew 9.4x. and what happened to cost per session? Down 52% from its June peak.
Most teams see these trends on a regular basis. Usage goes up, the bill goes up with it, and someone in finance starts asking uncomfortable questions in a budget review.
This article walks through how Uber’s engineering team actually did it, and what parts of the playbook apply even if you are a five-person team, not a company running 30,000+ agent skill executions a day.
An interactive coding agent burns tokens differently depending on who is using it, how long the session runs, how many times it calls a tool, and which model answers each call. Aggregate spend tells you the bill went up. It does not tell you why, and it definitely does not tell you what to fix.
More than 70% of Uber’s pull requests (merge requests) are now attributed to AI agents (local or cloud).
Uber’s fix was to stop treating cost as one number and decompose it into six.
Every dollar of AI spend, at any layer, breaks down as:
Users × Sessions/user × Turns/session × Requests/turn × Tokens/request × Price/token = Total cost
The first two (users, sessions/user) are adoption and engagement. You want those growing — that is the point of rolling out AI tooling in the first place.
The middle three (turns, requests, tokens) are pure overhead: work that the agent does on its own behalf, on top of whatever the engineer actually asked for. That is where almost all of Uber’s optimization effort goes.
Price per token is the one that you can’t control, but you still get to decide which model gets which task.
Six multiplying terms means six independent places to cut cost without touching adoption.
Three of these deserve a closer look !
Lets deep dive into them.
Uber’s model-selection process for every managed agent is four steps: build a benchmark from real work, run every candidate model on the same harness, move to whichever model is Pareto-optimal (best quality for the cost), and repeat. Reason: the frontier models are shifting every few weeks/months.
uReview which is Uber’s AI agent that automatically reviews every pull request, is the concrete example. Its benchmark runs actual PRs with known bugs, graded easy/medium/hard, scored on precision, recall, and F1 against those bugs, plus cost per review and latency. Switching models along that Pareto frontier raised uReview’s F1 score while cutting cost per review at the same time.
This is the finding I found most useful, because it is not obvious until someone measures it.
Uber routes agent-to-tool connections through MCP (the Model Context Protocol) via a unified gateway covering 1,000+ internal and third-party MCP servers. Standard MCP behavior loads the full schema for every installed tool into every session, whether that session ever calls the tool or not.
With 100+ tools installed, that pre- added roughly 50,000–70,000 tokens to the very first prompt, before an engineer typed a single prompt, and that same schema got re-sent on every turn afterward. Third-party SaaS tools made it worse: one workspace suite alone bundles 49 tools into ~22K tokens of schema. Load two or three MCP servers and the agent is carrying more schema than the file it is about to edit.
Uber’s fix had two parts: CLI-resolved tool calls (the model runs a shell command; the CLI resolves and invokes the actual tool against the gateway at call time, so the schema never sits in context) and tool search (the model searches a catalog and pulls in only the tool definition it actually needs, on demand).
Net effect: that 50–70K token dropped to near zero.
A related trick, code-mode i.e. batching multiple tool calls into one script instead of one model turn per call, cut token usage on simple warehouse queries by 50%+ and on bulk workflows by more than 90%, in Uber’s own measurements.
Across hundreds of millions of lines of code and thousands of tables, Uber found that agents spend most of their turns locating information, not generating it.
Their answer was the AI Context Graph: 24 million nodes, 80 million edges, integrating over 30 internal systems (services, incident logs, PRs, design docs, deployments, table-usage history) so an agent can query it in plain language instead of grepping around blind.
Same prompt → “Can I query the Vehicle Lists table in Forge?”, same model, and two different results:
That is arguably more valuable than any single model swap.
The smallest-looking lever, and probably underrated, but very effective.
Uber put a live running-cost counter directly in the terminal status line i.e. they added spend tiers at 50/80/100% of expected budget.
They also built a session-analysis dashboard that automatically flags 16 anti-patterns per session.
Flagging things like running a simple multi-turn task on an expensive model when a cheap one would do, or resuming a session after a break long enough to blow the prompt cache and force a full-price context rebuild.
Cost per 1,000 model requests dropped 34% from its peak, and cost per session dropped 52% from its June peak.
7x more weekly active users, 9.4x more weekly agent requests, and total AI spend that has “relatively stabilized” since April, 2026.
You do not need Uber’s type internal Context Graph or a 1,000-server MCP gateway to take something from this. The structural ideas transfer at any scale (small or even bigger than this):
Quick definitions:
Source: Running a Software Factory Efficiently at Uber Scale Uber’s AI Software Factory: Cutting Cost Per Session in Half at 9.4x More Agent Requests was originally published in Towards AI on Medium, where people are continuing the conversation by highlighting and responding to this story.