Prompt caching lets Claude store a repeated prompt prefix — your system prompt, tool definitions, a reference document — so later requests reuse it instead of reprocessing it. The catch is the pricing shape: the request that writes the cache pays more than normal input, and only the requests that read it pay less. Caching is therefore a bet that the prefix will be reused. This article gives you the numbers to price that bet.
The three multipliers
All cache pricing is expressed as a multiplier on the model's base input price, and it works the same on every platform that supports caching (the Claude API, Claude Platform on AWS, Amazon Bedrock, Google Cloud, and Microsoft Foundry):
| Operation | Multiplier | Claude Opus 4.8 ($5/MTok base) | Claude Haiku 4.5 ($1/MTok base) |
|---|---|---|---|
| 5-minute cache write | 1.25x | $6.25/MTok | $1.25/MTok |
| 1-hour cache write | 2x | $10.00/MTok | $2.00/MTok |
| Cache read (hit) | 0.1x | $0.50/MTok | $0.10/MTok |
The two write tiers correspond to how long the entry stays valid: the default cache_control: {"type": "ephemeral"} gives a 5-minute time-to-live, while {"type": "ephemeral", "ttl": "1h"} keeps it for an hour at a higher write price.
The break-even calculation
Compare total multipliers across N requests that share the same prefix.
5-minute cache: two uncached requests cost 1x + 1x = 2x. Cached, they cost 1.25x (write) + 0.1x (read) = 1.35x. Break-even arrives at the very first reuse — the 0.25x write premium is repaid by the 0.9x saved on one read, and every further hit saves another 0.9x.
1-hour cache: the write premium is a full 1x, so one read isn't enough (2x + 0.1x = 2.1x vs. 2x uncached). You need at least two reads within the hour: 2x + 0.2x = 2.2x beats 3x uncached, and it improves from there.
In dollars, on Claude Opus 4.8 with a 50,000-token shared prefix: uncached, each request's prefix costs 50,000 × $5/1M = $0.25. A 10-turn conversation reprocessing that prefix every turn pays $2.50. With a 5-minute cache: one write at $0.3125 plus nine reads at $0.025 each = $0.5375 — under a quarter of the uncached cost.
When the bet goes wrong
The failure mode is paying the write premium and never collecting the reads. Three common causes:
Byte-level prefix changes. The cache key is an exact prefix match — a timestamp or request ID interpolated into the system prompt, or JSON serialized in a different key order, invalidates every breakpoint after the change. Keep dynamic content after the cached prefix.
TTL mismatch. If requests arrive 20 minutes apart, a 5-minute cache rewrites every time — you pay 1.25x forever. Either upgrade to the 1-hour tier (worth it from two reads per hour) or accept uncached pricing.
Prefix too short. There is a minimum cacheable length: 512 tokens on Claude Fable 5, 1,024 on Opus 4.8, Sonnet 5, Sonnet 4.6, and Haiku 4.5 (and 1,024 for Fable 5 on Bedrock). Shorter prefixes simply don't cache — no error, no savings.
Also note a concurrency subtlety: a cache entry only becomes readable after the first response begins streaming, so parallel identical requests all pay full price. For fan-out workloads, let the first request start before firing the rest.
Reading the result on your bill
Every response reports cache_creation_input_tokens (written) and cache_read_input_tokens (served from cache) alongside plain input_tokens. A healthy caching setup shows reads dwarfing writes. If writes dominate, one of the failure modes above is eating your discount. Cache multipliers also stack with the Batch API's 50% discount — and because batches can take longer than five minutes, use the 1-hour tier for shared context in batch jobs. Platform nuance: Bedrock supports explicit cache_control breakpoints only, not the automatic top-level caching mode — details in prompt caching on Bedrock.
Where to go next
See the token bill anatomy for how cache line items land on the invoice, and context strategy for how caching changes the summarize-vs-full-history decision.