TEARDOWN Nº 6 / FIELD NOTES

Where a Claude Code bill actually goes

PUBLISHED 2026-10-19 · BY Llorenç Ballester — Chief Burn Officer

We pointed our own audit tool at five months of the author's Claude Code logs (2026-05-18 to 2026-10-19, 91,475 agent messages, plus some Codex) and asked where the money went at list prices. The prompt itself barely registers. The bill is context: re-reading it, writing it to a cache that costs double, and carrying it through sessions that run for hundreds of turns.

Where it burned

This is the first table tokenburn audit prints, for the whole period. Every component is priced at its own rate for the model that produced it.

Shares of the spend we can price. 2% of tokens ran on models that are not on our board and are left out instead of guessed at. We publish shares, not the dollar figure: a list price is not what a subscription user pays, and the shape is the part that transfers to your own usage.

The line nobody expects: one-hour cache writes

Anthropic sells two cache lifetimes. A write that lives five minutes costs 1.25x the input price. One that lives an hour costs 2x. Reads cost a small fraction of input either way. In these logs, 94% of everything written to cache used the one-hour lifetime, and each written token was read back about 33 times. So the writes paid for themselves, but at double the input rate they still came to more than a third of the bill.

Per million tokens, from the board, recomputed on every deploy. Only models that publish a one-hour write rate are listed. More on how caching is billed in prompt caching, explained.

Most of the context is history

Every turn of a session re-sends everything before it. To separate what is fixed from what accumulates, we took the smallest context of each session's first three turns as its fixed prefix (system prompt, tool definitions, CLAUDE.md) and counted everything above that as history. Across all sessions, 78% of the context was history. That is the part a /compact or a fresh session would drop.

It is also very unevenly spread. The median session lasted 17 turns, but one in ten went past 152. The sessions of 100 turns or more were 14% of all sessions and 92% of all context sent. By their last turn they were re-sending a median of about 427K tokens every time. Counted another way, 90% of all context was sent after the fiftieth turn of its session.

The practical reading is unexciting. The cost is in the long sessions, so that is where compacting or starting over pays. We can't tell from logs how much a compaction recovers, because it leaves a summary in place of the history. Our audit assumes half and says that it is an assumption.

Three ways to count it wrong

We found these while building the reader. Anyone parsing these logs by hand will hit them.

• Claude Code writes one log line per content block, and every line repeats the same usage block. Here that meant 2.27 lines per real message: count lines and you more than double the bill. Deduplicate on the message id and request id.
• Claude Code reports cached tokens outside the input count. Codex reports them inside. The field names match and the meaning is the opposite. Add them up naively and the Codex cache gets billed twice.
• The one-hour and five-minute writes come split under cache_creation. Price them with one rate and you understate the biggest surprise in the bill.

Check your own

Method and limits

This is n=1. One developer (the person who writes this site), heavy agentic use, mostly Claude models with some Codex, measured with [email protected] on 2026-10-19. The fixed prefix here is large, a median of about 76K tokens, because this machine loads many MCP servers. With a leaner setup the prefix shrinks and history becomes an even bigger share. Session counts include the separate logs Claude Code writes for subagents.

Spend is computed at public list prices. A subscription doesn't bill per token, but the proportions still say what is eating your limit. For a measured agent workload on a different tool, see teardown #5, where cache reads outnumbered fresh input 35 to 1. If you run the audit on your own logs and the split looks very different, we would like to know. One data point is the honest reason this page says n=1.

Frequently asked questions