Repository navigation
Description
Describe the bug
Prompt caching appears to be underutilized. Across multiple sessions, cacheCreationInputTokens is consistently 0 while cacheReadInputTokens is very low relative to total input tokens, resulting in significantly higher costs.
I have reinstalled Claude Code multiple times and the problem persists. Another Mac on the same account does not have this issue — cache creation works normally there.
Environment
- Claude Code version:
2.1.37 - OS: macOS (Darwin 25.2.0)
- Model:
claude-opus-4-6
Observed behavior
Session stats from two different projects in the same workspace:
| Project | Total Input Tokens | Cache Creation | Cache Read | Cache Hit Rate |
|---|---|---|---|---|
| Project A | 1,343,276 | 0 | 42,052 | ~3.1% |
| Project B | 3,287,771 | 10,513 | 588,728 | ~17.9% |
- Project A has zero cache creation tokens and an extremely low cache hit rate (~3.1%)
- Project B is slightly better but still seems low (~17.9%)
- Both projects have a large
CLAUDE.md(~500 lines) that should be cacheable across turns - Reinstalling Claude Code multiple times did not resolve the issue
- A different Mac does not exhibit this problem — caching works as expected
Relevant feature flags
Noticed from cachedGrowthBookFeatures:
"tengu_system_prompt_global_cache": false
"tengu_compact_cache_prefix": true
"tengu_cache_plum_violet": true
The tengu_system_prompt_global_cache is false for this machine. On the other Mac where caching works correctly, this flag may differ. If this is an A/B test, it would be helpful to understand:
- Is this flag expected to impact cache creation/read rates?
- Can users opt in to system prompt global caching?
- Why would reinstalling not reset/re-roll the feature flag assignment?
Expected behavior
With a stable system prompt and CLAUDE.md that doesn't change between turns, I'd expect:
- Cache creation on the first API call of a session
- High cache read rates on subsequent calls (at least for the system prompt + project instructions prefix)
- Significantly lower effective cost per turn as the session progresses
Impact
The low cache hit rate means nearly all input tokens are billed at full price on every turn, making long sessions on Opus disproportionately expensive.
Activity
ramakay commentedon Feb 9, 2026
This is a massive issue ... specifically investigating opus 4.6 unknowingly the cost blew up for one of our keys
Jianxinnn commentedon Feb 10, 2026
The latest version consumes too many tokens.
zhanxin-xu commentedon Feb 13, 2026
github-actions commentedon Mar 14, 2026
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
github-actions commentedon Mar 21, 2026
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.