Prompt-caching economics, in full
| Cache read price, standard | 0.1x standard input |
|---|---|
| Cache read price, Fable 5.1 | 0.025x standard input |
| Cache read price, Mythos 5.1 | 0.025x standard input |
| Cache read price, Opus 5.5 | 0.05x standard input |
| Cache write price, 5-minute TTL | 1.25x standard input |
| Cache write price, 1-hour TTL | 2x standard input |
| Break-even, 5-minute TTL | 2 requests |
| Break-even, 1-hour TTL | 3 requests |
| Max cache breakpoints per request | 4 |
| Breakpoint lookback distance | 20 content blocks |
What silently stops a cache from being read
A timestamp or datetime.now() interpolated into the system prompt | The prefix differs on every request, so there is never a prior entry to read. |
|---|---|
| A UUID, request id or session id early in the content | Same as a timestamp — every request is byte-unique from that point onward. |
json.dumps(d) without sort_keys=True, or iterating a set | Serialisation order is non-deterministic, so the bytes differ run to run. |
| Building the tool list per user or per mode | Tools render at position 0. Any change there invalidates system and messages too. |
| Switching model mid-conversation | Caches are model-scoped. The new model starts cold. |
| Conditional system-prompt sections behind a feature flag | Every combination of flags is a separate prefix, so hits are split across variants. |
Changing top-level effort or thinking between requests | Both render into the prompt, so a change invalidates the messages cache. On models with per-message effort, make the change in a system message inside messages instead. |
| Editing, trimming or re-inserting an earlier turn | The prefix changes from that turn onward. On Fable 5.1, Opus 5.5 and Sonnet 5.5 it also invalidates every later thinking block — keep histories append-only. |
| A single turn that adds more than 20 content blocks | A breakpoint walks back at most 20 blocks to find a prior entry. Long agentic turns overshoot it and miss silently. |
| A prefix shorter than the model's minimum cacheable length | Below the minimum nothing caches and no error is raised. The minimum is not the same across models — see the table. |
Reading this table correctly
Every figure here describes the economics of caching itself — what a read and a write cost relative to standard input, and how many requests it takes before caching wins. It does not include the minimum prefix a request must clear before any of this applies at all; that is a separate, non-monotonic figure with its own page, and conflating the two is a common source of confusion.
The read price is no longer one number
Until Fable 5.1, one read multiplier covered every model. It no longer does: the table lists the standard rate and, beneath it, the models that read cheaper — Fable 5.1 and Mythos 5.1 at the deepest discount, Opus 5.5 between them and everyone else. Writes did not change. Two consequences follow. A long session that re-reads a large prefix every turn gets cheaper on those models than the headline input price suggests. And a cache miss gets relatively more expensive, because the gap between a read and a fresh input token is wider — which makes keeping the cache warm worth more engineering on those models than anywhere else. The published break-even request counts hold for every model's actual read rate; this site checks that in its test suite rather than assuming it.
Why a write costs more than a read, and why that's not a flaw
The first request against a new prefix has to establish the cache entry, which costs more than a standard read would have — that's the up-front cost the savings on every later read are earned back against. A prefix read only once, ever, never recoups it; caching pays off only on genuinely repeated reads within the TTL.
Choosing between the two TTLs
The shorter window suits dense, closely spaced reuse; the longer one suits reuse that is more sporadic but still reliably inside the longer window. On the models with the deepest read discount, Anthropic's guidance is that a cheap keep-alive request on the short TTL usually beats the longer TTL's pricier write for gaps inside the longer window — see cache reads got cheaper on Fable 5.1 and Opus 5.5.
The limits and the silent invalidators
The breakpoint and lookback rows aren't pricing, but they constrain how a request can be built to use the pricing. The second table lists the patterns that stop a cache from ever being read, without an error — two of them new with the latest models, where editing an earlier turn also invalidates thinking. See too many cache breakpoints in one request and a breakpoint that misses the lookback window.
Related
See the minimum-cacheable-prefix table and the prompt-caching savings calculator.
Verified 2026-09-30 against claude-api skill — shared/prompt-caching.md and Anthropic's pricing page (canonical: https://platform.claude.com/docs/en/build-with-claude/prompt-caching, https://platform.claude.com/docs/en/about-claude/pricing).
Verified 2026-09-30 against claude-api skill — shared/models.md, model-migration.md + SKILL.md model table and Anthropic's pricing and model-deprecation pages (canonical: https://platform.claude.com/docs/en/about-claude/models/overview, https://platform.claude.com/docs/en/about-claude/pricing, https://platform.claude.com/docs/en/about-claude/model-deprecations).