提示缓存命中高，为什么费用没明显下降？

缓存命中率描述输入复用程度，不能直接当作整次调用的折扣。 输出量、缓存写入费用、实际价格和额外计费项，都可能让高命中请求仍然花费较多。

本文核对 OpenAI 官方缓存文档和本站计费说明，示例使用公开协议字段与假设数字，不是某条 RootFlowAI 线路的实测报告，也不承诺固定命中率。

先看缓存究竟复用了什么

提示缓存复用的是相同提示前缀已经完成的计算。它不是把上一次回答直接返回给你，新的输入和输出仍需要处理。

官方说明指出，完整前缀是否一致很关键：工具定义、系统或开发者指令、上下文内容及相关请求设置发生变化，都可能影响后续前缀匹配。用户最后一句话相同，并不意味着完整请求前缀相同；保留同一个会话也不保证每次命中。

对应用开发者，有价值的做法是将稳定规则和固定工具结构保持稳定，把变化频繁的内容放在合适的位置。不要为了追求命中率保留不再需要的长历史；输入总量增加，仍可能抵消缓存单价带来的收益。

命中率要用同一种协议的分母

以 OpenAI Responses 的公开 usage 为例，input_tokens 是输入总量，input_tokens_details.cached_tokens 是其中的缓存读取部分。输入已经包含命中量，不能再把两者相加作为总输入。

Token 缓存命中率 = cached_tokens / input_tokens

跨多个请求统计时，先累加 Token 数再相除。一个 100 Token 请求和一个 100,000 Token 请求，不应在平均命中率中拥有相同权重。

把 0% 和 100% 简单平均得到 50%，不能代表这批请求按 Token 统计的命中率。输入总量为 0 时应记录“不适用”，避免除零；缺失 usage 字段时也不应自行填成已测得的零。

不同厂商协议可能将普通输入、缓存读取和缓存创建分开报告。切换到 Claude 等接口时，需要按该接口定义重新确定分母，不能照搬 Responses 的字段相加规则。

新增缓存写入字段时，注意避免重复收费计算

截至本文核对时，OpenAI 官方文档已为部分新模型列出 input_tokens_details.cache_write_tokens，并明确缓存写入价格不是在普通输入价上重复加收：相应 Token 应归入对应计费类别。

在响应与价格规则明确支持这三个互斥类别的前提下：

普通输入 = 输入总量 - 缓存读取 - 缓存写入
输入费用 = 普通输入 × 普通输入单价
         + 缓存读取 × 缓存读取单价
         + 缓存写入 × 缓存写入单价

若价格单位为每百万 Token，结果还需除以 1,000,000。不要先对全部输入收一次普通价格，再叠加全部缓存价格。

这是官方协议的核算思路。网关是否转发写入字段、某模型和分组是否单独计价，需要检查实际响应、当前价格和账单；不能因为官方支持某字段，就认定所有兼容接口已经提供。遇到字段缺失或计算结果出现负数，应先核对口径，不要强行修正为零。

一个高命中但总费用只下降一部分的例子

以下全部是计算示例，不是本站或厂商报价。假设某请求没有单独缓存写入项，普通输入为 2 额度/百万 Token、缓存读取为 0.2 额度/百万 Token、输出为 8 额度/百万 Token。

这里输入命中率为 80%，总费用下降为 40%。输出费用没有随输入缓存命中而消失。如果输出变长、增加工具计费或首次写入成本，最终节省比例还会变化。

RootFlowAI 的站内额度与官方美元参考价是不同口径，具体说明见 服务定价。比较时使用同一模型、分组、会员档和单位。

排查“没有省钱”的顺序

1. 确认响应字段完整。 记录输入、缓存读取、支持时的缓存写入、输出及独立工具费用，不只记录一个百分比。
2. 确认价格口径。 查看 当前价格，不要重复乘已包含的倍率，也不要把未展示的价格当成免费。
3. 比较相似任务。 保持模型、工具、上下文范围和输出要求可比；长任务不能直接和短任务比较单次费用。
4. 检查前缀变化。 留意每次变化的时间戳、工具顺序、模板、模型或上下文压缩，不要只比较最后一条用户消息。
5. 看成功完成任务的总成本。 将必要重试和多轮调用计入，单次高命中不能抵消无效的反复请求。

先使用已有消费记录和响应定位问题，确需实测时再设计少量可对照请求。不要为了刷出更高命中率而连续发送没有业务价值的付费调用。