In December 2025, Uber opened up AI coding tools to its engineering teams, Claude Code among them. To speed things along it ran an internal leaderboard ranking teams by how much AI they used. It worked. The share of its 5,000 engineers using agentic coding tools went from 32% in February to 84% by March.
By April, Uber’s entire 2026 budget for AI coding tools was gone.
Four months.
The fix was a cap: $1,500 per employee, per coding tool, per month, with a dashboard so people can see where they stand. Later, Uber’s COO was asked whether all that usage was producing more useful features for customers. His answer was that the link wasn’t there yet.
SAP retells the Uber story near the start of a white paper it published in September, A Four-Stage Framework for Controlling Enterprise AI Spend. Opening your own document with someone else’s budget blowout is a bold move, and I rather like them for it.
It’s SAP’s own playbook for AI token governance, written by its controlling function and aimed at CFOs. It looks like a finance document.
Which means a lot of architects will skip it, and they shouldn’t. The controls it recommends for AI agents live inside the agent, and they have to be designed in before it ships. Read that way, it’s an architecture brief as much as a finance one.
Why AI agents cost more when tokens are getting cheaper
A quick definition first. A token is the unit large language models charge in, roughly three quarters of an English word, counted on the way in and on the way out. Your prompt, the documents you ground the model in, the tool results it reads and the answer it writes are all tokens.
The paper makes a point early on that I hadn’t seen framed this plainly. By its numbers, token prices have fallen by about 75% since 2024. On that basis, AI bills should be shrinking.
They aren’t, because the work changed shape. A typical 2024 query was one request to one model. Around 2,000 tokens, two cents. The same task in 2026 runs through an agent that calls sub-agents, tools, retrieval and validation, and retries until it’s happy with the result. Around 500,000 tokens, $1.25.
Tokens per task up 250-fold. Price per token down 75%. You probably get a better answer. You also pay roughly sixty times more for it.
Economists call this Jevons paradox. When something gets cheaper per unit, people use so much more of it that total spend rises anyway.
Most of us have spent twenty years learning that cheaper inputs mean smaller bills. With agents it runs the other way, and you won’t see why if you only watch the price per token. You have to count tokens per task.
Most organisations can’t see what AI costs them
The paper leans on outside research rather than asking you to take SAP’s word for it, which is the right call for a vendor document.
McKinsey has 93% of respondents exceeding their AI budgets, with spend rising nearly fourfold as companies move from isolated use cases to enterprise-wide adoption. KPMG’s Q2 2026 Global AI Pulse has nearly half of organisations scaling back, delaying or pausing agent deployments because expected costs outweighed the value. Only one in three organisations has full visibility of what its AI costs to run.
Put those last two findings together and they’re uncomfortable. The stated reason for pausing wasn’t that the agents failed. It was cost outpacing value. But if two thirds of organisations can’t properly see their running costs, I’d guess plenty of those decisions were made without anyone able to show the value side at all.
What SAP found when it looked at its own AI bill
The case study in the middle is more candid than I expected.
In late April 2026, SAP’s controlling team spotted the signal and set up a dedicated AI Token Steering function. Its first consolidated projection, pulled together under time pressure before an Executive Board session, showed a triple-digit million exposure for 2026.
One meeting, and a controlling workstream became a board problem.
Three things were driving it. A small group of very heavy users, including automated agents stuck in loops they couldn’t get out of. People defaulting to the most expensive model for work a lighter one would have handled. And a pile of overlapping tools, some still generating cost long after anyone had stopped using them.
The response was token caps, model routing and tool rationalisation.
The most useful example is the Joule Work Desktop rollout. On its own it looked like extra spend. By looking at the financials and the tool estate together, SAP switched off overlapping tools, rolled Joule Work Desktop out with a daily token cap, and mitigated a double-digit million risk along the way.
SAP also tracked what the spend was producing. After rolling out AI developer tools, it recorded a mid-double-digit percentage increase in pull request merge rates. The paper’s own warning is that governance without that view risks optimising for cost at the expense of value.
A smaller bill was never the goal. Knowing which part of the bill is earning its keep is.
Token budgets, circuit breakers and cost per task
Chapter five is where the paper turns to agents, and I don’t think it flags the shift loudly enough.
Everything before it is about people using AI tools. Agentic AI, the paper says, is orders of magnitude bigger, and it quotes a Goldman Sachs forecast of a 24-fold increase in token consumption by 2030.
Then comes the number anyone scoping an agent should read twice. A single business request through a ten-step agent workflow can cost between $1.50 and $30 to resolve, with no spending limit, no visibility, and little human intervention until the invoice turns up.
That’s a twenty-fold range on one transaction. You find out which end you got at month end.
The paper names three controls for the agent layer.
Per-agent token budgets. A ceiling on each agent workflow, independent of whoever configured it. SAP’s phrasing is that an agent without a token budget is a liability without a limit.
AI circuit breakers. Something watching consumption in real time. If an agent exceeds a defined rate, or keeps consuming tokens without producing output, the breaker stops it and tells someone.
Cost-per-task measurement. Value per token measured per completed task rather than per session. An agent that solves something hard in 50,000 tokens may be worth far more than one that finishes something trivial in 5,000.
Now think about where each of those would actually sit.
Finance can decide what the budget should be. Enforcing it happens in the agent. A per-agent token budget is a limit someone has to build into the workflow. A circuit breaker sits on the retry loop. Cost per task only works if the workflow emits clear task boundaries (where a task starts, where it ends, whether it succeeded), and that only happens if someone designed it that way.
These are architecture decisions. They sit in the orchestration layer, and they need to be there before the agent goes live. Retrofitting a circuit breaker into a running agent estate is a much worse project than building one in.
So the paper needs two readers. The CFO who sets the limits, and the architect who builds them in.
What this means if you’re building agents on SAP BTP
One line in the paper stuck with me. A human power user can be coached and capped. An agent in a runaway loop has no such feedback mechanism unless one was built into the architecture from the start.
Uber’s fix is the human version of this. A monthly cap and a dashboard work because an engineer who sees the number changes what they do. An agent doesn’t check dashboards.
SAP’s three causes of runaway spend translate straight into things to check on a BTP build.
Loops first. Anyone who has built flows in SAP Integration Suite knows the retry pattern well. It’s fine when a retry costs a few milliseconds of processing. It’s a different conversation when every attempt is a model call and the failure is something retrying was never going to fix.
Retry logic is standard. Circuit breakers aren’t.
Model routing next. Plenty of steps in a typical agent workflow are classification and extraction, and they don’t need a frontier model. But in a proof of concept you reach for the best model available because you’re trying to make the demo work. Then the PoC quietly becomes production and nobody goes back to change it.
Tool sprawl is the least technical of the three, which makes it the easiest to find. How many teams in your organisation are running their own AI experiments on BTP right now? The platform team’s estimate is usually low.
One SAP-specific wrinkle: you often won’t see tokens on the bill at all. Base AI comes with the cloud subscription, and premium Joule scenarios draw down AI Units. Nothing on that invoice maps to a task unless your workflow reports one.
I should be straight about something. I have not built these controls into a production agent, and I do not know anyone who has. The paper describes what should exist. Most of us are still scoping the agents that will need it. That gap, between guidance that is already published and builds that have not started, is where the whole ecosystem is right now. It closes the moment the first invoice surprises someone.
Seven questions to ask before an agent estimate is committed
If you’re scoping an agent project, I’d want these answered before the number goes into the plan. Not after.
- What does one complete run cost, end to end, including retries?
- What’s the expected volume, and what’s the worst realistic case?
- What stops the agent if it loops, and who gets told?
- Which steps genuinely need the largest model?
- Can we measure cost per completed task, or only per session?
- Who owns this line in the budget, and do they know they own it?
- What value metric sits next to the cost metric, and who agreed it?
Most of these can’t be answered precisely up front. That’s fine. Asking them is the point. “We haven’t thought about that” is cheap to hear at scoping and expensive to hear at the first budget review.
Start with the inventory nobody wants to do
The paper closes with a 90-day plan, and the first 30 days are just an honest inventory of what’s already being consumed. That means department subscriptions, AI features embedded in SaaS products and API keys nobody mentioned, as well as whatever IT bought.
SAP’s warning is that it will be bigger and more expensive than you expect. I’d take them at their word.
One comparison I keep making. Uber spent a year’s AI coding budget in four months. SAP says its token governance model mitigated its own financial risk in under four months. Same clock, and Uber was counting too. It just counted usage, and ranked teams on it. SAP counted cost against value.
With people, you can do that counting after the fact. With agents, it has to be built in before they go live.
Sources
- SAP, A Four-Stage Framework for Controlling Enterprise AI Spend, September 2026
- SAP News Center, AI’s Finance Challenge: Managing Token Spend Without Slowing Innovation, September 2026
- SAP, SAP Business AI packages and pricing
- Forbes, Uber Burns Its 2026 AI Budget In Four Months On Claude Code, May 2026
- Fortune, Uber burned through its entire 2026 AI budget in four months. Now its COO is questioning whether it’s worth it, May 2026
- Bloomberg, Uber Caps Employee Spending on AI Tools Like Claude Code to Manage Costs, June 2026
- McKinsey, The cost of intelligence: How CIOs can manage AI demand at scale, July 2026
- KPMG, Global AI Pulse Q2 2026, June 2026