claude code 随机字符串导致缓存失效问题，以及现有的解决方案，以及我个人的项目级解决方案

• 我的帖子已经打上 开源推广 标签： 是
• 我的开源项目完整开源，无未开源部分： 是
• 我的开源项目已链接认可 LINUX DO 社区： 是
• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

目前我在之前的讨论中，讨论过关于 claude code 缓存的问题

经过我的一些调研，OpenAI Response 接口可以使用 prompt_cache_key 的字段来路由启用缓存，提供命中率。 目前 OpenCode 中已经可以通过 setCacheKey 的字段来设置了，然后 codex cli 是默认带这个功能的，并且不知道什么原因 codex cli 的支持貌似是最好的。当然他是原生支持，肯定最好。 举个例子就是我用 rightcodes 家的 …

关于之前的帖子，我有过关于 claude code 缓存的疑问，我后面更新了一下，决定再开一篇帖子，转述一遍，从评论区转述我自己哈哈 原来的帖子如上，考虑到内容一样不太行，决定不在原来的帖子上发评论了 目前已确认，是 claude code 本身的问题，只能命中少数缓存是因为 claude code 的缓存是 anthropic 他们自定义的一套，他们采用了分段分块缓存的策略，就是 c…

后来根据我的后续的一些搜索和观察，发现在 Bilibili 上还有小红书上，都或多或少有不少前辈发现了这个问题，并且提出了一些解决方案，这里我就不再把他们的东西搬移过来了

大致的意思是这样的

1. claude code 为了统计用户的请求特征，会在每次请求前面，添加一个 cch 的字段，这是一个随机字符串。

2. 然后国产模型会主动兼容 claude code 应用

   1. 他们在服务端识别到这个随机字符串会给他过滤掉，于是他们就能命中缓存。
   2. 这也是为什么他们官方都提供了 /anthropic 这种 claude code 兼容端点

3. 而现在的协议转换网关（ anthropic message → openai response），比如 new api，cc-switch 之类的。

   1. 会自动把这个随机字符串，转换打包进 openai 协议中的 system prompt 中
   2. 从而导致 openai 协议这边无法高效命中缓存，因为在 system prompt 这边就被随机字符串污染了，只能命中前面的一些 tools skills 的固定文本

然后各位前辈提出来的解决方案就是，在 claude code 里面设置环境变量 CLAUDE_CODE_ATTRIBUTION_HEADER 为 "0" 就可以了。

这个是从泄露出来的 2.1.88 版本的 claude code 源码中找到的

使用了这个环境变量后，会在应用客户端这里，取消这个 cch 字符串的注入，进而也能命中缓存

接下来是我个人的带货环节

我做（vibe coding）了一个 github 开源项目

GitHub - brilliantrough/responses-api-compat-proxy: Compatibility proxy for OpenAI-style Responses API...

Compatibility proxy for OpenAI-style Responses API providers with SSE normalization, fallback routing, and local admin tools.

1. 这个项目是我买了市面上很多家的 openai codex 的 api

2. 但是因为毕竟来路不明，这些 api 都不稳，用起来总是会报错。这也很正常，毕竟人力维护。但是会使人大动肝火，乳腺不畅

3. 于是乎我自己 vibe coding 了一个自动 fallback 的微型中转平台

   1. 对外暴露一个统一的 openai response 接口

   2. 在 json 文件中从前往后配置各家的 api

   3. 运行时自动从前往后进行请求，成功则返回，失败则 fallback

      1. 另外我还设置了熔断，比如某一家的 api 请求失败了，禁用几分钟，状态置为 open，就是 fallback 的时候会跳过这个条目
      2. 几分钟时间过后状态置为 half_open
      3. 然后后面的请求继续 fallback 到 half_open 的条目时不会跳过，尝试重新请求，一旦成功，则把条目状态置为 close
      4. close 就代表条目的状态正常，继续使用

   4. 平台摆铺的策略就是

      1. 前面放一些量大管饱的平台，比如 rawchat micu ikun 等等
      2. 后面放一些稳定的平台，比如几个小伙伴一起拼拼凑凑的 openai pro 账号之类的

4. 这个项目和这篇小文章的联系就是

   1. 我发现了存在 cch 随机字符串这个行为，并且认为让客户端去进行一个环境变量的更改，是一件非常困难的事情，毕竟这类信息都是少数人的智慧，大多数人仍然被蒙在鼓里
   2. 于是乎我在我这个 response proxy 层，从 system prompt 中拿到这个 cch ，然后把他 strip 掉
   3. 效果就是确实能够让客户端（claude code）不用做任何更改就能实现 openai 模型的高效缓存

5. 和其他项目的联动，作用到 claude code，opencode，codex 当中

   1. 我直接在本地另外起一个 sub2api 项目，然后把这个 response 接口接进去

   2. sub2api 的 openai response 接口接入到 new api 中，取名为 codex 分组，进行统一分发

   3. 将 sub2api 的接口接入给 cc-switch，用于协议转换

      1. 之所以使用 cc-switch 再套一层，是我觉得 sub2api 实现的模型转换还有些小问题，懒得折腾了，干脆再套一层
      2. cc-switch 专职做这个，response -> anthropic 这一块的转换我还挺放心的

   4. 将 cc-switch 的 anthropic 接口接入到 new api 中，取名为 codex anthropic 分组，进行统一分发

   5. codex 分组用于 opencode， codex 中，能够通过 prompt_cache_key 进行高效缓存

   6. codex anthropic 分组用于 claude code 中，能够通过 cc-switch 自动添加 prompt_cache_key 的功能，以及 response proxy 自动 strip cch 字段的功能，实现高效缓存

至此，我的项目管理如下

1. 在 sub2api 中我用于全局的监控
2. 在 reponse proxy 中，我能看到各个上游的调用情况
3. 在 new api 中，我能看到 codex 分组和 codex anthropic 分组的调用情况

以下是战绩汇报

在这些监控的同时，我收获了一个在 Agent 中调用 4000 次，可能只出现 1 次报错甚至 0 次报错的高贵体验（SLA 级别服务！！！芜湖！！起飞！！！）

当然上面这个是在 Agent 中调用就是这样的体验

1. 如果你分发到了 chat 端
2. 以及 gpt-5.5 本身还有一些 258K 上下文限制
3. 以及 openai 官方还有报错的情况下

那么还是会出现一些正常报错的，这就比较难避免了，不过我的目标场景也不是要解决这些问题，官方出错我还能咋地呢？

再说，上次官方出现连续报错的时候，我这个项目一天下来的几千次监控，仍然就只出现了一两次报错，因为有连续的 fallback 规则兜底，总能 fallback 到当前不报错的那个请求

（继续吹牛）当时啊，我正在用我的这个 api，然后我的同学跑过来跟我说他的 plus 老是报错是怎么回事。我一打开我常年混迹的各家中转API的QQ群才发现，到处都在哀嚎。但是呢，我用起来完全没有感觉这天出现了大变故。算是直观感受到这个项目带给我的容灾能力，心里美滋滋~~

总结部分

总之一方面，claude code 应用端会自动注入随机字符串，可以通过 CLAUDE_CODE_ATTRIBUTION_HEADER 设置为 "0" 来解决。

另一方面，主包做了一个微型网关，用于 response proxy，其中规避了这个随机字符串的问题，当然更多的是为了 SLA 体验。

欢迎大家来发表评论和见解

1 个帖子 - 1 位参与者

阅读完整话题