Cache TTL silently regressed from 1h to 5m around early March 2026, causing quota and cost inflation

Yeah this change is terrible, need to compact every time I plan on stopping coding for 5 min. At least increase cache for max users.

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 #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.

I mean how do you scale this otherwise?... some people gotta get real...

With a fair middle ground. 15 minutes would be a better balance.

This perfectly explains why it would take hours before I ran out of Claude on Pro to now running out in 20 minutes. My sessions are a lot longer than 5 minutes, the majority of the time due to my codebase.

Instead of posting a wall of AI slop you could have posted literally 2 lines

Independent data confirming per-request TTL selection

Adding data from a different user to corroborate @Jarred-Sumner's description of per-request TTL optimisation.

Setup: ~407k API turns, Nov 2025 – Apr 2026, two machines (UK and DE), both Max subscription and Vertex billing.

The phase timeline matches OP's, independently confirming the Mar 6 date. Main conversation turns and subagent turns shown separately — the split is where per-request selection becomes visible:

| Period | What happened | Max (main turns) | Max (subagent turns) | Vertex |
|--------|--------------|-------------------|----------------------|--------|
| Nov 25 – Jan 28 | Pre-1h | 100% 5m | 100% 5m | — |
| Jan 29 – Feb 6 | 1h rollout | ~58% | ~40% | — |
| Feb 7 – Mar 5 | Stable 1h | 0% | 14% | — |
| Mar 6 – Mar 31 | Per-request selection | ~20–45% | 99% | 100% |
| Apr 1 onwards | Post v2.1.90 bug fix | 0–6% | 100% | 100% |

_(Values are 5m share of cache_creation tokens. UK/DE combined — no geographic difference for subagents. ~255k Max main turns, ~103k Max subagent turns, ~35k Vertex turns.)_

The pattern is clear: subagents moved to 5m earlier and more completely than main turns, consistent with the client putting one-shot context on the cheaper write tier. Main conversation turns — where the cache will be re-read on the next turn — stayed on 1h. The Apr 1 improvement in main turns aligns with the v2.1.90 bug fix @Jarred-Sumner mentioned.

One addition — Vertex is always 5m. Across 35k Vertex-billed turns (UK and DE), every cache creation is ephemeral_5m, zero exceptions. In 49 sessions where we hit the Vertex 200k context limit and billing flips to Max mid-session, the TTL tier changes instantly at the boundary. This is expected — the prompt caching docs note that 5m is the default API cache lifetime with 1h available at additional cost, and that automatic caching support for Vertex AI is "coming later."

I mean people will use long session for work they actually care about, right?
<img width="400" height="300" alt="Image" src="https://github.com/user-attachments/assets/051e6c80-54e1-4cd9-af54-bb5c5d9143fb" />

Instead of posting a wall of AI slop you could have posted literally 2 lines

I see you on every thread insulting these people who've spent a lot of time crafting a quality bug report. Please stop.

And no, two lines would not suffice. The data is important.

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.

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

Making these changes silently costs users MASSIVELY because they have to figure out if they're doing something wrong or if they were rug pulled.

When they do finally do something wrong, they have to again check if they were rug pulled or if it was there error because they no longer trust you not to secretly rug pull.

Do NOT do that. The real bug here was rug pulling your users without sufficient notification! It leads to massive massive costs in wasted effort.

Thanks for the detailed reply.

One gap still needs a direct answer. And I need to correct some of my original math.

The original post treated all 275M 5m-tier tokens as waste. That was an error. When you separate by session type, the picture changes.

| Session type | Calls | 5m tokens | 1h tokens | Read:Write | Share of all calls |
|-------------|-------|-----------|-----------|------------|-------------------|
| Main session | 46,376 | 35.3M | 165.1M | 21.8:1 | 38.7% |
| Subagent | 73,490 | 239.8M | 134.5M | 9.1:1 | 61.3% |

87% of all 5m tokens come from subagent sessions. Subagents have a 1.4-second median inter-turn gap. Their caches almost never expire under 5m. For them, a 5m write at $3.75/MTok is genuinely cheaper than a 1h write at $6.00/MTok. The 1h tier buys them nothing.

Corrected numbers:

| | Tokens | Impact |
|---|--------|--------|
| Subagent 5m savings | 239.8M | -$539.63 (saved vs 1h writes) |
| Main session 5m waste | 35.3M | +$121.64 (upper bound, assuming all were expired rewrites) |
| Net | | Users saved ~$418 |

The original $949 figure was wrong. Just wanted to own up to that and put that on the record.

API users who pay per token came out ahead from the March 6 change. That part of the response was correct, and it missed it because I didn't separate session types. Fair enough.

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.

But the cost correction does not resolve the subscription problem.

I pay $200 per month for Max 20x. A lower API bill does not help me. My limit is quota, not token price.

If this change helps API users, good. Subscription users should see a benefit too, or at least no loss. That is not what happened in March.

I have been a subscriber for over six months. I had never hit the 5-hour limit. I had never hit the weekly limit. March was the first month where both started happening.

Many Max users report the same pattern. Same plan. Less usable time per window. I am not using openclaw or anything like that I am using https://github.com/gsd-build/get-shit-done, could the march 6 changes be negatively effecting that type of workflow?

So the core question is simple. If the routing change was a net win, why did subscription capacity drop at the same time?

## 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.

If I am understanding correctly, that sequence does not fit my account.

• I did not enter overage.
• I was not billed for overage.
• I still hit the 5-hour and 7-day limits for the first time in March.

So this bug may explain some reports, but it does not explain mine.

I also took a look at the CHANGELOG for v2.1.90 but see no mention of that bug. Is this the first time it's being reported? I do see

Fixed an infinite loop where the rate-limit options dialog would repeatedly auto-open after hitting your usage limit, eventually crashing the session
Fixed --resume causing a full prompt-cache miss on the first request for users with deferred tools, MCP servers, or custom agents (regression since v2.1.69)

## 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](https://github.com/anthropics/claude-code/issues/45756)): we'll follow up there.

1. Thank you for being transparent about this. Has there been any changelog describing exactly what changed?
2. Eagerly awaiting to get some concrete answers soon. I really want to continue my subscription but this current bug + the new 5am–11am PT (i.e. the majority of Americans Work Hours which I use Claude the most) extra burn rate it making a once great service unusable.

The data has been slowly building up and points to a very likely economic and rational conclusion : Anthropic is effectively constructively terminating its Max subscription plans with the eventual goal of an enterprise-first (or only) focus, planning to offer only (1) massively higher tiered (i.e., expensive) subscription plans or (2) dramatically stricter plan limits going forward.

The term "constructive termination" is being used in this case because Anthropic appears willing to slowly attrit and lose customers to churn through silent degradation rather than transparently communicate plan, limit, model changes to its customers.

The likely rational economic conclusion is that this is in an attempt to salvage subscription ARR for as long as possible, while making changes that reduce negative margins, ramp up enterprise business, and slow churn through publicly ambiguous responsibility and technical explanations for regressions.

We are likely heading towards an era where liberal access to frontier models will be restricted to large enterprises and impose dramatic cost barriers to usage by individuals and smaller teams. Without very clear and open communication from Anthropic that makes firm commitments around future expectations for individuals and teams using subscriptions to plan around, users should base their future plans around the expectation of having less access to these models than today.

For max subscribers who are running into this, having the telemetry disabled may be the cause: https://github.com/anthropics/claude-code/issues/45381

With the amount of issues we've all been putting up with while paying full price, all while OpenAI has been resetting limits for everyone; it's time we get compensated.

Instead of posting a wall of AI slop you could have posted literally 2 lines

Who should have posted 2 lines? Jarred? OP? both?

For max subscribers who are running into this, having the telemetry disabled may be the cause: #45381

Seems like an easy way to implicitly tax OAuth cheaters.

> For max subscribers who are running into this, having the telemetry disabled may be the cause: #45381 Seems like an easy way to implicitly tax OAuth cheaters.

Don't see the connection. More like "allow for surveillance or we'll make you"

> > For max subscribers who are running into this, having the telemetry disabled may be the cause: #45381 > > > Seems like an easy way to implicitly tax OAuth cheaters. Don't see the connection. More like "allow for surveillance or we'll make you"

It's not that. It's that through telemetry Anthropic is able to make a better guess are you running a different harness than CC or not.

But running a different harness is always against the ToS, so I can't blame them.

👋 1h prompt cache is nuanced actually. It costs more for cache writes, and less for cache reads. Whether you benefit from cheaper cache reads depends on your usage pattern -- context window size, whether the query is the main agent or subagent, etc.

We have been testing a number of heuristics to give subscribers better prompt cache hit rates, which means lower token usage and lower latency, when it works. But this effect is far from uniform due to the nuance above. Say you use 1h cache for an agent, but only used the agent to make a single query -- in this case the 1h cache would be wasted and you'd be overcharged.

At this point we have rolled out 1h prompt cache by default in a number of places for subscribers to optimize cache duration based on real usage patterns, but we actually keep it at 5m for many queries also (eg. subagents, which are rarely resumed so you'd be paying for them even though they do not benefit from 1h). We also are not defaulting API customers to 1h yet -- this needs more testing to make sure it's a net improvement on average.

Separately, when we do this kind of experimentation, we use experiment gates that are cached client-side. When you turn off telemetry we also disable experiment gates -- we do not call home when telemetry is off -- so Claude reads the default value, which is 5m. We will soon be changing the client side default to 1h for a few queries, since we now feel good that it is a small token savings on average for those queries. We will also give you env vars to force 1h and 5m.

In any case, the token savings is nowhere near 12x unfortunately. It is a small win though, that we have been in the process of rolling out to everyone. Hope the explanation helps.

More here: https://platform.claude.com/docs/en/build-with-claude/prompt-caching#pricing

@bcherny

At this point we have rolled out 1h prompt cache by default in a number of places for subscribers ... We also are not defaulting API customers to 1h yet -- this needs more testing to make sure it's a net improvement on average.

how do api-key users do that? (opt-in?) currently seems impossible?
also https://github.com/cnighswonger/claude-code-cache-fix/issues/14#issuecomment-4237401358 + https://news.ycombinator.com/item?id=47743508

We will soon be changing the client side default to 1h for a few queries, since we now feel good that it is a small token savings on average for those queries. We will also give you env vars to force 1h and 5m.

• #47098
• #47107

In any case, the token savings is nowhere near 12x unfortunately. It is a small win though, that we have been in the process of rolling out to everyone. Hope the explanation helps.

^^ given the two issues above, - combined with the "reordering bug" that was fixed after .92 or whatever
-> i do not think that you currently have any data to make such calls

We will also give you env vars to force 1h and 5m.

Woo-hoo! Appreciate taking this suggestion.

Would it be possible to control it per session (similar to how model selection or plan mode or enabling extended thinking works currently)

Also -- could the granularity available be more diverse instead of just a binary choice? Say if I am sitting down for a marathon crtical work session I might want to try 2 hour cache write and willing to take the cost? OR try if 20m is a sweet-spot for my style of work?

Cheers!

We will soon be changing the client side default to 1h for a few queries, since we now feel good that it is a small token savings on average for those queries. We will also give you env vars to force 1h and 5m.

Just be sure to split the force flag between main and sub agents. This is a good approach here: https://github.com/cnighswonger/claude-code-cache-fix/issues/14#issue-4255749204 And will make this issue obsolete.

Small user story anecdote: I do ML research and many of my CC toolcalls run for >10 minutes when doing things like downloading checkpoints, loading them to run test forward passes/benchmarks, etc. Additionally, it isn't unusual for subagent calls exploring large codebases to take >5 minutes. Finally, since I'm juggling many >300k sessions across repos/test nodes, >5 minute idle gaps are very frequent.

If you want to check whether your specific Claude Code version compounds the TTL issue with cache_creation inflation (#46917), enter your version at this checker — it shows which known issues affect you and recommended fixes.
For checking your actual cache state, paste your /cost output into Cache Health Checker — it flags TTL breakage (creation > read consistently), inflation, and calculates your waste ratio. No sign-up, runs client-side.

Hi, I also encounter this issue and I'm experimenting with my solution: just ping claude code to keep cache alive. Welcome anyone give me some advice on this project: https://github.com/yujiachen-y/claude-code-cache-keepalive

Hi, I also encounter this issue and I'm experimenting with my solution: just ping claude code to keep cache alive. Welcome anyone give me some advice on this project: https://github.com/yujiachen-y/claude-code-cache-keepalive

you are wasting tokens doing this

sounds like a feature.

just to add clarity that Boris is saying the savings for this caching issue are not extensive and yet people are still hitting limits rapidly - meaning in addition to the caching change, there must have been other changes not yet documented to lower everyone's limits under the radar. In addition to the peak hours change and the model feeling drastically more stupid during most of the working day

The "average savings" framing hides a structural problem. Let's break down who actually wins and loses at 5m TTL:

| Session gap | 1h TTL cost | 5m TTL cost | Winner |
|---|---|---|---|
| < 5 min | 1× write (2×) + reads | 1× write (1.25×) + reads | 5m |
| 5–60 min | 1× write (2×) + reads | Rewrite every turn (1.25× × N) | 1h, by a lot |
| > 1 hour | Rewrite (2×) | Rewrite (1.25×) | 5m |

The middle row is exactly where real human coding sessions live — thinking, code review, context switching, meetings, long-running tool calls. The "1h everywhere would cost more" argument only holds if this middle band is small in the request mix. It's not small for main-agent turns; it's only small if you average in subagents, which are architecturally one-shot (1.4s median inter-turn gap per @spm1001's data). Lumping those together makes the statistics look favorable while individual users in the middle band pay more.

Two things the current narrative doesn't address

1. Why are "one-shot" requests on a frontier model in the first place?

If a query is genuinely one-shot and simple enough that 5m TTL suffices, it probably doesn't need Opus/Sonnet 4.6 with full CLAUDE.md context — it needs Haiku with a trimmed prompt. Using a large model + short cache to "save cache cost" is optimizing the wrong axis.

2. Cache cost vs. compute cost are not the same thing

A cache miss doesn't save GPU time — it forces a full prefill of the same context again. Shorter TTL in the 5–60 min band means the same prompt gets prefilled multiple times per session. That's a transfer from "cache line-item" to "GPU-hour," not a real saving. It also inflates TTFT and tightens peak-hour capacity, which lines up with the recent 5am–11am PT burn-rate and throttling complaints.

The honest summary

• Cache storage accounting improved
• GPU compute likely got worse
• Subscription users eat the quota hit
• API users see a small net win on token price

That's not a uniform improvement — it's a redistribution.

What would actually resolve this

• Per-request env var / flag for TTL (as @bcherny mentioned) — ship it soon, and make it per-session switchable like model selection
• Separate flags for main agent vs. subagent — the distinction that actually matters
• Smarter model routing for genuinely one-shot simple queries, instead of using TTL as a proxy
• Publish the end-to-end GPU-hour delta, not just cache-tier token accounting, if you want the "cheaper on average" claim to be credible
• Answer @raghuvv / @seanGSISG's question directly: if this was net-positive, why did subscription capacity drop in the same window?

Appreciate the transparency from @Jarred-Sumner and @bcherny — but the response so far addresses the token-price math while sidestepping the quota-capacity question, which is what subscribers actually care about.

Yet another issue closed without resolution by Anthropic.

You really wonder why they're closing these without reading if every other person posts an auto-generated wall of slop?

You really wonder why they're closing these without reading if every other person posts an auto-generated wall of slop?

Let's see an example of one of your epic Issue posts

Now I see: why I got 200$ credit, then I burned in 5 minutes again lol i was wondering if I was a non-profit for Anthropic.

You really wonder why they're closing these without reading if every other person posts an auto-generated wall of slop?

Data is data. It does not matter how it was written or what appearance it takes.

Hi, I also encounter this issue and I'm experimenting with my solution: just ping claude code to keep cache alive. Welcome anyone give me some advice on this project: https://github.com/yujiachen-y/claude-code-cache-keepalive

Nice try, but I don't think the math works out, especially on Max.

The ping isn't free. To get a cache hit, the request still has to send the whole cached prefix, so every ping is a full cache-read (0.1x) on the prefix plus the ping tokens plus whatever comes back. And if you're on a subscription, those reads count against your 5h and weekly quotas. So you're spending real coding capacity to keep a cache warm that you might not even use.

I don't like the stealth nerf.

> You really wonder why they're closing these without reading if every other person posts an auto-generated wall of slop? Let's see an example of one of your epic Issue posts

He's literally a GitHub troll. Ignore him. I never thought people would waste their time doing that, but apparently they exist.

The shorter TTL makes cache misses more expensive, but most of the cost comes from how much payload gets sent on each cache-creation call. Smaller sessions = fewer cache_creation tokens per miss. Cozempic's guard daemon continuously prunes stale tool results, old images, and metadata between turns so each API call sends significantly less, reducing the cost impact of these TTL changes.

pipx install cozempic && cozempic guard — https://github.com/anthropics/claude-code/issues/46829

It's possible to determine whether you were affected, and with which versions, by running:

grep -h -r -E 'ephemeral_.*_input_tokens' ~/.claude | jq 'select(.isSidechain == false and (.message.model | startswith("claude-haiku") | not) and .message.usage.cache_creation.ephemeral_5m_input_tokens > 0) | .timestamp + "," + .version' 2>/dev/null | sed 's/T.*,/,/'| sort | uniq -c

My output shows:

  92 "2026-04-01,2.1.81"
 418 "2026-04-02,2.1.81"
 317 "2026-04-09,2.1.85"
 188 "2026-04-13,2.1.92"
 241 "2026-04-14,2.1.92"
  35 "2026-04-15,2.1.92"
 449 "2026-04-16,2.1.92"
  25 "2026-04-17,2.1.92"
 826 "2026-04-21,2.1.114"
 134 "2026-04-22,2.1.114"

I have provided Anthropic with a redacted copy of my jsonl transcripts for my sessions exhibiting this issue.

Max 20x subscriber ($200/month). Never hit the 5-hour session limit in 2+ months of daily heavy use — until this week.
My typical workflow: Claude Code with Opus 4.6 (1M context), 2-4 subagents per session (builders + auditors), system programming (Next.js web-admin, Python backend). I regularly run sessions at 60-90% context without hitting token limits.

This week I hit the 5-hour session limit on what I consider a light day. My weekly usage counter also reset unexpectedly (Thursday → Sunday, likely the April 23 compensation reset).

The 5-minute cache TTL is the likely cause: every time I wait for a subagent to complete (5-10 min), the main session's cache expires. The next turn recreates the full context at write price instead of read price. With 12+ subagent dispatches per session, that's 12+ full cache recreations.

Environment: Claude Code v2.1.121, Max 20x plan, Opus 4.6 (1M context), Linux
This is unsustainable for power users. A 5-minute TTL with 1M context windows makes heavy workflows prohibitively expensive, even on the highest tier plan.

@sunkwolf I think this article sums up what is going on. I've lowered my Anthropic sub to the $100 and got the $100 OpenAI sub.

Might just ditch the Anthropic subscription all together and use it through my GitHub Copilot subscription until they get their shit together.

https://medium.com/ai-software-engineer/anthropics-new-tokenizer-is-quietly-hiking-your-claude-costs-by-47-i-fixed-it-91c69ff0017b

4. Cache-read quota weighting (ref [[BUG] Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate Usage #45756](https://github.com/anthropics/claude-code/issues/45756)): we'll follow up there.

Still waiting on that update...

Supplemental Observation: Consistent Tool "Cold-Starts" and the "Msg 0" Cache Escape (v2.1.126)

I’ve been tracking the regression data in this thread and have a supplemental observation regarding why quota consumption is exceeding even the 5m TTL projections.

In auditing raw request bodies for v2.1.126, I’ve identified two architectural behaviors that effectively bypass the prefix cache:

• Consistently Uncached System Tool Catalog: The core tool definitions (~24k tokens) are consistently shipped without cache_control headers. In the native CLI, these blocks are treated as "cold" on every turn. This forces a full input charge against the user's quota regardless of the TTL window, as the model cannot "warm start" the tool definitions.
• The "Msg 0" Cache Escape: While Msg 0 (the stable anchor) remains uncached in the native binary, I've observed that the /compact command triggers a structural migration. Static project metadata and tool registrations are shifted away from the start of the stream into later indices (e.g., Msg 1 or Msg 3). By "burying" these static blocks behind dynamic turn history and system-reminder scaffolding, the CLI ensures a prefix hash mismatch for all subsequent messages in that session.

Technical Validation:
I’ve been using a minimalist Node.js proxy Pino to verify these findings. Interestingly, attempts to forcefully inject cache_control into Msg 0 via proxy appear to trigger further non-deterministic reshuffling of these blocks into later message indices. By surgically re-anchoring these migrated blocks back to a stabilized Msg 0 and restoring the missing headers, I was able to verify that the overhead is almost entirely avoidable.

This suggests that the primary driver of the rapid 'quota vanish' is an architectural shift—specifically the lack of caching for both the tool catalog and the Msg 0 anchor, alongside a move away from stable, deterministic context placement.

here is the response I received from Anthropic earlier this week regarding the KIs that were fixed in v2.1.108 and earlier:

During the window you identified, two separate Claude Code bugs could cause eligible subscription seats to fall back to the 5-minute prompt-cache TTL on the main conversation loop instead of the intended 1-hour TTL: • Overage-latch bug — caused if a seat was in its quota-overage state → Fixed in Claude Code v2.1.90 (released April 1, 2026). • Telemetry-disabled fallback → Fixed in Claude Code v2.1.106 released April 13, 2026; also noted publicly on GitHub #46829. These two bugs fully account for the per-user inconsistency you observed: which users were affected depended on whether they had telemetry disabled and/or happened to start a session while in overage — not on seat type. Recommendation: ensure all seats are on v2.1.108 or later (this covers both fixes). Users who want to force 1-hour TTL in non-default scenarios can set ENABLE_PROMPT_CACHING_1H=1.

I have received today a further response from Anthropic that explains the remainder of the symptoms I saw post v2.1.108, on v2.1.114.

the remaining condition that selects 5-minute TTL on the main loop is the seat's billing state. Claude Code uses 1-hour TTL on the main conversation loop only while a subscription seat is within its included allowance; once the seat crosses into Extra Usage it is treated as pay-as-you-go and the client selects 5-minute TTL across the board.

the 1H environment variable was also being ignored in that state, but now is being respected. https://github.com/anthropics/claude-code/issues/49139

I hope this is helpful to all who have been struggling with this issue.

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.