Skip to content

Low prompt cache utilization — cacheCreationInputTokens consistently 0 #24121

Closed as not planned

Description

@kytu800

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.

Activity

  1. ramakay commented on Feb 9, 2026

    @ramakay

    This is a massive issue ... specifically investigating opus 4.6 unknowingly the cost blew up for one of our keys

  2. Jianxinnn commented on Feb 10, 2026

    @Jianxinnn

    The latest version consumes too many tokens.

  3. zhanxin-xu commented on Feb 13, 2026

    @zhanxin-xu
    Image
  4. github-actions commented on Mar 14, 2026

    @github-actions

    Closing for now — inactive for too long. Please open a new issue if this is still relevant.

  5. github-actions commented on Mar 21, 2026

    @github-actions

    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.

  6. locked as resolved and limited conversation to collaborators on Mar 21, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    area:apiarea:costbugSomething isn't workinghas reproHas detailed reproduction stepsplatform:macosIssue specifically occurs on macOSstaleIssue is inactive

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions