Uber Gets 70%+ of PRs from AI Agents — Here's How It Cut Agent Session Cost 52%
More than 70% of pull requests at Uber are now attributed to local or cloud AI agents. Uber engineers have created over 3,600 agent skills and run more than 30,000 skill executions per day. Weekly active users of agentic tools grew 7x, and weekly agentic requests grew 9.4x between February and August 2026.
The surprising part is what happened to the bill. Total AI spend roughly stabilized after April, cost per 1,000 requests fell almost 34% from its peak, and cost per session fell 52% from its June peak.
So here is the question I kept asking after reading Uber Engineering’s post, “Running a Software Factory Efficiently at Uber Scale”: How can agent usage grow almost tenfold without the AI bill growing at the same rate?
The short answer, which I will unpack below: Uber stopped treating AI coding as a chat tool and started treating it as an engineering system. Every cost lever it pulled has a smaller personal equivalent that works with Claude Code, Codex, Cursor, or OpenCode.
The key numbers
| Metric | Uber result |
|---|---|
| PRs attributed to local/cloud agents | 70%+ |
| Agent skills | 3,600+ |
| Skill executions | 30K+/day |
| Weekly active user growth | 7x |
| Agentic request growth | 9.4x |
| Cost / 1K requests | ~34% lower |
| Cost / session | 52% lower |
The interesting number is not 70%. It is the 9.4x usage growth combined with falling unit economics. Before I get to the reusable lessons, I want to be precise about that first row: “attributed to” does not mean “autonomously written by an agent.” Humans still review, escalate, and decide. Uber itself reports the 70%+ figure, and I will keep every number below attributed to Uber rather than strengthening it.
What Is Uber’s Software Factory?
Uber’s Software Factory is not a single coding agent or a company-wide chatbot. It is an engineering system around AI-assisted software development: interactive coding harnesses, reusable skills, managed agents, tool and MCP access, subagents, model routing, context infrastructure, evaluation, review, and escalation.
The important distinction is that Uber is trying to control the whole path from a developer or automated trigger to a completed engineering outcome. That gives the company levers beyond model choice: it can change which model runs, which tools are loaded, how much context is sent, when a subagent is used, how retries happen, and how success is evaluated.
For an individual developer, the equivalent is much smaller. You do not need Uber’s infrastructure; you need a deliberate harness around Claude Code, Codex, Cursor, or OpenCode so recurring work uses the right context, tools, models, and reusable workflows.
Uber Is No Longer Treating AI Coding as a Chat Tool
The old mental model is one developer talking to one chatbot:
Developer -> chatbot -> answerUber’s model is a pipeline, and the human is only one possible trigger:
Developer / trigger | vCoding harness -> Skills -> Tools / MCP -> Subagents -> Models | vEvaluation -> Review / escalationUber runs managed agents for automated code review, self-healing CI failures, end-to-end PR generation, visual validation, on-call triage, bug debugging, and code maintenance. This points to the economic distinction that matters most: interactive agents vs managed agents.
Interactive agents leave every decision to thousands of individual sessions — each developer’s model choice, prompt, and context. Managed agents let the organization control model selection, prompts, context, tools, retries, evaluation, token use, and therefore cost per completed task.
Uber’s Agent Cost Equation Is More Important Than Its 3,600 Skills
Uber decomposes spend into a chain:
Total AI Spend =Users x Sessions per User x Turns per Session x Requests per Turn x Tokens per Request x Price per TokenThe useful part of this equation is that each optimization maps to a specific variable:
| Optimization | Primary cost lever | Why it helps |
|---|---|---|
| Cheaper subagents | Price / Token | Reserve expensive models for reasoning-heavy work |
| Context compaction | Tokens / Request | Stop resending stale history |
| Prompt caching | Effective Tokens / Request | Reuse repeated prompt prefixes when economics favor it |
| MCP lazy loading | Tokens / Request | Avoid injecting unused tool schemas |
| Code-mode / batching | Requests / Turn | Replace many model-tool round trips with one deterministic script |
| Better grounding | Turns / Session + Requests / Turn | Reduce blind search, retries, and wrong branches |
| Reusable skills | Turns / Session + retries | Reuse known workflows instead of rediscovering them |
| Managed workflows | Sessions / task + variance | Standardize model, tools, context, and evaluation for repeated work |
This is the framework I would copy from Uber: do not ask only, “Which model is cheaper?” Ask, “Which variable in the cost equation is making this task expensive?”
Most developers only think about the last factor, price per token. But an expensive session usually comes from too many turns, repeated context, unnecessary tool schemas, failed searches, oversized tool responses, poor model routing, cache misses, or overpowered models on trivial tasks.
That leads to the argument I find most useful for individual developers: the cheapest model is not necessarily the cheapest agent. Measure cost per completed task, not cost per million tokens. A cheap model that needs four retries can cost more than a strong model that finishes in one pass.
Model Economics
Lesson #1 — Route Work, Not Everything, to the Best Model
Uber does not point its most expensive model at every request. It picks models against workload benchmarks and a Pareto frontier over quality, reliability, latency, and cost. The main model handles decomposition, planning, evaluation, and hard decisions. Cheaper subagents do repo search, file inspection, mechanical edits, running tests, and well-scoped implementation. Uber calls the subagent default model selection one of the most important cost levers, and it makes sense: subagents run far more often than the main model does.
What this means for Claude Code / Codex users
Use the frontier model only where reasoning is actually valuable:
- Architectural decisions and API design
- Debugging with ambiguous failures
- Evaluating an implementation before accepting it
Use a cheaper model for:
- grep-style search and repo exploration
- Repetitive test runs
- Renames and formatting
- Doc cleanup
- Straightforward refactors
Do not make the strongest reasoning model the universal default. Many harnesses let you set a different model for the main agent and for subagents. That single setting is one of the easiest cost wins available today.
Context Economics
Lesson #2 — Context Is Often More Expensive Than Generation
Every request can re-carry the conversation history, project instructions, tool definitions, prior tool results, and repo context. When those are large, generation is cheap relative to the fixed cost of shipping the context on each turn.
Uber’s choices here are workload-specific, not universal recommendations: automatic context compaction around 400K tokens even on 1M-context models, and Medium reasoning effort as the default for many interactive workflows. Uber reports these as its own engineering decisions.
The general lesson for the rest of us: large context windows are capacity, not a target. Just because the model accepts 1M tokens does not mean you should feed it 1M tokens.
Personal-agent context bloat looks like this:
- One huge AGENTS.md file stuffed with everything
- Dozens of MCP servers loaded in every session
- Feeding the same full docs into each turn
- Dumping large logs into the conversation
- Carrying obsolete tool output for 20 turns
- One giant all-day session that never restarts
A personal context checklist
- Start a clean session when the context is stale
- Keep project instructions concise and scoped
- Summarize large logs before pasting them
- Avoid loading tools you are not using
- Compact strategically instead of waiting for the agent to struggle
- Keep reusable knowledge outside the transcript, in files the agent reads on demand
Lesson #3 — MCP Can Quietly Become a Token Tax
This is the lesson that surprised me most, because MCP is sold as a way to add capability, not a way to add cost. Traditional MCP loading preloads every tool schema into context. Each tool costs tokens for its name, description, input schema, and parameter descriptions. Uber measured roughly 50K to 70K tokens of schema overhead at session initialization when more than 100 tools were installed.
Session initialization with 100+ MCP tools (traditional loading)tool schemas preloaded into context -> ~50K-70K tokens (Uber measurement)# before the developer types a single promptUber’s fix is a unified MCP gateway that exposes tools as CLI commands, resolves them dynamically, and lets the agent search for and load only the tools the current job needs.
| Strategy | Context cost | Scalability |
|---|---|---|
| Load every MCP tool | High | Poor |
| Tool search | Low | Good |
| CLI / on-demand loading | Very low | Excellent |
What individual developers should do
- Bad: every MCP server enabled in every session
- Better: enable MCP servers per project or per task
- Best: lazy loading, tool search, CLI wrappers, and skills that invoke tools only when needed
The memorable line I will keep from this section: if your client preloads MCP tool schemas, a server can cost tokens even when the agent never calls its tools.
Lesson #7 — Prompt Caching Is an Economic Problem, Not Just a Feature
Prompt caching looks like a pure win, but Uber treats it as a trade-off between cache read cost, cache write premium, session idle time, and cache TTL. It reports shifting its primary interactive workflow to a longer cache TTL because engineers leave sessions idle, while short-lived subagents kept shorter caching behavior.
I will not repeat provider-specific numbers here, because pricing changes and what is optimal for one provider is not optimal for another. The reusable idea is to measure the average time between your turns and compare it with the cache TTL and pricing, then choose accordingly. Blindly maximizing TTL is not automatically cheapest — a session that resumes right after the cache expires can cost more than one that was compacted and restarted.
Tool-Calling Economics
Lesson #4 — Code-Mode Beats Chatty Tool Calling
The chatty pattern is one LLM turn per operation: the model calls a tool, gets a result, calls again, polls, gets another result. Each round trip occupies expensive model context with machine-to-machine chatter.
Chatty pattern (expensive)LLM -> tool call -> result -> LLM -> poll -> result -> LLM -> ...
Code-mode pattern (cheaper)LLM writes one Python / shell scriptscript loops and batches the deterministic workcompact summarized result returns to the modelUber reports more than 50% token reduction for several simple SQL workflows with code-mode, and says bulk workflows can save substantially more. I will not overstate the number; the principle is what matters: use deterministic code for deterministic loops.
A personal equivalent that needs none of Uber’s infrastructure:
# Better than asking the agent to inspect 100 files individually:rg -l "TODO|FIXME|DeprecatedAPI" src/ | head -40# or a short Python script that scans and prints only the matching subsetWhen I want to know which files still reference a deprecated API, one ripgrep command beats asking the agent to read files one by one. The result comes back as a short list instead of dozens of full-file reads in context.
Grounding and Reuse
Lesson #5 — Grounding Can Save More Money Than Choosing a Cheaper Model
Uber built an AI Context Graph with roughly 24 million nodes and 80 million edges, pulling from 30+ internal systems that connect services, teams, incidents, PRs, architecture docs, deployments, datasets, and usage.
The demo number is the one that convinced me. With graph grounding, a representative investigation took 38 seconds and reached a correct answer. Without it, the same task took over 20 minutes, involved multiple searches, subagents, and errors, and ended at an incorrect conclusion.
The deep lesson: an agent that knows where to look is cheaper than an agent that searches intelligently for 20 minutes. Search is not free — each failed search burns turns and tokens.
A poor man’s Context Graph
You do not need a graph database to get most of the benefit. A lightweight version is:
- AGENTS.md or CLAUDE.md that tells the agent where things live
- A repo architecture doc and docs/index.md
- ADRs and READMEs
- Symbol and code search, ripgrep, git history
- An issue tracker
- A small project-knowledge Markdown file
Even a short, well-maintained repository map can prevent a surprising amount of blind exploration. A few kilobytes of concise guidance may already be useful in many projects, but treat that as a practical rule of thumb, not an Uber recommendation. That is grounding without a single node or edge.
Lesson #6 — Skills Are More Valuable Than Prompts
Uber’s 3,600+ skills and 30K+ daily executions sound impressive, but the number is not the point. A skill encodes a tool sequence, repo knowledge, constraints, expected outputs, known failure modes, and evaluation criteria. Without a skill, the agent rediscovers the whole workflow every single time.
Compare a prompt with a skill:
- Prompt: “Please review this PR.”
- Skill: fetch the diff, classify changed subsystems, run checks, inspect risky patterns, summarize findings, format the review.
Skills cut exploration, repeated prompts, wrong tool selection, retries, context size, and human correction. The same request becomes more reliable and cheaper once the workflow is codified.
A realistic personal skill library
Do not try to build 3,600 skills. Ten to thirty high-value, reusable workflows are enough:
- Run the tests correctly
- Review a PR
- Investigate a production error
- Update dependencies
- Create a release
- Write migrations
- Add an API endpoint
- Security-sensitive review
- Generate docs
- Repo build commands
The line I will remember: ten excellent skills are more useful than hundreds of vague prompts.
Measurement and Managed Agents
Lesson #8 — Make Agent Cost Visible
Uber tracks live cost counters and session analytics to catch anti-patterns: expensive models on easy workflows, context bloat, large MCP payloads, cache expiration, and excessive init instructions. The behavioral insight is that developers change behavior when cost is visible.
“This debugging session has already consumed $8” beats “Claude seems to be working.” Seeing the number changes how long you let an agent wander.
At a personal scale, track session duration, token usage, model used, retries, approximate cost, and task outcome. Then prefer cost per successful task over tokens per request. A session that spent $1 and finished the job beats one that spent $0.20 and needed three follow-ups.
The Most Important Shift: Interactive Agents to Managed Agents
Seen together, the eight lessons describe a maturity path:
L1 Manual prompting -> L2 Persistent project instructions -> L3 Reusable skills -> L4 Specialized subagents -> L5 Managed agents responding to triggersPersonal trigger examples for L5 without any corporate platform:
- PR opened -> review agent
- CI failure -> investigation agent
- Dependency update -> test and patch agent
- Bug report -> reproduce and locate agent
- Release tag -> changelog and validation agent
Humans stay in the loop for review, escalation, and high-risk decisions. Nothing in Uber’s post implies fully unsupervised production deployment, and I am not recommending it either.
How an Individual Developer Can Apply Uber’s Ideas This Weekend
Every Uber-scale idea maps to something a single developer can do with existing tools:
| Uber-scale idea | Personal version |
|---|---|
| AI Context Graph | repository map + AGENTS.md + code search |
| 3,600 skills | 10-30 reusable project skills |
| MCP gateway | enable tools only when needed |
| Dynamic model routing | strong main model + cheaper subagents |
| Code-mode | shell/Python scripts for repetitive tool work |
| Cost dashboard | session/token/cost logging |
| Managed agents | GitHub/CI-triggered workflows |
| Benchmarks | repeatable tasks from your real projects |
Here is a seven-step plan that is tool-agnostic and needs no Uber internal infrastructure:
- Audit which tools and MCP servers are enabled in your sessions
- List your top 10 repeated agent tasks
- Turn them into skills
- Separate planning vs execution models where your tool supports it
- Create a lightweight repository map
- Replace repetitive tool loops with scripts
- Track cost per successful task for one week
Example: Why a Cheap Search Task Can Become an Expensive Agent Session
Consider a common personal-development task: find the source of a deprecated API call and propose a safe replacement. The expensive version is often expensive for system reasons, not because the task itself is hard.
Before:
Frontier model for every step+ many MCP servers loaded up front+ large schema/context payload+ blind repository exploration+ dozens of small tool calls+ repeated retries after weak search resultsAfter:
Small repository map+ task-specific tools only+ cheaper search/execution subagent+ one rg/Python batch for deterministic scanning+ frontier model only for final diagnosis and decisionThe second workflow is not cheaper merely because one model has a lower token price. It is cheaper because the system creates fewer expensive model interactions, sends less repeated context, and gives the reasoning model better evidence. That is the personal-scale version of Uber’s cost equation.
A Personal AI Agent Cost Equation
Your monthly cost follows the same shape as Uber’s, only smaller:
Monthly AI Cost ~=Sessions x Turns per Sessionx Requests per Turn x Tokens per Request x Model PriceWhen a session feels wasteful, ask five diagnostic questions:
- Am I using an expensive model for this task?
- Why are there so many turns?
- Am I re-sending context the agent already has?
- Are tool schemas or large tool results inflating every request?
- Am I making the agent search for information I could have provided upfront?
The symptom table is a fast way to find the fix:
| Symptom | Likely cause | Fix |
|---|---|---|
| Session gets slower over time | context bloat | compact/restart |
| Huge first request | MCP/tool schemas | lazy-load tools |
| Many tiny tool calls | chatty workflow | code-mode/script |
| Expensive simple jobs | poor routing | cheaper subagent |
| Agent searches endlessly | weak grounding | repository map/context |
| Repeated corrections | missing skill/instructions | codify workflow |
What You Should NOT Copy From Uber
Individuals do not need a 24-million-node graph, a thousand MCP servers, centralized authorization gateways, thousands of skills, corporate spend tiers, or enterprise dashboards. Those exist because Uber operates at a scale where coordination cost dominates.
Copy the principles instead: route models intelligently, minimize unnecessary context, load tools on demand, script repetitive operations, ground agents before execution, turn recurring workflows into skills, and measure cost per completed outcome.
The signature line: copy Uber’s economics, not Uber’s infrastructure.
The Broader Lesson for Claude Code and Codex Users
The industry question is shifting from “Which model is smartest?” to “Which agent system completes this task reliably at the lowest total cost?”
The emerging stack is Model -> Harness -> Skills -> Context -> Tools -> Subagents -> Evaluation. The model is one component. A well-designed harness can make a cheaper model more effective than its raw model ranking suggests. Uber’s results show why system-level optimization can matter as much as model choice.
This is why docs.bswen.com keeps covering agent harnesses, agent skills, MCP, context engineering, and model routing: those are the levers individual developers control. The cheapest Chinese or open-weight model changes the price per token, but context hygiene, tool loading, and routing change how many tokens and retries a task needs in the first place.
FAQ
What percentage of Uber pull requests use AI agents? More than 70% are attributed to local or cloud agents. That does not mean 70% of code is written fully autonomously — humans still review and decide.
How many AI agent skills does Uber have? More than 3,600, with over 30,000 skill executions per day.
How did Uber reduce AI agent cost? Uber attacked several terms in the cost equation at once: model selection and cheaper subagents reduced price per token; compaction, caching, and MCP optimization reduced context cost; code-mode reduced model-tool round trips; grounding and skills reduced blind search and retries; and live cost visibility helped engineers spot anti-patterns.
What is Uber’s AI Context Graph? A grounding system with about 24 million nodes and 80 million edges built from 30+ internal systems.
Why can MCP increase token usage? Some MCP clients preload tool names, descriptions, and JSON schemas into model context at session initialization. Uber reported roughly 50K–70K tokens of schema overhead with 100+ installed tools. Lazy loading, tool search, or CLI-style access can reduce that fixed context cost.
What is code-mode for AI agents? Batching deterministic tool operations in code instead of spending one LLM turn per tool call.
Are Uber’s techniques useful for individual developers? Yes, but the personal version is much smaller. A concise repository map, 10–30 useful skills, task-specific tool loading, cheap subagents where supported, scripts for deterministic loops, and simple session-cost tracking capture much of the method without copying Uber’s infrastructure.
How can I reduce Claude Code or Codex agent costs? Start by reducing wasted turns and context before chasing the cheapest model. Audit MCP/tool loading, keep project instructions concise, use scripts for repetitive operations, route well-scoped work to cheaper models where your harness supports it, and measure cost per successful task rather than tokens alone.
Should every coding task use the strongest model? No. Route by task: strong models for planning and hard reasoning, cheaper models for search, edits, and well-scoped work.
Summary
Uber’s real achievement is not simply getting agents into more than 70% of PRs. It is making rapidly increasing agent usage economically manageable by optimizing the whole system around the model.
For individual developers, the takeaway is simpler: use better grounding, reusable skills, selective tools, scripts for deterministic work, and strong models only where their reasoning is valuable. Copy Uber’s economics, not Uber’s infrastructure.
The next step in AI coding is not using agents more. It is engineering the system around them so each successful task requires less model intelligence, fewer tokens, and fewer retries.
Final Words + More Resources
My intention with this article was to help others share my knowledge and experience. If you want to contact me, you can contact by email: Email me
Here are also the most important links from this article along with some further resources that will help you in this scope:
Oh, and if you found these resources useful, don’t forget to support me by starring the repo on GitHub!
Comments