Prompt caching
Prompt caching lets a provider store the processed form of a prompt prefix so that repeated requests do not pay full input price for the same tokens. When it works, cached tokens cost a fraction of the standard input rate. When it silently fails, you pay full price and often a write surcharge on top. This page covers the mechanics, the pricing, and the failure modes.
Caching is a prefix match
A cache hit requires an exact prefix match. Any byte change anywhere in the cached prefix invalidates everything after that point. There is no fuzzy matching and no partial credit for content that moved.
On Anthropic's API, the prompt renders in a fixed order: tools, then system, then messages. Everything before your cache breakpoint must be byte-identical between requests for the cache to hit. There is also a minimum cacheable prefix, roughly 512 to 4,096 tokens depending on model. Prefixes below the minimum are not cached at all.
Anthropic pricing: reads, writes, and TTL
Cache reads cost 0.1x the model's input price. Cache writes cost 1.25x input price for the default 5-minute TTL, or 2x for the 1-hour TTL. Verified 2026-08-10.
The TTL choice is a bet on your request cadence. The 5-minute TTL is cheap to write but expires fast. The 1-hour TTL costs more to write and needs more subsequent hits to pay off.
Break-even math
With the 5-minute TTL, two requests break even. The first request pays 1.25x to write, the second pays 0.1x to read, for a total of 1.35x. The same two requests uncached cost 2x. Caching wins on the second request.
With the 1-hour TTL, you need at least three requests. Write plus two reads costs 2x + 0.2x = 2.2x, against 3x uncached. Two requests on the 1-hour TTL cost 2.1x against 2x uncached, so a prefix that is only read once within the hour loses money.
If your traffic reliably re-arrives within 5 minutes, the default TTL is the better price at every hit count. Buy the 1-hour TTL only when gaps between requests exceed 5 minutes.
Silent cache-killers
Cache misses do not raise errors. The request succeeds and bills at full input price plus the write surcharge. The common causes are all small and easy to miss:
- Timestamps or UUIDs in the system prompt. A "current time" line interpolated per request changes bytes on every call, so nothing after it ever hits.
- Non-deterministic JSON serialization. If key order or whitespace varies between requests, the serialized prefix varies too.
- Tool lists that vary between requests. Tools render first, so any change to the tool list invalidates the entire prefix behind it.
- Switching models. Caches are per-model. A request routed to a different model writes a new cache instead of reading the existing one.
Other providers
OpenAI prices cached input as a separate per-model rate rather than a multiplier. DeepSeek and Kimi publish flat cache-hit rates: roughly 10x off standard input on Kimi K3, and 50x off on DeepSeek V4 Flash. Example rates:
| Provider / model | Standard input | Cached input |
|---|---|---|
| OpenAI GPT-5 | $1.25 | $0.125 |
| OpenAI GPT-5.6 Sol | $5.00 | $0.50 |
| DeepSeek V4 Flash | $0.14 | $0.0028 |
| Kimi K3 | $3.00 | $0.30 |
| Anthropic (any Claude model) | 1x | 0.1x read, 1.25x or 2x write |
Prices per million tokens. Verified 2026-08-10. Current rates for every model are on the pricing pages.
Caching is not the batch discount
Anthropic also offers a 50% batch discount for asynchronous workloads. Caching and batching solve different problems: caching cuts the cost of a repeated prefix in live traffic, batching cuts the cost of work that can wait. They are priced independently.
Related
What is a token? explains the units all of these multipliers apply to. Claude pricing has the current per-model input rates the read and write multipliers act on, and all provider pricing covers the rest.