blog / anthropic-cache-write-premiums
Anthropic cache write premiums: the break-even math nobody runs
Anthropic's prompt-cache pricing has three multipliers on the input rate: cache reads cost 0.1x (the 90% discount everyone quotes), 5-minute-TTL cache writes cost 1.25x, and 1-hour-TTL writes cost 2x. The reads get all the attention. The writes are where teams quietly lose money, because a cache entry that is written and never re-read within its TTL costs strictly more than not caching at all.
The break-even derivation
Consider one prefix token. Written to cache, it costs the write premium once, and each within-TTL re-read costs 0.1x instead of the 1x it would cost uncached. With R expected within-TTL re-reads, the net change versus never caching is:
5-minute tier: (1.25 − 1) + R·(0.1 − 1) = 0.25 − 0.9R → saves iff R > 0.278 1-hour tier: (2.00 − 1) + R·(0.1 − 1) = 1.00 − 0.9R → saves iff R > 1.111
Read that second line again: on the 1-hour tier a written prefix must be re-read more than 1.1 times, on average, inside its window, or the write premium ate the savings and then some. The 5-minute tier needs roughly one re-read per four writes. Neither threshold is exotic, but neither is guaranteed either, and nothing in the API stops you from paying premiums on traffic that never comes back.
From re-reads to a per-arrival probability
In production you rarely observe R directly. What you can observe per route is r, the probability that a given prefix arrival recurs within the TTL window. For a geometric recurrence process, R ≈ r/(1−r), which turns the break-evens into per-arrival thresholds:
5-minute tier: r > 0.25/1.15 ≈ 0.217 1-hour tier: r > 1.00/1.90 ≈ 0.526
In words: cache a route on the 5-minute tier only when at least about 22% of its arrivals recur within 5 minutes, and on the 1-hour tier only when more than half recur within the hour. These are measurable quantities. Measure them before you pay premiums, not after.
Point estimates lie on small samples
Two requests, one repeat: is that route at r = 0.5? With two observations, you have no idea. Gating on a point estimate means one lucky repeat unlocks cache writes on a route that will bleed premiums for the rest of the day. The statistically honest gate is a confidence bound: we use the Wilson 95% lower bound on the observed reuse rate, and emit writes only once the lower bound clears the break-even threshold. A perfectly stable route clears the 5-minute threshold on its third request; a noisy route may honestly never clear it, and the correct behavior then is to keep passing it through untouched rather than to cache on hope.
Why no automatic mode does this
Anthropic's automatic mode places and advances breakpoints for you, which solves the annoying part of the API. It does not reason about expected reuse, because it cannot: the provider sees one request at a time, and betting your money on future traffic patterns is not its job. Reuse-aware write decisions require observing your routes over time, deriving per-route recurrence, and being willing to conclude "do not cache this." That conclusion is the entire point: a cost-optimization layer that can never decide against caching is a cost-generation layer on low-reuse traffic.
The checklist version
- Know each route's within-TTL recurrence rate before enabling writes on it.
- Apply the thresholds: r > 0.217 (5m), r > 0.526 (1h), on a confidence bound, not a point estimate.
- Prefer the 5-minute tier unless measured recurrence genuinely supports 1-hour economics.
- Report savings net of every premium paid, or your dashboard is fiction.