1. Claude Code 接入 MiMo 后缓存为什么总是不命中如果你正在用 Claude Code 接小米 MiMo并且发现账单里cache_creation_input_tokens一直很高、cache_read_input_tokens却低得可怜那这篇就是写给你的。这个现象很典型多轮对话每一轮都像第一次处理完整上下文首 token 变慢输入成本居高不下。很多人第一反应是 MiMo 不支持 Prompt Caching或者中间网关没透传cache_control但实测下来问题往往出在 Claude Code 自己发出去的一段 attribution 信息上。Claude Code 的 Prompt Caching 依赖一个稳定的 prompt 前缀。Agent 类工具每一轮请求都会带上大量重复内容system prompt、CLAUDE.md、项目上下文、tools/MCP 工具定义、历史消息、文件摘要。这些内容只要保持稳定服务端就能缓存下一轮只处理新增部分。但第三方模型和 LLM Gateway 的缓存机制通常没有 Anthropic 官方 API 那么完善只要前缀里有动态变化的内容缓存就会失效。Claude Code 默认会在 system prompt 开头插入一段 attribution block用来标识请求来源、客户端版本、prompt fingerprint 等信息。在官方 API 里这段信息不影响缓存但在第三方网关、OpenAI 兼容接口、本地模型、小米 MiMo 这类场景中它会被当成普通 prompt 内容参与前缀匹配。一旦这段内容变化服务端看到的前缀就不一致缓存自然命中不了。解决办法就是关掉这个 header一个环境变量CLAUDE_CODE_ATTRIBUTION_HEADER0就能搞定。2. 动手前先把 TaoToken 的接入信息准备好在改配置之前先把模型接入这一层理顺。我这边用的是 TaoToken 作为统一入口它同时提供 Claude Code 的 Anthropic 兼容接入和 API Key 管理省得在多个网关之间来回切。你可以先到官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 了解一下整体能力然后进控制台创建 Key。创建 Key 的入口在 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_contentconsoleutm_campaignrewrite 进去之后新建一个 API Key复制出来备用。如果你要接的是 Claude Code 这类编码 Agent建议直接看 Coding Plan 页面 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 里面有专门针对长期编码场景的配置说明。API 的基础地址是 https://taotoken.net/api 注意这个地址不带 UTM 参数配置时直接填。Key 拿到之后先别急着改CLAUDE_CODE_ATTRIBUTION_HEADER先把基础接入跑通。基础接入的文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 里面有完整的字段说明。如果你用的是 Claude Code 原生的 Anthropic 协议接入参考 https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite 这个页面它把 Claude Code 的接入参数列得很清楚。Key 管理页面在 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 后续要换 Key 或者看用量都从这里进。3. 可复制的 settings.json 配置骨架Claude Code 的配置文件在~/.claude/settings.jsonWindows 一般是C:\Users\你的用户名\.claude\settings.json。如果你之前已经配过ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN不要直接覆盖把新变量合并进去。下面是一个完整的骨架你可以直接抄{ env: { ANTHROPIC_BASE_URL: https://taotoken.net/api, ANTHROPIC_AUTH_TOKEN: 你的 TaoToken API Key, CLAUDE_CODE_ATTRIBUTION_HEADER: 0 } }这里CLAUDE_CODE_ATTRIBUTION_HEADER的值要用字符串0不要写成数字0也不要写成false。网上有些文章写false在部分版本里可能有效但官方文档推荐的是0统一用0最稳。如果你不想改配置文件也可以在 shell 里临时导出export CLAUDE_CODE_ATTRIBUTION_HEADER0想持久化就写进~/.bashrc或~/.zshrcecho export CLAUDE_CODE_ATTRIBUTION_HEADER0 ~/.bashrc source ~/.bashrcWindows PowerShell 临时测试可以这样$env:CLAUDE_CODE_ATTRIBUTION_HEADER0 claude改完之后必须重启终端、重启 VSCode、重新启动 Claude Code否则环境变量不会生效。这一步很多人会漏改完发现没变化八成是没重启干净。4. 验证缓存是否真的恢复命中配置生效后重点看日志或账单里的缓存字段。常见的字段有这几个cache_creation_input_tokens、cache_read_input_tokens、cached_tokens、prompt_tokens_details.cached_tokens。配置前通常是cache_creation_input_tokens很高、cache_read_input_tokens很低配置后如果cache_read_input_tokens明显增加cached_tokens也上来了说明生效了。你可以连续进行几轮同项目对话然后观察 MiMo 或网关日志。我这边配置后的实际变化是cache read 开始增加多轮对话能复用缓存首 token 速度改善输入成本下降。这说明 MiMo 不是不能缓存而是之前 Claude Code 发出去的 attribution 信息破坏了第三方网关的缓存前缀。如果你想更直观地验证模型本身的行为可以到模型对话页面 https://taotoken.net/model-chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite 手动发几轮相同前缀的请求对比一下带 attribution 和不带 attribution 时的缓存字段差异。这个页面适合做小范围验证不用每次都跑完整的 Claude Code 流程。5. 本篇常见错排查配置后如果缓存还是没改善按下面这几条逐个排查。第一确认真的重启了 Claude Code。环境变量是在进程启动时读取的改完配置文件不重启等于没改。终端、VSCode、Claude Code 三层都要重启。第二确认配置写到了正确的settings.json。有些系统里 Claude Code 会读多个位置的配置优先级不一样。用claude config list或者直接看启动日志确认加载的是哪个文件。第三检查中间网关是否丢弃了缓存字段。如果你用的是 Claude Code Router、NewAPI、CPA 这类中间层它们可能没有把cache_control正确透传。这种情况下即使 Claude Code 这边配好了网关那边也会把缓存信息吃掉。第四检查每轮 MCP 工具列表是否在变化。如果工具定义每轮都不一样前缀就不稳定缓存照样命中不了。把工具列表固定下来。第五检查是否切换了模型或网关节点。不同模型、不同上游实例的缓存是独立的负载均衡把请求打到不同实例上缓存自然不共享。第六检查是否超过了缓存 TTL。缓存有生存时间间隔太久再发请求缓存已经过期了。第七检查 CLAUDE.md 或项目上下文是否频繁变化。这些内容在前缀里一变缓存就失效。还有一个容易混淆的变量是DISABLE_PROMPT_CACHING1。这个变量的含义是直接关闭 Claude Code 的 Prompt Caching它不是修复命中而是绕开缓存机制。对于 MiMo 这种已经支持缓存、只是因为前缀被破坏导致命中率低的场景不应该优先关闭缓存。推荐顺序是先设CLAUDE_CODE_ATTRIBUTION_HEADER0观察 cache read 是否改善如果仍然异常再考虑DISABLE_PROMPT_CACHING1。另外ENABLE_PROMPT_CACHING_1H1是尝试更长缓存 TTL取决于上游是否支持可以后续测试。配置作用是否推荐CLAUDE_CODE_ATTRIBUTION_HEADER0去掉 attribution block保留 Prompt Caching推荐DISABLE_PROMPT_CACHING1直接关闭 Prompt Caching不优先推荐ENABLE_PROMPT_CACHING_1H1尝试更长缓存 TTL后续可测试关于副作用这个配置影响很小。它不会影响文件读取、文件修改、Bash 工具调用、MCP 工具、计划模式、上下文管理、多轮对话也不会关闭 Prompt Caching 本身。可能影响的是上游网关少了一些 Claude Code 请求来源信息如果某些网关依赖 attribution 做统计、归因、调试关闭后可能看不到 client version、prompt fingerprint 等内容。整体来说属于可观测性减少不是功能损坏。对于官方 Anthropic API 场景官方缓存机制本身已经适配不一定需要这个配置它主要适合第三方网关、OpenAI 兼容接口、本地模型、小米 MiMo 这类场景。6. 长期编码场景的接入建议如果你是把 Claude Code 当日常编码主力长期跑 Agent 任务建议把CLAUDE_CODE_ATTRIBUTION_HEADER0直接写进settings.json长期保留而不是每次临时 export。这样每次启动都自动生效不用记着手动设。接入层这边长期编码和 Agent 场景更适合用 Coding Plan配置入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite 它针对高频调用做了优化。Key 的日常管理走 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite 接入细节查 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。Claude Code 原生 Anthropic 协议的完整参数在 https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentClaudeCodeAnthropicutm_campaignrewrite 里都有照着填就行。最后提醒一句改配置的时候一定要合并而不是覆盖。很多人settings.json里已经有ANTHROPIC_BASE_URL和ANTHROPIC_AUTH_TOKEN直接粘贴新配置把原来的冲掉了结果接入都断了。正确做法是把CLAUDE_CODE_ATTRIBUTION_HEADER加到已有的env对象里保持其他字段不动。改完重启跑几轮同项目对话看 cache read 有没有起来起来了就说明这个变量确实管用。