The published numbers on agent cost are all directional. Gartner says agentic workloads consume five to thirty times more tokens per task than a chatbot turn. Vendors quote $10–100 per session for an unoptimised production agent. Both are true, and neither tells you what you will actually pay, because the range is wide enough to contain every possible answer.
So I stopped reading and started logging. Every session transcript, every API call, every token class, for 34 active days between 18 June and 3 August 2026 — running five real businesses through Claude Code. Then I costed it at published list rates.
Where the tokens actually went
This is the chart that reframed the problem for me. Token volume and token cost are two different distributions, and the gap between them is where the money hides.
Output is a sliver of volume and a visible slab of spend — a 38-fold amplification. Cache reads run the other way: they dominate volume but bill at a tenth of the input rate, so their cost share lands below their volume share.
| Token class | Tokens | % of volume | Cost | % of spend |
|---|---|---|---|---|
| Cache reads re-reading context | 9,753,346,376 | 97.94% | $4,837.25 | 74.82% |
| Cache writes establishing context | 170,837,424 | 1.72% | $1,042.60 | 16.13% |
| Output what the model generates | 20,721,138 | 0.21% | $518.15 | 8.01% |
| Fresh input uncached prompt | 13,105,247 | 0.13% | $67.11 | 1.04% |
| Total | 9,958,010,185 | 100% | $6,465.11 | 100% |
Costed at published per-model list rates. Cache reads bill at 0.1× the model's input rate, cache writes at 1.25× on the five-minute TTL. On the one-hour TTL, writes bill at 2× and the total rises to $7,090.68.
Ninety-eight percent of every token I paid for was the model re-reading context it had already been given. The average call read 420,566 cached tokens and produced 893 tokens of output — a ratio of roughly 470 to 1.
I had been optimising output tokens for months. Output tokens are 8% of the bill.
I want to be blunt about this, because I was wrong in a way that cost me real money. My working assumption — taken from the standard guidance, which correctly notes that output tokens are priced at three to eight times input tokens — was that generation is where the spend lives. The per-token price is indeed higher. The volume is four hundred times lower, and volume wins by two orders of magnitude.
What caching is worth
The same data makes the opposite case for prompt caching, and here the effect is enormous.
| Model | Calls | Billed | Without caching |
|---|---|---|---|
| Opus 4.8 79.9% of all calls | 18,530 | $5,515.36 | $42,584.18 |
| Opus 4.7 | 2,151 | $685.92 | $5,429.53 |
| Opus 5 | 792 | $173.51 | $1,287.33 |
| Fable 5 | 90 | $32.48 | $130.25 |
| Sonnet 5 | 631 | $30.10 | $183.33 |
| Sonnet 4.6 | 558 | $23.11 | $151.78 |
| Haiku 4.5 | 405 | $4.63 | $25.40 |
| Total | 23,157 | $6,465.11 | $49,791.80 |
"Without caching" prices every cached token at the full input rate — what the identical workload would have cost with no cache hits. The gap is $43,326.69, or 87%.
Caching is not a marginal optimisation on this workload. It is the difference between $6,465 and $49,792 for identical work. And because cache reads bill at a tenth of the input rate, the 97.94% of tokens that dominate volume account for only 74.82% of spend — the discount is already doing enormous work before any optimisation of mine.
What I actually paid
Everything above is the counterfactual — what this work would have cost at published API rates. I don't pay those rates. I ran all of it on a $100/month subscription, and the window spans two billing cycles.
| Basis | Cost | Multiple | Per day |
|---|---|---|---|
| Subscription 2 cycles at $100/mo | $200.00 | 1.0× | $4.26 |
| API list rates 5-minute cache TTL | $6,465.11 | 32.3× | $190.15 |
| API list, no caching every token at full input rate | $49,791.80 | 248.9× | $1,464.46 |
Per-day figures use 47 calendar days for the subscription and 34 active days for the API columns. Pro-rating the subscription to the 47-day window ($154) widens the gap to 41.9×; $200 is the conservative figure because it is what actually left my account.
That works out to an effective $0.0155 per million tokens. It is the single largest cost lever available, and it is a pricing decision rather than an engineering one — no amount of prompt optimisation closes a 32x gap.
The caveat matters, though, and it is the part the "just use a subscription" advice leaves
out: the plan has usage limits, and this workload lives against them. The 8%
output share is precisely why my own mitigations — capping max_tokens, compressing
agent responses — bought less headroom than I expected. I was rationing the wrong resource.
What actually keeps a workload like this inside a plan is controlling how much context gets
re-read on every call.
What this means for your budget
The useful takeaway is not my total. It is the shape of the distribution, which I would expect to hold for any agentic workload with a large working context:
- Measure before optimising. If I had acted on my assumption instead of the log, I would have spent effort on 8% of the bill.
- Caching is the whole game. Verify you are actually getting hits —
cache_read_input_tokensat zero across repeated calls means something in your prefix is changing. - Context size is cost. At 470 read tokens per output token, what you keep in the window matters far more than what the model says back.
- Cheap models did not help. Haiku, Sonnet 5 and Sonnet 4.6 together were $57.84 of $6,465 — under 1%. Routing away from Opus is a rounding error unless it moves the work that actually runs.
This applies to you if
- You run agentic sessions with large working context — codebases, document sets, long tool-call chains
- You are forecasting agent spend and using per-token list rates as your model
- You have been optimising output length and haven't yet measured what it's worth
- Not: short interactive chat turns, where the context is small and the ratios invert
- Not: enterprise contract volume, where pricing is structured differently enough that none of this transfers
Method & disclosure
Figures are derived from 381 local session transcripts covering 18 June to 3 August 2026 — 34 days with recorded activity. Every assistant message carries a usage record; I parsed all of them, de-duplicated by message ID, and summed input, output, cache-creation and cache-read tokens per model. 23,157 billable calls, zero parse errors.
Two different things are being reported. What I paid is actual: a $100/month subscription across two billing cycles. What it would have cost at API rates is calculated — token counts are actual, and I applied published per-model list rates (cache reads at 0.1× input, cache writes at 1.25× on the five-minute TTL). Sonnet 5 is costed at its introductory rate, which covers this window. The one-hour-TTL figure is given alongside where it differs. This measures Claude Code usage specifically, not a separate autonomous agent fleet.
I have no commercial relationship with any vendor named here, and no affiliate arrangement on any product in this piece. Where Astraas earns affiliate revenue, it is disclosed on the page it appears. The parsing script and per-day breakdown are available on request.