Low prompt cache utilization — cacheCreationInputTokens consistently 0

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:

1. Is this flag expected to impact cache creation/read rates?
2. Can users opt in to system prompt global caching?
3. 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.