Cache hit rate only 40% and extremely slow - Claude Code

Quick fix

Disable the dynamic attribution header in .claude/settings.json; if that fails, switch to a model with working caching and monitor the main issue.

Symptom

Error outputCopy

claude code接codex时，开启本地路由。命中率只有40%多,而且速度特别慢。但是codex自己运行时命中率有90%

English translation

When connecting claude code to codex with local routing enabled, the cache hit rate is only just over 40%, and it is extremely slow. But when codex runs by itself, the cache hit rate is 90%.

Cause

Claude Code injects a dynamic attribution header (CCH), which may break prompt caching for third-party models, reducing cache hit rates, increasing token usage, and significantly slowing responses. Related reports showed hit rates falling from over 90% to just over 70%, while another reported just over 40%.

Outcomes in the threads were inconsistent. One suggestion was to disable the dynamic header through `CLAUDE_CODE_ATTRIBUTION_HEADER`, but the original reporter still experienced slow responses and high token usage after setting it to `false`; switching to `minimax2.7` or `deepseek v4` restored normal behavior. Issue #3232 was closed as a duplicate, while Issue #3908 was closed after no new reproduction details were provided for a long time, so the corpus contains no confirmed universal fix.

Fix

1. 1

   Add `CLAUDE_CODE_ATTRIBUTION_HEADER` to `.claude/settings.json` to try disabling the dynamic attribution header automatically generated by Claude Code.

   .claude/settings.json

   {
     "env": {
       "CLAUDE_CODE_ATTRIBUTION_HEADER": "false"
     }
   }

2. 2

   Run the same request again and check the cache hit rate, response speed, and token usage. This setting did not resolve the problem in the Issue #3232 reporter's environment.

3. 3

   If disabling the dynamic attribution header does not help, switch to `minimax2.7` or `deepseek v4`, which worked normally in the reporter's tests. This is only that user's observed result, not a confirmed universal fix.

4. 4

   Issue #3232 was merged into the main issue for tracking. If the problem persists, provide the CC Switch version, system details, complete reproduction steps, and logs or screenshots.

Affected Versions

ToolClaude Code

Version受影响版本：3.15.0

PlatformsWindows

Source Issues

This page is distilled from 2 real issues

• #3232claude code接codex时，开启本地路由。命中率只有40%多,而且速度特别慢。但是codex自己运行时命中率有90%
• #3908缓存命中率多级告警

FAQ

Has this problem been resolved? Why does even a simple sentence take more than ten minutes to receive a response?

The existing threads contain no confirmed universal fix. The Issue #3232 reporter still experienced slow responses and high token usage after disabling the dynamic attribution header, but switching to `minimax2.7` or `deepseek v4` restored normal behavior.

Can setting `CLAUDE_CODE_ATTRIBUTION_HEADER="0"` resolve the lower cache hit rate?

Issue #3908 indicates that this environment variable can mitigate cache invalidation caused by the dynamic attribution header, but the Issue #3232 reporter saw no improvement with the value `false`, so the result may depend on the Claude Code version, model, or third-party provider integration.

Was this fixed after upgrading to CC Switch 4.0?

The maintainer said that related functionality was substantially refactored in 4.0 and recommended upgrading and trying again, but no user feedback in the thread confirms that the upgrade resolved the problem.

Related problems

Provider API Key Overwritten: After Codex Restart or SwitchUpgrade to cc-switch v4.0.0 or later to prevent provider keys from overwriting each other and restore the official login state.6 issues mergeddeepseek接入 模型勾选了1m: no 1M context option in Claude Code model pickerUpgrade cc-switch to v3.17.0+, leave the DeepSeek provider's ANTHROPIC_MODEL empty or check 1M there too, fill only Haiku/Sonnet/Opus mappings… (Claude Code)7 issues mergedinvalid tool_call_id (HTTP 400) — CodexIf tool calls fail, use a native Responses-compatible GPT model; v3.16.5 can be rolled back to v3.16.4.3 issues merged