Start with what the provider actually does when your compactor rewrites turn three of a twelve-turn session. The prefix no longer matches verbatim, so nothing before the edit is reusable, and the whole prefix is processed again [3][2]. You also pay to write the new prefix, which on some newer model families bills at 1.25x input [6]. Edit again on the next turn and you buy another write and never collect a read [5].
The pricing is worth doing by hand. Reads run at roughly 0.1x full input price [6]. Over N requests sharing a prefix, the cached path costs 1.25 + 0.1(N-1) against N for the uncached path, and the two cross just above N = 1.28 [2]. A prefix used twice has already paid for its write. That is why the write premium is tolerable at all, and why a compactor that manufactures single-use prefixes is expensive: it pays the premium every turn for a discount it never reaches.
Both cited results are somebody else's workload. Shrinking tool output 38.4% while the bill rose 6.8% [8] means each surviving tool-output token cost about 1.73x what it did before, if you divide the new bill by the tokens left [1]. That transfers only if your spend is dominated by input tokens on a genuinely reused prefix and your compactor edits inside it. If your volatile content already sits after the anchor, the study describes a bug you do not have.
The coding-agent number is narrower still. Going from 27/40 to 15/40 patches is a 44% relative fall in success [9][4], and the stated cause is broken code anchors [9]. To reproduce that, your agent has to quote file content back into its edits by literal or line number, so a summarizer can quietly remove the thing the patch is keyed to. Agents that address files by path and let the tool do the reading are not exposed the same way.
Routing constrains the other axis, and it gets less attention. Requests hash to a machine by prefix, each machine serves roughly 15 requests per minute for that prefix, and the overflow spills to machines that miss [7]. That is one request every four seconds [5]. A fan-out agent firing twenty parallel subtasks at one shared system prompt is generating misses by design. The playbook's answer is to shard deliberately with a routing key [7], declared alongside an explicit cache mode and TTL in the request body [11].
Defaults are short. The author puts OpenAI near 30 minutes and Anthropic near 5, with 10 to 60 minutes as the tuning band for interactive sessions [12]. Keepalive reads at 240 to 480 second intervals are offered as the way to hold a prefix across builds and human approvals [13]. Against a 300-second TTL, a 240-second ping leaves 60 seconds of margin [6]. His own caveat is the load-bearing one: measure first, because a ping into an evicted cache pays the full write [13].
The rule I would take from this is narrow. Compaction stays, but it happens before the write and never behind it, and everything volatile, timestamps included, goes after the anchor [10]. The number on the dashboard becomes cache hit rate next to time-to-first-token, not tokens per turn, because tokens per turn is precisely the metric that made this failure look like a win.
