[BUG] ENABLE_PROMPT_CACHING_1H is not working (API key user)
Status Fixed / completed
Reported on v2.1.110
Maintainer reply ✓ Yes — mhegazy
Activity 5 comments · opened Apr 16, 2026 · closed May 4, 2026
💡 Likely answer: A maintainer (mhegazy, contributor)
responded on this thread — see the highlighted reply below.
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
The ENABLE_PROMPT_CACHING_1H environment variable (which opts into 1-hour prompt cache TTL) has no effect. Cache entries are always created with 5-minute TTL regardless of the setting.
By intercepting the raw HTTP traffic between Claude Code and the Anthropic API, I confirmed that:
- The client correctly sends
cache_control: {"type":"ephemeral","ttl":"1h","scope":"global"}on system blocks andcache_control: {"type":"ephemeral","ttl":"1h"}on message blocks - The
anthropic-betaheader includesprompt-caching-scope-2026-01-05 - The server responds with
ephemeral_5m_input_tokens: 7025, ephemeral_1h_input_tokens: 0— all cache creation goes into the 5-minute bucket, none into the 1-hour bucket
This is reproducible on both an enterprise/organization API key and a personal API key.
What Should Happen?
When ENABLE_PROMPT_CACHING_1H=1 is set, cache entries should be created with a 1-hour TTL. The server response should show ephemeral_1h_input_tokens > 0 and ephemeral_5m_input_tokens: 0 for the cache creation.
Error Messages/Logs
**Request (client → server):**
POST https://api.anthropic.com/v1/messages?beta=true
anthropic-beta: claude-code-20250219,context-1m-2025-08-07,interleaved-thinking-2025-05-14,context-management-2025-06-27,prompt-caching-scope-2026-01-05,advisor-tool-2026-03-01,advanced-tool-use-2025-11-20,effort-2025-11-24,afk-mode-2026-01-31
System block cache_control: {"type":"ephemeral","ttl":"1h","scope":"global"}
Message block cache_control: {"type":"ephemeral","ttl":"1h"}
**Response (server → client):**
{
"input_tokens": 3,
"cache_creation_input_tokens": 7025,
"cache_read_input_tokens": 12112,
"cache_creation": {
"ephemeral_5m_input_tokens": 7025,
"ephemeral_1h_input_tokens": 0
}
}
The server creates cache entries (7025 tokens) but places them all in the 5-minute bucket despite the client requesting 1-hour TTL.
Steps to Reproduce
- Set
ENABLE_PROMPT_CACHING_1H=1(either as environment variable or insettings.jsonunderenv) - Start Claude Code
- Send a message
- Observe usage stats —
ephemeral_1h_input_tokensis always 0
Claude Model
Opus
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.110 (Claude Code)
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
Other
Additional Information
_No response_
5 Comments
I can confirm the same issue on Linux and using Sonnet.
Confirming on Windows 11, Claude Code 2.1.114, API key (organization), on
claude-opus-4-7.ENABLE_PROMPT_CACHING_1H=1set in both~/.claude/settings.jsonenvas well as a Windows user env var to be sureecho $ENABLE_PROMPT_CACHING_1Hreturns1from inside the Bash tool)FORCE_PROMPT_CACHING_5M,DISABLE_PROMPT_CACHING,DISABLE_TELEMETRY,CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFICare all emptyclaude-opus-4-7in separate fresh sessions. Every turn'susagein the session JSONL showsephemeral_5m_input_tokens > 0andephemeral_1h_input_tokens: 0, so this doesn't appear to be a 1M-context interaction.Hoping this can get fixed. The default 5 minute cache TTL is really insufficient for a lot of what I do. I often spend at least that much time reviewing Claude's output and/or thinking about what to do next, so there's a lot of full cache misses on my turns.
Sorry. took a while. but backend change for this should be in now.
Can confirm, I see that it started working for me a couple of hours ago. Excellent!
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.