Token prices fell around 90% since 2023. Corporate spending on AI went up about 320%.
Both numbers are true at the same time, and if you run any kind of agent loop, you already feel it. 😅
This is not a billing bug. It is Jevons paradox, and it has been running in the background of every AI budget for the last two years.
The 160-year-old explanation
In 1865 William Stanley Jevons noticed that as steam engines got more efficient, Britain did not burn less coal. It burned more. Cheaper energy made new uses viable, new uses drove consumption, total spend went up while unit cost went down.
Tokens work exactly the same way. Except with tokens the effect is stronger, because cheap tokens did not just make existing work cheaper. They made a whole class of architectures possible that nobody would have paid for two years ago.
Nobody was running a 20-step autonomous loop when a million output tokens cost real money. Now everybody is.
Why agents multiply the bill
A chat call is one shot. You ask, the model answers, done. Maybe a few thousand tokens.
An agent does not work like that. It runs in a loop: think, act, observe, adjust, repeat. And on every single step it reloads the entire conversation so far, because the model has no memory between calls. Step 12 is paying for steps 1 through 11 again.
So consumption does not scale linearly with the result. It scales more like rocket fuel: to go a bit further you need a lot more of it.
Goldman Sachs projects roughly a 24x increase in global token consumption by 2030, driven mostly by agents. That number sounds absurd until you count the reloads in one of your own sessions.
Btw this is also why context bloat is not a cosmetic problem. Every unnecessary file you dump into context gets paid for once per loop iteration, not once per task. I built a small plugin for this in Claude Code specifically because the default behaviour of resending everything each turn was quietly the most expensive thing in my setup.
Reasoning models on trivial tasks
The second multiplier is the thinking part. Reasoning models generate thousands of internal tokens before they emit a single visible character. On a hard problem that is exactly what you want, and it is genuinely better output.
On "rename this variable" it is money set on fire.
The failure mode here is not the model. It is that most setups have one model configured for everything, so the expensive one handles the trivial work too. You do not notice per call. You notice at the end of the month.
The number managers actually look at is the wrong one
Acceptance rate for AI-generated code sits somewhere around 80 to 90%. It looks fantastic on a slide.
It also does not mean the code shipped.
GitClear's longitudinal study across 211 million changed lines found code churn, meaning lines reverted or rewritten within two weeks, went from a stable ~3.3% before AI assistants to roughly double that now. Copy-pasted lines overtook refactored lines for the first time in the dataset's history. AI-authored PRs carry noticeably more issues per PR.
There are more dramatic numbers going around, like the chart claiming only $0.18 of every AI coding dollar becomes shipped value. I would treat that one carefully. It comes from a single platform's own data, not an audited benchmark. The direction is right, the precision is not something I would put in a board deck.
But the underlying point holds and matches what I see: the expensive part is not generation. It is the loop after generation. Fixing edge cases. Rewriting half the diff. Reviewing a change that touched three files nobody asked about.
Tokens spent on code that gets rewritten next sprint are not cheaper because tokens are cheap. They are pure loss with an invoice attached.
So the actual lever is routing
Not discipline. Not "use AI less". Telling your team to use less AI just gives back the productivity you were trying to buy.
The lever is which model handles which step.
Here is my current /implement loop, the one that pulls a task from Linear and drives it to Done:
- Opus plans and writes production code
- Cursor Composer 2 writes tests and does the first review pass
- Sonnet clicks through the result in a browser to verify it works
- Codex does the milestone review
The rule behind it is simple. The expensive model runs where a mistake costs more than tokens. Everywhere else, something cheaper runs.
Planning and production code are where a bad decision propagates into everything downstream, so that is where I pay. Test scaffolding, mechanical refactors, browser verification: none of those need the frontier tier, and using it there buys nothing.
What did not work
Giving the planning step to a cheap model.
I tried it, because on paper it is the biggest single line item. It came out more expensive, not less. A weak plan means you rewrite the implementation, and rewriting is precisely the part that burns money. You save on one call and pay for it across the next twelve.
Same lesson in a different shape: a frontier model that solves a task in three turns can genuinely cost less in total than a budget model that needs twelve, because every extra turn resends the whole context. The cheap model is only cheap per call.
The other thing that did not work was doing the model switching by hand. Two terminals, copy diffs between them, lose track of which one has the current state. I ended up writing a plugin to bridge Claude Code and Cursor Composer 2 so the handoff happens in one place. Heavily inspired by openai/codex-plugin-cc, which does the same trick with GPT. Credit where due.
The boring part nobody posts about
Knowing when to stop the agent.
Knowing when to take autonomy away from it and hand it a narrower task.
Knowing when writing it yourself is just faster.
None of that is impressive on a demo. All of it is the difference between an AI setup that pays for itself and one that produces the same output at a higher price.
What I actually track
Not tokens consumed. That metric has already been tested at scale by companies much larger than mine, and the result was Goodhart's law in production: the moment consumption became the target, it stopped measuring productivity and started measuring nothing except the invoice.
What I care about is how much of what the agent produced survived review and made it to deploy. That number is harder to get, and it is the only one that answers whether any of this is working.
The value of a developer right now is not lines produced. It is the architecture of control around what generates those lines.
If you run agents in production: are you measuring token spend, or what actually ships out of it? Curious how other teams attribute this, because I do not think anyone has a clean answer yet.
Top comments (0)