Claude 5.5：停止为失败任务买单

真正重要的 Sonnet 与 Opus 配置：effort、缓存、验证，以及每个已完成任务的成本

最便宜的模型，并不是 token 单价最低的那个

而是能真正把活干完、通过检查、并且不会让你为同一段上下文反复买单五次的那个

Sonnet 5.5 和 Opus 5.5 让这种区别变得格外重要。一个按量定价，另一个为更难的活儿定价。两者都有全新的 effort 行为，而且在设计良好的 Agent 循环里配合缓存使用时，成本都可能低得出乎意料

把旧配置直接套到这两个模型上，结果可能是更慢、更贵，或者直接报 400 错误

这才是我会采用的配置方式

1任务 → SONNET 5.5 → 检查 → 必要时用 OPUS 5.5 → 已验证的结果
2             ↘ effort ↗         ↘ 缓存 + 用量账本 ↗

我在 Substack 上发布关于 AI Agents、工作流和生产系统的实用拆解

点击这里订阅 newsletter

决定你技术栈的那个关键数字

大多数模型对比都是从“每百万 token 多少美元”开始的

但你的 Agent 交付的不是 token，而是完成的任务

https://x.com/claudeai/status/2102435511222890900

再说一遍：那是他们的测试。你的架构需要你自己的数据

这意味着验证不能是看完一个漂亮回答后随手点个赞。写代码时，就用那个会拦住合并的测试；做信息提取时，就把必填字段和标注集做比对；做研究时，就记录引用的来源是否真的支持每一条结论。要把那些始终无法通过的任务成本也算进去，别只盯着 demo 里的漂亮例子

还要单独观察长尾难题。如果最便宜的设置能处理 90% 的请求，却在剩下 10% 上烧掉一半预算，那么平均成本就会掩盖住真正需要换模型的那部分工作流

5.5 价格表到底写了什么

截至 2026 年 10 月 3 日，按 Claude API 标准费率，每百万 token 的价格如下：

1SONNET 5.5
2新输入  $2       输出  $10
3缓存读取   $0.20    缓存写入  $2.50 / 5分钟, $4 / 1小时
4
5OPUS 5.5
6新输入  $4       输出  $20
7缓存读取   $0.20    缓存写入  $5 / 5分钟, $8 / 1小时

两个模型都支持 1M token 上下文窗口，最大输出 128K token。这是上限，不是让你非得把它们塞满的理由。

模型规格与定价

比较反常的是缓存读取这一行

Opus 的新输入和输出价格是 Sonnet 的两倍，但缓存前缀在两个模型上都是一样的每百万 $0.20。这并不意味着跑一次 Opus 同样便宜：它在新输入、输出和缓存写入上依然更贵。但它说明，在读多写少的会话中，两个模型的价格差距会缩小

还有第二个大家容易忽略的区别。Anthropic 说的“比 Opus 5 便宜 40%”是对典型\运行成本\的估算。Opus 5.5 的新 token 价格降了 20%，缓存读取价格降了 60%。这些数字有关联，但不能混为一谈

Effort 是路由决策，不是质量滑块

Sonnet 5.5 支持 low、medium、high、xhigh 和 max。在 API 上默认是 high，而在 Claude 应用中，Anthropic 表示默认是 medium。Opus 5.5 在 API 上默认是 medium。这些档位并不完全对应上一代模型里同样的词义。

我的初始参考映射：

• Sonnet low 适合范围窄、对延迟敏感、且验证成本低的请求
• Sonnet medium 适合需求明确的编码任务和常规多步骤工作
• Sonnet high 当 medium 跑不过真实验证，或任务已被证明复杂度较高时使用
• Opus medium 适合模糊、跨文件、长周期的任务——也就是 Sonnet 开始原地打转的时候
• Xhigh/max 只有当你的评测证明额外时间和 token 确实值得时才用

这只是起点假设，不是通用法则。在 Anthropic 公布的 Sonnet 5.5 FrontierCode 结果中，xhigh 的得分高于 max。投入更多 effort 并不等于结果更好

Anthropic 的脚注解释了这个反直觉的结果：在 max 下，模型更容易启动额外的代码审查工作。在两个被检查的案例中，这导致了超时或超出任务范围的修改。

失败模式并不是“模型想得不够多”，而是把力气花在了错的地方。如果你的 Agent 已经能通过验证，额外的审查轮次只会变成成本和新错误的来源

https://x.com/edwinarbus/status/2104675431853248816

另外，别以为把 max_tokens 调低就叫优化。这个限制同时包含思考和可见输出。如果在任务中途把它截断，你买到的可能是一个残缺答案加第二次重跑，而不是省钱

https://x.com/claudeai/status/2104633115620823187

这是个很有吸引力的发布宣传。但生产环境的配置还是得跑赢你自己的基线

先跑一轮小规模扫描，别急着造模型路由器

挑 10-30 个你真正关心的任务。要包含简单任务、模糊任务，以及日志里那些烦人的失败案例。给每个任务配一个验证器：测试用例、结构化比对、已知答案，或者在运行前就定好的人工评分标准

下面是最小可用的 API 探测脚本。它会记录你需要的 usage 字段。在每个模型和 effort 级别上针对同一个任务跑一遍，然后接上你自己的通过/失败判断。这不是完整的 Agent 基准测试

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # 换成 claude-opus-5-5 再跑一次
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # 换成 high 再跑一次
8    messages=[{"role": "user", "content": "把这里替换成真实任务。"}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("fresh", usage.input_tokens, "output", usage.output_tokens)
15print("cache read", usage.cache_read_input_tokens)
16print("cache write", usage.cache_creation_input_tokens)

这段代码假设你安装了官方 Anthropic Python 包，并配置了 ANTHROPIC_API_KEY 环境变量。这是一次没有启用缓存的独立调用，所以缓存读写预期都是零。下一节会讲什么情况会改变这一点

对于真实的 Agent，要把同一个任务 ID 下所有 API 调用的 usage 加起来，包括重试和工具调用。只有验证器确认任务完成，才算一次通过

在确定默认配置前，先比较每次通过的总花费

保持测试诚实：

• 在比较配置前，先固定任务集和验证器
• 对所有候选方案使用相同的工具、权限、上下文和输出要求
• 记录通过率、总支出、单次通过成本、延迟，以及耗时最长或最贵的失败案例
• 把 stop_reason: "max_tokens" 算作未完成的尝试，而不是廉价的成功

上面那段简短的代码示例用了 8K 的输出上限，只适合单轮探测。别把这个上限照搬到长流程编码 Agent 上

Anthropic 建议给 agentic 工作留出大得多的余量，因为隐藏的思考过程也占用同一个额度

根据任务设好上限，然后用 effort、缓存和任务预算来控制开销，而不是逼着模型在半途强行停下

把任务中稳定的部分缓存起来

Agent 会反复发送相同的系统指令、工具定义、仓库地图和历史对话。如果这段前缀是稳定的，prompt caching 对成本的改变远大于微调几句 prompt

举个例子，200K 缓存 token 被读取 50 次，就是 10M 缓存读取 token。按每百万 $0.20 计算，在任意一个 5.5 模型上这笔读取只要 $2

而在 Opus 5.5 上，把这 10M token 当作新输入发送要花 $40。首次写入 200K token 的 5 分钟缓存还要再加 $1

这只是前缀费用的示意：新输入、输出、其他写入、TTL 过期和实际缓存未命中都会叠加进账单

实用规则：

• 在 Claude API 上，通过顶层 cache_control={"type": "ephemeral"} 或显式缓存断点来开启 prompt caching。上面的探测脚本两样都没用，所以它的缓存计数器通常一直是零
• 把稳定的指令和工具放在会变动的用户请求之前
• 让各轮对话共享的前缀保持一致；去核实实际的 cache_read_input_tokens
• 切换模型要当成新的会话预算，而不是免费续杯。缓存是按模型隔离的：Opus 请求读不到 Sonnet 刚缓存的前缀
• 避免每一轮都改顶层 effort；那会改变渲染后的 prompt，导致缓存前缀失效

在支持的模型上，逐条消息修改 effort 可以保留之前的缓存，但这需要 Anthropic 的 beta header，而且和修改顶层 output_config 不是一回事

Sonnet 5.5 还有一个 between_tools 注意事项：在该模式下，effort 不能在对话中途改变

Prompt caching 文档

别看到响应快就以为是缓存命中。去看 usage 对象，它把新输入、缓存创建和缓存读取分得很清楚

两个 5.5 模型的可缓存前缀至少需要 512 个 token。太短的系统提示词省不出上面例子里的钱。默认缓存有效期是 5 分钟，很适合快速的工具调用循环

1 小时的写入更贵，只有当真实会话经常停顿到错过 5 分钟窗口时才有意义。在为更长 TTL 付费前，先测一下这些间隔

凭证据升级，别凭焦虑

大多数团队把路由器搭反了：先把任务标成“难”，丢给贵的模型，却从不验证便宜的路径是不是也能过

把验证器当作路由信号

11  Sonnet 5.5 · 选定的 effort  → 执行任务
22  验证器                    → 通过则接受
33  Opus 5.5 · medium           → 只在有失败证据时重试
44  验证器                    → 接受，或带着证据转交人工

验证可以是测试套件、schema 校验、已知答案或人工审核。它应该说明哪里失败了

“感觉回答不太行”是很差的重试信号，“改动后的端点没通过两个集成测试”才有用

别盲目重复一模一样的 prompt。给下一次尝试提供失败的检查结果、相关产物，以及一条具体的修正指令。给升级链路设个上限，别让 Agent 为了修一个需要人工决策的任务把预算烧光

你可以在离线扫描里测试 Sonnet high 重试。只有当它能降低单个已验证任务的成本时，才放进线上链路。没必要让每次失败都在上 Opus 前先付两次 Sonnet 的钱

切换模型本身可能会破坏缓存前缀。在比较“补救路径”和“Opus 优先路径”时要把这点算进去

交叉点很容易被忽略。假设一次 Sonnet 尝试花 $0.06，能通过你 80% 的任务

如果每个失败任务接着花 $0.20 在 Opus 上收尾，那么示意性的平均成本是每个完成任务 $0.10：$0.06 加上五分之一概率的 $0.20 补救。这比每个任务都花 $0.20 用 Opus 划算。但如果 Sonnet 花 $0.14 却只能过一半，同样的链路成本就是 $0.24，还没算切换模型的代价。在这种负载下，Opus 优先反而更便宜更快

这些数字只是举例，不是实测的 Claude 结果。它们的作用是让路由规则可被证伪。只有当省下的 Opus 调用足以覆盖失败的 Sonnet 尝试、缓存未命中和额外延迟时，这套升级链路才站得住脚

还有一条中间路线：Anthropic 的 beta advisor tool。Sonnet 可以继续执行任务，只在某个难点上向 Opus 求助，而不是把整件事都交给 Opus

这不一定更便宜。要记录 Sonnet 实际咨询 advisor 的频率、这些调用的成本，以及它们是否提高了最终通过率。如果执行者很少提问，advisor 就只是个摆设

在这些 5.5 模型上，建议内容本身是加密返回给客户端的，所以请评估最终产出，别假装你能审计私密的建议文本

在模型选择起作用之前，先堵住这四个漏钱的洞

不是每个成本问题都需要一个新路由器

先查这些：

• 不断膨胀的输出 在两个 5.5 模型上，输出 token 的价格是新输入 token 的五倍。在对话中，冗长的回答还会在后续轮次作为上下文再次计费。要产物和简短的完成说明，不要每一步的解说词。隐藏思考也按输出计费，所以光靠精简最终回答解决不了 effort 的问题。但也别把验证结果所需的证据一并砍掉
• 图片分辨率超过任务所需 Sonnet 5.5 能处理比旧版 Sonnet 更高分辨率的图片，这会推高图片 token 数。如果 Agent 只需要一个按钮标签或一段文字，先裁剪或缩放。如果它需要密集的图表或极小的 UI 细节，就保留分辨率并测算成本，别盲目压缩
• 没人用的上下文 工具定义、过期日志、旧搜索结果和一份臃肿的 CLAUDE.md 可能会跟着每个请求走。把长期规则放进简短稳定的前缀里；把临时证据留在需要它的任务附近。精简上下文不等于删掉模型正确完成任务仍需的事实
• 为没人等的任务付交互式价格 Message Batches API 在两个模型上都能给输入输出打五折。它适合离线评测、文档回填和其他异步任务。但它替代不了需要立刻拿到下一步的实时工具调用循环

这四点的规律都一样：先砍掉任务不需要的部分，再去买更强的智能，或者把 effort 降到质量崩盘为止

让省钱变成 400 报错的迁移陷阱

旧的请求体不适合直接拿来跑 5.5 系列

尤其是：

• Opus 5.5 的思考功能始终开启 删掉 thinking: {"type": "disabled"} 和旧的固定 budget_tokens 设置；用 output_config.effort 控制深度
• 强制指定工具在两个 5.5 模型上都会失败

tool_choice 取值 any 和 tool 会返回 400。用 auto，明确什么时候该用工具，并在你自己的代码里校验工具返回结果

• Thinking blocks 不是 text blocks 按 type 读取 content，别用 content [0]。在工具调用循环中，把 thinking blocks 原样随 assistant 回合返回
• 你的 UI 可能看起来像卡住了 在 Opus 5.5 上，工具调用之间的进度可能出现在 thinking blocks 里，而默认显示设置下它们是空的。如果你以前会把这些提示展示给用户，请请求受支持的 thinking 显示模式并按类型渲染 blocks。否则 Agent 其实在干活，界面却像死机了一样
• 旧版 computer-use 工具可能会失败 迁移浏览器/电脑 Agent 前，先确认当前工具版本
• 更小的 max_tokens 上限可能会中断工作

即使文本被隐藏，思考过程也会计入额度

这些都是 API 行为变更，不是写 prompt 的小技巧

Opus 迁移指南 和 Sonnet 迁移指南

把约定写进 Claude Code，别只记在脑子里

API 是你能精确测量每个 usage 字段的地方。而很多人第一次感受到模型变化是在 Claude Code 里。原则是一样的：给 Agent 一个有边界的完成定义，然后让它拿出证据

在 Claude Code 中，/model 选择模型，/effort 选择支持的 effort 级别。比较不同会话前，先确认当前设置。Sonnet 的 API 默认值并不能准确描述你的 Claude 应用或 Claude Code 会话正在用什么

这是一个完整、可复用的 CLAUDE.md 起始模板。把命令改成适配你项目的样子

1# 工作约定
2
3只做要求的改动。保留无关内容。
4编辑后运行相关测试。报告任何你无法运行的检查。
5要求的工作通过后即停止。不要添加额外功能或审查循环。
6结尾格式：Changed / Verified / Remaining risk。
7在执行破坏性操作、发布或修改本仓库外的内容前先询问。

这段内容不会神奇地让每次运行都变便宜。它让成功和失败变得可见。有了它，你就能在同一批任务上比较 Sonnet 优先和 Opus 优先的工作流

任务消息依然必须具体。“修一下支付代码”和一个 Agent 真能做完的任务之间差别很大

1Change: 将支付端点迁移到新客户端
2Done: 移除旧客户端，端点测试通过，diff 仅限此路径
3Stop: 删除数据或修改仓库外内容前先询问
4Report: 改动的文件、实际运行的检查、剩余风险

这份小小的约定给了验证器具体可查的东西，也给了模型停下来的理由。一句开放式的“一直审查到完美为止”，能把一次已经通过的改动拖进又一轮付费循环

对于长周期项目，把清单放在压缩上下文后依然存在的文件里。对于子 Agent，让主 Agent 在采纳报告前先检查它们的证据。如果你只是想听听思路，就告诉 Claude 别动手实现。这些是工作流边界，不是“变聪明点”的 prompt

我会最先上线的配置

• 挑 10-30 个真实任务，为每个定义验证方式
• 扫描 Sonnet 5.5 的 medium 和 high，再扫 Opus 5.5 的 medium
• 记录每个任务的新输入、输出、缓存写入、缓存读取、延迟、重试次数和通过/失败情况
• 让稳定前缀可被缓存，并在 usage 中确认命中
• 只把失败的任务连同证据一起向上路由
• 工作负载变化时重新评估链路。保存下来的基准测试结果不是永久真理

如果那 10% 的难题总是从 Sonnet 失败直接跳到 Opus 成功，可以考虑一开始就把这类特征明显的任务路由给 Opus。如果 Sonnet high 能用更低成本搞定同样的情况，就让它们留在那儿。路由器是基于测量的策略，不是关于哪个模型更聪明的永久偏见

5.5 的升级不只是“便宜活用 Sonnet，难活用 Opus”

它是一个机会，让你别再给模型定价，转而给完成的任务定价

如果你看到了这里

-> 订阅我的 Substack

-> 加入我的 Telegram

-> 收藏这篇文章

-> 关注 @0xwhrrari