缓存优化
缓存读是最便宜的一档计价。搞懂它怎么命中，账单能差出好几倍。
Claude Code、Codex 这类工具的请求有个共同特征：每一轮对话都要把之前的全部历史重发一遍。 对话越长，重复发送的上下文越大。
如果这些重复内容每次都按普通输入价计费，成本会随对话长度平方级上涨。 缓存就是用来把这块重复内容按折扣价计费的。命中率高低，直接决定你的账单。
一、缓存的原理：前缀匹配
缓存不是「记住你的问题」，而是按前缀逐字节匹配：
服务端把你请求的最前面一段内容（按字节）算一个指纹存起来。 下次请求如果开头这一段完全一样，就直接复用，不再重新计算和计费。
关键推论只有一条：
前缀中任何一个字节变了，从这个位置往后全部失效。
请求的拼接顺序是固定的：工具定义 → 系统提示 → 消息历史。 所以：
- 放在前面的东西必须稳定（系统提示、工具列表）
- 放在后面的东西才可以每轮变（你的新问题、新读进来的文件）
顺序搞对，缓存自然命中；顺序搞错，标记写得再对也没用。
三个「悄悄毁掉缓存」的习惯
- 把时间戳写进系统提示（如「当前时间：…」）——每秒钟前缀都不一样，永远命中不了。
- 工具列表顺序不确定——工具定义排在最前面，顺序一变，后面全部作废。
- 中途换模型——缓存是按模型隔离的，换模型等于全部重来。
这些问题的共同点是：请求照样成功，你只是多花钱，没有任何报错。 所以要靠下面的验证方法主动发现。
二、三个计价字段
价格表里有三个和缓存相关的字段，理解它们的相对关系就够了：
| 字段 | 含义 | 相对成本 |
|---|---|---|
cache_read | 缓存读 —— 命中缓存的部分 | 最便宜的一档 |
cache_write | 缓存写 —— 本次把前缀写进缓存 | 比普通输入价更贵（写是溢价） |
cache_write_1h | 1 小时缓存写 —— 有效期更长的写 | 通常比 cache_write 更贵 |
两条使用结论：
- 缓存读通常是一个模型里最便宜的一档，所以命中率越高越省。
- 缓存写是溢价的，因为你在为「以后能便宜读」先付一笔钱。
因此缓存的账是这么算的：先付一次溢价写，之后每次命中都按最便宜的价读。 只有当同一段前缀会被反复读取时，这笔溢价才划算。
为什么有的模型 cache_write 是 0
价格表里有些模型的缓存写字段是 0，含义是该模型这一项没有单独公布价格， 不等于免费、也不等于不支持缓存。具体到某个模型怎么计费，看 模型价格表的「缓存读」列，那里是实付价。
5 分钟与 1 小时：该用哪个
两个缓存写的区别是有效期：
| 字段 | 有效期 | 什么时候划算 |
|---|---|---|
cache_write | 短（分钟级，通常是 5 分钟） | 连续使用。每次请求都会刷新计时，只要请求间隔足够密，缓存一直热着 |
cache_write_1h | 1 小时 | 有停顿。你离开 20 分钟回来接着聊，短期的缓存已经过期了 |
选择标准是两次请求之间的间隔：
- 间隔远小于 5 分钟（连续对话、agent 循环）→ 用默认的短期写，每次请求都在续期，不需要 1 小时
- 间隔在 5 分钟到 1 小时之间（离开一会儿再回来）→ 1 小时写才有意义
- 间隔超过 1 小时 → 两种都过期了，接受这次冷启动
不要为了「保险」一律用 1 小时写——它单价更贵，连续使用时纯属多花钱。
缓存会不会「过期」由上游决定
上面的时效是这类缓存机制的通行设计，实际有效期和计费口径以上游返回与实测为准。 控制台和价格表给了你字段名，但具体的 TTL 表现建议自己用下面的方法实测一遍。
三、缓存命中率怎么提高
核心就一句：让每轮请求的开头保持完全一致，只让结尾变化。
Claude Code
Claude Code 自己已经按这个原则组织请求了，你能做的是别去破坏它：
| 做法 | 效果 |
|---|---|
| 别频繁改系统提示 / CLAUDE.md | 系统提示在最前面，改一个字，本次会话的缓存全部失效 |
| 别中途换模型 | 缓存按模型隔离，换模型 = 全部重来 |
| 别中途换分组 | 换分组就是换上游线路，缓存不通用。改完必须重启客户端 |
| 一次会话做完一件事 | 长时间的连续会话命中率最高；频繁开新会话等于频繁冷启动 |
| 长任务别切开重开 | 每次重开都要重新写一遍前缀（付溢价），连续跑更省 |
Codex
Codex 走 OpenAI 兼容接口，规则相同。另外注意：
- 改动
config.toml后重启 —— 配置变了，请求前缀通常也会变。 - 模型名要保持一致 —— 在
gpt-5.6和gpt-5.6-sol之间来回切，缓存不通用。
通用原则
- 稳定的东西放前面：指令、项目说明、工具定义。
- 易变的东西放后面：本轮问题、新粘进来的日志、时间戳。
- 前缀太短建立不了缓存：只有重复内容足够长时缓存才有意义，短提示词本来也没多少可省的。
命中率是成本杠杆，不是配置开关
缓存不需要你在 FluxToken 侧开任何东西，它是上游按请求内容自动判定的。 你能控制的只有「请求前缀稳不稳」。
四、【Codex】满血 · 官Key 的「缓存命中 100%」
这个分组的官方说明原文是：
GPT 满血官 key 直连渠道，缓存命中 100%，要求高质量和稳定性的强烈推荐。
「缓存命中 100%」指的是这条通道上的缓存表现稳定可靠， 也就是说你为缓存付出的溢价能稳定换回折扣读，不会出现「写了一堆缓存却读不到」的情况。
对 Codex 这类每轮重发完整上下文的工具，这一点尤其值钱： 分组说明里的「缓存命中 100%」不是一句宣传语，而是直接对应账单的差异。
GPT 满血官 key 直连渠道，缓存命中 100%，要求高质量和稳定性的强烈推荐。
- 模型数
- 8
- 输入价起
- $1.2 /1M
- 上游
- OpenAI
查看该组全部模型（8）
gpt-5.5$3 / $18gpt-5.6$3 / $18gpt-5.6-luna$3 / $18gpt-5.6-sol$3 / $18gpt-5.6-terra$1.2 / $7.2gpt-6-astra$6 / $30gpt-6-sol$1.2 / $6gpt-6.1-sol$1.2 / $6
代价是这个分组的倍率在 Codex 系里偏高。取舍是：
| 你在意的是 | 选哪个 |
|---|---|
| 成本最低 | 【Codex】Pro · 惠享 |
| 日常稳定 | 【Codex】Pro · 稳享 |
| 缓存稳定 + 输出质量 | 【Codex】满血 · 官Key |
反过来，如果你主要在意的就是省钱，而对话又短（重复前缀本来就没多少）， 「缓存命中 100%」带来的收益有限，选便宜的档更合适。
【Claude】Max · 惠享 的缓存是会浮动的
这个分组的官方说明原文点名了这件事：「cursor、kiro性价比线路 · 缓存可能会有浮动， 若有异常请立即切换稳享分组。」
缓存浮动意味着你的实际账单会比预期高，因为你以为能命中读到的东西没命中。 说明里已经给了处置方式：遇到异常立刻切回 稳享，别等它自己恢复。
五、怎么验证缓存有没有生效
这是本页最实用的一节。缓存失效不会报错，只会让你多花钱， 所以必须主动查。
看响应里的用量字段
接口返回的 usage 对象里通常有几个和缓存相关的字段，含义如下：
| 字段 | 含义 |
|---|---|
cache_read_input_tokens | 本次有多少 token 是从缓存读的（按最便宜的价计费） |
cache_creation_input_tokens | 本次写进缓存的 token 数（付了溢价的写） |
input_tokens | 没走缓存、按全价计的 token 数 |
判断标准：连续发两次相同前缀的请求，第二次的 cache_read_input_tokens 应该大于 0。
如果一直是 0，说明前缀在每次请求里都变了——回去看上面那三个「悄悄毁掉缓存」的习惯。
更实际的观察方式
不看字段也能判断：在一次长会话里，把对话拉到几十轮，观察用量记录的增长曲线。
- 曲线线性增长 → 缓存在正常工作（每轮只新增一点）
- 曲线加速上翘 → 命中率有问题，每轮都在按全价重发历史
控制台可以查看自己的请求记录，配合服务状态页 判断是配置问题还是上游波动。
改了配置之后要重新验证
缓存失效最常见的形式不是「一开始就配错了」，而是本来好好的，某次改动之后悄悄失效了。 换过分组、改过系统提示、升级过客户端之后，回头看一眼用量曲线。
六、和分档计价的叠加
缓存不是唯一的成本变量。部分模型按上下文长度分档计价： 不超过某个阈值是一个价，超过之后单价跳升。
这意味着长对话面临双重成本压力：
- 上下文变长 → token 数量变多
- 超过分档阈值 → 单价本身跳升
分档阈值按上游不同：Claude 系、Codex / GPT 系、Grok 系、Gemini 系各有自己的界线， 详见模型价格表的「分档」一节。
实际建议：如果任务不需要超长上下文，及时开新会话。 缓存能降低重复前缀的单价，但压不住「上下文变长后单价跳档」这件事。
七、一页总结
| 要点 | 结论 |
|---|---|
| 缓存原理 | 前缀逐字节匹配，前面变一点后面全废 |
| 谁最便宜 | cache_read（缓存读）永远是三者里最低的一档 |
| 写是溢价 | cache_write 比普通输入贵，靠反复读出价值 |
| 短期 vs 1h | 连续用短期，有停顿才用 1 小时 |
| 提高命中率 | 前言稳定、后段变化、不换模型、不换分组、少改系统提示 |
| 怎么验证 | 连续两次相同前缀，cache_read_input_tokens 应大于 0 |
| 缓存 100% 的分组 | 【Codex】满血 · 官Key |
| 缓存会浮动的分组 | 【Claude】Max · 惠享（说明里要求异常时切稳享） |
相关页面
- Claude Code —— 长会话工具，缓存收益最明显
- Codex —— 官 Key 分组与缓存的关系
- 模型价格表 —— 缓存读、缓存写、1 小时写的实付价
- 计费与倍率 —— 实付价 = 基准价 × 分组倍率
- 怎么选分组 —— 缓存稳定性也是选组依据