Prompt-caching economics, in full
| Cache read price | 0.1x 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 |
Reading this table correctly
Every figure here describes the economics of caching itself — what a read and a write actually cost relative to standard pricing, and how many repeated reads it takes before caching wins. It does not include the minimum prefix length required before any of this applies at all; that's a separate, non-monotonic figure covered on its own dedicated page, since conflating the two is a common source of confusion.
Why a write costs more than a read, and why that's not a flaw
The first request against a new prefix has to actually establish the cache entry, which costs more than a standard read would have — that's not caching failing to save money, it's the up-front cost the savings on every subsequent read are earned back against. A prefix read only once, ever, never recoups that write cost; caching only pays off on genuinely repeated reads within the TTL window.
Choosing between the two TTLs
The shorter window suits dense, closely-spaced reuse; the longer one suits reuse that's more sporadic but still reliably within an hour. Picking the wrong one for your actual request cadence either lets a cache expire between genuinely related requests or pays for a longer write than your reuse pattern justifies — see a working prompt-caching implementation guide for how to actually structure a request around this choice.
The breakpoint limits are worth reading alongside the pricing
The maximum breakpoints and lookback figures in this table aren't pricing details, but they directly constrain how you can structure a request to take advantage of the pricing above them — a request that needs more independently-cacheable segments than the maximum allows, or that adds more content in one turn than the lookback distance covers, needs restructuring regardless of how favourable the underlying read and write economics are. See more than 4 cache breakpoints in one request and a cache breakpoint missed because of the 20-block lookback limit for what happens when either limit is hit in practice.
Related
See the minimum-cacheable-prefix table for the separate, per-model floor that has to be cleared before any of this applies, and the prompt-caching savings calculator to run these numbers against your own request pattern rather than reasoning through them by hand.
Verified 2026-08-08 against claude-api skill — shared/prompt-caching.md (canonical: https://platform.claude.com/docs/en/build-with-claude/prompt-caching).