Appearance
为什么缓存命中率没期望的高？
缓存可以减少重复输入带来的消耗，但它不是“聊过一次，后面的内容就全部免费”。一次请求能否命中缓存，既取决于输入内容是否可以复用，也会受到模型、上游账号、请求路由和缓存有效期等因素影响。
因此，低价分组和高价分组出现不同的缓存命中率，并不矛盾。两种分组背后的账号额度和切换频率不同，缓存连续性自然也可能不同。
先理解缓存命中的是什么
大模型缓存通常复用的是输入中连续且一致的前缀。系统提示词、工具定义和前几轮对话没有变化时，后续请求才有机会复用这部分内容。
缓存一般不包括：
- 本次新增的输入
- 模型本次生成的输出
- 与上次请求不同的上下文
- 没有达到上游缓存条件的短请求
一次请求里可能同时包含缓存输入、未缓存输入和模型输出。因此，“命中了缓存”不等于整个请求都按缓存价格计算。
低价分组与高价分组为什么不一致？
在当前的上游调度方式下，低价分组和高价分组背后的账号池并不完全相同，账号可用额度也存在差异。
当一个上游账号的额度不足或耗尽时，后续请求需要切换到其他可用账号。原账号已经建立的缓存不一定能在新账号或新路由上继续复用，切换后通常需要重新积累可复用的缓存。
其中的影响关系可以简单理解为：
账号额度较小 → 更容易耗尽 → 更频繁地切换账号 → 缓存连续性更容易中断 → 命中率更容易下降或波动
低价分组使用的账号额度相对较小时，账号切换会更加明显，连续请求落在同一账号和同一缓存范围内的概率也会降低。因此，即使用户一直使用同一个会话，观察到的缓存命中率仍可能低于账号额度更充足的分组。
高价分组的账号额度通常更充足，请求连续落在同一账号上的概率相对更高，缓存也更容易保持连续。但这是一种概率上的差异，并不代表高价分组每次都能命中，也不代表低价分组一定无法命中。
还有哪些因素会影响缓存？
新会话没有历史缓存
新会话的第一次请求没有之前的请求可以复用。对话较短、上下文本来就少时，即使后续命中，缓存 Token 占全部 Token 的比例也可能不高。
请求前缀发生变化
下面这些变化都可能使部分缓存失效：
- 修改系统提示词或自定义指令
- 增删 MCP、插件、Skill 或工具定义
- 客户端升级后调整内置提示词
- 切换工作区、项目或权限配置
- 改变消息顺序、附件或上下文内容
用户看到的提问即使相似，客户端实际提交给模型的完整请求也可能不同。
切换模型、渠道或协议
不同模型的缓存通常不能互相复用。切换模型、分组、上游渠道，或者在 chat/completions 与 responses 等协议之间切换，都可能进入不同的缓存范围。
故障重试、负载均衡和渠道调整也可能改变请求路由，使短时间内的缓存命中率发生波动。
上下文被压缩
长会话达到一定长度后，Codex 等客户端可能压缩或重新整理上下文。压缩后的请求前缀与之前不同，需要重新建立缓存。
这类情况通常表现为：前一段时间命中较高，压缩后短暂下降，继续稳定对话后再逐步恢复。
缓存过期或被上游回收
缓存不会永久保留。请求间隔过长、上游回收缓存或服务商调整策略后，之前的内容可能无法继续复用。
平台可以尽量选择缓存表现更好的渠道，但无法绕过模型服务商的缓存规则，也不能保证每次请求都命中。
应该怎样判断缓存是否正常？
在使用日志中查看单次请求的输入明细。如果输入 Token 下方显示“缓存读”或类似字段，并且有具体数量，就说明该请求已经复用了缓存。
上图中的多条请求，大部分输入都来自缓存读取。这比单独查看某一条请求的瞬时命中率更能说明缓存是否实际生效。
建议使用一段稳定的真实工作流进行观察：
- 固定模型、令牌分组和客户端配置。
- 在同一会话中连续完成多轮任务。
- 不要中途频繁修改提示词或增删工具。
- 同时对比输入 Token、缓存读取 Token 和实际花费。
- 比较不同分组时，使用相同模型、相同客户端和相似的长会话。
首次请求没有缓存属于正常现象。如果同一长会话连续多次都没有任何缓存读取，可以带上请求时间、模型、分组和 Request ID 联系站长排查。
理性看待缓存命中率
缓存命中率不适合只看单次请求，也不能脱离模型、账号池、会话长度和客户端配置直接比较。
尤其是低价分组和高价分组，价格差异背后可能包含账号额度与调度稳定性的差异。低价分组节省了调用成本，也可能更容易遇到账号切换和缓存波动，这是需要一起考虑的实际取舍。
缓存的价值是在符合条件时减少重复输入成本。真正值得关注的是一段时间内的实际花费、服务稳定性，以及日志中是否持续存在缓存读取，而不是要求每次请求都达到某个固定命中率。