Did Claude Code's cache TTL get shorter? What actually changed

A GitHub issue with 119,866 API calls of receipts said Claude Code's cache quietly went from a 1-hour lifetime to 5 minutes, costing some users 17% more. The engineer who answered it agreed on the data and disagreed on the conclusion: the March change was supposed to lower total cost, not raise it, and the one piece that genuinely regressed was a narrower client bug that shipped a fix months ago.

What the bug report actually showed

The issue's author pulled usage.cache_creation.ephemeral_5m_input_tokens and ephemeral_1h_input_tokens out of raw session JSONL files across two machines, 119,866 API calls between January 11 and April 11, 2026. The pattern was clean enough to date to the day: 33 straight days of near-100% 1-hour cache writes from February 1 to March 5, then a hard flip toward 5-minute writes starting March 6.

Applying Anthropic's own published rates to that same call volume, the issue calculated $949.08 in extra Sonnet spend and $1,581.80 in extra Opus spend across the four months, concentrated almost entirely in March and April - 17.1% of the total bill, by the issue's own accounting, not a UsageCut measurement.

A second user corroborated the date and added a detail the original report didn't have: subagent turns moved to the 5-minute tier earlier and more completely than main conversation turns did, which turns out to be the whole story.

Anthropic's answer: optimization, not a regression

Jarred-Sumner replied directly in the thread with a correction to the framing, not the data: "The March 6 change makes Claude Code cheaper, not more expensive. 1h TTL for every request could cost more, not less." His argument rests on the pricing itself, not a policy claim:

A 1-hour cache write costs 2x base input price; a 5-minute write costs 1.25x. That difference only pays for itself if the write gets read back before it expires. For a request that's read many times inside the hour - a long, active main conversation - the 1-hour tier wins. For a request that's written once and never revisited - a one-shot subagent call, a background check - the 5-minute tier is strictly cheaper, because you paid less to create it and nothing was ever going to reuse it either way.

So the client started choosing per request instead of applying one TTL to everything. That is a real, dated change (Anthropic confirmed March 6, matching the issue's own detective work), and on Anthropic's numbers it lowers the blended cost across Claude Code's full request mix. Whether it lowered your bill depends on your own mix of long sessions versus one-shot calls, which the issue's aggregate accounting can't tell you and neither can this article - see the limits section below.

The bug that was real, and the version that fixed it

Buried in the same reply is the part that isn't a reframe - a genuine client-side bug: sessions that had already burned through their subscription quota and were drawing on paid usage credits at startup stayed pinned to the 5-minute TTL for the rest of that session, even past the point they'd normally have gotten the 1-hour tier. Fixed in v2.1.90.

This is the same overage-TTL behavior this site's cache-bug guide already flags as documented, not a leak - what's new here is the version number that fixed the one case where it stuck around longer than it should have. Checking this repo's own install right now:

$ claude --version
2.1.222 (Claude Code)

That's more than 130 patch versions past the fix. If your claude --version reports something starting with 2.1.0 through 2.1.89, this specific bug is still live for you; everything from v2.1.90 on has it.

How the client decides your TTL tier today

There's no single global default anymore - Jarred-Sumner said so explicitly: "the client picks per request based on the expected cache-reuse pattern; there is no single global default, by design." The independent corroboration in the thread put numbers on what that looks like in practice:

| Period | Main conversation turns on 5m | Subagent turns on 5m | | --- | --- | --- | | Feb 7 - Mar 5 (pre-change) | 0% | 14% | | Mar 6 - Mar 31 (rollout) | 20-45% | 99% | | Apr 1 onward (post v2.1.90) | 0-6% | 100% |

Main turns - the ones a reply is likely to land on within the hour - ended up back near the 1-hour tier once the overage bug was fixed. Subagents, which almost always run once and never get revisited, settled at effectively 100% on the cheaper 5-minute tier. That split is the mechanism working as described, not a leftover bug.

Where you're locked to five minutes regardless

Per-request selection is a subscription-side behavior. Several surfaces don't get a choice at all:

Claude Code's own docs confirm the pattern directly: on a Claude subscription, "Claude Code requests the one-hour TTL automatically." On an API key, Bedrock, Google Cloud's Agent Platform, or Microsoft Foundry, "you pay the per-token rates, so the TTL stays at the cheaper five minutes by default" - the Vertex setup docs list the exact override, ENABLE_PROMPT_CACHING_1H=1, which bills the 1-hour rate in exchange for the longer window. Subagents stay on 5 minutes everywhere, subscription included, because a fresh subagent call has nothing cached to reuse yet.

Three environment variables cover every override you'd actually want:

| Variable | Effect | | --- | --- | | ENABLE_PROMPT_CACHING_1H=1 | Request the 1-hour tier on API key, Bedrock, Vertex, or Foundry (costs more per write) | | FORCE_PROMPT_CACHING_5M=1 | Force the 5-minute tier even on a subscription (useful for debugging) | | DISABLE_PROMPT_CACHING=1 | Turn caching off entirely (per-model variants exist too, e.g. DISABLE_PROMPT_CACHING_OPUS) |

Checking your own tier without guessing

Two ways to see which tier you're actually getting, cheapest first:

1. Update, then look at /usage. If you're behind v2.1.90, that alone closes the one confirmed bug. cache_create values that stay high turn after turn on an idle-free session are a different problem - that's the cache-holding bug, not a TTL tier question.
2. Read your own session JSONL. The two fields the GitHub issue's analysis was built on - usage.cache_creation.ephemeral_5m_input_tokens and ephemeral_1h_input_tokens - are in every assistant message under ~/.claude/projects/. A session sitting mostly in ephemeral_5m while you're on a subscription and mid-conversation is worth a second look; the same split on a subagent-heavy workflow is expected behavior, not a bug.

If you're on Vertex, Bedrock, or an API key and run long-lived sessions with gaps over 5 minutes, ENABLE_PROMPT_CACHING_1H=1 is the actual lever - weigh it against the 2x write cost using your own session cost math rather than assuming it's automatically a win.

What this explanation can't tell you

This resolves what changed and why - it doesn't tell you whether the March 6 change was good or bad for your specific workload. The issue's aggregate 17.1% figure came from one account's request mix; a team running mostly long, single-threaded sessions could see a different number than a team running heavy subagent fan-out, and neither this article nor the GitHub thread has your session data. It also doesn't cover raw Anthropic API usage outside Claude Code, where you set cache_control and its ttl directly per request rather than letting a client choose for you - a different decision with the same underlying pricing.

FAQ

• Did Claude Code's cache TTL actually get shorter? Not as a blanket change. A real behavior shift happened on March 6, 2026, confirmed by Anthropic, but it was per-request tier selection replacing a single global default, not a cut applied everywhere. The one confirmed bug - overage sessions stuck on 5 minutes - was fixed in v2.1.90.
• Why would a shorter cache TTL ever be cheaper? Because a 1-hour cache write costs 2x base input price against 1.25x for 5 minutes, and that premium only earns its keep if the cache gets read again before it expires. A one-shot call - most subagent calls - never gets that second read, so the cheaper, shorter-lived write is the better deal on average.
• Am I still getting the 1-hour TTL? On a Claude subscription, main conversation turns request it automatically. Subagent calls use 5 minutes regardless of plan. On an API key, Bedrock, Vertex, or Foundry, you're on 5 minutes by default unless you set ENABLE_PROMPT_CACHING_1H=1.
• Is this the same as the Claude Code cache bug that spikes token costs 10-20x? No - that's the cache failing to hold at all, a different failure mode with its own GitHub issues and fix history. This article covers which TTL tier you get, not whether the cache engages.
• How do I check which tier my sessions are actually using? Update to v2.1.90 or later first. Past that, the ephemeral_5m_input_tokens and ephemeral_1h_input_tokens fields in your session JSONL under ~/.claude/projects/ show the real split per turn.

Whichever tier a given turn lands on, the bill is still driven by how much sits in context and how often it gets rebuilt from scratch - the part a TTL setting can't fix on its own. Run UsageCut's free scan if you want to see what's actually driving cache-create costs in your own sessions before reaching for an environment variable.

Made by Neo

UsageCut by ClockedCode - not affiliated with Anthropic. The figures on this page are measured on real Claude Code sessions and labeled measured or estimated where it matters.