Uber Capped AI Coding Spend at $1,500 an Engineer. How to Set Your AI Budget

Uber spent its 2026 AI coding budget in about four months, then capped each engineer at $1,500 a month per agentic coding tool. That cap sits roughly 6 to 10 times above the average Claude Code bill Anthropic publishes. So the useful lesson for AI budgeting is not the number. It is that Uber had no exception path and no output metric until the money ran out.

Who this is for: the head of engineering or delivery who owns the AI tools line and has to defend it to finance.

What Uber actually did with its AI coding budget

Strip the coverage back to what was reported first-hand, and the Uber story is short. Much of the retelling is wrong in small ways that matter if you copy the policy.

In April 2026, Uber CTO Praveen Neppalli Naga told The Information that the company had used up its 2026 AI coding budget within roughly the first four months of the year. CFO Dive summarised that interview on 29 May. Naga said he was going "back to the drawing board" on how spend was allotted, according to Fortune's account of the interview.

The overrun followed a deliberate push. Uber had encouraged staff to use AI tools "as much as possible" and ranked internal usage on leaderboards, according to The Information as cited by TechCrunch. The incentive did exactly what it said.

On 2 June 2026, TechCrunch reported, citing Bloomberg, that Uber had set a monthly $1,500 cap per employee and per agentic coding tool. Each employee can track usage on an internal dashboard. In certain cases the cap can be exceeded with permission, the company said. No formal approval process was described.

On 5 August, Naga posted on X that Uber had quadrupled the number of employees using frontier AI tools while bringing down its cost per token. Fortune listed the levers he named: better prompt caching, a changed default model, testing new models for efficiency, and showing engineers their usage and cost per hour.

Costs fell, he wrote, "not because we've restricted access, but because we've treated efficiency as an engineering problem rather than a budget problem". It is the strongest argument against the cap his own company introduced two months earlier.

Where the reported Uber AI budget numbers conflict

Most coverage of the Uber AI budget restates two or three original reports. Traced back, several figures disagree, and one looks borrowed from elsewhere.

Uber AI coding spend: what each source says, and where they disagree.

Figure	Version A	Version B	Our read
Which budget ran out	"Entire annual AI budget" (TechCrunch)	"Claude Code budget for 2026" (Business Insider); "2026 AI coding budget" (CFO Dive)	These are three different scopes. The coding-tools reading is the best supported.
Size of the budget	Not disclosed anywhere	Not disclosed anywhere	Nobody outside Uber knows whether "four months" means a small budget or large spend.
Average spend per engineer	$150 to $250 a month (Forbes, via CFO Dive)	$150 to $250 a month (Anthropic's public docs average)	Identical to the vendor's published average. Treat as unconfirmed for Uber.
Heavy-user spend	Up to $2,000 a month (Forbes, via CFO Dive)	$500 to $2,000 a month (secondary outlets)	The $2,000 ceiling is consistent. The $500 floor is untraced.
Share of code from AI	About 70% of committed code (Forbes, via CFO Dive)	About 11% of live backend code updates (secondary outlets)	Different measures, likely both partly true. Neither traced to Uber directly.

We could not open Bloomberg, The Information or Forbes directly. Every Uber figure above reaches you through at least one intermediary, and the table names it.

The per-engineer figure deserves the most suspicion. The $150 to $250 monthly average attributed to Uber matches, to the dollar, the average Anthropic publishes for enterprise Claude Code deployments. That could be coincidence, or a reporter quoting the vendor's docs that aggregators then attached to Uber.

I would not build a budget on it either way. Use the vendor figure and label it as the vendor's, or better, measure your own.

The budget size is the missing denominator too. "Spent the budget in four months" sounds alarming. Without the budget figure, it tells you only that spend ran about 3 times faster than plan. That is a forecasting failure as much as a spending failure.

What a $1,500 AI spend cap really constrains

The cap headline makes it sound like rationing. Run the arithmetic against the vendor's own usage data and it looks more like a guardrail for a small tail.

Anthropic's Claude Code cost page says enterprise deployments average around $13 per developer per active day, with 90% of users below $30 per active day. If you assume 21 working days in a month, a user at that 90th-percentile daily ceiling spends about $630. That is our arithmetic, not Anthropic's.

So a $1,500 cap is more than double what 9 in 10 users would hit working every day at the high end. It binds the reported heavy users near $2,000 and never touches the median engineer.

The cap also applies per tool. An engineer with Claude Code, Cursor and a third agent can, in principle, spend $4,500 a month before anyone is asked for permission. Cap per person across tools instead. Per-tool caps reward sprawl and hide the total from the manager who should see it.

Anthropic's published average did not always say $13. On 15 April 2026 it more than doubled the public estimate from $6 per active day, Business Insider reported, because Opus 4.7 had become Claude Code's primary model. Anthropic said there was no pricing change. If your budget was built on the February figure, it was half what your team would actually spend.

The transferable lesson: default-model changes move cost per seat more than any policy you write. The mechanics of why falling token prices still produce bigger invoices are covered in the breakdown of cheap tokens and rising AI bills.

The missing link between token spend and shipped output

Uber's executives were candid about the worrying part: they could see usage, not output.

COO Andrew Macdonald was blunt about it on the Rapid Response podcast in May 2026: "That link is not there yet". He added that maybe more was being shipped implicitly. But "it's very hard to draw a line" between the usage statistics and producing 25% more useful consumer features, he said, according to Business Insider.

The 25% is his hypothetical, not a measurement, but it is the right shape of claim. A budget owner needs one like it, with a real number, before the next renewal.

Outside Uber, the best public evidence comes from engineering analytics vendors, so treat it as directional. Jellyfish told TechCrunch that its heaviest token users were about twice as productive but spent 10 times the tokens, and that per-developer consumption rose about 18.6 times in nine months.

Jellyfish's head of research, Nicholas Arcolano, drew the budgeting conclusion directly: "The best ROI comes from moving the broad middle from low to moderate usage, not pushing heavy users higher," he told TechCrunch. If that holds for your team, a tail cap plus a push on the middle is the correct shape. A leaderboard is the opposite shape.

Meta's Adam Mosseri put the trap plainly on Lenny's Podcast: "It's not that hard to build a token incinerator, and that doesn't create a lot of value," as TechCrunch reported in July. Meta also shut down its own internal token-spend leaderboard. Any metric you can raise by spending more is evidence of spending, not value.

Real evidence is slower to collect, which is why most teams skip it. Measuring output honestly also runs into the review queue, as the post on why code review became the AI bottleneck lays out.

An AI budgeting method in five steps

Here is the method I would use for an engineering org of 20 to 500 people. It keeps Uber's visible per-seat limit and adds what Uber appears to have built only after the money ran out.

Step 1: Measure a pilot before you set any number

Anthropic's own docs advise starting with a small pilot group to establish a baseline before wider rollout. Run 4 to 6 weeks with 10 to 20 engineers across seniority, then record the median, the 90th percentile and the maximum monthly cost per person.

Your own 90th percentile beats any vendor average, because it reflects your codebase, default model and habits.

Step 2: Set the base allowance at your 90th percentile

The base allowance is what any engineer can spend without asking. Set it at your pilot's 90th percentile, rounded up. Most people never notice it, and the 10% who hit it are the people you want to talk to.

Uber's $1,500 is far above any plausible 90th percentile. That never blocks anyone, but it teaches you nothing about who your heavy users are and why.

Step 3: Fund an exception reserve explicitly

Put 15% to 25% of the base allowance pool into a separate exception line. Skip this and overruns land on the main budget, discovered at quarter end. A named reserve turns "we overspent" into "we used the reserve, and here is what it bought".

Step 4: Add an org-level ceiling with an early warning

Per-seat limits do not add up to a budget on their own. Set a monthly org ceiling at the sum of base plus reserve, with an alert at 70% by mid-month. That alert is what Uber needed in February.

Step 5: Fix the efficiency levers before you tighten anything

Naga's list is a good checklist: caching, default model, model evaluation and per-engineer cost visibility. Changing the default model alone can halve or double cost per seat, as Anthropic's own April revision shows. The trade-offs of routing work to cheaper models are covered in the analysis of model routing and the quality gap.

Worked example: monthly AI coding budget for a 100-engineer team (illustrative).

Line	Rule	Monthly amount
Base allowance	Pilot 90th percentile of $300, times 100 seats.	$30,000
Exception reserve	20% of the base pool.	$6,000
Experiment pool	Fixed, for new tools and agent trials.	$4,000
Org ceiling	Sum of the above, alert at 70%.	$40,000
Comparison: Uber-style cap only	$1,500 times 100 seats, one tool, worst case.	$150,000

Every figure in this table is illustrative. The $300 percentile is a placeholder for your own pilot result, not a benchmark. The last row is maximum exposure, not expected spend, and it doubles with a second tool.

The last row is not a forecast of Uber's spend. It shows that a cap alone gives finance a worst case 3.75 times your planned budget, the kind of number that produces a mid-year freeze.

Exception paths that do not leak

Uber's policy says the cap "can be exceeded with permission". Design that part carefully: a vague exception path either blocks everyone or approves everyone within a month.

Make the first exception cheap. The first request should take one sentence and one click. Approve it automatically for the rest of the month, with a note to the manager. Your heaviest users are often your most productive, per the Jellyfish data, and a slow approval costs more in lost hours than the tokens do.

Make the renewal expensive. A second consecutive month above the allowance needs evidence. Ask for output that someone else can check.

Evidence for renewing an AI spend exception: weak versus usable.

Weak evidence	Why it fails	Usable evidence instead
Tokens consumed or leaderboard rank	Rises with spend by definition	Merged changes that passed review, per month, against the engineer's own prior baseline.
Lines of code accepted	Rewards verbosity and churn	Rework rate: share of merged AI-assisted changes reverted or rewritten within 30 days.
Self-reported hours saved	Unverifiable and generous	Cycle time on a named ticket class, before and after.
"Working on a hard migration"	True, and unbounded	A stated end date and a deliverable, after which the exception lapses.

Let exceptions expire by default. Every exception should lapse at month end unless renewed. Standing exceptions are how an allowance quietly becomes a floor. Per-tool caps leak worst here, because each tool gets its own.

The same logic applies to projects: a pilot that cannot show output after two renewal cycles belongs in the framework from the post on setting kill criteria for AI projects.

What your AI coding tools can enforce today

A policy you cannot enforce is a memo. Controls differ by plan, and the differences decide whether a per-person cap is even possible.

Claude Code

On Claude for Teams or Enterprise, each seat draws on a usage allowance that resets on rolling five-hour and weekly windows. Admins who switch on usage credits can then set spend limits at the organization, group or individual member level, with a daily per-user spend report. On the API Console, the control is a workspace spend limit across all Claude Code use.

One gap matters for large firms. If you run Claude Code through Amazon Bedrock, Google Cloud or Microsoft Foundry, Anthropic's dashboards do not see the usage. Your cloud budget controls, OpenTelemetry or an LLM gateway have to do the enforcing. Plan-level differences are covered in the guide to Claude plans and API rates.

Cursor

Cursor's spend-limit documentation draws a sharp plan line. Teams plans get one team-level limit, and when it is reached, all members consuming on-demand usage lose access to AI features. Member-level limits are an Enterprise feature. Cursor also notes enforcement is not instant, so usage can briefly exceed a limit.

On a Teams plan, then, you cannot copy Uber's per-person design. One heavy user can exhaust the shared ceiling for everyone.

Per-person spend controls by tool and plan, October 2026.

Setup	Per-person cap	Org ceiling	Per-user reporting
Claude Team or Enterprise	Yes, member or group level	Yes	Daily spend report, CSV.
Claude Console (API)	No, workspace level only	Yes, workspace spend limit	Console dashboard, Analytics API.
Claude via Bedrock, Google Cloud or Foundry	Only via a gateway	Cloud budget controls	OpenTelemetry or gateway.
Cursor Teams	No	Yes, team-level limit	Admin dashboard.
Cursor Enterprise	Yes, member and group overrides	Yes	Admin dashboard, Admin API.

Compiled from Anthropic's Claude Code cost documentation and Cursor's spend-limit documentation, both checked October 2026. Vendor controls change often; verify in your own admin console before writing policy around them.

Where the case for AI spend caps is weakest

I have argued for a capped base allowance with a funded exception path. Here is where that argument is most exposed.

Uber's own CTO credits efficiency, not the cap

Naga's August post explicitly says cost per token fell without restricting access. If he is right, the cap was a holding action and the real gains came from caching and model defaults. A team that copies the cap without the engineering work gets the friction and none of the savings.

Caps can tax your best engineers

If the heaviest users really are about twice as productive, as Jellyfish reports, then any cap that slows them has a cost in output. At a fully loaded engineer cost, a few lost hours a month outweigh a few hundred dollars of tokens. A badly designed exception path turns a cap into a tax on exactly the wrong people.

The cost curve may also bend on its own. Mosseri said Meta has no per-engineer caps today and expects token prices to fall as model makers compete. He also imagined a near future where a strong engineer's token burn might equal their salary. If prices fall fast, a cap written today is too loose by spring. If agent use grows faster than prices fall, it is too tight. A cap is a guess about a curve nobody has published.

The honest limit on this whole post: nobody outside Uber knows what the budget was, so nobody knows whether the overrun was large or the plan was small. The method above stands without Uber's numbers. Hold the Uber-specific lessons loosely. Forecasting in the first place is a separate problem, covered in the review of AI spend forecasting tools.

Frequently asked questions

How to set your AI budget this month

Pull last month's per-user spend from every AI coding tool you pay for, and add it up per person, not per tool. If you cannot get that number in an afternoon, your first job is reporting, not a cap.

Then check one setting before you write any policy: the default model in each tool, and what it cost last month against the month before. Uber's biggest savings came from changes like that. Yours probably will too.

Related reading