值班记录：缓存写入先记成本，缓存读取再核回本

本班账单差异出在重复输入的归类

同一份长文档，第一次请求和后续请求的费用可能不同。原因不一定是模型降价，而是部分输入从普通输入变成了缓存写入或缓存读取。排查账单时，应先确认缓存指的是模型服务端的提示词缓存，而不是应用直接返回旧答案的结果缓存。前者通常仍会执行模型推理，输出费用不会因此自动消失。

缓存写入先付成本，缓存读取兑现复用

缓存写入把符合条件的输入保存下来，供后续请求复用。它可能有独立单价、写入附加费或存储费用，也可能采用其他计费方式。不能默认“第一次只是普通输入价”，更不能把所有提供方的规则混为一谈。

缓存读取则是在请求满足复用条件时，按相应规则处理已缓存的输入。如果读取单价低于普通输入单价，命中部分就有节省空间；但新增问题、未命中的上下文和模型输出，仍可能按各自类别收费。读取便宜，不等于整次请求都按读取价结算。

两边放进同一张账表才有结论

不使用缓存时，重复发送的固定内容通常反复计入普通输入。使用缓存时，则要核算首次写入、后续读取，以及可能存在的存储或续期成本。比较两种方案，应保持模型、任务和输出规模尽量一致，避免把回答变短带来的节省误算成缓存收益。

• 如果写入费用较高，而固定内容只使用一次，缓存可能增加成本。
• 如果同一段长内容能在有效期内多次命中，读取节省才有机会覆盖写入成本。
• 如果有效期很短、请求间隔很长，反复重建缓存可能吞掉预期收益。

核算回本点时，可以比较“后续命中累计省下的普通输入费用”和“首次写入相对普通输入增加的费用及其他缓存成本”。具体计算必须以实际计费口径为准：有的平台返回的输入总量已经包含缓存部分，不能再把所有字段直接相加。

固定前缀适合写，频繁改动的前缀容易白写

长系统提示、工具定义和重复使用的参考资料，通常是值得检查的候选内容。把稳定内容放在前面、动态问题放在后面，有助于满足一些服务的前缀匹配要求，但不是通用保证。

若每次都在开头插入时间戳、随机标识或变化的用户资料，可能破坏可复用部分。最低长度、匹配边界、有效期、续期方式及是否需要显式开启，也应逐项确认。以 Claude Haiku 4.5 或 Gemini 2.5 Flash 为例，不能仅凭模型名称推断当前渠道一定支持某种缓存机制。

值班验收看计量，不只看响应快慢

响应变快不能单独证明缓存命中；读取缓存也不保证每次延迟都下降。上线前应保存请求条件、普通输入量、缓存写入量、缓存读取量、输出量和实际费用，再核对控制台账单。若接口没有提供相关字段，应先确认可用的计量依据，而不是按总输入量猜测命中率。

对按量付费、需要接入多种模型的团队，Relay365 可以作为统一中转的候选。采用前应核实目标模型与渠道的缓存支持、参数透传及计费展示，不能把上游缓存规则直接当成中转账单规则。需要评估这条接入路径时，可以创建一个 Relay365 账户，先用固定样本验证一次写入和多次读取的费用记录。

交班结论：高复用选缓存，低复用先别写

• 长内容稳定、有效期内复用频繁且读取价格有优势时，缓存读取是主要的降本来源。
• 内容只用一次、前缀持续变化或缓存频繁失效时，写入不应被默认开启。
• 无法确认命中量和收费口径时，先补齐观测，再决定是否扩大使用。

最终判定不是“缓存越多越好”，而是可验证的读取收益是否覆盖了写入及维护成本。缓存写入负责投入，缓存读取负责回收；账单上两边都核清，优化才算完成。