Which AI Coding Model Burns the Fewest Tokens?

Ask a coding agent to fix the same bug twice and you can pay two very different amounts. Ask it in advance what the fix will cost and it will lowball you.

Both of those are now measured rather than folklore. A 2026 preprint, How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks (Bai, Huang, Wang, Sun, Mihalcea, Brynjolfsson, Pentland and Pei), ran eight frontier models across 500 SWE-bench Verified instances and logged every token. The authors are at the University of Michigan, Stanford University, All Hands AI, Google DeepMind, Microsoft AI and MIT. It is a preprint and has not been peer reviewed, so treat it as strong early evidence rather than settled fact.

The headline number, that agentic work burns about 1000 times the tokens of chat, has been widely repeated. The findings underneath it have not, and they are the ones that change which model you pick.

How many tokens does an AI coding agent use?

An agentic coding task in this study averaged 4.17 million tokens and $1.857. The same class of problem handled as multi-turn chat averaged 3.39k tokens and $0.023, and as single-turn code reasoning 1.19k tokens and $0.016.

That is roughly 1,230 times the tokens of chat and about 81 times the dollars. The gap between those two multiples is the whole story: agent tokens are cheap tokens bought in enormous volume. The input-to-output ratio tells you why. Code reasoning runs at 0.16 input tokens per output token, chat at 1.33, and agentic coding at 153.85. An agent barely writes more than a chatbot. It reads vastly more, because every round re-sends the accumulated context.

Token efficiency belongs to the model, not the task

The obvious objection to any per-model cost comparison is that the expensive models attempted harder problems. The study closes that door directly.

The authors isolated two subsets: 230 tasks every model solved, and 100 tasks every model failed. The relative ranking of token usage held on both. GPT-5 and GPT-5.2 achieved strong accuracy at low cost. Claude Sonnet 4.5, Claude Sonnet 4 and Qwen3-Coder-480B sat in a higher-cost regime. Kimi-K2 was the outlier with the highest cost and the lowest accuracy.

There is a second-order effect worth pricing in. Every model burned more tokens on the shared failure set than the shared success set, but the size of that penalty varied enormously. GPT-5 and GPT-5.2 rose by under 0.5M tokens. Kimi-K2 rose by about 2M. Models have no reliable mechanism for recognising that a task is unsolvable and stopping, so the ones that explore hardest also fail most expensively.

That matters more than the average, because failures are where budgets actually break.

The mechanism is re-reading, and it is measurable

Averages do not tell you what to change. Action counts do.

On the shared success subset the study counted how many file views and file modifications each model performed, and how many of those were repeats on a file the model had already touched.

File view actions per task, and how many were repeats

Model	All file views	Repeated views	Repeated share
GPT-5	2.38	0.65	27%
GPT-5.2	3.18	1.10	35%
Claude Sonnet-3.7	6.86	3.52	51%
Gemini-3-Pro Preview	7.14	3.54	50%
Claude Sonnet-4.5	11.24	5.80	52%
Claude Sonnet-4	14.20	7.17	50%
Kimi-K2	15.27	7.92	52%
Qwen3-Coder 480B	15.42	7.93	51%

Two things fall out of that picture.

The first is the spread. GPT-5 opened 2.38 files per task. Qwen3-Coder-480B opened 15.42. That is a 6.5x difference in how much of the repository a model feels it needs to see before acting, on tasks all of them ultimately solved.

The second is the repeat share, and it is the more damning one. Six of the eight models re-opened roughly half of the files they read. Only GPT-5 (27%) and GPT-5.2 (35%) stayed meaningfully below that. Modification actions follow the same shape: Kimi-K2 averaged 14.02 edits with 7.05 of them landing on a file it had already edited, against GPT-5’s 1.93 edits with 0.82 repeated.

Re-reading a file is not free. It re-enters the context, and the context is re-sent every round. This is where the 153.85 input-to-output ratio comes from, and it is why efficiency differences compound rather than add.

Spending more does not buy accuracy

Holding the problem constant, the study grouped runs into cost quartiles and estimated relative accuracy with a mixed-effects regression. Accuracy rose modestly from the minimum-cost quartile to the second, then saturated. The most expensive runs on a given problem were not the most accurate ones.

The behavioural explanation is the same redundancy. Repeated file views and repeated modifications both rose sharply with cost, significantly so in the top quartile. Expensive runs are thrashing runs: back-and-forth file access and re-editing that inflates context without progress.

This is the agentic version of a result already established on the reasoning side, in the price reversal phenomenon. More compute stops helping, and then starts hurting.

Human difficulty ratings do not predict agent cost

SWE-bench Verified carries expert difficulty labels based on how long a professional developer would need: under 15 minutes, 15 minutes to an hour, and over an hour.

Those labels correlate with agent token spend only weakly, a familiar shape for anyone who has looked at whether AI benchmarks are reliable at all. The rank association is real but modest at Kendall tau-b 0.32, with a 95% confidence interval of 0.25 to 0.38, and the distributions overlap heavily:

• 6.7% of tasks labeled under 15 minutes consumed more tokens than the average over-an-hour task.
• 11.1% of over-an-hour tasks consumed fewer tokens than the average under-15-minute task.

So the instinct to route “easy” tickets to a cheap model and “hard” tickets to an expensive one is built on a signal that is barely there. What looks trivial to an engineer may demand extensive exploration from an agent, and some genuinely hard problems land inside the model’s priors and resolve quickly.

Agents cannot predict their own bills

The most useful finding for anyone building cost controls is also the least reported.

The authors repurposed each agent as its own estimator: same tools, same repository access, but instructed to inspect the codebase and output a token estimate instead of attempting a fix. Three independent predictions per model across the same 500 instances.

Result	Value
Best correlation, predicted vs actual	0.39 (Sonnet 4.5, output tokens)
Best input-token correlation	0.38 (Kimi-K2)
Weakest performer	Gemini-3-Pro Preview, on both token types
Direction of error	Systematic underestimation across every model

Two details sharpen this. Input tokens are consistently harder to predict than output tokens, which is unsurprising given that input is the part that grows without bound over a long trajectory. And the bias is not random noise: most points fall below the perfect-calibration diagonal for every model tested, with the compression worst on input tokens, whose predictions stayed flat even as real usage climbed into the millions.

Then there is the cost of asking. Prediction is itself an agentic task, so it bills. Sonnet 3.7 and Sonnet 4 each spent more than twice the task’s own cost producing an estimate, and still did not achieve the best correlations. Sonnet 4.5 delivered the top correlation at 0.32x the task cost. GPT-5.2 got prediction overhead below 6%.

Where the tokens go inside a single task

Using Claude Sonnet 4.5 as the case study, the authors split each trajectory into five phases:

Phase	What happens	Share of rounds
Setup	Task planning, environment setup, initial reproduction	9.98%
Explore	Code search, file inspection, root-cause analysis	30.37%
Fix	Code edits, debugging iterations, patch refinement	33.53%
Validate	Testing, regression checks, verification	16.59%
Closeout	Final checks, cleanup, summary output	9.53%

Fix and Explore together account for roughly two-thirds of all rounds.

The cost breakdown inside those phases is counterintuitive. Cache-read input tokens were the largest cost contributor in every single phase, despite being the cheapest token type on the price sheet. Output tokens are priced roughly 80x higher per token, and still lost, because accumulated context is re-read on every round and the volume overwhelms the unit price.

Output tokens only stand out in Setup, where planning-heavy generation is concentrated.

At round level the pattern is that cache-read cost forms a steady, predictable baseline, while the visible spikes come from whatever the agent chooses to add to the context on that round: repository exploration, file creation, test execution, final summarisation. The accumulating part is predictable. The additions are not.

Does this hold up outside the paper?

It is one preprint on one benchmark, so the honest answer is that it needs corroboration. Some has already arrived, from a completely different source.

The Terminal-Bench 4.0 leaderboard, published on 28 August 2026, reports total run cost alongside accuracy. Claude Sonnet 5 consumed 21.6 billion tokens across its 330 trials against 6.5 billion for Claude Opus 5, a 3.3x spread on identical work, and posted the largest absolute bill on the board while tying for last on accuracy.

Different benchmark, different models, different harness, four months later. Same shape: token appetite is a model trait, and the biggest spender is not the winner.

What to actually do with this

1. Budget the p90, not the mean. A 30x same-task spread means an average is a planning fiction. Size budgets off the tail you have observed, then alert on it.
2. Treat cost as a failure signal. Accuracy saturates while cost keeps climbing, and expensive runs are disproportionately thrashing runs. Cap runaway runs rather than letting them finish.
3. Do not ask the agent for an estimate. Correlations top out at 0.39, the error is biased toward underestimation, and on two of eight models the estimate cost more than the task.
4. Do not route by human-perceived difficulty. A tau-b of 0.32 is too weak to carry a routing rule.
5. Compare models on tokens consumed, not just on price per token. A model at half the per-token rate that reads six times as many files is not cheaper. The cost calculator works in tokens per task for this reason.

The uncomfortable implication for the industry is the one the authors point at: per-token pricing passes an unpredictable, model-specific cost straight to the customer, and nobody currently has the tools to forecast it. Not even the agent.

Frequently asked questions

How many tokens does an AI coding agent use per task?

In a 2026 study of eight frontier models on 500 SWE-bench Verified instances, an average agentic coding task consumed 4.17 million tokens and cost $1.857. The same problem handled as multi-turn chat averaged 3.39k tokens and $0.023. Usage is highly variable though: runs on the same task differed by up to 30x.

Which AI model uses the fewest tokens for coding?

Among the eight models measured, GPT-5 and GPT-5.2 were the most token-efficient, achieving strong accuracy at the lowest token cost. GPT-5 averaged 2.38 file view actions per task against 15.42 for Qwen3-Coder-480B and 15.27 for Kimi-K2. Kimi-K2 was the least efficient, with both the highest token cost and the lowest accuracy.

Why does the same coding task cost a different amount each time?

Agent trajectories are stochastic. The agent chooses which files to open, how many times to re-read them, and when to stop, and small differences early compound through the context window. Measured runs on the same task differed by up to 30x in total tokens.

Does spending more tokens make a coding agent more accurate?

No. Holding the problem constant, accuracy rose modestly from the cheapest cost quartile to the second and then saturated. Expensive runs showed sharply higher rates of repeated file views and repeated edits, meaning the extra spend went on redundant back-and-forth rather than progress.

Can an AI agent predict what a task will cost before running it?

Not reliably. When frontier models were asked to estimate their own token usage before execution, the best correlation with actual usage was 0.39 and every model systematically underestimated. On two models the estimate cost more than twice the task itself.

Why do input tokens dominate agent costs?

An agent re-sends its accumulated context every round, so the same material is read many times while the model writes relatively little. The measured input-to-output ratio for agentic coding was 153.85, against 1.33 for chat. Cache-read input tokens were the single largest cost contributor in every phase of a task, despite output tokens being priced around 80x higher per token.

Sources

• Bai, L., Huang, Z., Wang, X., Sun, J., Mihalcea, R., Brynjolfsson, E., Pentland, A., & Pei, J. (2026). How Do AI Agents Spend Your Money? Analyzing and Predicting Token Consumption in Agentic Coding Tasks. arXiv preprint arXiv:2604.22750. arxiv.org/abs/2604.22750
• Stanford Digital Economy Lab (2026). How are AI agents spending your tokens? digitaleconomy.stanford.edu
• Jimenez, C. E., et al. (2024). SWE-bench: Can Language Models Resolve Real-World GitHub Issues? ICLR. arxiv.org/abs/2310.06770
• Terminal-Bench (2026). Terminal-Bench 4.0 leaderboard. tbench.ai