Claude Sonnet 5.5的effort旋钮不是油门：档位越高不等于结果越好

Anthropic在9月28日发布Claude Sonnet 5.5。价格与Sonnet 5完全相同（10），Terminal-Bench 4.0拿到70.6%，反超发布仅6天的旗舰Opus 5.5。真正值得看的不是分数，是那个五档effort旋钮。但旋钮不是油门：Anthropic自己的数据里，最高档Max在FrontierCode上比次高档Xhigh低5.9分。本文拆解这个反例、四档各档的真实行为副作用、官方成本叙事与第三方实测的落差，附完整迁移checklist和可跑的effort sweep脚本。

关键词：Claude Sonnet 5.5、effort参数、agentic coding、Terminal-Bench、FrontierCode、max_tokens、prompt cache、迁移

一、发布事实

以下数据全部来自Anthropic官方发布表，未经第三方复现。

¹ Opus 5.5的66.4%是在最高effort档测的　² Anthropic自行跑分

Terminal-Bench 4.0测的是”模型能不能在命令行里完成复杂的多步专业任务”，这个榜单的形态跟Claude Code的实际用法高度重合，所以这一列的权重应该给得比其他列高。Sonnet 5.5在这一项反超旗舰，差距4.2分。

几个值得记的：Chartography（视觉图表识别）从15.6%跳到61.6%，是相对提升最大的一项；GDPval-AA 1844对1846，差2分。附带一提，Sonnet 5.5是第一支只靠截图就把宝可梦红版通关的Sonnet模型。

Anthropic自己在发布稿里加了一句限定：跑分只捕捉模型能力的一个侧面，在他们自己和外部测试者的实测中，Opus 5.5在需要持续判断力的复杂开放式工作上仍然明显更强。这句话待会儿会用到。

1.1 规格

最短可缓存prompt长度从1024降到512。缓存读取价是输入价的十分之一，这个门槛降低意味着更短的系统提示和工具定义也能吃到缓存折扣。对工具定义多的Agent场景是直接的账单改进。

Claude Code从v2.1.284起，sonnet别名指向Sonnet 5.5，默认medium档，1M上下文原生启用。

1.2 价格

与Sonnet 5逐项相同。Batch API输入输出五折，美国境内专属推理（inference_geo: "us"）是标准价的1.1倍。

也就是说换模型ID不改变单价。Anthropic省钱的说法是：Sonnet 5.5完成同一件工作”typically needs far fewer tokens”，因此单任务成本最多降低30%。

1.3 官方的成本叙事和第三方实测，方向是反的

官方口径：单任务最多省30%。而且分档位给出了具体倍数：

Artificial Analysis的独立实测给出了完全不同的图景：

• 方向一致，绝对值不同。它自己跑的Terminal-Bench：Sonnet 5.5得63.6%，Opus 5.5得59.6%，GPT-6 Astra得59.1%。Sonnet 5.5确实第一，但没官方说的那么夸张。
• 在Max档，Sonnet 5.5每个测试任务写了约193,000个token，是Artificial Analysis测过的所有模型里最多的，比Opus 5.5多约60%。单任务成本$7.60，比Sonnet 5贵约50%。

$7.60比Sonnet 5贵50%，这跟”最多省30%”的方向正好相反。

Datacamp自己做的上手测试结论更保守：Sonnet 5.5和Opus 5完成同一类任务，成本基本持平。

三家数据放一起，能得出的结论是：省下来的钱来自你把档位调低了，不来自模型本身变便宜了。 Anthropic的30%是”低档位打旧档位”的口径，Artificial Analysis的-50%是”高档位打旧版”的口径。两个数都不算撒谎，但只有第二个对按默认档迁移的团队有参考价值。

这也解释了为什么Anthropic自己的推荐是”从high开始”——high是Claude API的默认值，不是成本最优档。Artificial Analysis认为high是性价比最优档，两家在这一点上倒是碰巧一致。

二、effort旋钮到底是什么

2.1 一条被砍掉的旧路

Anthropic对手写思考预算的处理是三级跳：

Sonnet 5.5的迁移文档写得很直接：budget_tokens在Sonnet 5.5上返回400错误，删掉它，然后设一个effort档位。文档还补了一句：预算和档位之间没有固定映射关系，所以要”run your evaluations at two or three levels”。

这条路的消失不是偷懒。budget_tokens要求调用方自己猜”这道题该想多少token”，猜错的代价很直接：给少了答案被截断，给多了白烧钱。Adaptive thinking把”该想多少”的判断交还给模型，effort参数再把”这个判断的松紧度”交还给调用方。控制权换了两次手。

2.2 五档和默认值

默认值有个容易踩的差异：Claude API默认high，Claude Code和Claude应用默认medium。 不同入口拿到的默认行为不一样，所以”我什么都没改”在不同地方是两种配置。

2.3 档位被重新校准过

档位是重新校准的，同一个档位在Sonnet 5.5上产生的思考量跟在Sonnet 5上不一样，你原来的设置不会继承过来。

官方给了一条粗略的跨模型映射供参考：

• Sonnet 5.5的medium ≈ Sonnet 5的高档
• Sonnet 5.5的high ≈ Sonnet 5的最高档

做benchmark时，按观察到的思考长度来匹配，而不是按档位名匹配。

档位名不是稳定契约，思考长度才是。 你在Sonnet 5上用的high，迁到Sonnet 5.5之后实际思考量可能变成了别的档位。任何从Sonnet 5迁过来的团队都必须重跑一次effort sweep，官方在迁移checklist里也把”re-run your effort sweep”和”re-baseline cost”列为必做项。

三、这个旋钮不是油门

3.1 官方数据里藏着一个反例

把第一章那张表竖着看FrontierCode 1.1这一行：

最高档比次高档低5.9分。

Anthropic给了原因：Max档下模型更频繁地触发code-review功能，把工作拆给多个子agent。在一些情况下这导致了超时，或者改动了任务范围之外的东西——而FrontierCode恰好惩罚这两件事。

这个反例的分量在于：它不是第三方的挑刺，是厂商自己在官方表格里放进去的数字，而且用的是自己旗舰分数最高的那个基准。“参数化推理”这个抽象概念，第一次被官方数据打出了一个具体破绽：档位和结果之间不是单调关系。

原因也不难理解。effort调高改变的不只是”想多久”，还有”干什么”——高 effort下模型倾向于在完成主任务后自己开启额外的review和验证轮次，有时候派子agent。FrontierCode的评判标准是”这个agent的代码改动会不会被合并”，越界改动和超时都是直接扣分项。它在惩罚的不是能力不足，是行为发散。

3.2 各档位的行为副作用

这一节的内容全部来自Anthropic官方的prompting文档，不是我在跑分表里读出来的。官方在这块写得比跑分表诚实得多。

有两行的工程影响比表格本身更大。

第一行low的”假阳性完成”，是这份文档里工程价值最高的一条。原文的描述是：在agentic编码任务上，Sonnet 5.5通常会在报告改动完成前检查自己的工作，但low档下它有时会在没有跑任何能验证改动的检查的情况下，就报告改动完成。官方给的例子很具体：项目依赖没装，它就跳过了测试。

测试没跑、绿了但其实是跳过的、构建根本没启动。区别在于以前你得从CI日志里分辨这个，现在模型会主动告诉你”完成了”，而它自己知道没验证。Anthropic为这个专门给了一段system prompt补丁，放在后面第3.4节。

最后一行medium以上”包括一句问候”这个细节，说明了一件容易被忽略的事：effort影响的是首token延迟，不只是总成本。 官方明确说，如果你在用medium跑Chat这类延迟敏感的场景，更高档位意味着回复开始前要等更久。对交互式产品来说这个成本不是钱，是体感。

3.3 想让它少想，说”少想”是没用的

想去掉更多思考，就降effort档位。在system prompt里让模型少想，不会可靠地减少思考。

这条值得单列，因为它戳中了一个很常见的误区——很多人在调成本的时候会先去改prompt，”你能不能少用点token””请直接给结论”。这些在旧模型上有一定效果，在adaptive thinking模式下不可靠。官方的态度很明确：这是一个参数，不是一个措辞。

3.4 两个system prompt补丁

Anthropic为三个场景各给了一段可以直接抄的文本。

补丁一：要求真实验证检查（low档必备）

When you change code that can be run, built, or type-checked, run a real
check that exercises the change before reporting it done: the project's
tests, type-checker, or build, or the changed command itself. A
syntax-only check, or a check command that failed to start, does not
count; if all that is missing is the project's declared dependencies,
install them with its own package manager and lockfile (e.g. npm install,
pip install -r requirements.txt), never via sudo or the system package
manager, unless told not to. Only if no real check can run here, say
which one you did not run and why instead of reporting the change as done.

官方说加上这段之后，跳过检查或做表面检查的情况会变得很少，对任务质量没有可测量的影响，单任务成本只略升。

补丁二：干完就停（xhigh/max档必备）

Keep working until everything the user asked for is done, and only stop
to ask when you can't go on without the user or before a risky step.

When the work the user asked for is done and checked, stop and report.
Don't add features, tests, files, docs or refactors that weren't asked
for. If you think one would help, mention it at the end instead of
doing it.

还有一个专门给xhigh/max的变体，抑制它自己开启额外review轮次和reviewer子agent：

When the work the user asked for is done and its checks pass, stop and
report. Don't start extra rounds of review or hardening on your own,
and don't launch reviewer sub-agents unless the user asked for a review.
If you think a deeper review is worth doing, say so at the end.

值得留意的是，官方在讲第一段时用了一个词：Carrying work through。在low/medium档上，模型在完成前停下来问你是正常行为。 如果你的工作流是靠模型一路跑到底，加了这段prompt它确实会一路做到底——但代价是那些档位的session会跑得更久、花得更多。官方说得很清楚，这段prompt不能替代你自己对高风险和不可逆操作设的规则。

这三段prompt在中文工作流里怎么落地，可以参考AGENTS.md的写法规范——同样的道理，写成仓库里的版本化文件比每次在对话里重复一遍更可靠。

(未完待续)