避坑指南：快自查你的 Claude 5.6 模型是否在收取“缓存创建”冤枉钱

最近这段时间，搞技术的圈子里有不少朋友在后台跟我吐槽，说自家的 AI 中转站或者自用的 Sub2API 工具，最近账单有点“烫手”。尤其是那个刚更新没多久的大版本模型（也就是大家习惯叫的 5.6），费用跑得比以前快了不少。

一开始以为是最近用量上来导致自然增长，结果扒开日志一看，好家伙，里面竟然冒出了大量的“缓存创建”费用项。要知道，缓存功能本来是用来省钱提速的，怎么现在反倒成了吞金兽？今天我就把这个问题掰开了揉碎了跟大家说说，顺便给几个排查和解决的思路。

一、 什么是“缓存创建”费用？

在 OpenAI 和 Claude 这一类的 API 接口里，有一个很香的功能叫“Prompt Caching”（提示词缓存）。简单理解，就是你发给模型的指令里，如果包含了一大段固定的背景资料（比如几万字的代码库、或者很长的系统提示词），模型不需要每次都重新读一遍。

系统会把这部分内容存个“存档”，下次调用的时候直接读存档，这样既快又便宜。这个“存档”的动作，或者是每次刷新这个存档，就会产生一次“缓存创建”的费用。

但问题来了：如果你发的请求明明是一次性的短对话，或者是没开启缓存功能的普通请求，却还能收到这笔钱，那肯定就是哪里出了Bug。

二、 为什么你会被多收费？

经过多位站长的联合排查，大家发现矛头主要集中在 5.6 这个新模型的计费逻辑上。这里有几个可能的“嫌疑犯”：</n 1. 接口字段冲突（最常见） 很多自建的 Sub2api 或者中转程序，为了兼容新旧模型，会在转发请求时强制插入某些参数。比如 extra_body 里的 caching: enabled 字段。如果代码里写死了“只要走这个通道就开启缓存”，那 5.6 模型收到指令后，就会乖乖地去创建缓存。 哪怕你只是一句“你好”，它也会把你的“你好”当成待缓存的内容处理，这笔缓存创建费就这么稀里糊涂地扣掉了。

2. 上游 API 的默认行为变更 在 5.6（以及对应的 Anthropic 官方版本）更新后，有些接口的默认行为可能发生了变化。以前可能需要显式声明才开启，现在或许是隐式开启，或者对于特定长度的 Prompt 自动触发了缓存机制。如果你手里的中转程序没跟上版本更新，计费就会对不上。

3. 第三方聚合层的误判 有些渠道不是直连官方，而是走的第三方聚合。这些中间商在计费转换时，把上游的“Token 读取”标记错误地转换成了“缓存创建”，或者是把预读取的费用直接算在了缓存头上。

三、 手把手排查方案

别光顾着心疼钱，赶紧拿起键盘查一下。这里提供几种不同层面的检查方法：

1. 检查日志中的 Request ID 去你的监控面板或者数据库，找到那几笔异常订单对应的 request_id。然后去上游提供的开发者控制台，用这个 ID 查询原始请求。重点看 usage 字段下的 cache_creation_input_tokens 是否有数值。

2. 抓包看实际发送的 JSON 如果你是自建节点，用 Wireshark 或者直接在应用层打印日志，看看你发给上游的 JSON Body 里，到底有没有包含 caching: { enabled: true } 或者类似的 beta 参数。如果有，检查你的代码逻辑，是不是把全局配置写死了。

3. 简单的对比测试 开一个干净的测试用例，直接用官方的 Curl 或者 Postman 调用一次 5.6 接口，完全不传任何缓存参数，看看账单是怎么算的。如果直接调用没事，通过你的中转站就有事，那 100% 是你的转发代码需要修正了。

四、 解决方案与建议

既然找到了原因，解决起来就有方向了。

• 修改配置: 如果你是通过 Sub2api 之类的工具搭建的，去翻翻配置文件（通常是 .env 或者 config.yaml），把关于自动缓存或强制缓存的开关关掉。除非你明确知道自己有一大段固定的 System Prompt 需要缓存，否则普通聊天场景下建议保持默认关闭。

• 更新转发逻辑: 如果你是开发者，检查转发逻辑。对于不支持缓存的老模型，或者不需要缓存的短对话，不要在转发给上游时自动添加 caching 控制字段。可以尝试根据模型的 version 准确判断是否注入该参数。

• 用户侧的止损: 如果你是中转站的用户，发现这个问题后第一时间联系站长。目前来看，这大概率不是一个恶意的扣费，而是技术实现上的疏忽。大部分站长在收到反馈后都会核实并退还差价，或者调整计费脚本。

写在最后

5.6 这一波更新虽然带来的能力提升很明显，但与之配套的计费细节确实给不少运维同学上了一课。搞技术的路上，这种因为“特性没对齐”导致的小坑在所难免。

今天的文章就到这里，希望能帮各位站长挽回点损失。如果你在排查过程中发现了其他异常情况（比如别的模型也有类似情况），欢迎在下面留言，咱们一起把这个坑填平。