[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 and cache_control: {"type":"ephemeral","ttl":"1h"} on message blocks
  • The anthropic-beta header includes prompt-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

  1. Set ENABLE_PROMPT_CACHING_1H=1 (either as environment variable or in settings.json under env)
  2. Start Claude Code
  3. Send a message
  4. Observe usage stats — ephemeral_1h_input_tokens is 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_

View original on GitHub ↗

5 Comments

Confusion · 4 months ago

I can confirm the same issue on Linux and using Sonnet.

chimermc · 4 months ago

Confirming on Windows 11, Claude Code 2.1.114, API key (organization), on claude-opus-4-7.

  • ENABLE_PROMPT_CACHING_1H=1 set in both ~/.claude/settings.json env as well as a Windows user env var to be sure
  • Verified the variable is in Claude Code's process environment (echo $ENABLE_PROMPT_CACHING_1H returns 1 from inside the Bash tool)
  • No interfering vars: FORCE_PROMPT_CACHING_5M, DISABLE_PROMPT_CACHING, DISABLE_TELEMETRY, CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC are all empty
  • Tested both the 1M-context variant and vanilla 200K claude-opus-4-7 in separate fresh sessions. Every turn's usage in the session JSONL shows ephemeral_5m_input_tokens > 0 and ephemeral_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.

mhegazy contributor · 4 months ago

Sorry. took a while. but backend change for this should be in now.

chimermc · 4 months ago
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!

github-actions[bot] · 2 months ago

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.