关于之前的帖子，我有过关于 claude code 缓存的疑问，我后面更新了一下，决定再开一篇帖子，转述一遍，从评论区转述我自己哈哈
OpenAI Response 缓存字段分析，OpenCode，Codex，CC-Switch，中转厂商，New API
开发调优
经过我的一些调研，OpenAI Response 接口可以使用 prompt_cache_key 的字段来路由启用缓存，提供命中率。 目前 OpenCode 中已经可以通过 setCacheKey 的字段来设置了，然后 codex cli 是默认带这个功能的，并且不知道什么原因 codex cli 的支持貌似是最好的。当然他是原生支持，肯定最好。 举个例子就是我用 rightcodes 家的 …
原来的帖子如上，考虑到内容一样不太行，决定不在原来的帖子上发评论了
目前已确认，是 claude code 本身的问题，只能命中少数缓存是因为 claude code 的缓存是 anthropic 他们自定义的一套，他们采用了分段分块缓存的策略，就是 cache control 这种断点。
因为 claude code 的设计模式里面，并不是保证已经存在的文本成为历史消息后不再变动，他们会在一些文本节点处注入一些动态的信息，每次请求都不一样，比如时间戳之类的。
而正是因为 anthropic 他们后端推理引擎实现的这套缓存策略，可以完美和自家的这个契合，基本都能缓存上。至于具体原理我不懂。但是因为他们是自己实现了一套缓存的策略和 openai 这边的 prefix cache 不一致，导致 gpt 模型，转成 anthropic 协议后接入到 claude code，这里的动态注入的行为，导致 prefix cache 无法整体命中。
在这种模式下只能命中到在动态注入节点之前的文本缓存，所以在 claude code 中使用 prefix cache 推理引擎的模型，基本只能命中一些系统提示，工具列表定义，skill 描述文本之类的。所以就出现了在 claude code 中 gpt 模型大几十万的输入token，只命中了 1 万 token 的缓存。
所以，如果你用一些其他的 Coding Agent，比如 kilo code，trae，opencode 之类的，在里面自定义协议的地方，使用 anthropic 协议，然后接入 cc-switch 之后的 gpt 模型，其实是可以完美命中缓存的。
因为这些的 Coding Agent，或者我敢说，市面上除了 claude code 之外的所有的 Coding Agent，他们的设计模式，都是符合 prefix cache 策略的预定义行为标准的。就是已经存在出现过的文本，成为了历史消息，将不再进行任何变动，目前我所知道的也就 claude code 这一家是在背后这么干的，他们的这种设计，配合他们专有的缓存策略能够生效，但是和主流的 prefix cache 这种模式相悖。
但是话又说回来，claude code 作为 Coding Agent 这方面的龙头，无可争议的 No.1 产品，不知道他们这些特立独行的设计，是否有真正的道理在里面，还是说只是为了抬高使用门槛，抑或是不让其他的模型进入自己的生态，再者难道是这么做真的对于生产活动真正有效。但是 gpt-5.5 也是目前最优秀的模型之一，显然他就不这么干。
当然，这里还得表扬一下国产模型 kimi，他们家的模型接入到 claude code 后可以完美的命中缓存，我在小红书以及站内一些地方看过一些帖子，说是他们对于 claude code 这种设计模式，也做了专门的优化，在后端的推理引擎，会做各种各样的过滤，使得 claude code 中注入的这些 artifacts 不会影响到缓存的命中率，只能说，上有政策，下有对策。方法真的总比困难多。（当然，此处应该还有其他的国产模型，glm，minimax，qwen ，但是我懒得挨个去测试了，我估摸着，他们大概率也这么做了，因为他的 coding plan/token plan 出来就说要接入到 claude code 当中，要是不做这个，那就很宰割用户了）
但是显然 gpt 家的模型以及 infra 部门不屑于这么干，在 claude code 中用 gpt 模型实在是有些吃力不讨好了，这种情况下还是拥抱 codex 好一点。
写在最后，这些东西和想法肯定不属于我的原创了。但我也不知道要参考哪里了，找不到来源了，看了一堆乱七八糟的东西和做了一堆七七八八的实验才得到的一个结论，只能说感谢整个互联网了 
所以还有一个小疑惑就是，anthropic/claude code 为什么要如此设计，这种小设计是不是使得他成为行业龙头的又一个因素…
1 个帖子 - 1 位参与者