AI budgets should follow workloads, not employees
Uber burned a 12-month AI budget in 4 months and answered with a $1,500/month cap per employee per coding tool. The cap treats spend as a person problem — but spend belongs to workloads, and workloads are what to budget.
Uber's CTO disclosed this week that the company burned through its entire annual AI budget in four months. The response, per Bloomberg and TechCrunch: a $1,500 monthly cap per employee, per agentic coding tool — Claude Code, Cursor and the like — trackable on an internal dashboard, exceedable with permission.
The backstory makes it better. Uber had been encouraging staff to use AI "as much as possible", complete with internal leaderboards ranking usage. Roughly 95% of engineers now use the tools, and about 10% of the company's code is agent-generated. They built the incentive, the incentive worked, and the bill arrived. Fair enough — every platform team is living some version of this year.
It is the fix I want to argue with. A per-user cap is the payroll department's mental model applied to inference: spend attaches to a person, so ration the person. But almost nothing interesting about AI spend is true at the level of a person.
The unit of spend is the workload
Under one $1,500 cap sit three completely different things. An engineer autocompleting through the day — cheap, latency-sensitive, low stakes. An overnight agentic loop refactoring a service — expensive, async, and the whole reason you bought the tools. And somewhere, a production-critical pipeline that happens to run under a human's account because that was easiest at setup time. The cap prices all three identically, which means it rations the second and third — the highest-value work — to protect against overuse of the first.
And people respond to caps the way people always respond to caps. The practitioner version of this story, which I have now watched at more than one client: the moment individual limits land, teams start sharing accounts, routing expensive jobs through whoever has headroom this month, or burying inference inside an unrelated project's cloud budget where nobody itemizes it. The spend does not shrink — it goes dark. A platform owner who sees sudden per-user uniformity right under the cap is not looking at compliance. They are looking at shadow routing, and they have lost the telemetry that would have told them which work was worth the money.
My rule: budget the workload, not the identity. A workload has an owner, an outcome, a quality threshold, a monthly budget, and an escalation rule for the month it wants more. "Nightly refactor loop on the payments service, owned by K., $4,000/month, escalate past that with a one-line justification" is governable. "Every human gets $1,500" is not governance — it is a speed bump with reporting.
To be fair to Uber: the exceed-with-permission valve and the visible dashboard are the right instincts, and a blunt cap is a defensible tourniquet while you build the real thing. The mistake would be mistaking the tourniquet for the circulatory system.
Steal this if the cap memo is heading for your desk: before capping anyone, tag every AI-consuming job with a workload label — even a crude one. Run thirty days of spend-by-workload instead of spend-by-employee. My bet, having seen the exercise run: the top ten workloads explain most of the bill, at most a couple of them are questionable, and the per-user distribution underneath turns out to be noise. Then fund the workloads that earn it, kill the ones that don't, and let humans autocomplete in peace.
Uber capped the people because people are what the dashboard could see — build the dashboard that sees workloads, and the budget conversation becomes an investment conversation.
