This explains a lot about the quota burn rate increase people have been reporting. A 1h → 5min cache TTL change means cache_create operations happen 12x more frequently for the same session, and cache_create tokens cost significantly more than cache_read.

For anyone trying to work around this in the meantime: keeping sessions shorter and more focused (one task per session) reduces the impact since you hit cache invalidation less often. Also, structuring your CLAUDE.md to front-load the most critical context means the cache_create tokens are at least spent on high-value content.

Would be great to get official transparency on pricing-related infrastructure changes like this — silent downgrades erode trust, especially for teams budgeting based on observed costs.

Thanks for the writeup — the JSONL analysis and date pinpointing is good detective work. Let me walk through what's going on.

The March 6 change makes Claude Code cheaper, not more expensive. 1h TTL for every request could cost more, not less.

The cost tables assume every 5m-tier write would have become a cheap cache read under 1h TTL. That's only true when the cached content is re-accessed within the hour. A meaningful share of Claude Code's requests are one-shot calls where the cached context is used once and not revisited — the 1h TTL those would just be more expensive writes with no follow-up read to amortize them, because 1h writes cost more than 5m writes (roughly 2× base input vs. 1.25× — see the prompt caching docs). So "1h everywhere" isn't the cheaper baseline the tables frame it as; for the requests that are on 5m, it would be more expensive.

Prompt cache optimization is something the Claude Code team invests heavily in on an ongoing basis. Different request types benefit from different TTL tiers, and the client selects per request. The March 6 change you spotted is part of that ongoing optimization work — it wasn't a regression, on balance it lowers total cost for users across the request mix. The pre-March-6 behavior (what your Phase 2 captures) wasn't the intended steady state.

A bug fixed in v2.1.90

A client-side bug could cause sessions that have used up all their subscription quota at application start and started using overages to stay on 5m TTL until their session exits. This was fixed in v2.1.90.

Responses to your specific asks

1. Was there a change? Yes — March 6, intentional, part of ongoing cache optimization. You pinpointed the date correctly.
2. Intended TTL behavior? The client picks per request based on the expected cache-reuse pattern; there is no single global default, by design.
3. Restore 1h as the default / expose as configurable? 1h everywhere would increase total cost given the request mix, so we're not planning a global toggle.
4. Cache-read quota weighting (ref [BUG] Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage #45756): we'll follow up there.

Jarred what I'm getting from your convoluted post is the change is to reduce costs to Anthropic at the users' expense.

A lot of time typing "claude pls open an issue about this, add lots of detail"

Classic scammer tactics: first, lure users in by promising a huge deal, then scam the hell out of them.

The March 6 change you spotted is part of that ongoing optimization work — it wasn't a regression, on balance it lowers total cost for users across the request mix.

How does say a Claude Pro user benefit from this "lower total cost" exactly?

User has already paid the monthly/annual subscription cost. The money is already in Anthropic's bank acocunt.

What we are seeing instead is we exhaust the session quota under an hour and have to wait 4 hours to resume our work. This effectively wipes out our day.

This means even if I stay up 24 hours to try and max my utilization, I get about 4 hours of real use out of my subscription.

Responses to your specific asks

1. Was there a change? Yes — March 6, intentional, part of ongoing cache optimization. You pinpointed the date correctly.
2. Intended TTL behavior? The client picks per request based on the expected cache-reuse pattern; there is no single global default, by design.
3. Restore 1h as the default / expose as configurable? 1h everywhere would increase total cost given the request mix, so we're not planning a global toggle.

If the caching TTL is being so drastically changed -- from 1 hour to 5 minutes is a humongous change -- and that change has this oversized impact on user experience to the point that Claude is effectively unusable for the majortity of the day....

... you ought to give your paying customers the control to toggle this the way they want. Let us experiment with setting it at 5 minutes, 15 mins, or 1 hour. With some experience we will figure out what works best for our way of working -- and will apply the right settings for ach session. Just like selecting a model, enabling extended thinking, or turning on plan mode. And I am sure community will find optimal ways of utilizing the cache TTLs that lower the cost for Anthropic as well in the long run.

PS: The drastic drop in user experience seen in mid March that I experienced first-hand is compelling me to add this voice. Otherwise, I am deeply respectful of the technical work being done by Anthropic team and wish you the very best -- want to see you succeed and make greater things. Cheers!

Jarred’s response was very informative and very transparent, but came at the wrong time. Instead of having this answer as a post-mortem, it should have been a pre-mortem.

As amazing as is your product, I sense the lack of transparency and strategical thinking from the product team.

You need to be clear about it - every change that touches consumption limits or has a probability to change how customers are billed - this must be announced well well in advance. The folks are getting tired of new features, while their regular workflows are starting to misbehave and their limits are getting smaller and smaller.

The only proper way now is to make your roadmap public. This is the best thing you can do for yourself. Not so much for the customers. They will learn to live with the TTLs, with the bugs, and in the end, they will vote with their wallets. But the optics are getting really bad really quickly now for Anthropic.

My usage is API usage and not a subscription, this is a good change, works out cheaper.

My usage is API usage and not a subscription, this is a good change, works out cheaper.

API was always 5 minutes, don't spread misinformation. This is a bad overall change.

@Jarred-Sumner How does this work out cheaper? People not paying for caching writes? How about stop charging people caching writes then as I am pretty sure OpenAI does not charge extra for caching, it's done automatically.

Not to mention, you are expecting people to be able to read/process/formulate and then type a reply to every conversation turn within 5 minutes or risk a 10x token use?

This is AFTER changing limits to burn them faster during peak hours?

How is any of this customer-friendly? We're risking our tokens burning TWENTY TIMES FASTER and you are out here saying it's cheaper? No bro, it's to make YOUR costs cheaper. Be honest about it at least.

My usage is API usage and not a subscription, this is a good change, works out cheaper.

API was always 5 minutes, don't spread misinformation. This is a bad overall change.

Via CC? Since when is the caching different between subscription and API different via CC? If you're suffering from lack of 1h caching then it sounds like you're not even using CC enough to hit any subscription limits.

Via CC? Since when is the caching different between subscription and API different via CC?

Literally check the documentation and the results of this exact thread? Are you being dense?

If you're suffering from lack of 1h caching then it sounds like you're not even using CC enough to hit any subscription limits.

What? It's the exact opposite. 1h caching prevents you from resending every message as cache writes every 6 minutes.

Yeah it makes sense to me. I use the Claude dope daily and notice it slacking and switched over to Codex which can't write, but can code. Claude's ability to keep context definitely declined or feels 'throttled' or nerfed. Thanks for writing this. As someone that's been around the block I think they found it more profitable to sell the sizzle, than the steak. You can see the turn of events from the political pressure to the inflated claims on mythos, the cyber use case restrictions. They're not what they were and it's clear.

Via CC? Since when is the caching different between subscription and API different via CC?

Literally check the documentation and the results of this exact thread? Are you being dense?

CC doesn't go to different places if you're using a subscription vs an API Key. 😆

@phillip-haydon Where "CC goes" is irrelevant. API keys are distinct from subscription keys. If these are distinct entities, then Anthropic's servers obviously can and do treat the requests differently.

In pseudo code:

if (isAPIKey(key)) {
  // ... apply API key TTL, etc ...
} else {
  // ... apply subscription TTL, etc ...
}

Here's the API docs on prompt caching from January: https://web.archive.org/web/20260124153111/https://platform.claude.com/docs/en/build-with-claude/prompt-caching

By default, the cache has a 5-minute lifetime. The cache is refreshed for no additional cost each time the cached content is used.

If you find that 5 minutes is too short, Anthropic also offers a 1-hour cache duration at additional cost.

For more information, see 1-hour cache duration.

So I feel the need to reiterate what @hi-fox said:

Literally check the documentation and the results of this exact thread? Are you being dense?

If you can't wrap your head around this, I'd recommend spending more time sharpening your programming skills and spending less time in Claude Code.