Addy Osmani 在 2026 年 9 月 22 日发了一篇 23 分钟长读的 What a task costs on Opus 5.5。标题看起来只是一个价格问题，但它真正拆开的是一层更基础的东西：
你买的不是 token，是一个做完的任务。
这句话的工程含义是：两个模型可以有一模一样的每 token 单价，跑同一个任务却算出完全不同的账单。 因为决定账单的除了单价，还有"要来回多少轮"。反过来，任何"省 token"的设置都可能是假省钱——如果它让你多跑一轮，省下的就还回去了，甚至倒贴。
原文回答三件事：典型任务多少钱、哪些设置会改变它、怎么量自己的会话。下面我把它重组成一条决策链——先看成本由什么构成，再看每个杠杆的实测数字，最后落到"什么时候升档、什么时候换模型、什么时候压缩"。
一、一次任务的成本结构：四个杠杆
Claude Code 里的一个任务是一个循环：读文件 → 调工具 → 读结果 → 再决定下一步。每一次循环的往返就是一次请求，也就是一轮（turn）。
账单由四样东西决定：
- 轮数——每一轮都会把"到目前为止的全部对话"重新发一遍。它决定了你到底处理了多少 token。
- 缓存读取（cache read）——被重发的文本里绝大部分会命中 prompt cache，按输入价的一个零头计费。
- 输出 token——最贵的一类，单价是输入的 5 倍，而且 thinking 也按输出计费。
- 模型——它决定上面每一项的单价。
先把一句话记住：前三个杠杆决定"处理多少 token"，第四个决定"每个 token 多少钱"。 很多人只在第四个杠杆上做文章——换便宜模型——但真正放大账单的是第一个。
二、杠杆一：轮数，把 120K 放大成 2.8M
原文给了一个非常直观的算术。假设一个任务的上下文从 20K 涨到 120K，平均每轮发送约 70K token：
- 40 轮：累计输入约 2.8M token。按 90% 缓存命中率算，输入部分约 $1.62。
- 25 轮：累计输入约 1.75M token，约 $1.02。
注意那个刺眼的地方：对话本身从没超过 120K，但账单上处理了 2.8M。 多出来的部分全部是"重发"。对话大小是水位，输入总量是过水量——水位不高，过水量照样可以很大。
轮数还是唯一一个同时被"成本"和"质量"拉扯的杠杆。轮数多往往意味着重试多、探索多、返工多。所以减少轮数的正确姿势不是"逼模型少说话"，而是把任务问清楚、给模型自检手段、别让它在错误的文件上打转。这些做法同时降成本、提质量——这是罕见的好买卖。
一个容易忽略的推论：如果一次会话中途重启缓存，轮数的代价会被重新计一遍。 因为每一轮重发的内容，原本大多数是按缓存价计费的；缓存一失效，同样的重发就按新输入价计费了。后面第三节会展开这件事。
三、杠杆二与三：最便宜的部分和最贵的部分
缓存读取是整条链上最便宜的东西。 Opus 5.5 的缓存读价格是每百万 token $0.20，等于输入价的 5%（输入是 $4/百万）。同一段 2.8M 的输入：
- 0% 缓存命中：$11.20
- 90% 命中：$1.62
- 96% 命中：约 $0.99
同一个任务、同样的 token 数，缓存命中率决定的是一个数量级的差别。这也是为什么原文反复强调"保持会话在动"——长时间暂停不只是浪费时间，它推翻的是整个折扣结构。
缓存写是贵的。 以 120K 上下文为例：
- 一次 5 分钟缓存的写入约 $0.60，一次读取约 $0.02——一次写入 ≈ 25 次读取。
- 一次 1 小时缓存的写入约 $0.96。
于是有一类非常具体的浪费：一杯六分钟的咖啡。 缓存生命周期在订阅计划下是 1 小时，在 API key / 云厂商通道下是 5 分钟（订阅计划一旦动用 usage credits，也会掉到 5 分钟）。去泡杯咖啡回来，原本 $0.02 的一次读取就变成 $0.60 的一次写入。反过来说，如果你知道要离开十分钟以上，在离开前先 /compact 或干脆 /clear，比"留着热缓存"更划算。
还有几个会隐式触发缓存写入的动作，值得单独列出来：
- 改动 effort 或 thinking 档位
- 连接或断开 MCP server
- 切换模型
- 会话压缩（compact）
这也解释了原文一条容易被误读的建议：改 effort 最好在休息点改。 因为改动本身会清掉已缓存的对话，下一个请求要为整段对话付写入价。
缓存还有一个结构性的坑：它是前缀存储，只从请求的开头匹配。 改动工具定义会让整段缓存失效；改系统提示则只从改动点开始失效。这就是为什么 CLAUDE.md 的官方建议是控制在 200 行以内——它每一轮都在前缀里；而 MCP 的工具定义被延迟加载，初始只加载工具名和 server 说明，正是为了别把它塞进前缀。
最后是输出 token，整条链上唯一没有折扣的部分。一个输出 token 的价格是缓存读的 100 倍。典型任务 60K 输出 = $1.20，等于从缓存里读 6M token 的钱。而且 thinking 包含在内——即使界面上只给你看一段摘要，你也为全部思考过程付了费。
这一条给出了三个很实用的观察判据（后面第九节还会用到）：
- 一个小改动却产生大量输出 → effort 开太高，或者在反复重试。
- 输出占总成本的比例偏高 → 这是"重推理"任务，省 token 的空间在输出侧。
- 缓存占比很低 → 不是任务难，是会话被打断过。
再补一个代数关系，它解释了为什么"降 token"设置如此危险：如果某项设置省了 15% 的 token，却让任务多跑一轮，在多轮任务里你就已经亏了。 原文的说法很直白——一次重试的代价，往往大于所有便宜设置节省的总和。
四、第四个杠杆：模型换了一代，价格降了多少
Opus 5.5 的 API 列表价是 $4 / 百万输入、$20 / 百万输出、$0.20 / 百万缓存读。相对 Opus 5：
- 输入和输出各便宜 20%
- 缓存读取便宜 60%，缓存读相对输入的比率从 1/10 降到 1/20
- 在 Pro / Max / Team 订阅计划上，降价会传导到额度上（含缓存上下文），额度大约多跑 25%；额外的缓存读降幅则被说明为纯 API 侧价格变化
用原图 B 的那组示例会话（2.0M 缓存读 + 200K 新输入 + 60K 输出）算：
| 项目 | Opus 5 | Opus 5.5 |
|---|---|---|
| 缓存读 2.0M | $1.00 | $0.40 |
| 新输入 200K | $1.00 | $0.80 |
| 输出 60K | $1.50 | $1.20 |
| 合计 | $3.50 | $2.40 |
同样的 token，账单少 31%。把它乘上"10 个任务/天 × 22 个工作日"：$770/月 → $528/月，每月少 $242。
但有一个必须同时记住的反向变量：Opus 5.5 总是先思考再回答，这可能让它消耗更多 token。原文对此的态度是克制的——价格降了，但它不承诺你的账单一定降，要按任务来量。这正好是第四节到第九节存在的理由。
还有一个更细的价格事实值得单独提：升级档 Fable 5.1 的定价是 $10 / 百万输入、$50 / 百万输出，是 Opus 5.5 的 2.5 倍；但它的缓存读是 $0.25/百万，只比 Opus 5.5 贵 1.25 倍——因为它按自身输入价的 0.025 倍计费。
这个非对称性直接给出模型选择的一个判据：缓存密集的长跑，两档之间的差距最小；输出密集的任务，差距最大。
五、难度档位：high 值不值那 $0.40
Claude Code 有四档 effort 加一个单会话档：low / medium / high / xhigh / max。原文给的定位很清楚：
- low：机械工作——重命名、把一个已知模式套到一批文件上
- medium：范围明确的日常工作，官方说"从这里开始"
- high：medium 卡住时
- xhigh：难题
- max：留给单次会话
关键是算清 high 的价格：high 大约多花 20K thinking token，在 Opus 5.5 上约 $0.40。 而一次十轮的失败重试（100K 缓存上下文 + 10K 输出）大约也是这个量级。
于是结论非常干净：high 只要帮你省掉一次重试，它就已经回本了；但如果在 medium 就能一次做对的活上开 high，那是纯浪费。
原文给了一个"medium 只修一层"的经典例子：把某个 API 字段改名，medium 档位会把 handler 和它的测试改对、跑通，但客户端还在发旧字段——因为它只看了改动点附近的调用方。high 档位会先读更多调用点再动手，一趟把两层都修掉。
但这个例子真正的教训不是"该开 high"，而是修这个 bug 有更便宜的第三条路：加一个检查。 一个真的会跑到客户端的测试，在 medium 档位下用一轮就能暴露同一个问题。所以原文给出的操作顺序是：
先加检查 → 再升 effort → 最后才换模型。
这个顺序之所以成立，是因为它按"性价比"排序：加检查几乎不花钱且长期复利；升 effort 花 $0.40 买一次上限；换模型直接让每个 token 涨 2.5 倍。
最后一件事：改 effort 会清缓存。所以 /effort high 虽然是下一个请求就生效，但那个请求要为整段对话付写入价。在休息点升档，不要在任务中途升档。
六、模型路由：什么时候升到 Fable 5.1
原文推荐大多数日子里用三档分工：
- 小模型（Haiku / Sonnet）：检索、读日志、回答"这个定义在哪"
- Opus 5.5：日常主力——跨文件功能开发、调试、带后续修改的代码评审
- Fable 5.1：最难的活——无人值守长跑、没有现成模式可参考的问题、大规模多 subagent 改动
这里最重要的是一条升级触发器，它比"看价格"更可执行：
Don’t wait for a third failure. 如果 Opus 5.5 在 high 档位下同一个问题失败了两次，就升到 Fable 5.1——问题解决后立刻换回。
为什么要"立刻换回"？因为 Opus 5.5 延迟更低、交互场景更便宜，而 Fable 5.1 的输入输出价是它的 2.5 倍。升级档不是"更好的日常配置"，是"解卡工具"。
换模型有一个必须付的代价：缓存不属于新模型。 切过去的第一轮，会按写入价重新为整段对话建缓存。所以原文建议：切换前先 /compact，或者干脆带一份简短的手写计划重开一个会话——后者往往更便宜也更清晰。
往下的方向也要小心。 把检索类 subagent 放到 Sonnet / Haiku 是明确划算的，配置方式有两种：在 subagent 定义里写 model: haiku / model: sonnet，或者设 CLAUDE_CODE_SUBAGENT_MODEL 环境变量（subagent 级设置优先于环境变量；没设的 subagent 继承主模型）。
但机械式多文件编辑不要交给小模型——保持 Opus 5.5 在 low 档位反而更好。原因原文说得很直白：一个误读检索结果的小模型，会让主模型去追错文件；只让小模型做"错了很容易被发现"的活。
另外还有一个把分工倒过来的别名 opusplan——Opus 负责规划、Sonnet 负责执行。原文的态度是"先量再决定要不要把它设成默认"，没给推荐。
七、提示词迁移：旧模型的指令会让新模型变贵
这一节是我认为全文最反直觉的部分。
为旧模型写的提示词，会让新模型写得更多、重复工具调用更多。 原文给了一个内部基准：把一个 44 张工单的客户支持场景从 Opus 4.8 迁到 Opus 5.5，在 low 档位下成本降了约 18%；再用 /claude-api prompt-audit 检查 skills、CLAUDE.md 和应用代码里的提示词反模式，又降了约 9%——最终比 Opus 4.8 的起点低 25%。
被删掉的反模式很有代表性：
- 一条强制的六步流程
- 一条"先写草稿"的 scratchpad 规则
- 一条"验证两遍"的规则
- 若干条互相矛盾的指令
这些规则的共同点是：它们都是为"不会自己规划"的模型写的护栏。 新模型会规划，这些护栏就变成了额外输出和额外往返——也就是说，成本直接体现在轮数和输出 token 上。
原文作者自己也留了边界：这只是一个基准，当成一个例子，而不是一个承诺。 这句话应该被认真对待。
八、压缩、清理与会话卫生
把前面的机制合起来，会得到几条很具体的会话卫生规则。
压缩（compact）是笔可以算的账。 在 150K 上下文时压缩一次约 $0.25（读取 + 几千 token 的摘要 + 新的缓存写入）；之后每一轮大约省下 $0.025 的读取成本，也就是约 10 轮之后回本。所以：
- 任务快结束了 → 压缩不划算
- 还有很长一段路要走 → 压缩划算
/clear 是免费的，适合在无关任务之间清场；/compact 是一次真实请求；/autocompact 用来设置自动触发的阈值。
长会话的成本曲线是非线性的。 20K 上下文时，每轮缓存读约 $0.004；150K 上下文时，每轮约 $0.03。30 轮下来，前者约 $0.12，后者约 $0.90。在 Claude 4.6 及之后的模型上，更大的上下文窗口不会改变每 token 价格，成本完全来自"重发"。
有些动作看起来是优化，实际上是反优化，值得单独列一份清单：
- 为了"省 token"缩短提示词，结果模型多跑一轮
- 任务中途改 effort 或换模型（触发缓存写入）
- 长时间暂停后接着用旧会话（触发缓存写入）
- 在长会话里挂着不用的 MCP server
- 把 CLAUDE.md 写成几百行的操作手册（它每一轮都在前缀里）
九、自己量：三个读数与一条基线
原文最实用的一节是度量方法。全部动作只有四步：
- 在会话里跑
/usage（或/cost）。 Session 区会给出 token 数和按列表价估算的美元金额，还有一行 prompt cache 显示缓存占比。订阅计划下，金额是参考值而不是账单。 - 用同一个真实任务跑两遍（不要用玩具任务），中途用
/model切换模型，记下轮数、输出 token 和花费。 - 做三到四个任务再下结论，不要用一个任务的波动下判断。
- 团队层面用 Claude Code Analytics API（按用户的估算成本）和 Usage and Cost API（按模型的支出、缓存与未缓存对比）。
读会话时只看三个数：
- 缓存占比——长会话应该很高；偏低意味着中途暂停、改了 effort/模型，或者会话中挂载了 MCP。
- 输出 vs 输入——小改动却大量输出，说明 effort 太高或正在重试。
- 总输入 vs 会话大小——如果总输入是会话大小的很多倍，说明轮数太多。
还有一条可以拿来对表的基线：Claude Code 官方成本文档给出的企业平均值是每位开发者每个活跃日约 $13，90% 的用户在 $30 以内。
关于这些数字的性质
有必要把证据边界说清楚：原文明确把图 A–D 和计算器里的数字称为"best effort illustrations"，并建议读者以官方文档和自己在 /usage 里看到的数字为准。计算器里那组预设（2.2M 输入/任务、91% 缓存、60K 输出、10 任务/天）也只是"典型会话"的假设，且明确不含批量折扣、不含缓存写入成本。
所以本文所有美元数字都应该这样读：它们解释的是机制和量级，不是你明天的账单。 机制是可迁移的，数字不是。
十、把整篇压缩成一份清单
原文最后那份 “Keep in mind” 清单，我按决策场景重排了一遍：
关于档位
- 范围明确的日常工作用 medium；机械改动用 low
- medium 卡住再升 high；在休息点升，别在中途升
- high 档位同一个问题失败两次 → 换 Fable 5.1，解决后换回
关于模型
- 检索和读日志的 subagent 放 Sonnet / Haiku；改代码留在 Opus 5.5
- 换模型前先
/compact，或带一份简短计划重开
关于会话
- 给模型一个能自检的手段；多文件改动作先从 plan mode 起步
- 让长会话保持流动，别让缓存冷掉
- 无关任务之间用
/clear；休息点用/compact并带上"要保留什么"的说明
关于度量
- 最重要的一条：在一个真实任务上各跑一次两个模型，比较
/usage，相信自己的数字。
如果只留一句：先修任务，再调档位，最后才换模型。 顺序错了，省下来的钱会以重试的形式还回去。
「真诚赞赏，手留余香」
爱折腾的工程师
真诚赞赏，手留余香
使用微信扫描二维码完成支付
