How this was built
What it cost
Nineteen sessions, ten days, and the number nobody expects: fresh input was 38,307 tokens against 2.71 billion cache reads.
# The shape of the bill
Ten days, nineteen sessions, one model. Every figure here is generated from local transcript records by a script in the repository, not typed in by hand.
| Span | 2 – 11 August 2026, 19 sessions |
| Assistant messages | 9,176 |
| Output tokens | 8,085,931 |
| Cache reads | 2,711,252,834 |
| Cache writes | 26,221,472 |
| Fresh input tokens | 38,307 |
Read the last two rows together, because that is the whole story: 99.999% of everything this project fed a model was a cache read. Fresh input — the tokens that had never been seen before — came to thirty-eight thousand across ten days, against two point seven billion read back out of cache.
# Why that number is the interesting one
The intuition most people bring to this is that an agent costs what it writes. It does not. It costs what it re-reads, over and over, on every single turn.
A long session is one enormous and slowly growing context — the frozen scope, the architecture notes, the file being edited, the last twenty tool results — and every message pays to read all of it again. Output is the small number: eight million tokens of actual writing against two point seven billion tokens of re-reading, a ratio of roughly 335 to 1.
Two things follow, and they are the practical content of this page:
- Caching is not an optimisation here, it is the economics. At 99.999% cache read, the difference between a warm context and a cold one is the difference between a workable tool and an unusable one.
- A long session is cheaper than it looks, and a scattered one is dearer. The expensive move is not asking for more; it is repeatedly rebuilding a context that was already warm.
# Lined up against what shipped
Sessions are dated and so is everything in the repository, so the two can be put side by side. Output tokens by the day a session started:
| Day | Output tokens | What shipped |
|---|---|---|
| 2 Aug | 1,269,581 | The parsers and the data layer |
| 3 Aug | 1,629,558 | The player, and the scope freeze admitting Android TV |
| 4 Aug | 1,445,645 | The television frontend |
| 5 Aug | 831,988 | First CI runs — and the two failures they exposed immediately |
| 6 Aug | 75,654 | The shake, solved on the device |
| 9 Aug | 1,136,027 | Search, the catalogue scan, profiles |
| 10 Aug | 994,119 | Signed releases, the release-on-merge lane |
| 11 Aug | 703,359 | The legal round, the licence check, the first-launch terms |
The most interesting row is the smallest one. 6 August cost 75,654 output tokens — under a tenth of any other working day — and what it produced was the fix for the bug that had taken four wrong answers across the previous days. The reason it was cheap is that the answer did not come from the model: it came from someone watching the television. Cost tracks typing, not difficulty.
# What these numbers are not
This is a local record, not a billing statement. It is generated from the transcripts Claude Code keeps on one machine, and it should be read as a floor rather than a total:
- A session whose transcript was truncated or removed is simply absent from it.
- Work done before the project was renamed lives in a separate directory, which is included — but anything from before those records began is not counted at all.
- Tokens are not money. There is no price in this table on purpose: the rate depends on a plan we are not going to pretend to know from here.
And there is nothing in it but numbers, by construction. The transcripts contain real provider hostnames and the debugging that got an account blocked, which is exactly what this project forbids anywhere near its repository. So the script that produces this page never reads a text field at all — only a timestamp, a model name and a usage record — and it refuses to write its own output if any string in it is not a date, a session id or a model name. The safety is structural rather than careful.