How Uber Runs Coding Agents Cost-Effectively at Scale

More than 70% of Uber's pull requests are now attributed to coding agents — and the company's total AI bill has been roughly flat since April 2026. That is the headline of "Running a Software Factory Efficiently at Uber Scale", published on Uber's engineering blog on August 29, 2026 by Uday Kiran Medisetty. The interesting part is not the adoption number. It is that Uber grew weekly agentic requests 9.4x in six months without the spend curve following.

If you run a software factory — a repeatable agent pipeline for shipping software — this post is the closest thing yet to a public cost-control manual for one at scale. Below is what Uber actually does, and what transfers to a team running a handful of agents rather than an org-wide fleet.

TL;DR

The cost equation: six terms, and which ones to touch

Uber's central framing is that total agent spend factors into six multiplicative terms:

1. Adoption — how many engineers use agents
2. Engagement — how often each one does
3. Turns per session — how many back-and-forth cycles the agent runs
4. Requests per turn — how many model calls each turn fans out into
5. Tokens per request — how much context each call carries
6. Price per token — set by which model serves the call

Terms 1 and 2 are demand. Uber's stated goal is to grow them — more engineers, using agents more — because that is where the return lives. Terms 3, 4, and 5 are what Uber calls "the work the agent does on its own behalf": wasted turns, redundant subagent calls, bloated context. That is the optimization target. Term 6 is a model-selection problem.

This is the same decomposition explainx.ai covered in why AI companies want you using agents and the generative AI cost-optimization guide, applied at fleet scale. The discipline is refusing to treat "AI spend" as one number.

Four layers of agent usage

Uber sorts agent usage into four layers, most specialized to most general. A higher layer gives the platform team more control over cost, quality, and model choice; a lower layer is more flexible but harder to govern. Managed, well-defined agents (code review, migrations) sit high; open-ended interactive sessions in an agent harness sit low. The cost strategy is to push predictable work up the stack where it can be tuned.

Model selection is a benchmark problem, not a preference

Uber picks the Pareto-efficient model per workload — best trade-off across cost per completed task, quality, and reliability — using a four-step loop:

1. Build a benchmark from the agent's real work. Not a public leaderboard — actual tasks the agent runs in production.
2. Run it on a harness that serves any model behind one interface, so swapping models is a config change.
3. Move to the Pareto-optimal model.
4. Keep moving — the frontier shifts every few weeks.

The worked example is uReview, Uber's AI code-review agent. The team built a benchmark from real pull requests with known bugs, graded easy/medium/hard, then scored candidate models on precision, recall, and F1, plus cost per PR, latency, timeouts, and noise. Switching models improved F1 and cut cost per PR. Uber also maintains an internal "Uber SWE Benchmark" over thousands of real PRs.

The takeaway for smaller teams: you cannot pick a model well from vibes or Twitter benchmarks. Build a ten-task eval from your own agent's transcripts and re-run it monthly.

The subagent default model is the biggest lever

Uber calls the subagent default model "the most impactful lever, and growing." Subagents handle well-defined tasks that do not need frontier reasoning — running a search, applying a known edit, summarizing a file. So Uber defaults them to a weaker, cheaper model, with a manual override available. The primary model is reserved for decomposition and evaluation — deciding what to do and whether it worked.

This maps directly onto how agent skills and subagents are configured in most harnesses, and it is the same reasoning behind Claude's effort parameter: match the model's cost to the task's difficulty, not to the hardest task in the session.

Tokens per request: caching, compaction, and reasoning effort

Uber's tuning on term 5:

• Automatic compaction at 400K tokens, even for models with a 1M-token context window. Long context is available, but paying to re-send it every turn is not worth it.
• Reasoning effort defaulted to Medium. Output and reasoning tokens bill at a multiple of the input rate, so uncapped high-effort reasoning is expensive by default.
• Prompt-cache TTL tuning. Cache reads bill at 0.1x the input rate; a 5-minute cache write costs 1.25x and a 1-hour write costs 2x. Uber moved interactive sessions from the 5-minute to the 1-hour TTL because engineers idle longer than five minutes between prompts and were paying to rebuild the cache. Subagents, which run start-to-finish without idling, stayed on the 5-minute TTL. (Anthropic offers 5-minute and 1-hour TTLs; OpenAI's is 30 minutes.)

For the mechanics of why context length dominates agent bills, see what are LLM tokens and the context-compression guide.

MCP context bloat, and the code-mode fix

Standard Model Context Protocol loads every connected tool's schema into every session. At Uber, 100+ tools added roughly 50K–70K tokens that were re-sent on every single turn. Three fixes:

1. CLI tool resolution. The model runs a shell command; a CLI resolves and invokes the tool against a gateway at call time. The MCP schemas leave the context entirely. Uber is projecting all 1,000+ internal MCP tools as CLI commands.
2. Tool search. The model searches a tool catalog and loads only the tools it needs on demand, instead of carrying all of them.
3. Code-mode. Tools are callable as shell commands, so the model writes one script that batches many actions — and polling loops run in a subprocess, returning only a summary to the context.

Uber measured code-mode directly: five identical SQL queries, run both ways. Code-mode cut token usage by more than 50% even for tiny result sets, and by more than 90% for bulk workflows. Uber ships 25+ pre-built code-mode skills for its top MCP servers. One SaaS workspace suite alone exposed 49 tools and about 22K tokens of schema — now routed through the gateway, exposed as CLIs, and given dedicated code-mode skills.

This is the practical answer to the MCP vs RAG context-budget question: MCP's convenience has a standing token tax, and at scale you pay it down by not putting schemas in the prompt at all.

Requests per turn: ground the agent so it stops flailing

Term 4 — model calls per turn — balloons when an agent does not know where to look and explores. Uber's fix is the AI Context Graph: 24M nodes, 80M edges, 86 node types, 117 edge types, integrating 30+ internal systems (services, teams, incidents, PRs, design docs, deployments, datasets, historical query usage), all queryable in natural language.

The example: asked to identify the right table for a task, a grounded agent answered in 38 seconds. An ungrounded agent spent 20 minutes, spawned two subagents, hit three errors, and returned the wrong answer. The ungrounded run cost far more and was worse.

The lesson generalizes below fleet scale: a small, accurate index of your codebase, runbooks, and past incidents pays for itself by cutting the exploratory turns an agent would otherwise burn.

Visibility: make the cost visible while it is being spent

Uber's governance layer:

• Live cost counter in the harness status line — per-harness and cumulative across harnesses for each user.
• One shared spend tier across all interactive harnesses, not per-tool, so engineers cannot dodge a limit by switching tools.
• Slack nudges at 50%, 80%, and 100% of expected spend; manager approval to upgrade a tier.
• A "cost check" dashboard skill engineers can run themselves.
• A Session Analysis Dashboard built into the runtime with zero setup, analyzing every session trace across local and cloud sandboxes. It flags 16 anti-patterns with financial impact and remediation — running a simple session on Opus when Sonnet would do, 40KB MCP payloads persisting in context, resuming a session after the cache expired, pre-loading 100K tokens of instructions and tools before the user has typed anything.

This is the same instinct behind the cost dashboards in the Slash Fintech $80K bill and ABC Legal case studies: spend that is invisible until the monthly invoice never gets optimized.

What Uber says is next

More managed agents; dynamic model routing (pick the model per request, not per workload); deeper Context Graph integration; real-time anti-pattern guidance instead of batch analysis; and auto-generating skill updates from the "papercuts" that show up in agent-skill execution logs.

What transfers to a smaller team

You do not need 24M graph nodes. You need the habits:

• Decompose your AI bill into the six terms and know which one is growing.
• Default subagents to a cheaper model. Reserve the expensive one for planning and grading.
• Build a private eval from your agent's real transcripts; re-run it monthly.
• Cap reasoning effort at Medium unless a task earns more.
• Get MCP schemas out of the prompt — tool search or code-mode, not 60K tokens of schema every turn.
• Put the running cost on screen during the session, not in a report next month.

Related on explainx.ai

• What is a software factory? The SMB promise, explained
• Why AI companies want you using agents: the token economics
• Optimising costs for generative AI: the explainx.ai guide
• How ABC Legal runs 50+ Claude agents as code
• Slash Fintech cut an $80K AI bill with Claude token cost control
• What is an agent harness? Complete guide
• What is MCP? Model Context Protocol guide
• What are agent skills? Complete guide
• Loop engineering for coding agents with Claude Code
• Claude's effort parameter and model selection guide

Primary source: Uber Engineering — Running a Software Factory Efficiently at Uber Scale (August 29, 2026)

Anthropic, Claude, and Claude Code are trademarks of Anthropic, PBC. OpenAI is a trademark of OpenAI. Figures and quotes are Uber's own, as published in its August 29, 2026 engineering post — self-reported, not independently audited.

Specifications, pricing multiples, and figures in this post are accurate as of publication on August 29, 2026. Model pricing, cache TTLs, and Uber's internal numbers change — check the primary source for the current state.