VynarisEarly betaGet your API key

Blog · 2026-07-14 · Vynaris Team

The 54x cache-write penalty: what mid-session prompt-cache churn actually costs

A cached token you re-write instead of read costs 12.5x more. Mid-session cache churn burns $249 per 1,000 requests on Opus 4.8. The per-model math, verified.

A cached token you re-write instead of read costs 12.5x more on every Claude model, and 20x on the one-hour cache. One public teardown measured a coding harness re-writing 43,342 already-cached tokens per request. On [Claude Opus 4.8](/models) that churn burns $249 per 1,000 requests, work a cache read would have billed at $22.

Prices verified 2026-07-14 against Anthropic's live pricing page; deepseek-v4-flash from our 2026-07-13 price snapshot.

TL;DR

What we computed and why

[Prompt caching](/glossary/prompt-caching) is sold as a discount: read a cached prefix at 0.1x the input price instead of reprocessing it. That framing hides a second price. Before you can read from cache, something has to write to it, and a write is billed above the base input rate, not below it.

Most posts about caching model the happy path: write once, read many. We modeled the unhappy one. When a harness invalidates its cache mid-session and re-writes a prefix it already cached, every re-written token flips from the 0.1x read rate to the 1.25x write rate. We computed the dollar size of that flip across four models, using the exact multipliers on Anthropic's pricing page and a churn volume measured in public.

The mechanic

Anthropic's pricing page states the multipliers directly, relative to each model's base input price:

Cache operation       Multiplier        Duration
--------------------  ----------------  ------------------------
5-minute cache write  1.25x base input  cache valid 5 minutes
1-hour cache write    2x base input     cache valid 1 hour
Cache read (hit)      0.1x base input   same window as the write

The read-versus-write gap is what bites. A 5-minute write at 1.25x against a read at 0.1x is a 12.5x ratio. The 1-hour write at 2x makes it 20x. Anthropic's own guidance sets the break-even: a 5-minute write pays off after one read, a 1-hour write after two. Below that, caching is a tax, not a discount. Churn is the case where you pay the write and never collect the reads, because the content you cached is gone by the next turn.

The public example comes from a [coding-agent](/glossary/coding-agent) token-overhead teardown (Hacker News, 686 points, 378 comments) that metered two harnesses on the same task. Claude Code's cache-write volume ran from 5.9x to 54x OpenCode's, with mid-session re-writes of 43,342 tokens in one run and 36,899 in another. Those are tokens that were already in cache and got written again.

Assumptions

Assumption                      Value                                 Source
------------------------------  ------------------------------------  -----------------------------
Churn volume                    43,342 tokens re-written per request  systima.ai teardown, run 1
Claude Code total cache writes  53,839 tokens (5 requests)            same
OpenCode total cache writes     1,003 tokens                          same
5-min write / read multipliers  1.25x / 0.1x base input               Anthropic pricing, 2026-07-14
1-hour write multiplier         2x base input                         same
Model              Base input $/1M  5-min write  1-hour write  Cache read
-----------------  ---------------  -----------  ------------  ----------
claude-opus-4-8    5.00             6.25         10.00         0.50
claude-sonnet-5    2.00             2.50         4.00          0.20
claude-haiku-4-5   1.00             1.25         2.00          0.10
deepseek-v4-flash  0.14             0.14*        0.14*         0.0028

*DeepSeek charges no write premium; a write is standard input, a hit is $0.0028/1M. Sonnet 5 shows introductory pricing through 2026-08-31; it rises to $3/$15 input/output on 2026-09-01.

Results: the churn tax per 1,000 requests

Re-writing 43,342 cached tokens on every request, instead of reading them:

Model              Write cost (5m)  Read cost  Wasted       Penalty ratio
-----------------  ---------------  ---------  -----------  -------------
claude-opus-4-8    $270.89          $21.67     **$249.22**  12.5x
claude-sonnet-5    $108.36          $8.67      **$99.69**   12.5x
claude-haiku-4-5   $54.18           $4.33      **$49.84**   12.5x
deepseek-v4-flash  $6.07            $0.12      **$5.95**    50.0x

The Opus row is worth doing by hand, because it is the whole argument in three lines. Writing 43,342 tokens at $6.25/1M costs $0.2709 per request. Reading the same tokens at $0.50/1M costs $0.0217. The difference is $0.2492, and multiplied by 1,000 requests that is $249.22 spent to store data you already had.

On the 1-hour cache the waste climbs to $411.75 on Opus, $164.70 on Sonnet 5, and $82.35 on Haiku. DeepSeek's penalty ratio is the steepest at 50x, but its absolute dollars stay small because its base input is $0.14.

Dollars wasted per 1,000 requests when 43,342 cached tokens are re-written instead of read, by model, log scale
Source: Anthropic pricing verified 2026-07-14 (1.25x write / 0.1x read) and 2026-07-13 snapshot; churn volume from the systima.ai token-overhead report.

The spread across models is 42x, from $249 to $6, which is why the chart uses a log scale. The [cost-per-token](/glossary/cost-per-token) of your frontier model sets the size of the penalty; the churn behavior of your harness decides whether you pay it.

The 54x, in dollars

The teardown's headline was a token ratio. Priced out on Opus 4.8, the same five-request task looks like this:

Harness      Cache-write tokens  Cost per request  Per 1,000 requests
-----------  ------------------  ----------------  ------------------
Claude Code  53,839              $0.3365           $336.49
OpenCode     1,003               $0.0063           $6.27

Same task, same model, same output. The delta is $330 per 1,000 requests, and it is entirely how each harness manages its cache. One appends and reads; the other re-writes. At a million requests a month that is a $330,000 line item with no change in what the model produced.

When caching helps, and when it hurts

Caching is still the largest lever in agent cost, when the reads arrive. The rule from Anthropic's break-even is short enough to keep in your head: if a cached block will be read at least once inside the 5-minute window, cache it; if it will not, do not. Two patterns break the read:

  1. Dynamic content high in the prompt. A timestamp, a request ID, or a per-turn counter placed before the stable [system prompt](/glossary/system-prompt) or [tool](/glossary/tool-use) schemas invalidates everything after it. Prompt caches match on an exact prefix, so a single changed token near the top voids the cache for every token below it. The cache key changes every request, the write fires, and no read ever lands. The fix is placement: put the volatile tokens at the end of the prompt, after the cacheable prefix, so the stable 40,000 tokens keep their cache and only the last few hundred are reprocessed.
  2. Mid-session prefix rewrites. A harness that reconstructs its context each turn, rather than extending it, re-caches the whole prefix every time. This is the 43,342-token case. The fix is structural: append to the cached prefix, do not rebuild it.

Below the break-even, turn caching off. A prompt read once and never repeated costs 1.25x with caching and 1.0x without. Caching a one-shot request is a 25% surcharge.

Run your own prefix size, churn rate, and read count through the cost calculator before you assume caching is saving you money.

What it means for routing

Cross-model routing multiplies this problem. Caches are per model, so every time a [router](/glossary/model-routing) hands a turn to a different model, the new model must write its own copy of the prefix. Route a coding agent between Opus and Haiku on alternating turns and you pay the write penalty on both, which is why interleaved routing saves less than batched routing. We work that number in the [coding-agent router savings analysis](/blog/coding-agent-model-routers-savings-math-2026): the cross-model cache write is the single largest reason a router's real savings trail its advertised ones. The fixed scaffolding cost that drives all of this is measured in our [scaffolding token-overhead teardown](/blog/coding-agent-scaffolding-token-overhead-cost-2026).

Where we are wrong

The 43,342-token figure is one harness on one task, measured by a third party. Your churn will differ, and the honest way to know it is to read your own usage response: cache_creation_input_tokens versus cache_read_input_tokens on every request. If creation stays high after the first turn, you are churning.

Two more caveats. First, the [Batch API](/glossary/batch-api) halves both write and read, so the penalty ratio holds but the absolute dollars fall 50% for non-interactive work. Second, these are first-party API rates; Bedrock, Vertex, and data-residency endpoints carry their own multipliers that stack on top. The ratio is the durable finding. The dollar figures are correct as of the capture date and should be re-verified monthly, because Sonnet 5's introductory pricing ends 2026-08-31.

Sources