Opus 5.5 上一个任务到底花多少钱

本文是对官方文章「What a Task Costs on Opus 5.5」的中文要点摘要，完整内容以原文为准：https://claude.com/blog/what-a-task-costs-on-opus-5-5

任务成本≠token单价

用 Claude Code 时，真正关心的不是「买了多少 token」，而是「跑完一个任务、一次修 bug、一次迁移要花多少钱」。文章指出，一个任务在 Claude Code 里本质是一个循环：模型读对话历史、调用工具、读结果、再来一轮。决定最终账单的是四个变量，而不是单一的 token 定价。

决定任务成本的四个因素

回合数（Turns）：每一轮对话都要把此前的上下文重新发一遍。文章给出的示例里，一个任务如果跑 40 轮、每轮平均发送约 70K token，成本约 1.62 美元；同样的任务压缩到 25 轮，成本降到约 1.02 美元。回合数越少，重复发送的输入成本越低。

缓存命中（Cache reads）：一轮里重发的内容大多是上一轮模型已经看过的文本，命中缓存的部分只按 fresh input 价格的 5%（Opus 5.5 上）计费。示例任务在 90% 命中率下成本约 1.62 美元，提到 96% 命中率则降到约 0.99 美元。

输出 token：定价是 input 的 5 倍，且包含 thinking token。示例中 6 万输出 token 的成本（约 1.20 美元）与读取 600 万缓存 token 的成本相当，说明输出比看起来更贵。

模型选择：决定了以上三者各自的单价。更便宜的缓存读取价格，对长会话的收益尤其明显。

Opus 5.5 的价格变化

相比 Opus 5,Opus 5.5 的 input 和 output token 均降价 20%;cache reads 降价 60%（从占 input 价格的 10% 降到 5%）。官方给出的价格是：input 4 美元/百万 token,output 20 美元/百万 token,cache reads 0.20 美元/百万 token。

先调 effort，再考虑换模型

遇到任务卡壳，文章建议的顺序是先加大 effort 而不是急着换更贵的模型：日常、边界清晰的任务用 medium;medium 解决不了（比如需要跨多个文件层联动修改）再升到 high。需要注意的是，切换 effort 或 thinking 设置会清空已缓存的对话，相当于放弃之前攒下的缓存折扣，重新按全价写一遍上下文，所以不要频繁来回切换。

按工作类型选模型

文章建议大多数场景配置三档模型：

• 小模型（Sonnet / Haiku）：用于查找、读日志等你会亲自核实结果的场景，不用于直接写代码。
• Opus 5.5：作为日常主力，适合需要你紧盯的工作，例如跨几个文件的功能开发、调试、带后续修改的代码评审。
• Fable 5.1：仅在结果的重要性超过 token 成本时才「升」上去，例如不受监督的长任务、代码库里没有先例可参考的难题、需要协调多个 subagent 的大改动。Fable 5.1 定价为 input 10 美元/百万 token、output 50 美元/百万 token，约为 Opus 5.5 的 2.5 倍。文章给出的经验法则是：如果 Opus 5.5 在 high effort 下对同一个问题连续卡壳两次，就切到 Fable 5.1，问题解决后再切回来。

迁移模型时顺手查一遍 prompt

官方基准测试显示，仅仅把默认模型迁移到 Opus 5.5（并用 low effort）就把成本降低了约 18%；在此基础上再审查 prompt 中的低效写法（反模式），又额外省下约 9 个百分点，累计比迁移前低约 25%。换句话说，换模型省下的钱，靠优化 prompt 还能再挤出一截。

缓存与上下文压缩

缓存写入和读取的成本会随上下文长度增长：在 120K token 上下文时，一次 5 分钟的缓存写入约花 0.60 美元，读取约 0.02 美元；而单纯看每轮的读取成本，20K token 上下文时约 0.004 美元/轮，涨到 150K token 时约 0.03 美元/轮——上下文越长，每一轮维护缓存的边际成本越高。

这也是 /compact 和 /clear 存在的意义：在 150K token 上下文时执行一次压缩大约花费 0.25 美元，但由于后续每轮的上下文更短、读取更便宜，通常在约 10 个回合内就能把这笔压缩成本赚回来。

自己动手测量

文章最后提醒，文中的数字都是示例性质，实际成本因任务而异。建议的做法是拿真实任务分别在不同模型/effort 组合下跑一遍，对照 /usage 的输出，用自己的数据而不是文章里的插图数字来做决策。