The Five-Minute Window

Anthropic cut Claude's prompt cache TTL from 1 hour to 5 minutes around March 6-7, 2026, and there was no blog post, no deprecation notice, no API version bump. The change caused a 20-32% increase in cache creation costs for workloads that had been designed around the longer window. A developer parsed 119,866 Claude Code API calls from January through April 2026 and found the transition cleanly dated: 1-hour TTL by default from February 1, with clean consistent 1h behavior for 33 consecutive days across independent machines, then silently reverted to 5-minute TTL for most request types around March 6-8.

I do not work for Anthropic. I cannot tell you why they made this change, and I will not guess. What I can tell you is what a five-minute TTL costs the vendor, what a one-hour TTL costs the vendor, and what that arithmetic tells you about prefix caching as an architectural pattern once you are operating it at the scale Anthropic is operating it.

The lifetime is measured from the start of the request that writes or reads the cache entry, and time spent generating a response counts against the lifetime: 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. The clock is not generous. Anthropic's cache expires after roughly 5 minutes of inactivity, and each cache hit resets the timer. If you maintain a coding session where messages arrive every minute or two, the cache stays warm indefinitely, alive as long as you keep using it.

The pricing structure is exact. Anthropic offers two cache tiers: a 5-minute cache where writes cost 1.25x the base input price, and a 1-hour cache where writes cost 2x; cache reads on both tiers cost 0.1x. The math is transparent, and the difference between the two tiers is not subtle. A 5-minute cache that gets reused five times inside the window costs less than a 1-hour cache that gets reused five times inside an hour. A 1-hour cache that gets reused twenty times costs less than a 5-minute cache recreated four times to cover the same span. The question is not which tier is cheaper in principle. The question is which tier your traffic pattern makes cheaper in practice, and which tier the vendor can afford to offer you at scale.

A cache is a bet on reuse. The vendor is holding GPU memory for you in the hope that you will hit the same prefix again before the TTL expires. A 100K-token prompt might produce a KV cache of 500MB-1GB per request, and Anthropic is storing and retrieving this data in GPU memory for millions of concurrent users simultaneously; that is why there is a 25% surcharge on cache writes. You are not paying for compute alone. You are paying for VRAM allocation, the cost of keeping that memory warm and indexed and ready to serve you when the next request arrives.

A one-hour TTL is twelve times longer than a five-minute TTL. If the reuse rate inside that hour is high enough, the economics work. If the reuse rate is sparse, the vendor is holding memory for you that nobody is reading, and the cost of that hold is being distributed across every other request the system is serving. The margin on inference is not wide enough to absorb indefinite speculative holds. When you see a TTL cut from 60 minutes to 5, you are seeing the vendor tell you what the actual utilization data showed.

Analysis of the real dataset showed February, the month Anthropic was defaulting to 1h TTL, had only 1.1% waste from 5m activity; every other month showed 15-53% overpayment from 5m cache re-creations, and the cost difference was explained entirely by TTL tier, not by usage volume. That sentence is the whole story. The one-hour window was economically correct for February traffic, and economically wrong for March traffic, and the change happened because the traffic changed or the load changed or the infrastructure team ran the numbers and decided the subsidy was unsustainable.

The pattern this exposes is simple. Prefix caching in production is not a feature you configure once. It is a bet you re-price continuously, based on what the actual utilization curve looks like across the entire request population. Anthropic quietly changed the prompt cache TTL from 60 minutes down to 5 minutes in early 2026, and for many production workloads this single change increased effective API costs by 30-60%. The increase was real, the complaints were justified, and the change was not rolled back. That tells you the vendor could not afford the original TTL at the scale they were operating.

The second thing it tells you is that the long-TTL tier still exists. Anthropic offers a 1-hour cache duration at additional cost, which means they will sell you the longer window if you are willing to pay the 2x write surcharge that covers the actual cost of holding that memory. The five-minute default is not a product limit. It is the break-even point the infrastructure team landed on after looking at what aggregate traffic was actually doing. If your workload genuinely reuses a prefix often enough to justify the 2x write cost, you can still have the hour. You just have to opt in and accept the price.

What got cut to ship the five-minute default was the subsidy. The one-hour window was introduced, worked for a month, then reverted when the economics stopped working. Anthropic reduced the TTL for the Claude Code prompt cache from one hour to five minutes for many requests, and user Sean Swanson posted a bug report showing that Anthropic introduced a one-hour cache for Claude Code context around February 1, then changed it back to a five-minute cache around March 7. The vendor shipped the longer window, measured what it cost them, and pulled it back. That is not a bug. That is a production system adjusting to its own cost curve.

The lesson for anyone building on top of a caching primitive is this: the TTL you get by default is the TTL the vendor can afford to give everyone. If your workload wants a longer window, you need to measure whether you can afford the higher write cost, and you need to design your system so it does not break when the default changes. If you built a caching strategy based on the original 1-hour window, and most people did because that is what the docs showed, your cache hit rate has been cratering for weeks and you might not have noticed.

The fix is mechanical. If you need the hour, you can request the 1-hour cache duration explicitly and pay the surcharge. If you cannot afford the surcharge, you redesign around the five-minute window: batch tighter, send keepalive pings to reset the timer, or accept that your cache writes are being recreated more often and tune your request cadence to match. Some teams now send a lightweight ping request every 4 minutes to reset the TTL clock, which works if the cost of the ping is cheaper than the cost of the cache recreation. The arithmetic is not hidden.

What you cannot do is assume the default will stay stable. Silent infrastructure changes happen when the cost model underneath them shifts. The vendor cannot announce every load-balancing tweak, every capacity adjustment, every TTL revision that keeps the service economically viable. If your margin depends on a specific cache behaviour, you instrument it, you log the hit rate, and you set an alert for when it drops. That is production discipline, and it is the only reliable defence against changes you will not see coming.

The five-minute window is the number Anthropic landed on after running the service at scale and measuring what it actually costs to hold a prefix in VRAM for millions of users. It is not a generous number. It is the number that works. If you want more, you can buy more. If you cannot buy more, you design for the number you get. That is the deal, and it has been the deal since the first time someone tried to run a cache in front of a system with single-digit-millisecond median latency and ten-figure request counts per day.

The vendor knows what got cut. The vendor knows why it got cut. The vendor will not tell you, because the vendor cannot tell every customer why every default changed without turning the changelog into a cost-accounting seminar. What they will tell you is the new number, the opt-in path to the old number, and the price. Everything else is in the arithmetic.

Tarry Singh is the founder and CEO of Real AI (realai.eu), an enterprise AI advisory and deployment firm working with global enterprises on production agent systems, model risk, and AI sovereignty strategy. He also leads Earthscan (earthscan.io) for Energy AI, and is a founding contributor to the EU-funded HCAIM and PANORAIMA programmes for responsible AI education across European universities. He writes at tarrysingh.com.