2026 年 9 月 1 日，Anthropic 发布 Claude Fable 5.1，把 cache read 单价从每百万 token 1 美元降到 0.25 美元，降幅 75%。社群的第一反应是"agent 更便宜了"，但这句话既可能对，也可能完全落空：降价降的是单价，而账单是单价乘以 token 结构。若 agent 循环里 cache read 只占账单的一小部分，75% 的降幅落到总成本上可能只有个位数；若占大头，同一份单价表能省出的钱远超直觉。
本文不比谁的输入单价便宜——站内已有若干单价与性价比横评，那不是本篇的问题。这里要算的是：在缓存优先的架构下，命中率如何决定你的 agentic 账单。方法是把 agent 调用的 token 拆成四类、给出成本公式、按负载分档做敏感性分析，最后倒推吃到红利的工程前提，以及什么情况下根本吃不到。
先声明口径。Anthropic 官方公布的整体成本下降约 25%、高度依赖 cache read 的 agentic 工作负载最高约 45%，均为官方基于 2026 年 8 月真实使用数据的测算口径，不是独立第三方实测，本文所有节省数字沿用该口径；本文自己的推演会标注"以下为基于官方公布降幅的推演，非实测账单"。除 Anthropic 外的厂商缓存定价本批没有逐家实测，本文不给具体数字，只做相对关系描述，请以各厂商官网 2026-09-02 快照为准。
一、单价表的盲区：agentic 账单不是一条乘法
单价横评的隐含假设是"每百万输入多少钱"可以代表成本。这在单轮问答里勉强成立，在 agent 循环里会失效——原因不在价格，而在 token 的构成比例。
agent 循环里每一轮都要把此前已处理过的内容重新送进模型：仓库文件树、读过的代码、历史对话、工具返回的原始输出。这些对模型是已知信息，在 API 层面仍计入输入 token，缓存的作用就是让这部分不必按全价付费。于是有：轮次越多、上下文越长、每轮新内容越少，cache read 占比就越高。Fable 5.1 支持 1M 上下文，长上下文场景下 cache read 体量更大，占比被进一步放大。
两个团队用同一个模型，一个说便宜、一个说贵，通常不是谁算错，而是负载结构不同。判断降价有没有用，先看 token 结构。
二、token 构成拆解与成本公式
把输入 token 拆成三类，加上输出，一共四项：
| token 类别 | 计价 | 典型来源 | 在循环中的行为 |
|---|---|---|---|
| fresh input（未命中缓存） | 基础输入价 | 本轮新增指令、新读的文件、新工具输出 | 随轮次累积，无法靠缓存压缩 |
| cache write（写入缓存） | 写入价，高于基础输入价 | 首次进入上下文的内容块 | 只在首次出现时付一次 |
| cache read（读取缓存） | 读取价，远低于基础输入价 | 已在上下文中的稳定前缀 | 每轮重付，轮次越多占比越高 |
| output（输出） | 输出价 | 回复、thinking 块、工具调用参数 | 与轮次正相关 |
Fable 5.1 的具体计价为：输入 $10/M、输出 $50/M、cache read $0.25/M、5 分钟缓存写入 $12.50/M、1 小时缓存写入 $20.00/M，批量通道输入 $5.00/M、输出 $25.00/M。基础价与 Fable 5 持平，唯一变动是 cache read 由 $1/M 降至 $0.25/M。
公式如下，后面所有讨论都基于它：
单次调用成本（美元） =
fresh_input / 1e6 × P_fresh
+ cache_write / 1e6 × P_write
+ cache_read / 1e6 × P_read
+ output / 1e6 × P_out
整轮任务成本 = 各轮成本之和
cache read 成本占比 = (cache_read × P_read) / 总成本三个地方直觉容易出错。其一，写入比不写入贵：5 分钟档是基础输入价的 1.25 倍，1 小时档是 2 倍，缓存赚钱的前提是同一份前缀被读足够多次。其二，保活不免费：TTL 过期后要重新写入，低频任务可能每轮都在重写，等于用写入价替代读取价。其三，输出价是输入价的 5 倍：若每轮输出很长——比如官方记录的整文件重写倾向——输出会取代 cache read 成为第一大成本项，此时读取降价对总账的稀释作用有限。
三、四种负载档位的 token 结构
同一份单价表，在不同负载下会长出完全不同的账单。下表为定性分档，用于说明结构差异，不是实测数据，占比高低只描述相对排序，不对应具体百分比。
| 负载类型 | 典型形态 | token 结构主次 | cache read 占比 | 账单主要驱动 |
|---|---|---|---|---|
| 单轮问答 | 1 轮，短上下文 | fresh input 与 output 主导 | 低，接近零 | 输入与输出长度 |
| 多轮对话 | 数轮到十余轮，中等上下文 | cache read 上升，output 仍显著 | 中低 | 轮次乘上下文长度 |
| 长上下文 RAG | 少轮次，单次注入大量检索内容 | fresh input 与 cache read 并重 | 中 | 每次注入的检索体量 |
| 高频 agentic 循环 | 数十轮，上下文持续增长 | cache read 主导 | 高 | 轮次乘以重读次数 |
关键分界线是"每轮新增内容除以已处理内容"这个比值。agent 循环的典型形态是每轮只新增一个工具返回或一段 diff，却要重读整个已建立的上下文。这个比值随轮次单调下降，cache read 占比随之上升。这就是为什么 agent 越长跑越贵，也是为什么 cache read 单价对 agentic 负载的杠杆远大于对单轮问答。
四、敏感性分析：75% 的降幅能换来多少
在 token 结构不变的假设下，总成本降幅约等于 cache read 占账单比例乘以 75%。以下为基于官方公布降幅的推演，非实测账单。
| cache read 占账单比例 | 单价降 75% 后的总成本降幅 | 大致对应的负载 |
|---|---|---|
| 10% | 约 7.5% | 单轮问答、缓存几乎没用上的任务 |
| 20% | 约 15% | 短会话、命中率偏低的多轮对话 |
| 33% | 约 25% | 官方口径下的典型工作负载 |
| 45% | 约 34% | 中等强度的 agent 循环 |
| 60% | 约 45% | 官方口径下高度依赖 cache read 的 agentic 负载 |
| 70% | 约 52.5% | 极高命中率的长时程 agent |
这张表是一把反向标尺：若你实测总降幅只有 10%，反推 cache read 占账单约 13%，说明瓶颈不在单价而在命中率。
用官方数字反推可以校准：整体降约 25% 对应 cache read 占账单约三分之一，agentic 最高降约 45% 对应约六成。两者互相印证同一结论——agentic 负载的账单里 cache read 确实占大头。但这两个百分比本身是官方测算口径，不是独立第三方实测。
还有三个会吃掉降幅的二阶效应：价格下降会改变行为，上下文更长、轮次更多、命中率优化不做了；为留住缓存你可能选更贵的长 TTL 档或加保活调用，写入成本上升；输出价不变，输出越长，读取侧省下的钱在总账里越被稀释。
五、为什么不把这张表横向套到其他厂商
本篇只核实了 Anthropic 一家。其他厂商的缓存定价本批没有逐家实测，请以各厂商官网 2026-09-02 快照为准。你只需按下表维度填一遍自己的数字，就能把第二节的公式套用到任何一家。
| 需要核实的维度 | 为什么它决定命中率 |
|---|---|
| cache read 相对基础输入价的折扣率 | 决定 cache read 在账单里的权重 |
| 写入价相对基础输入价的溢价倍数 | 决定读几次才能回本 |
| TTL 档位与刷新机制 | 决定低频任务是否每轮重写 |
| 最小可缓存前缀长度 | 前缀过短直接不命中 |
| 计费粒度（自动缓存还是手动断点） | 自动与手动的命中率差别很大 |
| 缓存是否跨模型、跨会话共享 | 换模型会击穿缓存 |
这也解释了为什么"单价便宜"和"账单便宜"经常脱钩：一个输入单价更低的模型，若缓存折扣率低、最小可缓存前缀长、TTL 短，在高频 agentic 负载下的实际账单完全可能高于单价更贵的对手。选型时把它当六维向量，而不是一个数字。
从定位上看，Opus 5（2026 年 7 月发布，官方称价格约为 Fable 5 的一半）处在更低输入单价一侧；GPT-5.6 Sol 以 Terminal-Bench 4.0 得分 37.3% 进入 agent 能力讨论；DeepSeek-V4-Pro、Kimi K3、Qwen3.8-Flash-Next、GLM-5.3-Flash 与 Gemini 3.7 Flash 各有自己的缓存体系。本文不比较它们的单价。本篇的问题是：在你选定的那个模型上，你的命中率是多少。
六、四种典型的缓存失效触发
命中率不是模型给的，是自己写坏的。
| 触发动作 | 影响范围 | 后果 | 规避方向 |
|---|---|---|---|
| 改 system prompt | 前缀整体失效 | 全量按 fresh input 计费或重新写入 | 稳定指令放 system，随轮次变化的走 turn-scoped 通道 |
| 改 tools 数组 | 前缀整体失效 | 同上 | 工具定义一次性固定，动态内容不进工具描述 |
| 编辑历史轮次 | 从编辑点起失效 | 重读成本上升，Fable 5.1 上还可能报错 | 历史裁剪交给服务端，不在客户端重排数组 |
| 换模型 | 缓存与模型绑定，整体失效 | 切换那一轮起全量重新计费 | 把降级当成本事件，避免高低档频繁抖动 |
| TTL 过期 | 该前缀失效 | 低频任务等于每轮重写 | 按调用频率选 TTL 档位 |
前两条最常被轻视。为调优频繁改 system prompt，每次改动都让此前建立的缓存前缀全部失效；把运行时状态——当前时间、任务 ID——拼进 system prompt 更常见，这些内容每轮都变，等于把命中率锁死在零。规则只有一句：前缀里只放不变的东西，会变的一律放到尾部。
第三条在 Fable 5.1 上有额外严重性。官方把"编辑历史轮次会使思考块失效"列为破坏性变更之一，且该检查对 2026 年 8 月 31 日及之后创建的账号强制生效。老账号上客户端重排历史只是悄悄击穿缓存，新账号上还会直接报错。Fable 5.1 把缓存纪律从省钱建议升级成了不遵守就报错。迁移细节见Claude Fable 5.1 API 破坏性变更迁移 SOP。
第四条对有降级链路的系统尤其重要。缓存与具体模型绑定，一次降级切换不只是换模型，而是让整条前缀重新按全价计费。若系统因限流或超时频繁在模型间抖动，命中率会被反复清零。相关设计取舍留待后续单独成文。
七、把命中率做上去：六个工程前提
- 前缀不变性：按变化频率排序，system、tools、稳定历史、本轮新增，从前往后递增。会变的内容一旦进入前缀，会把它后面的全部内容一起拖下水。
- 布局稳定：不要在上下文中间插入内容。追加在尾部是安全的，插在中间会让插入点之后的整段前缀失效。
- 动态指令走 turn-scoped：随轮次变化的指令用 turn-scoped system messages 传，不重建 system，也不往
messages里插 per-turn 提醒。 - 历史裁剪交给服务端：客户端重排
messages既击穿缓存，又会在 Fable 5.1 新账号上触发报错。 - 按调用频率选 TTL：依据是同一前缀在 TTL 内会被读几次，不是越久越好。
- 命中率可观测：分别打点四类 token，把 cache read 占比当一级指标。没有这个数，前面所有讨论都是猜。
命中率建议同时看两个口径。token 口径是 cache_read / (cache_read + fresh_input + cache_write)，反映机制工作得好不好；成本口径是 cache_read × P_read / 总成本，反映实际省了多少钱。由于 cache read 单价只有基础输入价的四十分之一，同样好看的 token 命中率在成本口径下未必好看。
最后是验证。降价有没有落到你的账单上，不能靠感觉便宜了。做法是切换前后各取一批代表性任务，固定任务集与轮次上限，比较单任务成本与四类 token 构成。任务集设计见自建 agent 评测：Harbor 资源指南，发布本身的变化见Claude Fable 5.1 与 Mythos 5.1 发布解读。
八、结论：先测结构，再谈单价
- 单价只是第四位的影响因素。 排序是命中率、布局稳定性、轮次与输出长度，最后才是单价。
- 75% 的降幅能转化出多少，取决于 cache read 占你账单的比例。 三成对应约 25%，六成对应约 45%，两个锚点均来自官方测算口径。
- 吃到红利的前提是工程纪律，不是换模型。 前缀不变、布局稳定、TTL 匹配频率、命中率可观测，缺一件，降价就只是纸面数字。
- 最容易被忽略的是根本吃不到的情况。 system prompt 塞动态内容、每轮重建 tools、客户端重排历史、频繁跨模型抖动，都会让命中率归零。
- 别指望一次切换就看到变化。 把四类 token 打点接上，跑两批固定任务集，用数据说话。
参考来源
- Anthropic 官方公告与定价页（Claude Fable 5.1，2026-09-01 发布）——输入 $10/M、输出 $50/M、cache read 由 $1/M 降至 $0.25/M（降幅 75%）、5 分钟缓存写入 $12.50/M、1 小时 $20.00/M、批量输入 $5.00/M 与输出 $25.00/M、上下文 1M token、最大输出 128K token。具体 URL 未确认。
- Anthropic 官方成本测算（分析 2026 年 8 月真实使用数据，典型工作负载整体降约 25%，高度依赖 cache read 的 agentic 负载最高降约 45%）——官方测算口径，非独立第三方实测，本文所有节省数字沿用该口径。
- 除 Anthropic 外各厂商的缓存定价（读取折扣率、写入溢价、TTL 档位、最小可缓存前缀、计费粒度）——本批未逐家核实，请以各厂商官网 2026-09-02 快照为准，本文不给出具体数字。
- Fable 5.1 破坏性变更中"编辑历史轮次会使思考块失效"对 2026-08-31 及之后创建的账号强制生效——出自官方公告，URL 未确认。
- Opus 5 价格约为 Fable 5 的一半、GPT-5.6 Sol 在 Terminal-Bench 4.0 得分为 37.3%——来自各发布方公开信息，仅用于定位。
- 第三至五节表格为基于官方公布降幅的算术推演与定性分档，非实测账单；其余为工程建议，已在正文逐处标注。
常见问题
Q1：cache read 降价 75%，为什么我的账单没降多少？ A1：因为降的是单价，账单是单价乘以 token 结构。只有 cache read 占大头时，75% 的降幅才能转化为可观的总成本下降。先用成本口径算一遍占比：占比 10% 只能换到约 7.5% 的总降幅。占比上不去，原因通常是命中率低而非单价高，此时优化前缀比换模型有效得多。
Q2：缓存命中率应该怎么定义和计算？ A2：建议同时看两个口径。token 口径是 cache read 除以输入 token 总量，反映机制工作得好不好；成本口径是 cache read 的费用除以总费用，反映实际省了多少钱。由于 cache read 单价远低于基础输入价，同样的 token 命中率在成本口径下会明显更低。前者排查工程问题，后者与账单对账。
Q3：改 system prompt 真的会让缓存全部失效吗？ A3：会。命中前提是前缀逐 token 完全一致，而 system prompt 是前缀第一段，改动一个字符其后所有内容都不再命中。最常见的错误是把当前时间、任务 ID、用户名这类每轮都变的内容拼进 system prompt，等于把命中率锁死在零。
Q4：5 分钟和 1 小时两档缓存该怎么选？ A4：按同一前缀在 TTL 内会被读几次来选，不是越久越好。写入价高于基础输入价（Fable 5.1 上 5 分钟档 $12.50/M、1 小时档 $20.00/M），若一段前缀在 TTL 内只被读一次，你付的是写入价而非读取价，比不用缓存更贵。高频连续调用适合长 TTL。
Q5：多模型路由与降级会不会把缓存红利吃光？ A5：会，而且比多数人以为的更彻底。缓存与具体模型绑定，一次切换就让整条前缀重新按全价计费。若系统因限流或超时在高低档模型间频繁抖动，命中率会被反复清零，此时 cache read 单价多低都与你无关。做法是把降级当成成本事件：给降级次数设阈值、抖动时加冷却、并为降级路径单独核算成本。