Use the default five minute cache when the same prefix is requested at least every few minutes, because each read refreshes it. Use the one hour cache when gaps between requests exceed five minutes but the prefix is still reused several times an hour. Otherwise, skip caching.
The numbers to work with
The Claude documentation gives these multipliers on the base input price: a five minute write costs 1.25 times, a one hour write costs 2 times, and a cache read costs 0.1 times for most models. Some models list a lower read multiplier, so check the table for yours. Treat the base price as one unit per token of prefix.
Break even for the five minute cache
Two requests without caching cost 2.0 units. With the five minute cache, the first costs 1.25 and the second 0.1, so 1.35 total. It wins from the second request on.
If the entry expires between requests, each request pays a fresh write at 1.25, which is worse than 1.0 for no caching. A five minute cache used with gaps longer than five minutes costs 25 percent more on that prefix than no caching.
Break even for the one hour cache
The first request costs 2.0. Two requests total 2.1, against 2.0 uncached, so it loses slightly. Three requests total 2.2 against 3.0, and it wins from the third request on, provided the reads land inside the hour.
A simple decision rule
- Estimate how many requests share the prefix per hour and the longest gap between them.
- Longest gap under five minutes: five minute cache.
- Gaps over five minutes, at least three reuses per hour: one hour cache.
- One or two uses, or a prefix that changes: no cache.
Mixed lifetimes
If you use both lifetimes in one request, the docs say the one hour entries must come before the five minute entries. A sensible split is a very stable block, such as tool definitions and policy text, on the one hour entry, and a conversation prefix that grows each turn on the five minute entry.
Keep it alive on purpose?
You could send a small request to refresh a cache. That only makes sense if the read cost of the refresh is less than the write cost you would otherwise pay again. Do the arithmetic with your own prefix size before adding a heartbeat job.
Check against your bill
These multipliers are from the documentation as fetched on 19 October 2026 and can change. Confirm them on the live pricing and caching pages, and confirm the real saving by comparing cache read tokens to total input tokens in your usage data.
Quick check
Does a cache read extend the lifetime?
Yes. The documentation says the lifetime is refreshed at no additional cost each time the cached content is used.
Is the one hour cache always better because it lasts longer?
No. Its write costs more, so it only pays off when you reuse the prefix enough times and the five minute entry would have expired between requests.
Sources
Last reviewed: 19 October 2026.
