Repository navigation
Cache TTL silently regressed from 1h to 5m around early March 2026, causing quota and cost inflationΒ #46829
Description
Cache TTL appears to have silently regressed from 1h to 5m around early March 2026, causing significant quota and cost inflation
Summary
Analysis of raw Claude Code session JSONL files spanning Jan 11 β Apr 11, 2026 shows that Anthropic appears to have silently changed the prompt cache TTL default from 1 hour to 5 minutes sometime in early March 2026. Prior to this change, Claude Code was receiving 1-hour TTL cache writes β which we believe was the intended default. The reversion to 5-minute TTL has caused a 20β32% increase in cache creation costs and a measurable spike in quota consumption for subscription users who have never previously hit their limits.
This appears directly related to the behavior described in #45756.
Data
Session data extracted from ~/.claude/projects/ JSONL files across two machines (Linux workstation + Windows laptop, different accounts/sessions), totaling 119,866 API calls from Jan 11 β Apr 11, 2026. Each assistant message includes a usage.cache_creation.ephemeral_5m_input_tokens / ephemeral_1h_input_tokens breakdown that makes the TTL tier per-call observable. Having two independent machines strengthens the signal β both show the same behavioral shift at the same dates.
Phase breakdown
| Phase | Dates | TTL behavior | Evidence |
|---|---|---|---|
| 1 | Jan 11 β Jan 31 | 5m ONLY | ephemeral_1h absent/zero β likely predates 1h tier availability in the API |
| 2 | Feb 1 β Mar 5 | 1h ONLY | ephemeral_5m = 0, ephemeral_1h > 0 across 33+ consecutive days on both machines β near-zero exceptions |
| 3 | Mar 6β7 | Transition | First 5m tokens re-appear, small volumes, 1h still present |
| 4 | Mar 8 β Apr 11 | 5m dominant | 5m tokens surge to majority; 1h becomes minority or disappears entirely |
We believe Phase 2 represents Anthropic's intended default behavior β 1h TTL was rolled out as the Claude Code standard around Feb 1 and held consistently for over a month across two independent machines on two different accounts. January's all-5m data most likely predates the 1h TTL tier being available in the API. The regression began around March 6β8, 2026.
No client-side changes were made between phases. The same Claude Code version and usage patterns were in place throughout. The TTL tier is set server-side by Anthropic.
Day-by-day TTL data showing the regression (combined, both machines)
Date | 5m-create | 1h-create | Behavior
------------|------------|------------|----------
2026-02-01 | 0.00M | 1.70M | 1h ONLY β 1h default begins
2026-02-09 | 0.00M | 7.95M | 1h ONLY
2026-02-15 | 0.00M | 13.61M | 1h ONLY β heaviest day, 100% 1h
2026-02-28 | 0.00M | 16.15M | 1h ONLY β 16M tokens, still 100% 1h
2026-03-01 | 0.00M | 0.12M | 1h ONLY
2026-03-04 | 0.00M | 8.12M | 1h ONLY
2026-03-05 | 0.00M | 6.55M | 1h ONLY β last clean 1h-only day
| | |
2026-03-06 | 0.29M | 0.22M | MIXED β first 5m tokens reappear
2026-03-07 | 4.56M | 0.50M | MIXED β 5m surging
2026-03-08 | 16.86M | 3.44M | MIXED β 5m now dominant (83%)
2026-03-10 | 10.55M | 0.51M | MIXED
2026-03-15 | 19.47M | 1.84M | MIXED
2026-03-21 | 21.37M | 1.70M | MIXED β 93% 5m
2026-03-22 | 13.48M | 2.85M | MIXED
The transition is visible to the day: March 6 is when 5m tokens first reappear after 33 days of clean 1h-only behavior. By March 8, 5m tokens outnumber 1h by 5:1. This is consistent with a server-side configuration change being rolled out gradually then completing around March 8.
Cost impact
Applying official Anthropic pricing (rates.json, updated 2026-04-09):
Combined dataset (119,866 API calls, two machines):
claude-sonnet-4-6 (cache_write_5m = $3.75/MTok, cache_write_1h = $6.00/MTok, cache_read = $0.30/MTok):
| Month | Calls | Actual cost | Cost with 1h TTL | Overpaid | % waste |
|---|---|---|---|---|---|
| Jan 2026 | 2,639 | $78.99 | $37.54 | $41.45 | 52.5% |
| Feb 2026 | 27,220 | $1,120.43 | $1,108.11 | $12.32 | 1.1% β nearly 0 on 1h |
| Mar 2026 | 68,264 | $2,776.11 | $2,057.01 | $719.09 | 25.9% |
| Apr 2026 | 21,743 | $1,193.01 | $1,016.78 | $176.23 | 14.8% |
| Total | 119,866 | $5,561.17 | $4,612.09 | $949.08 | 17.1% |
claude-opus-4-6 (cache_write_5m = $6.25/MTok, cache_write_1h = $10.00/MTok, cache_read = $0.50/MTok):
| Month | Calls | Actual cost | Cost with 1h TTL | Overpaid | % waste |
|---|---|---|---|---|---|
| Jan 2026 | 2,639 | $131.65 | $62.57 | $69.08 | 52.5% |
| Feb 2026 | 27,220 | $1,867.38 | $1,846.85 | $20.53 | 1.1% β nearly 0 on 1h |
| Mar 2026 | 68,264 | $4,626.84 | $3,428.36 | $1,198.49 | 25.9% |
| Apr 2026 | 21,743 | $1,988.35 | $1,694.64 | $293.71 | 14.8% |
| Total | 119,866 | $9,268.97 | $7,687.17 | $1,581.80 | 17.1% |
February β the month Anthropic was defaulting to 1h TTL β shows only 1.1% waste (trace 5m activity from one machine on one day). Every other month shows 15β53% overpayment from 5m cache re-creations. The cost difference is explained entirely by TTL tier, not by usage volume. The percentage waste is identical across model tiers (17.1%) because it is driven purely by the 5m/1h token split, not by per-token price.
Why 5m TTL is so expensive in practice
With 5m TTL, any pause in a session longer than 5 minutes causes the entire cached context to expire. On the next turn, Claude Code must re-upload that context as a fresh cache_creation at the write rate, rather than a cache_read at the read rate. The write rate is 12.5Γ more expensive than the read rate for Sonnet, and the same ratio holds for Opus.
For long coding sessions β which are the primary Claude Code use case β this creates a compounding penalty: the longer and more complex your session, the more context you have cached, and the more expensive each cache expiry becomes.
Over the 3-month period analyzed:
- 220M tokens were written to the 5m tier
- Those same tokens generated 5.7B cache reads β meaning they were actively being used
- Had those 220M tokens been on the 1h tier, re-accesses within the same hour would be reads (
$0.30β0.50/MTok) instead of re-creations ($3.75β6.25/MTok)
Quota impact
Users on Pro/subscription plans are quota-limited, not just cost-limited. Cache creation tokens count toward quota at full rate; cache reads are significantly cheaper (the exact coefficient is under investigation in #45756). The silent reversion to 5m TTL in March is the most likely explanation for why subscription users began hitting their 5-hour quota limits for the first time β including the author of this issue, who had never hit quota limits before March 2026.
Hypothesis
The data strongly suggests that 1h TTL was the intended default for Claude Code and was in place as of early February 2026. Sometime between Feb 27 and Mar 8, 2026, Anthropic silently changed the default to 5m TTL β either intentionally as a cost-saving measure, or accidentally as an infrastructure regression.
Evidence supporting "1h was the intended default":
- Phase 2 (1h ONLY) shows zero 5m tokens across 14 separate active days spanning 3+ weeks β this is not noise or partial rollout, it is consistent deliberate behavior
- The February cost profile is the only month with 0% overpayment β it represents what users should have been paying all along
- The March reversion immediately produced the largest 5m-tier days in the entire dataset (30M tokens on Mar 22 alone), suggesting a sudden configuration flip rather than gradual drift
- Subscription users began hitting 5-hour quota limits for the first time in March β directly coinciding with the reversion
The most likely sequence of events:
- ~Feb 1 and prior: Anthropic defaulted to 1h TTL for Claude Code subscription users
- ~Mar 6: 5m tokens begin reappearing β gradual rollout of the change or partial infrastructure flip
- ~Mar 8: 5m TTL becomes dominant β the regression is fully in effect across both tested machines and accounts
- Mar 8+: Mixed behavior continues, suggesting either incomplete rollout, A/B testing, or regional infrastructure variance
The 33-day window of clean 1h-only behavior (Feb 1 β Mar 5) across two independent machines and two separate accounts makes this one of the strongest available signals that 1h TTL was Anthropic's deliberate default, not a fluke.
Request
- Confirm or deny whether Anthropic made a server-side TTL default change in early February 2026 and reverted it in early March 2026
- Clarify the intended TTL behavior for claude-code sessions β is 5m the intended default, or was 1h intended to be permanent?
- Consider restoring 1h TTL as the default for Claude Code sessions, or exposing it as a user-configurable option. The 5m TTL is disproportionately punishing for the long-session, high-context use case that defines Claude Code usage
- Disclose quota counting behavior for cache_read tokens (ref [BUG] Pro Max 5x Quota Exhausted in 1.5 Hours Despite Moderate UsageΒ #45756) so users can make informed decisions about their usage patterns
Methodology
- Source: raw
~/.claude/projects/**/*.jsonlsession files (Claude Code stores per-message API responses including fullusageobjects) - Extraction: filtered for
type: "assistant"entries withmessage.usage.cache_creationfield - No external tools or proxies involved β this data comes directly from Claude Code's own session logs
- Analysis tool: cnighswonger/claude-code-cache-fix
quota-analysis --sourcemode (added to support this investigation) - Pricing: official Anthropic rates from
rates.json(updated 2026-04-09)
Activity
khalic-lab commentedon Apr 12, 2026
EthanFrostpro commentedon Apr 12, 2026
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.
Jarred-Sumner commentedon Apr 12, 2026
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
Decme commentedon Apr 12, 2026
Jarred what I'm getting from your convoluted post is the change is to reduce costs to Anthropic at the users' expense.
kshmir commentedon Apr 12, 2026
I mean how do you scale this otherwise?... some people gotta get real...
Decme commentedon Apr 12, 2026
With a fair middle ground. 15 minutes would be a better balance.
rinchen commentedon Apr 12, 2026
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.
nukeop commentedon Apr 12, 2026
Instead of posting a wall of AI slop you could have posted literally 2 lines
spm1001 commentedon Apr 12, 2026
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:
(Values are 5m share of
cache_creationtokens. 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."52 remaining items
seanGSISG commentedon Apr 30, 2026
@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
Still waiting on that update...
feat(telemetry): surface cache TTL bucket split in show-cycle-cost
Add cache TTL silent regression event (Mar 6βApr 12, 2026)
alxsuv commentedon May 6, 2026
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:
cache_controlheaders. 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.Msg 0(the stable anchor) remains uncached in the native binary, I've observed that the/compactcommand 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 1orMsg 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_controlintoMsg 0via 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 stabilizedMsg 0and 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.
fix(dashboard): restore reset countdown on session/weekly mini-bars +β¦
#2030 - Cache-TTL-Diagnose-Skript: prueft ob ENABLE_PROMPT_CACHING_1Hβ¦
feat(dashboard): limits page polish + smart session affinity (#26)
Shape M PR-5: 1-hour prompt-cache TTL via --betas extended-cache-ttl-β¦
Shape M PR-5: 1-hour prompt-cache TTL via --betas extended-cache-ttl-β¦
lizthegrey commentedon May 8, 2026
here is the response I received from Anthropic earlier this week regarding the KIs that were fixed in v2.1.108 and earlier:
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 1H environment variable was also being ignored in that state, but now is being respected. #49139
I hope this is helpful to all who have been struggling with this issue.
perf(claude): use 1h TTL for system+tools cache markers
github-actions commentedon Jun 28, 2026
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.