From Shubhi K | Product & Market Analysis
The Same AI Agent Task Can Burn 30x the Tokens. Your Budget Has to Survive It
On this page
Run the same AI coding agent on the same task four times and the token bill can differ by up to 30x. That is the headline finding of a 2026 study of 500 real software tasks. AI agent costs are therefore a distribution, not a price, and any budget, contract or pricing model built on an average will be wrong in the tail.
Key takeaways
- Identical agent runs are not identical bills. A study of 8 models on 500 SWE-bench Verified tasks found repeat runs of one task differed by up to 30x in total tokens, with the most expensive run averaging about 2x the cheapest.
- Input tokens, not output, drive agent cost. Each turn re-sends the growing conversation, so cache-read input is the largest token category in every phase of a run, and cost grows faster than the number of steps.
- Spending more tokens did not buy more accuracy. The same study found accuracy peaks at intermediate cost and saturates or falls at the highest cost, which means the expensive tail is mostly waste.
- Agents cannot forecast their own spend. Frontier models predicting their own token use reached a correlation of at most 0.39 and consistently underestimated, so hard caps belong in contracts and code, not in the model's judgement.
Short answer
AI agent costs vary because each run takes a different path. Every extra step re-sends the whole conversation as input, so a run that explores, retries or re-reads files grows its bill faster than its step count. The fix is not a better estimate. It is a per-run token cap, a hard monthly budget and contract terms that assign the overage.
What the 30x agent cost study actually measured
The study is "How Do AI Agents Spend Your Money?", posted to arXiv in April 2026 and revised in October. Its 8 authors are from the University of Michigan, Stanford, UT Austin, All Hands AI, Google DeepMind and Microsoft AI. Microsoft Research lists it on its publication site, which is why some coverage calls it a Microsoft study. The lead institutions are academic.
The setup is narrow and that is its strength. The team ran the open-source OpenHands agent on all 500 tasks in SWE-bench Verified, a benchmark of real GitHub issues. Each task ran 4 independent times on each of 8 models, including Claude Sonnet 4.5, GPT-5, GPT-5.2, Kimi-K2, Qwen3-Coder and Gemini 3 Pro.
The abstract states the result plainly: "runs on the same task can differ by up to 30x in total tokens, and higher token usage does not translate into higher accuracy". Read that carefully, because it holds two numbers. The 30x is the worst case on a single task. The paper's own Figure 2 caption says the most expensive run is roughly 2x the cheapest on average.
Both numbers matter, for different people. The 2x average is what your monthly bill feels like. The 30x maximum is what one runaway job does to a fixed-price quote, and it is the number a contract has to be written around.
Where agent token usage variance comes from
A chat request is one call. An agent run is a loop: the model reads, calls a tool, reads the result, and decides again. The study measured that agentic coding consumes about 1000x more tokens than code chat or code reasoning. Variance lives inside that loop, in three places.
Context carried forward on every turn
Most agent harnesses send the full conversation history with every new call. The paper describes history being carried forward unchanged into later rounds, and finds the cost gap is driven by input tokens growing rather than by output. Each new file read, test log or error message is paid for again on every turn that follows.
That makes cost grow roughly with the square of the number of turns, not in a straight line. The table below is our own illustration of that arithmetic, not data from the study. It assumes each turn adds 8,000 tokens of new context.
| Turns in the run | Total input tokens billed | Multiple of the 20-turn run | Cost at GPT-5 rates, 90% cache hits |
|---|---|---|---|
| 20 | 1.68 million | 1x | $0.40 |
| 40 | 6.56 million | 3.9x | $1.56 |
| 80 | 25.92 million | 15.4x | $6.16 |
Working: total input = 8,000 x n(n+1)/2 for n turns. Blended input rate = 0.9 x $0.125 + 0.1 x $1.25 = $0.2375 per million, using the GPT-5 prices quoted in the paper's Appendix B.2. Output tokens excluded. Real harnesses compact or truncate history, which bends the curve down.
The point of the table is the third column. A run that takes 4x as many turns costs about 15x as much in input. You do not need anything exotic to get from a normal run to a 30x run. You need a run that wanders for longer.
Repeated reads, retries and exploration that does not converge
The paper finds high-cost runs are full of repeated file views and edits. For three of the models, around half of all file actions were repeats on a file already touched. On tasks that every model failed, the authors write that agents "continue exploring, retrying, and re-reading context, accumulating cost without progress."
This is the behaviour that turns a 2x spread into a 30x one. A failing run does not stop early. It keeps paying for context it already has, and the bill arrives whether or not the task is solved.
Model choice sets the baseline
Model choice moves the floor before any run-to-run noise. The abstract reports that Kimi-K2 and Claude Sonnet 4.5 consumed, on average, over 1.5 million more tokens per task than GPT-5. The gap held even on the 230 tasks every model solved, so it is not explained by harder problems.
Per-token price and tokens per task are separate numbers. A model that is cheaper per million tokens can still cost more per task if it takes longer paths. That is the same trap covered in why cheaper tokens have not produced smaller AI bills.
| Source | What the study found | Control that contains it |
|---|---|---|
| Context re-sent each turn | Input tokens, mostly cache reads, drive cost in every phase | Compaction, context resets between tasks, prompt caching |
| Repeated file reads and retries | Concentrated in high-cost runs, about 50% of file actions for 3 models | Per-run turn limit and token cap |
| Non-converging exploration on hard tasks | Failed runs keep spending without progress | Early stop on no progress, human escalation |
| Model choice | 1.5 million more tokens per task on average for two models versus GPT-5 | Measure tokens per task, not price per token, before choosing |
Why agent cost forecasting fails at the task level
The natural fix is to ask the agent how much a task will cost before it starts. The study tested exactly that. It asked each model to predict its own token use, 3 times per model, across the same 500 tasks.
The best result was a correlation of 0.39, for output tokens with Sonnet 4.5. The paper adds that models "consistently underestimate the tokens they need", and the bias is worst for input tokens, which is where the money is. A forecast that is weakly correlated and biased low is worse than no forecast, because it creates false confidence.
Task difficulty is not a reliable proxy either. The study found 6.7% of tasks rated under 15 minutes for a human used more tokens than the average task rated over an hour. The Stanford Digital Economy Lab's write-up put it bluntly: "Agents are not capable of predicting their own token costs. This is the fundamental bottleneck for result-based pricing for agents."
What token variance does to AI pricing models
Every pricing model decides who absorbs variance. The study does not change which models exist. It changes how much risk each one hides, and that is the question buyers should ask first.
Per-token pricing puts all the variance on you
Pay-as-you-go API billing passes every token straight through. You get a fair price per unit and no protection against the tail. The GPT-5 rates in the paper's appendix show why the unit matters: output at $10 per million is 80x the price of a cached input token. Cache reads still dominate the bill, because there are so many of them.
Per-task pricing moves the variance to the vendor
A flat price per task shifts the tail onto the seller. That only works if the vendor can absorb a 30x run inside a margin built on a 2x average. Vendors who cannot will respond with tighter limits, quiet step caps or price rises. The meters behind those per-task prices are compared in the breakdown of agent task pricing across three vendor meters.
Per-outcome pricing adds a second uncertainty
Outcome pricing charges only when the agent succeeds. The study's finding that cost and accuracy are only loosely linked means the vendor carries both the failed runs and the expensive successful ones. My view is that outcome pricing will survive mostly where tasks are short and bounded, like support resolutions, and struggle for open-ended engineering work. The clauses that make it workable are covered in the outcome pricing contract clauses guide.
Seat plans with a usage allowance split the difference. The vendor absorbs variance up to the allowance and you absorb it beyond. Whichever model you sign, ask for the overage rate and the behaviour at exhaustion in writing before the first invoice.
Contracting around token usage variance
You cannot negotiate the variance away. You can decide in writing who pays for it and where the ceiling sits. Three terms do most of the work.
First, a per-run ceiling. Ask the vendor to commit that no single task will bill above a stated token or dollar amount, and that runs hitting the ceiling stop and escalate rather than continue. If they refuse, that tells you they have not measured their own tail.
Second, a monthly hard budget with defined behaviour at the limit. OpenAI's API documentation is a useful model of honesty here. Its hard spend limits return a 429 error once reached, and the page states that "recorded spend can slightly exceed the configured amount" because enforcement is not instantaneous. Your contract should say who pays that overshoot.
Third, an overage and true-up clause. If usage exceeds the commitment, the rate should be fixed in advance, not set at renewal. Wider buyer concessions on usage contracts are covered in the usage-based pricing concessions guide.
| Weak version | Version that works |
|---|---|
| "Usage billed at standard rates" | Rates fixed for the term, with a per-run ceiling and stop-and-escalate behaviour |
| "Customer may set usage alerts" | Hard monthly cap enforced by the vendor, overshoot above the cap credited back |
| "Fair use applies" | Fair use defined in tokens or tasks per month, with 30 days notice before any change |
| Average cost per task quoted in the proposal | Median and 95th percentile cost per task from a pilot on your own workload |
Engineering controls for LLM cost control
If you run agents on your own API keys, you are the vendor in the section above. The controls are the same ideas expressed in configuration. Both major providers already ship the budget layer.
Anthropic's Console lets you set workspace spend limits that sit below the organisation limit, and its documentation states that organisation-wide limits "always apply, even if workspace limits add up to more". Give each agent workload its own workspace or project so one runaway job cannot drain the budget for everything else.
Inside the agent, cap turns and tokens per run. Clear context between unrelated tasks. Claude Code's own cost guide says stale context "wastes tokens on every subsequent message", and that agent teams use about 7x more tokens than standard sessions. Anthropic's engineering team made the same point in 2025, writing that early versions of its research agent made errors "like spawning 50 subagents for simple queries".
Finally, measure the distribution, not the mean. Claude Code's documentation reports an enterprise average of about $13 per developer per active day, with 90% of users below $30. That puts the 90th percentile ceiling at 2.3x the average, and your own workload will have its own ratio. A full cost model beyond inference is laid out in the enterprise agent cost model.
Where this argument is weakest
The 30x figure is real, sourced and easy to misuse. Here is where the case in this post is thinner than the headline suggests.
One benchmark, one harness
Every number comes from one agent framework, OpenHands, on one benchmark of Python repository fixes. The authors name their model set as the key limitation and do not flag the single harness. Commercial agents with aggressive compaction, step limits or better retrieval may show far less variance. I would not assume the 30x transfers to your support bot.
The 30x is a maximum, and it is fragile
The paper reports 30x in the abstract and about 2x as the average gap in its figure caption, without reconciling the two. A per-task maximum over 4 runs on 500 tasks is an extreme value, and extremes are sensitive to sample size. The paper is also a preprint, not yet peer reviewed, and it reports the agentic multiplier as 1000x, 3500x and 1200x in different places.
The strongest counter-case is that variance is a solvable engineering problem, not a property of agents. If harness design closes most of the gap, the contract terms in this post become insurance you rarely claim. I think that is likely for narrow tasks and unlikely for open-ended ones within the next year. Buy the insurance anyway, because it is cheap to write and expensive to need.
Frequently asked questions
Why do AI agent costs vary so much for the same task?
Each run takes a different path through the task. Agents re-send their growing conversation history on every turn, so a run that reads more files, retries more often or explores longer pays for that context again and again. A 2026 study of 500 coding tasks found repeat runs differed by up to 30x in total tokens, with input tokens driving the cost.
Do more tokens make an AI agent more accurate?
Not beyond a point. The 2026 study by Bai and colleagues found accuracy often peaks at intermediate cost and saturates at higher cost, with some evidence it falls at the highest cost levels. High-cost runs were full of repeated file views and edits. In practice the most expensive runs are often the ones that are stuck, not the ones doing better work.
Can an AI agent estimate its own token cost before a task?
Not reliably. When frontier models were asked to predict their own token use across 500 tasks, the best correlation with actual use was 0.39, and models consistently underestimated, especially for input tokens. Treat any model-generated cost estimate as a rough signal at best. Enforce budgets with hard limits in your billing settings and agent configuration instead.
How do I set a spending cap on AI agent usage?
Use the provider's hard limits, not alerts. OpenAI's API supports hard spend limits at organisation and project level that return a 429 error once reached. Anthropic's Console supports workspace spend limits below the organisation limit. Inside the agent, cap turns and tokens per run, and separate workloads into their own projects or workspaces so one job cannot exhaust the shared budget.
Is per-task or per-token pricing better for AI agents?
It depends on who should carry the variance. Per-token pricing is transparent but leaves the full tail with you. Per-task pricing moves the tail to the vendor, who may respond with step limits or price rises. Per-task suits short, bounded tasks. For open-ended agent work, per-token pricing with hard caps is usually easier to audit and to forecast.
What contract terms protect against AI agent cost overruns?
Ask for 3 terms in writing. A per-run ceiling that stops and escalates rather than continues. A monthly hard cap enforced by the vendor, with any overshoot above it credited back. A fixed overage rate for the contract term. Also ask for median and 95th percentile cost per task from a pilot on your own workload, not an average.
Where to start this week
Pull the last 30 days of agent usage and compute cost per task at the median and the 95th percentile. If the ratio between them is above 3, you have a tail problem that no average-based budget will catch, and a per-run cap is your first fix.
Then open your provider console and turn on a hard spend limit for each agent workload, set at about 1.5x last month's spend. An agent that stops at a limit is an incident you can see. An agent that keeps going is a bill you find out about later. These figures were last verified on 31 October 2026.
Related on agent cost
For the vendor tools that try to forecast this spend, read the AI spend forecasting tools review. For the discounts that bend the input curve, see prompt caching and batch discount rates.
References
- Bai, Huang, Wang, Sun, Mihalcea, Brynjolfsson, Pentland and Pei, How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks, arXiv 2604.22750, v1 24 April 2026, v3 2 October 2026. Used for the 30x and 2x spreads, the 1000x multiplier, input-token dominance, repeated file actions, the 1.5 million token model gap, the 0.39 correlation and GPT-5 prices.
- Microsoft Research, publication listing for the same paper, April 2026. Used to confirm the abstract and author list.
- Stanford Digital Economy Lab, How are AI agents spending your tokens?, by Matty Smith, 5 May 2026. Used for the quoted line on result-based pricing.
- Anthropic, Claude Code: manage costs effectively, retrieved 31 October 2026. Used for the $13 average, $30 90th percentile, 7x agent team figure and context advice.
- Anthropic Engineering, How we built our multi-agent research system, 13 June 2025. Used for the 50 subagents quote.
- OpenAI, Spend limits, API documentation, retrieved 31 October 2026. Used for hard limit behaviour and the overshoot statement.
- Anthropic, Workspaces, Claude platform documentation, retrieved 31 October 2026. Used for workspace spend limit rules.
Weakest point in the source base: every variance figure comes from a single preprint using one agent harness on one benchmark, and its 30x maximum and 2x average are not reconciled in the paper. Claude Code cost figures are vendor-reported with no sample size. The turn-count table and curve are illustrative arithmetic, not measurements.
Related reading