Expose extended (1h) prompt-cache TTL for interactive sessions
Problem
The Anthropic API's prompt cache defaults to a 5-minute TTL. In interactive Claude Code sessions, the human reply gap routinely exceeds that: measured across 1,967 reply times in one power user's session telemetry, 27% of replies landed after the 5-minute window and 10% after 15 minutes. Each late reply forces a cold re-read of the entire conversation context (often hundreds of KB in long sessions), paying full input cost and latency for content that was cached moments earlier.
Users can't reasonably be expected to watch a cache clock while thinking, reviewing diffs, or juggling parallel sessions — and the UI surfaces no signal about when the window lapses.
Ask
The API already supports cache_control: {type: "ephemeral", ttl: "1h"} (2x write cost, ~0.1x reads, break-even at ~3 requests). Expose it in Claude Code, any of:
- A setting (
cacheTtl: "1h"in settings.json) or env var, or - Automatic: use the 1h TTL for interactive sessions (or adaptively, when the user's recent reply gaps exceed the 5-minute window), keeping 5m for headless/scripted runs.
For long interactive sessions the economics clearly favor 1h: one 2x write amortizes across every turn of an afternoon session, versus repeated full-price cold re-reads.
Workaround today
None exposed. Users can only restructure their workflow (fewer, longer autonomous runs; checkpoint files + fresh short sessions instead of resuming stale transcripts), which helps but shouldn't be required to avoid a silent 10x cost cliff on a reply that took six minutes instead of four.
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Environment Details
Problem Statement
The current prompt cache TTL is fixed at 5 minutes on the AWS Bedrock backend gateway. For long single-task developer sessions (e.g., a full day of mobile automation development on a single ticket), this means any gap longer than 5 minutes results in a full cache miss and full input token billing—with no way to prevent it.
This is especially painful when:
Current Behavior
Cache TTL = 5 minutes, hardcoded. Even when using the CLI or standard env variables, Bedrock forces a 5-minute timeout on interactive sessions. Furthermore, users have no visibility into cache hit/miss rates per turn without checking
/costrepeatedly.Expected Behavior
Allow users to configure the cache TTL—up to 1 hour—specifically ensuring that the
ttlparameters map correctly to the Bedrock API payload body via:cacheTimeout: 3600)CLAUDE_CODE_CACHE_TTL="1h")Impact
For enterprise and professional users running day-long agentic coding sessions, a hardcoded 5-minute TTL effectively renders prompt caching useless during typical development loops.
As a concrete example, a single ticket workflow over a 24-hour wall-clock window resulted in:
Because the 5-minute TTL constantly expired during manual testing and approval pauses, the CLI was forced to repeatedly rewrite the exact same codebase context from scratch at full price. A 1-hour TTL would have kept those 2.0M tokens inside the 90% discounted "cache read" bucket, lowering the bill significantly without any architectural downsides.
<img width="687" height="126" alt="Image" src="https://github.com/user-attachments/assets/b0a4af90-fa7d-4d33-b221-b2f85cc8c237" />
Workarounds Tried
/compactto reduce context size — helps marginally, but the root cache invalidation remains.This is no longer just a feature request — the 1h TTL was already in use and was silently removed in 2.1.218.
ephemeral_1h_input_tokens > 0)The economic case you made (break-even at ~3 requests) is now a regression cost: 13.8% of total session cost across 236 sessions is attributable to the 1h→5m switch. Your "27% of replies land after the 5-minute window" stat is the user-driven half; the agentic half (test suites, subagent delegations, web fetches) makes the real-world gap frequency even higher.
Asking to "expose" the 1h TTL is right, but the more urgent ask is to restore it — it was there and was removed.
Filed as #84253.
✍️ Author: Claude Code with @carrotRakko (AI-written, human-approved)
Update:
ENABLE_PROMPT_CACHING_1H=1 env var works on 2.1.223 + AWS Bedrock (claude-opus-4-6).
Added to ~/.claude/settings.json:
"env": {
"ENABLE_PROMPT_CACHING_1H": "1"
}
Verified over a 58-minute session with intentional 6-14 minute idle gaps between turns:
Images -
Observations -
Previously with 5-min TTL, any 6+ minute gap would spike cache writes and cost. This confirms the 1h TTL is active and functioning on Bedrock.
This env var was introduced in 2.1.108 (changelog) but isn't documented anywhere obvious — found it by grepping the changelog. Would still benefit from proper docs/UI exposure.
This is already available. On a Claude subscription (Pro/Max/Team/Enterprise) within included usage, Claude Code uses the 1-hour prompt-cache lifetime automatically. On an API key or a cloud provider (Bedrock, Vertex, Foundry) — or when a subscription is drawing on usage credits — set the environment variable:
Note that 1-hour cache writes are billed at a higher rate. Docs: https://code.claude.com/docs/en/env-vars and https://code.claude.com/docs/en/costs
Closing since this is covered today — reopen if you're seeing 5-minute expiry on a subscription.
🤖 Generated with Claude Code