缓存经济学：命中率如何决定 agentic 真实账单

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 拆成三类，加上输出，一共四项：

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 结构

同一份单价表，在不同负载下会长出完全不同的账单。下表为定性分档，用于说明结构差异，不是实测数据，占比高低只描述相对排序，不对应具体百分比。

关键分界线是"每轮新增内容除以已处理内容"这个比值。agent 循环的典型形态是每轮只新增一个工具返回或一段 diff，却要重读整个已建立的上下文。这个比值随轮次单调下降，cache read 占比随之上升。这就是为什么 agent 越长跑越贵，也是为什么 cache read 单价对 agentic 负载的杠杆远大于对单轮问答。

四、敏感性分析：75% 的降幅能换来多少

在 token 结构不变的假设下，总成本降幅约等于 cache read 占账单比例乘以 75%。以下为基于官方公布降幅的推演，非实测账单。

这张表是一把反向标尺：若你实测总降幅只有 10%，反推 cache read 占账单约 13%，说明瓶颈不在单价而在命中率。

用官方数字反推可以校准：整体降约 25% 对应 cache read 占账单约三分之一，agentic 最高降约 45% 对应约六成。两者互相印证同一结论——agentic 负载的账单里 cache read 确实占大头。但这两个百分比本身是官方测算口径，不是独立第三方实测。

还有三个会吃掉降幅的二阶效应：价格下降会改变行为，上下文更长、轮次更多、命中率优化不做了；为留住缓存你可能选更贵的长 TTL 档或加保活调用，写入成本上升；输出价不变，输出越长，读取侧省下的钱在总账里越被稀释。

五、为什么不把这张表横向套到其他厂商

本篇只核实了 Anthropic 一家。其他厂商的缓存定价本批没有逐家实测，请以各厂商官网 2026-09-02 快照为准。你只需按下表维度填一遍自己的数字，就能把第二节的公式套用到任何一家。

这也解释了为什么"单价便宜"和"账单便宜"经常脱钩：一个输入单价更低的模型，若缓存折扣率低、最小可缓存前缀长、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，每次改动都让此前建立的缓存前缀全部失效；把运行时状态——当前时间、任务 ID——拼进 system prompt 更常见，这些内容每轮都变，等于把命中率锁死在零。规则只有一句：前缀里只放不变的东西，会变的一律放到尾部。

第三条在 Fable 5.1 上有额外严重性。官方把"编辑历史轮次会使思考块失效"列为破坏性变更之一，且该检查对 2026 年 8 月 31 日及之后创建的账号强制生效。老账号上客户端重排历史只是悄悄击穿缓存，新账号上还会直接报错。Fable 5.1 把缓存纪律从省钱建议升级成了不遵守就报错。迁移细节见Claude Fable 5.1 API 破坏性变更迁移 SOP。

第四条对有降级链路的系统尤其重要。缓存与具体模型绑定，一次降级切换不只是换模型，而是让整条前缀重新按全价计费。若系统因限流或超时频繁在模型间抖动，命中率会被反复清零。相关设计取舍留待后续单独成文。

七、把命中率做上去：六个工程前提

1. 前缀不变性：按变化频率排序，system、tools、稳定历史、本轮新增，从前往后递增。会变的内容一旦进入前缀，会把它后面的全部内容一起拖下水。
2. 布局稳定：不要在上下文中间插入内容。追加在尾部是安全的，插在中间会让插入点之后的整段前缀失效。
3. 动态指令走 turn-scoped：随轮次变化的指令用 turn-scoped system messages 传，不重建 system，也不往 messages 里插 per-turn 提醒。
4. 历史裁剪交给服务端：客户端重排 messages 既击穿缓存，又会在 Fable 5.1 新账号上触发报错。
5. 按调用频率选 TTL：依据是同一前缀在 TTL 内会被读几次，不是越久越好。
6. 命中率可观测：分别打点四类 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 单价多低都与你无关。做法是把降级当成成本事件：给降级次数设阈值、抖动时加冷却、并为降级路径单独核算成本。