A cache break does not raise an error. It raises the bill.

Almost every failure mode I write about on this site announces itself. A schema violation throws. A rate limit returns a 429 and eats a retry. A truncated JSON blob fails to parse. You find out because something broke, and breaking is how you learn.

A prompt cache miss is not like that. The response comes back identical. No exception, no retry, no 429, no log line, no shift in your eval score. The only artifact is on the invoice, and the invoice is a total with no attribution inside it. Which is why "your agent bill went up and nothing errored" is a sentence worth taking literally.

Replay Doctor is a local CLI built entirely around that sentence. It reads the agent transcripts already sitting on your disk and names the turn a cache broke on, the cause, and the tokens that got re-billed. I read its page on 15 September 2026, and the numbers on it are the first ones I have seen that put a figure on this failure class.

What a re-billed token actually costs

The published multipliers, from claude.com/pricing checked the same day, on Claude Sonnet 5 at $2.00 per MTok of base input: a cache read is $0.20 per MTok, and a five-minute cache write is $2.50 per MTok. Divide one by the other and you get the number that makes this whole subject worth an afternoon:

write  $2.50 / MTok
read   $0.20 / MTok
       -------------
         12.5

A token that gets re-billed at write price costs twelve and a half times a token read from cache. A cache break does not cost you the tokens. It costs you twelve and a half times them, and it costs it in one turn.

Replay's page reports one break by name: a session where three tools were added and WaitForMcpServers was removed, and the line that closes it reads "That break cost 157,080 tokens." Price that at the same published rates:

157,080 × $2.50 / 1,000,000  =  $0.39270   as a write
157,080 × $0.20 / 1,000,000  =  $0.03142   had it been a read
                                --------
                                $0.36128   the surcharge

$0.39, in a single turn, from a tool list changing. The same page reports a median task cost of $0.79 across its corpus. One silent break was half of a median task's entire spend, and it produced no output that a human or a test could distinguish from the run that did not have it.

The tool block sits at the front, which is the whole problem

Here is the part I had not thought through until this page made me look. Tool definitions serialise ahead of the system prompt, so the cacheable prefix runs tools → system → messages. The cache matches from the front and is exact. Which means a mutation in the tool block does not cost you the tool block. It costs you everything behind it.

tools                    12,000   ← three added, one removed, here
system + instructions     3,000
the document             20,000
nine prior turns         13,500
                         ------
prefix re-billed         48,500     4.0× the block that changed

You touched 12,000 tokens and re-billed 48,500. Now price the break at Sonnet 5 rates:

48,500 × $2.50 / 1,000,000  =  $0.12125
48,500 × $0.20 / 1,000,000  =  $0.00970
                               --------
                               $0.11155   per break

Eleven cents per break. That is the per-document number, if one break lands per document. At a thousand documents a day it is $111.55 a day, or $3,346.50 across a thirty-day month, spent re-reading context the pipeline had already paid for once. And that is the optimistic case where the break happens once.

Nothing in this arithmetic is exotic. It is $2.50 versus $0.20 and a prefix that matches from the front. The exotic part is that when it happens, every dashboard you own reports a successful run.

The cause is usually not the one you are tuning

Replay's page carries a line that reframes the whole problem: "A re-render is frequent and small; a TTL expiry is rare and enormous." Everyone I know who has thought about cache economics — including me, in the break-even arithmetic — spends their attention on the TTL, because the TTL is the thing with a number on it. Five minutes. An hour. A knob you can turn.

But the TTL only explains the breaks that time caused. A re-render caused by your own content changing explains the rest, and it is the frequent kind. Your bill is frequency times size, so a frequent small cause can dominate a rare enormous one, and you cannot tell which world you are in by reasoning about it.

The strongest evidence for that on the page is that Replay refuses to publish cause shares at all, because the ranking "flipped between two readings on 2026-09-11" — two days apart, on the same corpus. If a careful operator with the transcripts in hand gets a different answer on Tuesday than on Sunday, then nobody is going to get this right from first principles. You measure it or you guess.

Which also means the standard advice is only half right. Setting the TTL to an hour removes the expiries, but the documented one-hour write multiplier is 2× base input against 1.25× for five minutes — $4.00 per MTok against $2.50 on Sonnet 5. A re-billed token goes from 12.5× a read to 20×. So a longer TTL makes each remaining break 1.6× more expensive, and if your breaks were never expiries in the first place, you have bought nothing and raised the price of being wrong.

What this does to an eval suite

There is a second consequence, and it is worse than the cost.

If two arms of an eval differ in their tool configuration, they differ in their prompt. A quality delta and a cost delta then arrive together, and you cannot attribute either one — you have changed the thing you were measuring and the thing that pays for it in the same edit. And if your harness assembles the tool block by iterating an unordered mapping, two runs of the same build do not share a prefix. That is a cost bug and a reproducibility bug wearing one coat, and the way to find it costs nothing: render your tool block twice from the same config, hash both, compare. If the hashes differ, your cache hit rate is zero and your eval is not reproducible, and you learned it before spending anything.

This is the same category of mistake as putting a timestamp in the system prompt — variable content in a prefix that is supposed to be stable — except the variable content here is infrastructure you do not think of as part of the prompt. An MCP server coming up mid-run. A permission mode that filters the tool list. A skill that loads at turn four. None of those look like a prompt edit when you read the diff.

What I would record, and what I would not assume

Record cache_read_input_tokens and cache_creation_input_tokens per call and aggregate them per run, not per day. A daily ratio hides exactly this bug: a day of clean runs and one session with a mutated tool list average into a number that looks healthy. The query from attributing model spend already answers this, and the useful alert is a cliff in the ratio after a deploy rather than a threshold on the total.

Two things I would not do. I would not treat a cache break as a retry — a cache break is the failure, not a symptom of one, and there is nothing to retry because nothing failed. And I would not read a total as an answer. As Replay's own page puts it, ccusage "tells you the total, and it is better at that"; the open question is which turn, and why.

What I am not taking from this

The corpus is one machine. The page says so in the same breath as the figure: 119 sessions, 1,881 agent lanes, one machine, one operator, read 2026-09-12 on build 0.5.4, and it labels itself "a method demonstration, not a market." The 5% of spend it attributes to re-billing is 5% of that operator's $4,039.23 — not a benchmark, and not a number to put in a business case.

Two details are why I believe the rest of it anyway. The figures are calibrated against 32,188 real requests from 115 of that operator's own sessions, read 2026-09-07. And the page publishes its own retractions in a section titled "What it got wrong, in public" — a claim that 98.8% of re-billed tokens came from one cause, corrected to 4.2% the same day; 1,363 files counted as sessions, corrected to 78; 26 installs that were really 53 fetches from 2 IPs. A tool that logs its own errors is more credible than one that does not, and a method with no buyers yet — the forensic week is $22,000 and the page states plainly that none has been sold as of 2026-09-13 — is a method, not a market.

So the honest conclusion is narrow and still useful. Re-billing is real, it is invisible to every signal except the token counters, the trigger is more often your own prompt layout than the clock, and a single tool-list change can re-bill four times the tokens you touched.

This is the kind of thing that turns up when a pipeline gets a rescue and reprocessing pass and nobody has re-priced it since, and it is the sort of measurement I would rather run deliberately than discover on an invoice. More on what an AI feature costs to build and when the model bill triples.

All Replay Doctor figures — 119 sessions, 1,881 agent lanes, $4,039.23 total, $0.79 median task, $199.77 avoidable, 42.9M tokens re-billed, the 157,080-token break, the re-render/expiry line, the withheld cause shares, the retraction log, the calibration corpus and the $22,000 week — are quoted from replay.doctor, read 15 September 2026, and are one operator's corpus rather than a benchmark. Model rates and the 5-minute cache multipliers are from claude.com/pricing, checked 15 September 2026. The 12,000/3,000/20,000/13,500 token prefix and the one-break-per-document frequency are my stated scenario, not measurements — substitute your own token counts and the ratios hold while the dollars move.