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

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):

claude-opus-4-6 (cache_write_5m = $6.25/MTok, cache_write_1h = $10.00/MTok, cache_read = $0.50/MTok):

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:

1. ~Feb 1 and prior: Anthropic defaulted to 1h TTL for Claude Code subscription users
2. ~Mar 6: 5m tokens begin reappearing — gradual rollout of the change or partial infrastructure flip
3. ~Mar 8: 5m TTL becomes dominant — the regression is fully in effect across both tested machines and accounts
4. 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

1. Confirm or deny whether Anthropic made a server-side TTL default change in early February 2026 and reverted it in early March 2026
2. Clarify the intended TTL behavior for claude-code sessions — is 5m the intended default, or was 1h intended to be permanent?
3. 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
4. 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/**/*.jsonl session files (Claude Code stores per-message API responses including full usage objects)
• Extraction: filtered for type: "assistant" entries with message.usage.cache_creation field
• 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 --source mode (added to support this investigation)
• Pricing: official Anthropic rates from rates.json (updated 2026-04-09)