2026 年 9 月 24 日，Michael Segner 在 Claude 官方博客发了一篇只有 4 分钟阅读量的短文：Coding sessions are longer and use more context. Claude Opus 5.5 is built with that in mind.
标题里那句「built with that in mind」很容易被读成公关话术。但这篇文章真正有意思的地方不是「新模型更便宜了」这个结论，而是它先给出一组使用行为数据，再解释为什么降价要打在那几个特定位置。换句话说，它是一篇倒着写的成本设计说明书：先说用户变成了什么样，再说产品为此改了什么。
对于按 token 付费、每天在 Claude Code 里跑长会话的人来说，这里面有一个值得较真的问题：官方给的是「典型按 token 计费负载下比 Opus 5 便宜约 40%」，而公开定价的降幅明明只有输入输出 −20%、缓存读取 −60%。这两个数字之间的差额从哪来？
这篇文章就顺着这个差额往下拆。
一、先看行为：prompt 数没变，prompt 里的东西全变了
原文最有价值的部分是一组 Claude Code 聚合数据，覆盖 2026 年 3 月到 9 月这半年。它的前提条件必须先说清楚：
每个会话的 prompt 数量保持稳定。
这个前提很重要。它意味着用户的「交互频次」没变——你还是每天跟它对话差不多那么多次。但同一批 prompt 内部发生的事情，已经完全不是半年前那回事了。
这七个数字可以分成两组来读。
第一组是「会话变重」：每个 prompt 的工作时长延长 3.3 倍，每个 prompt 触发的模型调用增加 40% 以上，而人工打断次数减少了 68%。三个数字指向同一件事：用户从「站在旁边看着它一步步做」变成了「把任务整段扔过去，回来看结果」。工具服务器与 skill 的使用比例提高约 2 倍，进一步印证这点——委派任务的前提是它手上有能自己取信息、自己调工具的能力。
第二组是「上下文变厚」：每个请求携带的上下文量增长 2.6 倍，输入与输出的 token 比从 189:1 变成 324:1，而直接往 prompt 里粘贴文本的比例减少了约三分之一。
第二组里那个「粘贴减少」的数字，我认为是整篇文章最容易被跳过、但信息量最大的一条。它说明上下文的来源变了：以前是人把代码片段复制进对话框，现在是 Agent 自己用 grep、read、MCP 工具去取。人不再是上下文的搬运工，Agent 自己是。
这两组数字合在一起，得到一个对成本结构的判断：账单的重心正在从输出侧向输入侧转移，而输入侧的绝大部分是「被反复重读的同一批上下文」。原文那句话说得很克制但很准：
同样的降价，对今天的 Claude Code 流量比半年前更省钱——因为账单里现在更多是被重复读取的上下文。
这就是后面所有设计的出发点。
二、第一层：定价——把降价打在账单占比最大的那一段上
Opus 5.5 公布的定价变化只有两条：
- 输入与输出 token 价格下调 20%
- 缓存读取（cache read）token 价格下调 60%
这两个数字的不对称，就是整个设计意图。
结合上一篇关于任务成本的拆解里用到的列表价，可以反推出两代模型每百万 token 的单价（输入 / 输出 / 缓存读）：
| 模型 | 输入 | 输出 | 缓存读 |
|---|---|---|---|
| Opus 5 | $5 | $25 | $0.50（= 输入价 10%） |
| Opus 5.5 | $4 | $20 | $0.20（= 输入价 5%） |
注意最右一列的变化：缓存读取从「输入价的 10%」压到了「输入价的 5%」。也就是说，官方不只是把绝对价格砍了 60%，还把缓存相对于新输入的折扣力度翻了一倍。这是一个非常明确的信号——它在用价格逼你去做缓存友好的上下文工程。
拿一个具体会话来核对。假设一次会话消耗 2.0M 缓存读 + 200K 新输入 + 60K 输出（这是上一篇里用过的示例结构，比例上接近今天 Claude Code 的典型形态）：
按 Opus 5 列表价：2.0 × 0.50 + 0.2 × 5 + 0.06 × 25 = 1.00 + 1.00 + 1.50 = $3.50。
三段占比是 29% / 29% / 43%。然后两种降价分别落在不同的段上：
- 缓存读那 $1.00 降 60%，省 $0.60
- 新输入 + 输出那 $2.50 降 20%，省 $0.50
合计省 $1.10，新账单 $2.40，降幅 −31%。
这就是第一个关键结论：纯定价只能给你 −31%，离官方的「约 40%」还差一截。 而且降价之后的结构变得更刺眼了——缓存读只剩 17%，「新输入 + 输出」占到 83%。缓存读已经便宜到快要不构成问题，真正贵的是没进缓存的输入和模型吐出来的字。
这也解释了原文顺带提的那句竞品对比：截至发布日，Opus 5.5 的缓存 token 价格只有竞品模型的五分之一，且性能更优。缓存价是这一代 Agent 编码工作负载的主战场，官方显然认为自己在这一项上拉开了差距。
三、第二层：框架——让 Claude Code 自己少丢缓存
上一节的结构分析留下一个明显的杠杆：既然未命中缓存的输入按 $4/M 计费、而缓存读只要 $0.20/M，那么命中率每提高一点，都相当于给那部分 token 打了 95 折以上。二十倍的价差，比任何一次降价都凶。
原文在这里给出了一个很有说服力的反趋势数据：
按趋势推测，缓存未命中率本应上升（因为上下文量涨了 2.6 倍），实际却相反：未命中缓存的输入减少了超过 50%。
上下文翻了 2.6 倍、未命中反而腰斩，这只能是工程干预的结果。原文列了四类改动：
- 修掉「小痛点」导致的意外失效，典型例子是刷新登录态。这类失效对用户完全无感——你根本不知道自己刚刚把一整条缓存扔掉了，账单上却实实在在多了一笔。
- 修掉「大动作」导致的失效，比如对话中途追加指令、按需加载工具。prompt cache 的本质是前缀匹配，任何插在已缓存前缀中间的内容都会让后面全部重算。
- effort level 可以会话中途切换而不重置缓存（Opus 5.5 与 Fable 5.1 等新一代模型支持）。这一条的产品意义比听起来大：它把「思考深度」从一个需要提前押注的决策，变成了可以随时微调的旋钮。
- 分叉出去的 subagent 直接从父级缓存启动，相同上下文不再重复付费。对于 fan-out 式的多 Agent 编排，这几乎是结构性的成本变化——以前 N 个 subagent 就是 N 份上下文钱。
同时，1 小时的缓存生命周期（TTL）现在对 API key 与云服务商用户开放（订阅用户此前已有）。这一条配合的是真实工作节奏：你去开个会、吃个饭，回来会话还在缓存里。
把这一层叠回刚才那个示例会话。如果未命中的新输入从 200K 降到 100K：
2.0 × 0.20 + 0.1 × 4 + 0.06 × 20 = 0.40 + 0.40 + 1.20 = $2.00
相对 Opus 5 的 $3.50，累计降幅 −43%。
官方那句「约 40%」到这里才对得上。 它不是一个定价数字，是「定价降幅 + 框架侧命中率改善」的合成结果。这也解释了为什么官方用的是「估算」和「典型负载」这种措辞——第二层的收益取决于你的会话形态，不可能给一个精确值。
四、第三层：模型行为——少走一轮比省一个缓存 token 值得多
前两层都还在「同一条执行轨迹上省钱」。第三层换了维度：让轨迹本身变短。
原文引了 Zeta Labs 的实测：相比 Opus 5，Opus 5.5 在完成同一批任务时轮次与工具调用更少、每任务成本接近减半，而且最难那一档任务的完成数量翻了一倍。
然后是全文我最认同的一句判断：
少走一轮，比省下一个缓存 token 更省成本。（A reduced turn is even more cost efficient than a cached token.）
这句话值得换算成具体量级，因为它的差距大得反直觉：
按 Opus 5.5 列表价，一个缓存 token 是 $0.0000002。而在一条上下文已经涨到 100K 的会话里，多走一轮的成本是：
- 重读 100K 上下文（缓存命中）：
0.1 × $0.20 = $0.02 - 吐出 2K 输出（含 thinking）：
0.002 × $20 = $0.04 - 合计约 $0.06
$0.06 ÷ $0.0000002 = 30 万个缓存 token。
也就是说，模型少绕一个弯，等价于你省掉 30 万个缓存 token 的钱。而这一轮里贵的部分甚至不是重读上下文，是那 2K 输出——输出单价是缓存读的 100 倍。轮数之所以是最强的放大器，因为它同时放大了输入重读和输出生成两边。
顺带说一句原文提到的「输出生成速度比 Opus 5 快 30% 以上」。这一条要诚实地归类：它既不提高缓存命中率、也不减少 token，省的是你的时间，不是你的钱。在长时间运行的无人值守任务里，它的价值体现在别处——迭代节奏变快，你一天能跑完的实验数量变多。
五、落到操作：保护缓存读的三条规则
原文在「Protect your cached reads」一节给了三条建议。它们看起来简单到不像建议，但每一条都对应着前面某个真实的失效路径：
① 在会话开始时就把模型定下来，不要中途切换。 中途换模型会让整条缓存作废，从头重读一遍。要调，就调 effort level——那个现在不重置缓存。这是把「可变的」和「不可变的」分清楚：模型是会话级决策，effort 是轮级决策。
② 在离开之前 compact，而不是回来之后再 compact。 这条最反直觉，也最容易做错。回来后再压缩，意味着你先要为读完那条又长又旧的上下文付一次钱，然后才把它压掉。走之前压，下一段会话直接从瘦上下文起步。
③ 用 API key 或云服务商时，为长会话把缓存 TTL 设成 1 小时。 这一条基本是纯收益：只要你的工作节奏里存在「离开半小时再回来」的情况，它就在替你省钱。
原文还建议在 Claude Code 里用 /usage 看一眼自己的用量中缓存读取占多大比例。这个动作的意义不在于那个数字本身，而在于它决定了上面三条规则对你有多值钱：如果缓存读只占你账单的 5%，那你该关心的根本不是缓存，是输出 token 和轮数。
六、边界：谁能拿到 −40%，谁只拿到降价
这篇文章最克制的地方，是它没有把 −40% 说成人人有份。原文引了 Addy Osmani 的判断：
范围清晰的任务上，两个模型轮次差不多，你得到的只有降价。差距最大的是开放式任务——模型可能在错误思路上耗费大量轮次。没有哪个数字适用于所有代码库，所以请自行测量。
这个区分的逻辑很硬：第三层（轮数）的收益只在模型有机会走错路的地方才存在。
改一个函数、补一处测试、按模板重构——这类任务的轮数几乎由任务本身决定，两代模型跑出来都是那么多轮。你拿到的就是定价那 −31%，一分不多。而且说实话，这类任务本来就该往更便宜的模型上路由，讨论 Opus 之间的差价意义不大。
跨模块排障、架构迁移、无人值守的长跑就完全不同了。这类任务的成本方差主要来自「模型在错误方向上烧掉多少轮」。Zeta Labs 那个「最难任务完成量翻倍」的数据点尤其值得注意——它说的不是「同样的事更便宜」，是有些事从「跑到预算耗尽也做不完」变成了「做完了」。这种变化没法用百分比表达。
所以官方那句「最适合长时运行、高上下文会话」不是营销话术，它是在准确地划定适用边界。
七、我的几点判断
第一，这篇文章的真正主题是上下文工程的经济学，不是模型发布。 它把降价、框架修复、模型行为三件事写在一起，隐含的论点是：Agent 的成本不是一个定价问题，是一个系统问题。定价层能给 −31%，框架层再给十几个点，行为层给的收益则取决于你的任务长什么样。三层里只有第一层是官方单方面送你的，后两层需要你配合。
第二，「缓存读只剩 17%」这个结构变化，会重新排列优化优先级。 当缓存价格被压到输入价的 5%，缓存优化的边际收益就在下降；账单的重心已经移到「未命中的输入」和「输出 token」上。下一阶段的上下文工程重点，我认为会从「怎么让上下文进缓存」转向「怎么让不必要的上下文根本不进来」——原文那句「必须确保所提供的上下文都是必要的」放在第一条，顺序不是随便排的。
第三，价格结构正在教育使用方式。 缓存相对折扣翻倍、effort 切换不再毁缓存、subagent 继承父级缓存、1 小时 TTL——这四件事凑在一起，描绘的是一种被鼓励的工作方式：一条长会话、一个固定模型、上下文尽量少动、并行分叉复用同一份前缀。反过来，那些高频切模型、反复粘贴大段代码、频繁打断重启的用法，会在账单上被持续惩罚。
第四，也是最该照做的一条：自己测。 从 $3.50 到 $2.40 到 $2.00，这条链路我在上面一步步算了出来，但每一步都依赖那个示例会话的结构假设。你的仓库有多大、上下文多厚、输出多长、缓存命中多少，都会让结果偏移。原文引的那句「No single number holds for every codebase」值得当成结论本身——它比任何一个百分比都更可靠。
原文最后那句话，大概是这半年行业变化最简洁的概括：
组织已经从要求开发者「不计代价地扩张」，转向要求开发者「高效地扩张」。
会话变长了，Agent 变能干了，账单也变厚了。下一个门槛不是「AI 能不能做完这件事」，而是「做完这件事花了多少钱，以及这笔钱花得值不值」。
延伸阅读
- 原文：Coding sessions are longer and use more context. Claude Opus 5.5 is built with that in mind.（2026-09-24，Michael Segner）
- 姐妹篇成本测算：What a task costs on Opus 5.5（2026-09-22，Addy Osmani）
- 本站解读：一次任务到底花多少钱：Opus 5.5 成本模型深度解读
- 官方文档：1 小时缓存 TTL 与 prompt caching 配置（code.claude.com/docs/en/prompt-caching）
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
