经过我的一些调研，OpenAI Response 接口可以使用 prompt_cache_key 的字段来路由启用缓存，提供命中率。
目前 OpenCode 中已经可以通过 setCacheKey 的字段来设置了，然后 codex cli 是默认带这个功能的，并且不知道什么原因 codex cli 的支持貌似是最好的。当然他是原生支持，肯定最好。
举个例子就是我用 rightcodes 家的 API，发现用 codex cli 就能高效命中缓存，用 opencode + setCacheKey 则难以命中。（不过我目前发现也就这一家有这个问题，其他家的比如 timicc micu 等等一众中转厂商，使用 opencode + setCacheKey 也都能高效命中，并且在 New API 中也会展现出和 codex cli 一样的渠道亲和性）。所以姑且就当 rightcodes 家的后端哪里做的和主流的中转技术不一样。但是仍然可以认为 opencode + setCacheKey 的缓存覆盖范围近似等于 codex cli 的请求，但仍然小于 codex cli
而在这种情况下我使用 CC-Switch 来使用 openai response 来承接上游的 API，使用 claude 来代理，以方便直接在 claude code 中能够使用，通过让 AI 粗略的查看项目，结论说是 CC-Switch 中支持自动添加 prompt_cache_key。
随后我用 CC-Switch 承接了 openai response 的 New API 渠道，在 claude code 中使用，发现可以有渠道亲和性。也会有缓存。但是问题就出现在了这里，为什么这里的缓存不是基本全部命中，而是基本（市面上能看到的所有的中转 API）在大多数情况下，都是只能只能十几万 token，命中前面的一两万 token。我不清楚这个地方是 claude code 本身对上下文内容做了什么篡改导致无法全部命中，只能命中一些 builtin 的提示词（比如 mcp，skill 定义什么的）。因为传言之前 claude code 是会改动内容的，但我不清楚这个故事有没有后续。以及 claude code 的 anthropic 协议内部是通过 cache_control 字段在打断点，控制上下文缓存截止到哪里的。所以不清楚是不是 CC-Switch 断点没设置好了，我具体也没研究 OpenAI Response 这边有没有这种断点缓存的性质，我印象中，OpenAI 这边缓存应该就是全部都缓存，没记得有断点。
总之我个人目前的调研结果就是大多数中转支持通过 openai response 协议，使用 opencode，codex cli 来快速的命中缓存并响应。这个地方在 rightcodes 这个场合有点小特殊，目前不清楚原因。另一个大的疑惑就是通过 CC-Switch 转接 API 给 claude code 用之后，缓存的命中量大幅下降，明显只有开头的一些 prompt 命中了，不知道是不是有什么奇怪的 prompt 更改，或者断点之类的。
综上，个人的拙见以及疑惑就是这么多，希望各位有经验的佬友能够发表一下意见，感谢！
1 个帖子 - 1 位参与者