Anatomy of a Token Bill: Where 11.8 Billion AI Tokens Go
I spend most of my days building software with an AI coding agent, so out of curiosity I added up a month of it: 11.8 billion tokens across roughly 31,700 API calls. That is a large number, but the breakdown surprised me. 96% of it is one category I never used to think about.
This is a plain-English tour of what those numbers actually mean. If you use these tools or pay for them, it is worth knowing how to read the bill.
Four kinds of tokens
A token is a chunk of text, roughly three quarters of a word. Every request to a language model is metered in tokens. Not all tokens are the same, and they do not all cost the same. They fall into four buckets:
- Input - fresh text the model reads for the first time.
- Output - everything the model writes back: its answer, the code it produces, the tool calls it makes.
- Cache creation - the first time a large chunk of context is sent, it is written into a short-lived cache so it does not have to be re-sent on the next turn.
- Cache read - on every following turn, that stored context is read back from the cache instead of being reprocessed from scratch.
What the usage actually looks like
Here is every day of my last thirty. There are quiet stretches, a climb through heavy build weeks, and one 1.42-billion-token day when I had several projects going at once. Across 29 active days it averaged about 408 million tokens a day.
Where the 96% goes
Split those 11.8 billion tokens by type and one category takes up almost all of it. The four buckets span four orders of magnitude, so a plain bar chart would show a single stripe - here they are on a log scale, where each step is ten times the last:
| Type | 30-day total | Share |
|---|---|---|
| Cache read | 11,336,000,000 | 95.9% |
| Cache create | 457,000,000 | 3.9% |
| Output | 27,900,000 | 0.24% |
| Input | 3,000,000 | 0.03% |
Cache read is so large because of how a coding agent works. In a long session, the same large context - the codebase it is reading, the conversation so far, the definitions of every tool it can call - has to be present on every single turn. Hundreds of turns over a context approaching a million tokens adds up to billions of cache reads from a single afternoon's work.
How I measured this
These are my own numbers, not a vendor benchmark. My AI coding agent keeps a local log of every session, and each turn records exactly how many tokens fell into each of the four buckets. I summed those per-turn records by day across a 30-day window (29 days had activity), deduping by request id so nothing is counted twice. I did not estimate or sample anything. I added up the logs.
Here is the daily data behind every chart above. Download it and check my work:
Daily data (CSV) · Daily data (JSON)
One caveat: this is one user and one tool over one month. The exact numbers are mine. I would expect the general shape to hold for anyone using an agent like this, but I have not verified that.
Why this is good news
That lopsided split is not waste. It is the reason this kind of work is affordable. Providers deliberately price the buckets differently: a cache read costs roughly a tenth of a normal input token, while writing to the cache costs a small premium. So the 96% of my month that is cache read is billed at about a tenth of what it would cost if every turn re-sent the whole context cold. Without caching, the same work would cost on the order of ten times more.
It also changes what "usage" honestly means. The tokens that represent real building - the model's output plus the new context it writes to cache - came to about 485 million of the 11.8 billion. That is the signal I actually watch across my projects. The other 11.3 billion is the model re-reading context so it stays oriented. It is cheap, and it tracks how long I worked more than how much I produced.