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 the answer had to come from logs instead. Every session transcript, every API call, every token class, for 34 active days between 18 June and 3 August 2026, across a production agentic workload. Then it was costed at published list rates.
Where the tokens actually went
This is the chart that reframes the problem. 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 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.
Output tokens had been the optimisation target for months. Output tokens are 8% of the bill.
This is worth being blunt about, because the assumption was wrong in a way that cost real money. The 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.
What was actually paid
Everything above is the counterfactual: what this work would have cost at published API rates. Those rates are not what got paid. All of it ran 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 the 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 the obvious mitigations (capping max_tokens, compressing agent responses) bought less headroom than expected. The wrong resource was being rationed.
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 the total. It is the shape of the distribution, which should hold for any agentic workload with a large working context:
- Measure before optimising. Acting on the assumption instead of the log would have meant optimising 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
- Short interactive chat turns are a different shape: small context, and the ratios invert
- Enterprise contract volume is out of scope too, since pricing there is structured differently enough that nothing here carries over
Method & disclosure
Figures are derived from 381 local session transcripts covering 18 June to 3 August 2026, of which 34 days had recorded activity. Every assistant message carries a usage record; those were parsed, 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 was 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 published per-model list rates were applied (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.
Nothing named in this piece carries an 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.