The timer starts at the cache write, not the end of the response
Anthropic measures the cache lifetime from the last time the cache was written or read, not from the end of its response. That single sentence changes how you schedule follow-up calls.
The vendor gives a worked example. If a response takes 4 minutes to stream, a follow-up request that reuses the same cached prefix must start within about 1 minute of that response completing. Time spent generating output counts against the 5-minute window. A long answer eats most of the window before the next call even begins.
Short answers leave the full window. Long answers leave almost none. If your workload streams long output and then asks a follow-up question, the cache often misses for a reason that has nothing to do with your prompt.
The two TTL choices and their write prices
Anthropic offers a 5-minute default and a 1-hour option at extra cost. The documented multipliers are:
- 5-minute cache write: 1.25 times the base input token price.
- 1-hour cache write: 2 times the base input token price.
- Cache read: 0.1 times the base input token price.
A 1-hour entry costs 60% more to write than a 5-minute entry. It pays off when your follow-up gap is longer than 5 minutes but shorter than an hour, for example a scheduled job that runs every 20 minutes over the same document. For a gap under 5 minutes, the 5-minute entry is cheaper.
If you mix both TTLs in one request, put the 1-hour entry before any 5-minute entry. Anthropic states that longer TTL entries must appear before shorter ones.
What kills the cache before the timer runs out
The timer only matters if the prefix stays identical. These changes invalidate the cache immediately:
- Any change to the cached prefix. Cache keys are a cryptographic hash of the prompt up to the cache control point. One changed token at the start misses the whole entry.
- Tool definition changes. Names, descriptions or parameters invalidate the entire cache.
- Thinking and effort settings. Changing the thinking configuration always invalidates message blocks; tool and system caches are also invalidated on models that render the configuration ahead of them.
- Images and tool_choice. Adding or removing an image invalidates message blocks. A change to
tool_choiceaffects message blocks only.
There is no manual clear. Anthropic states that caches expire on their own and cannot be cleared by hand, so a cache you no longer want still costs nothing to keep idle: it simply expires.
How to measure a cache hit or miss
Read the usage fields on the response. cache_creation_input_tokens and cache_read_input_tokens tell you which path ran. If both are 0, the prompt was not cached, usually because it did not reach the minimum length for the model and platform. A prompt just under the minimum is worth extending to reach it, because a read costs 0.1 times the base input price.
What this means for a cost model
Model the timer, not only the price. A cache that misses because a 6-minute gap exceeded the window costs a full write at 1.25 times base, not a read at 0.1 times base. That is a 12.5 times jump on the cached prefix. Use the Cache Invalidations Cost Multiplier to price a miss pattern, and the Prompt Caching Savings Estimator to compare a cache-hit plan with no caching.
For a batch job that writes a cache inside the batch, remember that Anthropic does not support max_tokens: 0 pre-warming in a batch. The vendor expects the ephemeral entry to expire before the follow-up request runs.
Sources
- Anthropic, Prompt caching, "Cache lifetime" and "What invalidates the cache": platform.claude.com/docs/en/build-with-claude/prompt-caching, read 2026-10-28.
- Anthropic, Batch processing, "What can be batched": platform.claude.com/docs/en/build-with-claude/batch-processing, read 2026-10-28.
