Feature Request: 1 Hour Cache Support?

👍🏾

+1

This issue has been inactive for 30 days. If the issue is still occurring, please comment to let us know. Otherwise, this issue will be automatically closed in 30 days for housekeeping purposes.

Feature was not added as far i know. If feature was added, please give us context or link to release changelog @claude @anthropics

This would be an useful feature to have. Especially when you hit usage limits, you'll be paying twice for the same prompt when you resume the session. A general workaround could be to compact and resume but there's now way to compact / checkpoint once you hit the limit.

AWS now supports 1 hour TTL for caches since 2 days https://aws.amazon.com/about-aws/whats-new/2026/01/amazon-bedrock-one-hour-duration-prompt-caching/. This would be great if configurable for AWS bedrock users

@claude This feature request was open 7 months ago, can you write the code and deliver it 😊?

is it implemented yet?

+1

+1

Claude Code already uses 1-hour cache duration; confirmed by inspecting API requests.

Bumping with quantitative analysis and a specific failure mode that hasn't been documented here yet.

The multi-agent subagent expiry problem

There is a cluster of issues in multi-agent orchestration workflows (parent agent → Task tool → background subagent) that all reduce to the same root: the cache TTL is not user-configurable, and the default is shorter than typical subagent runtimes.

The specific failure mode:

1. Parent agent dispatches a subagent via the Task tool with run_in_background: true
2. Subagent runs a non-trivial task (code review, research synthesis, build + test) — routinely 5–15+ minutes
3. Parent's 5m cache expires during the wait
4. Parent receives the subagent result, hook fires, or user sends a message
5. Next API call: prefix re-written at 1.25× write cost, zero read hits
6. This repeats every turn

The result is a cache that writes constantly and reads never — net-negative compared to no caching at all.

The break-even math

| Cache event | Cost multiplier |
|-------------|----------------|
| Cache write (5m) | 1.25× base input |
| Cache write (1h) | 2.0× base input |
| Cache read | 0.1× base input |
| No cache | 1.0× base input |

For the 5m tier: each turn that misses the cache costs 1.25× instead of 1.0×. The cache is only net-positive if more than 22% of all cache events are reads (not writes). In a workflow where subagents routinely take longer than 5 minutes, the read rate approaches zero — every turn is a write. The user pays a 25% surcharge on every input token for a cache that never hits.

The current state is inconsistent

A comment above says "Claude Code already uses 1-hour cache." This is partially true — the client conditionally requests ttl: "1h" for claude.ai subscribers on the included-usage tier (see #43566 for what happens when Extra Usage kicks in). However, issue #29966 documents that subagents spawned via the Agent tool have enablePromptCaching hardcoded to false as recently as v2.1.63.

So even when the parent's cache is 1h, the subagent may not be caching at all. When the subagent completes and returns context to the parent, the parent's fresh turn re-writes the cache. The orchestration layer is the worst-case scenario for the 5m window.

Who this hits hardest

Users on higher plan tiers (Max 20×) running long-running autonomous workflows are the exact cohort this affects most. These users have generous token quotas — they're running orchestration jobs that take 30–60+ minutes with multiple subagents. They're precisely the users the 20× tier was designed for, and they're also the users for whom the 5m cache window fails entirely.

The telemetry gap makes diagnosis impossible

There is no way for a user to observe their cache hit/miss ratio from Claude Code. /cost shows total token usage but does not break out cache_read_input_tokens vs cache_write_input_tokens. Without this visibility, users cannot diagnose whether caching is working. Many users on Max plans reporting unusually fast quota drain (see #41788, #42052, #43274) cannot determine whether caching failure is a contributing factor.

What would help

In priority order:

1. Expose cache TTL as a user setting — settings.json field promptCacheTtl: "1h" | "5m" or env var CLAUDE_CODE_CACHE_TTL=1h. For workflows where turns exceed 5 minutes, 1h is strictly better.

1. Expose cache telemetry — add cache_read_input_tokens and cache_write_input_tokens to /cost output so users can diagnose hit rate and verify that caching is actually working.

1. Consistent caching for subagents — ensure Task tool subagents inherit or use the same TTL as the parent. See #29966 for the current enablePromptCaching: false default on subagents.

Workaround considered

DISABLE_PROMPT_CACHING=1 saves the 25% write penalty when the hit rate is near zero, but removes the benefit for sessions that would hit. Not a real fix — it trades one wrong state for another.

References: #29966 (subagent caching disabled), #43566 (TTL downgrade during Extra Usage), #37188 (TTL ordering errors with background agents), Anthropic prompt caching docs: https://platform.claude.com/docs/en/build-with-claude/prompt-caching

I think this is available now with ENABLE_PROMPT_CACHING_1H as per https://github.com/anthropics/claude-code/releases/tag/v2.1.108

Is this only for the API though? And subscribers are not able to get any of the nice caching control

This issue was fixed as of version 2.1.108.

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.