One production session burned 176 million tokens. Breaking the bill out by class showed the biggest line was not the expensive one.
I built one episode of a video series last week. When the session ended, the harness reported the total: 175,806,871 tokens across 511 turns. That number reads like a fire alarm. My first instinct was to go find the biggest line and cut it.
That instinct would have cost me money. When I broke the session out by token class and priced each class at published API rates, the largest line item by volume turned out to be the cheapest thing I bought, and the line I would have ignored turned out to be more than half the bill.
Here is the full breakdown. Every number comes from a real production run, not a model.
| Token class | Tokens | Share of volume | Cost | Share of cost |
|---|---|---|---|---|
| Cache reads | 160,708,680 | 91.4% | $78.62 | 33.6% |
| Cache writes | 14,138,903 | 8.0% | $133.61 | 57.0% |
| Output | 914,853 | 0.5% | $21.87 | 9.3% |
| Uncached input | 44,435 | 0.03% | $0.12 | 0.1% |
| Total | 175,806,871 | 100% | $234.21 | 100% |
One production session, modeled at published API list rates. Opus 4.8 in the main loop, Sonnet 5 in the subagent fan-out.
Every turn in a long session sends the whole conversation back to the model. Turn 400 re-sends everything from turns 1 through 399. That is why the totals get enormous: a session that ends at 511 turns has re-read its own history hundreds of times.
Prompt caching is what keeps that from being ruinous. The provider stores the processed state of a prefix it has already seen, so the next turn that starts with the same prefix reuses the stored work instead of reprocessing it. Reads against that stored state bill at roughly a tenth of the base input rate. Writing to the cache costs more than base input, because storing the state is the expensive part.
So the mechanic that makes long sessions possible also makes the aggregate number misleading. Cache reads pile up fast and cost almost nothing each. That is 160 million tokens for $78.62, which works out to about half a cent per thousand. Meanwhile the writes, 8% of the volume, carry a multiplier in the other direction.
Cache reads bill at approximately 0.1x the base input rate. Cache writes bill at 1.25x on a five minute time to live, or 2x on a one hour time to live. That is a 20x spread between the cheapest and most expensive class of the same underlying thing.
Look at the two middle columns of that table together. Cache reads are 91.4% of the volume and 33.6% of the cost. Cache writes are 8.0% of the volume and 57.0% of the cost. The ranking flips completely depending on which column you read.
Anyone optimizing this session by volume goes straight for the cache reads, because they are the obvious target at ninety one percent. Cutting them in half saves about thirty nine dollars. Cutting the writes in half saves sixty seven. The smaller line has more money in it.
The same pattern showed up in the model tier split. This session ran twelve subagents in a verification fan-out, and my assumption going in was that the fan-out was where the money went. It was 3% of the spend: $7.08 against $227.13 for the main loop. Every hour I might have spent tuning agent count would have been an hour spent on three percent of the problem.
The cache write number invites an obvious fix. This session ran on a one hour cache lifetime, which bills at 2x base input. The five minute lifetime bills at 1.25x. Same writes on the shorter lifetime would have cost $83.51 instead of $133.61, a fifty dollar saving.
That fix would have made the session more expensive. Video production means rendering, and this episode included three renders that each ran between fifty and fifty seven minutes. During a render, no turns happen. A five minute cache is dead long before the render finishes, so the next turn after each render has to rebuild the entire cached prefix from scratch.
Three full rewrites of a prefix that large would have cost considerably more than the fifty dollars saved on the multiplier. The expensive-looking option was the cheap one, and the only way to know that was to look at the shape of the work rather than the price of the unit.
Per-unit price and total cost pointed in opposite directions because of a variable that appears nowhere on a pricing page: the gap between turns. Fifty minute renders turned a cheaper rate into a more expensive session.
I pay a flat monthly rate. My invoice is one number, and that number stays the same whether a session runs 176 million tokens or two million. The breakdown above cost me nothing extra, and my own bill would never have shown it to me.
That is the reason this finding stays buried. A flat plan collapses every cost class into a single line, so the people running the heaviest sessions usually have the worst instrument. The people on metered billing can see the class breakdown, but most of them are not running single sessions at this scale, so the inversion never gets large enough to notice.
The overlap of those two groups is small. I ended up in it by accident, because a video pipeline produces long sessions and I happened to pull the class-level telemetry out of curiosity rather than necessity.
Every dollar figure here is modeled at published API list rates, not an invoice. Renders and voice generation for this episode consumed roughly ninety five minutes of compute and cost real money at zero tokens, so this total is not the full cost of producing the episode.
Token pricing is the example. The transferable part is what the example demonstrates about measurement, and it shows up anywhere costs come in classes with different unit prices.
An aggregate number sums units. When those units have different prices, the sum answers a question nobody asked: how much stuff moved. The question that matters is where the money went, and a total cannot answer it because the expensive units are outnumbered by the cheap ones.
The mechanism is simple arithmetic that intuition gets wrong. If class A is 91% of volume at one tenth the unit price, and class B is 8% of volume at twenty times that price, class B wins on cost while losing badly on volume. The larger the volume gap, the more confidently the aggregate points at the wrong line.
This shows up outside token billing constantly. A law firm counting hours instead of realization rate. A warehouse counting units shipped instead of units by handling class. A marketing team counting sessions instead of sessions by acquisition channel cost. In each case the count is easy to produce and the class breakdown requires a query somebody has to write on purpose.
Unit price is a property of the thing you buy. Total cost is a property of how the work is shaped. When those two diverge, the pricing page will confidently recommend the wrong choice, because it has no visibility into your usage pattern.
The cache lifetime decision is a clean demonstration. Five minutes costs 1.25x, one hour costs 2x, and the shorter lifetime looks cheaper by every measure available on the rate card. Add one fact that lives entirely on my side, that renders create fifty minute gaps between turns, and the ranking reverses. The cheaper rate would have triggered three full cache rebuilds worth more than the difference.
The test itself is one question: what has to be true about my usage pattern for the cheaper unit price to also be the cheaper total? Then check whether it is true. Bulk discounts fail this test when the excess spoils. Cheaper materials fail it when they need replacing twice. Lower hourly rates fail it when the work takes three times as long.
Measurement is not neutral. Every reporting surface makes some distinctions visible and flattens others, and the flattened ones become invisible rather than absent. A flat monthly plan is a good deal and a poor instrument: it hides the entire class structure that produced this article, because the whole point of a flat rate is that the structure stops mattering to the payer.
Before optimizing anything, check whether the instrument can even show the thing being optimized. I could see the class breakdown because the harness exposed per-class token counts, and I priced them by hand against published rates. Without that telemetry I would have had a total, an assumption, and no way to test the assumption.
The uncomfortable version of this is that a comfortable billing arrangement often removes the pressure to build the instrument. Salaried headcount hides which projects consume capacity. Bundled software pricing hides which tool nobody uses. An unlimited plan hides the exact ratio that will hurt when the plan changes.
The whole exercise took about twenty minutes and needed no tooling beyond a calculator and the published rate card. If you're running agents at any volume, here's the sequence that produced the table above.
Sorting by cost is the step that does the work. Sorted by volume, this session's story is cache reads and nothing else. Sorted by cost, the story is cache writes, and the reads drop to a supporting role. Same data, opposite conclusion.
The model tier split deserves the same treatment, and it produced the second surprise of the session.
| Tier | Model | Cost | Share of spend |
|---|---|---|---|
| Main loop | Opus 4.8 | $227.13 | 97% |
| Subagent fan-out | Sonnet 5 | $7.08 | 3% |
Twelve verification subagents accounted for three percent of the session. The cost lived in one long conversation, not in the agents branching off it.
That result rules out an entire category of optimization. Routing work to cheaper models is the standard advice, and on this session it addresses three percent of the spend. Session length is the driver, which means the useful lever is structural rather than a model swap.
The class breakdown pointed at one structural fix. Cache writes get expensive because the prefix being stored keeps growing, and it grows because a single session carries its entire history forward. Splitting one long session into two shorter ones, with a written brief on disk as the handoff, means the second session starts from a file instead of a transcript. Most of the re-reading never happens.
I have not made that change yet, and the reason is worth stating plainly. At current pricing the session costs $234 modeled and effectively nothing on my actual plan, so adding a handoff step would buy friction I do not need. What the breakdown gives me is a mitigation I understand and can deploy on a day's notice if cache pricing ever moves toward parity.
That is the real return on counting properly. The immediate answer was that nothing needed fixing. The durable answer was knowing exactly which number would hurt if conditions changed, and having the fix already designed when it does.
The billing table produced three transferable tests. That conversion, from a single observation to a method that works on the next problem, is what framework building actually is.
Explore How to Framework