Key facts.
- MAKER demonstrates that long-horizon tasks once thought intractable, on the order of a million steps, can now be run, so each new model invites longer and more expensive work rather than only making old work cheaper. source
- Agent cost grows with context and conversation length, often faster than linearly, so longer tasks opened up by better models carry disproportionate cost. source
- On OSWorld, frontier models still complete only about 12% of real computer tasks against roughly 72% for humans, so there is a large backlog of harder work a cheaper, better model will be pointed at next. source
Why doesn't a cheaper token mean a cheaper bill?
Because the saving is an invitation, not a refund. When the unit cost of a capability drops, the rational response is to use more of it and that is what teams do with agents: a cheaper, stronger model gets applied to tasks that were not worth it before, runs on longer context that was previously too expensive and is allowed to attempt the harder cases it can now reach. Each of those is more tokens, so the total usage rises to meet the lower price and the bill holds or climbs while the per-token cost falls. This is the long-running pattern in computing, where falling unit costs expand usage rather than shrinking spend and agents follow it cleanly because their appetite for tokens scales with the work you give them.
The capability trend makes this sharper rather than softer. MAKER's demonstration that million-step tasks are now reachable means the frontier of what is worth attempting keeps moving outward and the new frontier tasks are longer and costlier. So the more capable, cheaper model does not settle the bill, it raises the ceiling on what you will ask it to do and the quadratic-cost effect makes those longer jobs disproportionately expensive. The efficiency is real and it funds growth, which is good, as long as the budget expects it.
How should the budget treat efficiency gains?
As fuel for growth to be governed, not as an automatic saving to be banked. Assume each model generation lowers unit cost and raises usage and plan the budget around the total, with caps and routing to keep the growth pointed at value. Decide deliberately which new work the cheaper model opens up is worth doing, because "we can afford it now" is how the bill quietly expands past its purpose. And keep measuring cost per outcome, so the rising spend is justified by rising value rather than by drift. The teams that are surprised by their agent bills are the ones who assumed efficiency would shrink them; the teams in control assumed it would grow usage and budgeted for the work that growth was worth.
| Assumption | Efficiency lowers the bill | Efficiency grows usage |
|---|---|---|
| Budget basis | Falling unit price | Rising total at higher value |
| New work | Unmanaged | Chosen deliberately |
| Control | Hope for savings | Caps, routing, outcome tracking |
| Surprise risk | High | Low |
The Pattern Intelligence Layer is where efficiency-driven growth stays governed. Usage, cost per outcome and the value of newly-opened work are tracked at the pattern level, so a cheaper model's saving is steered into work worth doing rather than absorbed by drift. Reliability at the pattern level is what turns falling unit costs into rising value instead of a rising surprise.
Frequently asked questions
If tokens keep getting cheaper, won't my bill eventually drop?
Usually not on its own. The cheaper unit invites more usage, longer context and harder tasks, so the saving funds growth. The bill drops only if you deliberately hold usage flat.
Is rising spend a bad sign?
Not if it tracks rising value. Efficiency-driven growth is healthy when cost per outcome stays sound. It is only a problem when the extra usage is drift rather than chosen work.
Does a more capable model change this?
It intensifies it. MAKER shows even million-step tasks are now reachable, so a better model raises the ceiling on what you will attempt and those longer jobs cost more.