Prompt caching lets a provider reuse the processed form of a prompt prefix you send repeatedly, so you pay a reduced rate to read it again. The prefix must match exactly. Entries expire after a short time unless reused, and writing the cache costs slightly more than a normal request.
What gets cached
The cache holds a prefix, not a whole conversation. In the Claude documentation the prefix is built in a fixed order: tool definitions first, then the system prompt, then messages, up to the block you mark with a cache breakpoint. A change at one level invalidates that level and everything after it.
That order matters. If you edit a tool description, the system prompt and every message after it lose their cache hits too.
Exact match only
The documentation says cache hits require a 100 percent identical prefix. One changed character before the breakpoint is a miss. A timestamp in the system prompt, a reordered tool list, or a different user name inserted near the top can quietly turn every request into a miss.
There is also a minimum length. Prompts shorter than the model's minimum are processed without caching and no error is returned. The minimum differs by model in the docs I fetched, from 512 tokens on some newer models to 4,096 on some older ones, so check the table for the model you use.
How long entries last
The default lifetime is five minutes, measured from the start of the request that wrote or read the entry. Each read refreshes it at no extra charge. An optional one hour lifetime costs more to write.
So steady traffic keeps a five minute cache alive indefinitely. A job that runs once every ten minutes will miss every time.
What it costs
Relative to the base input price, the documentation lists a five minute write at 1.25 times, a one hour write at 2 times, and a read at 0.1 times for most models. Some models list a lower read multiplier, so read the table for yours. Breakpoints themselves add no cost. You pay for cache writes, cache reads, and uncached input.
A five minute write plus one read costs 1.35 units against 2.0 for two uncached requests. Caching pays for itself after a single reuse inside the window.
How to confirm it worked
The response usage object reports cache_creation_input_tokens and cache_read_input_tokens. If both are zero, nothing was cached. Total input is the sum of cache reads, cache writes, and the uncached input_tokens after the last breakpoint.
Other providers also document automatic prefix caching with their own minimum lengths and retention rules, so the habits here carry over, but the numbers do not. Read your provider's page.
Quick check
Does the cache store my answers?
No. It stores the processed prompt prefix, which lets the model skip reprocessing it. The output is still generated fresh each time.
Why did my cached request show zero cache reads?
Common causes are a prompt below the minimum length, a prefix that changed, an expired entry, or a changed tool definition earlier in the prefix.
Sources
Last reviewed: 19 October 2026.
