The chart we end up showing most often these days is a billing breakdown. One month of agent runs, split by token type. The first line is the one everybody looks at first: generated tokens. The code, the pull request descriptions, the test summaries — everything the agent wrote. A modest number.
The line underneath it is roughly seventy-five times larger.
It is labelled “cache reads”, and it accounts for something nobody experiences as work: reading the same context over and over. If you talk about the cost of agents and picture the text they produce, you are talking about the smaller of the two numbers.
A run is not a request
Picture what an agent does and you probably picture a question and an answer. In practice a run is a chain. It reads the ticket. It finds the file that matters. It reads it. It makes a change. It runs the tests. It reads the output. It fixes something. Forty steps is unremarkable for a medium-sized task.
And at every single one of those steps, the model is handed the entire history again. There is no memory between steps; the history is the memory. What got read into context at step three is sent again at step four, and at step five, and at step forty.
There is a mechanism that makes this affordable, and without it the whole shape of the thing would be uneconomic: the provider remembers the unchanged beginning of a request and charges a fraction for it next time — roughly a tenth of what freshly read tokens cost. That discount is the reason agents run at a sane price at all.
A tenth of something that happens forty times, growing with each step, is still a lot. What comes out the other end is a ratio somewhere around 75 to 1 between what was read and what was written. The exact figure moves with the workload. The order of magnitude does not.
The dial everyone reaches for first
Which leads somewhere uncomfortable: almost everything that intuitively looks like saving money saves nothing you can measure.
Make the agent answer more tersely — that changes the smaller number. Shorter commit messages, leaner PR descriptions, no explanatory prose: all the smaller number. You can halve the output and struggle to find the difference in the total.
It is easy to see why the conversation lands there. Output is the only part you see. Cache reads appear in no ticket and no review — they appear only on the invoice.
Lever one: the model per role
An agent system is rarely one model. It is several roles: one plans, one writes the code, one checks the result, one summarises. The obvious configuration is the strongest model everywhere, because you do not want to give up quality anywhere.
That is right in exactly one place and expensive in the rest. A checker answering whether a URL returns 200 and whether the link really appears in the rendered HTML does not need the model that wrote the change. The question is narrow, the answer is verifiable, and a smaller model handles it reliably at a fraction of the price. The same goes for summarising, for classifying, for ranking search results.
The exception is the writing role. Economising there usually does not pay, because a failed run costs almost as much as a successful one — and then has to be paid for a second time. Splitting by role does not mean cheaper everywhere. It means expensive only where being wrong genuinely hurts.
Lever two: how much context a run has to touch
The second lever falls straight out of the mechanics above. Every file an agent opens stays in context and is re-read at every subsequent step. Work through thirty files at the start of a run “for orientation” and you pay for those thirty files not once, but as many times as the run has steps left.
That makes reading discipline the single most effective lever we have found. Grep for a symbol instead of walking a directory. Open the file the ticket names, and go looking further only once it turns out not to be enough. For us this is now written into the agent’s instructions as an explicit rule, and it moved the number more than any prompt tuning that came before it.
The other half of the same lever is run length. Cost does not grow linearly with the number of steps; it grows faster, because each additional step reads a larger context. A run that takes sixty steps instead of twenty costs considerably more than three times as much.
So what does a task cost?
Not: how much code comes out of it. Three other things.
How much context it takes to understand it at all. A change to a clearly named file is cheap; the same change in a system whose connections the agent has to discover first costs a multiple of that.
How many steps it takes. That depends less on the model than on whether the task was described unambiguously.
And whether it works the first time. An abandoned run costs nearly as much as a successful one, minus the result. The number of retries is therefore a line item — which makes the quality of your task description a cost measure, not merely a courtesy extended to the machine.
Three questions for the next conversation
When somebody presents you the cost of an agent system, three questions tell you more than any forecast.
How does the bill split by token type? Which model runs in which role? And what does a typical task cost at the median — and how far does the tail stretch?
If the first question cannot be answered, everything after it is an estimate. That is not an accusation, it is the normal state of affairs: the figure sits in the provider’s billing breakdown rather than in your own dashboard, and nobody has looked yet.
An agent’s invoice is not an invoice for text produced. It is an invoice for looking things up. Once that lands, you start optimising in different places — and usually the right ones.
