AI 博客

档位顶端什么也没买到

Anthropic 在 9 月 22 日交付了 Claude Opus 5.5,并附上一条与自家天花板相抵触的成本曲线:在 FrontierCode 上,默认的 medium 力度拿到 54.6%、每任务约 0.80 美元,而 max 拿到 54.4%、每任务约 6.19 美元;同一个旋钮在 Terminal-Bench 上却值八个点。它也是第一个默认 medium 而非 high 的 Claude 模型,所以替换模型字符串就是一次行为变更。力度是一项按工作负载而定的测量,而「每完成一个任务的成本」是唯一能在它面前活下来的单位。

作者 智能体 AI 维基 23 分钟读完

9 月 22 日,Anthropic 发布了一条与自家「档位顶端」相抵触的成本曲线:在 FrontierCode 上,Claude Opus 5.5 以默认的 medium 力度拿到 54.6%,每个任务约 0.80 美元;而在 max 力度下拿到 54.4%,每个任务约 6.19 美元——八倍的钱,换来一个小到不足以称为差别的差别。而同一个旋钮在 Terminal-Bench 4.0 上大约值八个点。这就是该带走的结论:力度不是一个「有正确档位」的质量旋钮,它是一项按工作负载而定的测量,而标题里的那个档位,并不是你该部署的那个档位。

一览

Opus 5.5 也是第一个「力度参数默认值不是 high」的 Claude 模型,而这件事比降价更要紧。

模型每百万 token 输入 / 输出价格默认力度上下文 / 最大输出
Claude Opus 5.5(2026 年 9 月 22 日)$4 / $20medium1M / 128K
Claude Opus 5$5 / $25high1M / 128K
Claude Fable 5.1$10 / $50high1M / 128K
Claude Sonnet 5$2 / $10high1M / 128K
FrontierCode score and cost per task across four effort levels Four effort levels on Claude Opus 5.5. Medium scores 54.6 percent at about $0.80 per task, high 54.0 percent at about $1.09, xhigh 51.4 percent at about $2.25 and max 54.4 percent at about $6.19. The score bars are nearly equal while the cost bars grow almost eightfold from medium to max. FrontierCode v1.1 — score against cost, Claude Opus 5.5 Score (% of tasks) Cost per task (USD) $2 $4 $6 medium default 54.6 $0.80 high 54.0 $1.09 xhigh 51.4 $2.25 max 54.4 $6.19 Score bars use a zero-suppressed axis from 40% to 60% so the spread is visible; cost bars start at zero. 8x the default, same score
FrontierCode v1.1,读自 Anthropic 的发布图表:分数在噪声范围内是平的,账单不是。

那条曲线上的四个点,按采购会谈该看到的顺序排列:medium 54.6%,每任务约 0.80 美元;high 54.0%,约 1.09 美元;xhigh 51.4%,约 2.25 美元;max 54.4%,约 6.19 美元。Anthropic 自己对同一批数据的说法是:在默认力度下,该模型以大约五分之一的每任务成本,胜过 GPT-6 Astra 的最好成绩——这是一个关于默认值的论断,不是关于天花板的论断。

9 月 22 日真正交付了什么

价格变动是其中最没意思的部分:每百万 token 4 美元与 20 美元,对比 Opus 5 的 5 美元与 25 美元;缓存读取 0.20 美元,另有 8 美元与 40 美元的快速模式。Anthropic 更强的那个论断是:典型工作负载的运行成本比 Opus 5 低约 40%——这是拿标价做算术得不出来的,剩下的差额来自行为:用更少的 token 与更少的轮次把同一件事做完。

有三条 API 事实比价格更起作用:

  • 默认值是 medium。其他每一个支持力度的 Claude 模型默认都是 high。文档把后果说得很直白:一个省略 effort 的请求,会比它在 Opus 5 上低一档运行。因此替换一个模型字符串是一次行为变更,而不是一次版本号提升——而且它恰是那种「表现为质量回退、却没有任何 diff 可以怪」的变更。
  • 力度不是思考预算。它作用于每一个输出 token——正文、思考和工具调用。更低的力度产出更少、更简短的工具调用;更高的力度产出更多,并在其周围带上计划与总结。在智能体循环里,这是智能体所做之事的改变,不只是它花销的改变;而文档明说它是「一个行为信号,不是严格的 token 预算」。
  • 思考无法关闭。自适应思考始终开启;设置 thinking: {"type": "disabled"} 的请求在任何力度档位都会返回 400。没有可退回的非推理模式,所以在模型这一层,力度是唯一的成本控制。

如果你正在迁移,请在入口处显式设置 effort,而不是继承一个你并未选择的默认值。把它设成模型自己的默认值,在行为上是空操作,在可读性上却是一次大改善:请求里的那个值从此就是你仓库里的那个值——而正是这条性质,让下一次默认值变动变得无害。这件事的一般版本见未被钉住的厂商默认值。

0.2 个点不算差别

对 FrontierCode 那次扫描,诱人的读法是「max 比 medium 差」。并非如此:一次基准运行里的 54.4% 与 54.6%,是同一次测量换了一种四舍五入的样子。而这恰恰就是要点——在这个样本量下分数差异无法分辨,而成本差异是八倍;因此唯一站得住的结论是:档位顶端没买到任何你能察觉的东西,却照样收了钱。

xhigh 掉到 51.4% 这件事,应当用同样的纪律看待。它可能是真的——在结构化工作上「想太多」是有记录的失效模式,而 Anthropic 自己对某个更早的 Opus 的分模型指引就警告过,max 在结构化输出任务上「可能导致过度思考」。它同样可能只是一次运气不好的运行。仅凭一个数字你无从分辨,而这正是评测方差与统计功效的全部论点,也是为什么在有人把置信区间摆在旁边之前,头条分数大半是抖动。

所以请把那条曲线当作一个形状,而不是四个事实。这个形状说的是:在改代码这类工作上,「想得更久」的回报大约在默认档附近就已经变平,而它上面的一切,定价却像并非如此。

而到了下一个基准,同一个旋钮值八个点

Two task families, two shapes of payoff from effort A comparison across three rows for two task families. On code-change work the score-versus-cost curve is flat past the default level, the bottleneck is judgement, and the advice is to stay at the default. On long-running terminal work the curve keeps rising, the bottleneck is information the model does not yet have, and the advice is to step up and measure. The same dial, two payoff shapes Code change and review (FrontierCode) Long-running terminal work Shape of the curve flat past the default still climbing What the bottleneck is judgement on known context information not yet gathered Where to start default, and justify any step up one level up, measured What to report dollars per completed task, with an interval, paired against your current level
同一个模型、同一个参数、相反的建议——所以那次扫描必须在你自己的任务上跑。

Terminal-Bench 4.0 是那个反例,它让本文不至于变成一篇「越便宜越好」的辩护。Anthropic 在那里的头条数字是 66.4%,对比 Fable 5.1 的 55.8% 与 Opus 5 的 52.3%——而那个头条并不是默认力度下的数字。在默认力度下,同一个模型落在 57–58% 附近,每任务约 3 美元;已发布的曲线随着花销继续往上走,而第三方对该图表的读法在「66.4% 位于哪一档」上并不一致。即使确切那一档存疑,方向也毫无疑问:在长时间运行的终端类工作上,更多思考买到好几个点;在改代码与评审上,它买到的是噪声。

这道不对称有一个值得记住的机械解释。力度既提高工具调用的深度、也提高它的数量,而终端任务正是靠工具调用推进的——读状态、跑一条命令、检查结果。在「打补丁并评审」这类任务上,模型需要的上下文已经在 diff 里了,所以额外的探索无处可探,额外的斟酌也无事可决。力度在「瓶颈是模型尚未拥有的信息」处有回报,在「瓶颈是一个它在任何档位都会做出同样判断的判断」处没有。

力度在循环里是乘法,所以它不是一个按调用计的旋钮

Where the effort parameter lands in an agent loop One request-level effort setting affects three multipliers: tokens spent per turn, the number and verbosity of tool calls within a turn, and the number of turns an episode needs. The first two increase cost, the third can reduce it by finishing the task in fewer laps, so the net effect on cost per completed task is not determined by the parameter alone. output_config.effort one value per request 1. Tokens per turn thinking plus prose — cost up cost ↑ 2. Tool calls per turn more calls, more preamble — cost up cost ↑ 3. Turns per episode fewer laps to finish — cost down cost ↓ Net effect is a property of the task family, not of the parameter. Measure dollars per completed task, at the level you will deploy. A per-call view sees only the first two.
一个参数,三个乘数——而第三个乘数可能是砍账单而不是抬账单。

按单次调用去推理力度会得到错误答案,因为这个参数同时落在三处。它改变每轮的 token 数,它改变一轮里包含多少次工具调用,而且——因为一轮推理更充分的回合可以把本来还要再跑一圈才能完成的事做完——它还改变整个任务要花多少轮。前两者把账单推上去。第三者把它推下来,而正是它产出了「降价 20%、却省下 40%」这个说法。

这也是为什么「把力度压低来省钱」这条朴素政策在智能体类工作负载上会反噬:一个每轮省下 30%、却每四次多出一圈白跑的档位,是亏的。这个失败在按请求看的仪表盘上是看不见的,因为每一个单独请求都变便宜了;它只在一个地方可见——那些真正完成了的任务的成本。

每完成一个任务的成本,是唯一活得下来的单位

把两个档位并排放好、各自挂上成功率,这场比较就不再是关于 token 价格的了。设想一个任务族:更便宜的那一档以每次 1.00 美元完成 62% 的尝试,而高一档以每次 1.35 美元完成 85%,并假定一次失败的尝试会在有人来看之前重试一次:

# cost per completed task = attempt cost / success rate (single-shot)
medium : $1.00 / 0.62 = $1.61 per completed task
high   : $1.35 / 0.85 = $1.59 per completed task   # the "expensive" level is cheaper

# now price the failures you actually pay for
review : 15 min of an engineer at $90/h = $22.50 per failed task
medium : 0.38 failures x $22.50 = $8.55 + $1.61 = $10.16
high   : 0.15 failures x $22.50 = $3.38 + $1.59 = $4.97

token 价格的差异是 35%;与决策相关的差异是两倍,而它由一个不出现在任何模型对比页上的数字主导。这正是智能体成本控制围绕构建的那个单位,也是为什么一张以「每百万 token 多少钱」为主键的采购表格,排出的模型顺序与它们实际让你花多少钱关系不大。

在你开始测量的同时,有两处机制要弄对。在请求之间改动顶层的力度值会让提示词缓存失效,所以在同一段对话里搞「动态力度」比看起来更贵;在 Opus 5.5、Opus 5 以及 Fable 5.1 一族上,按消息改动力度(beta 头 mid-conversation-output-config-2026-07-01)能保住已缓存的前缀,而在其他地方,你应当按工作负载挑一个档位并保持不动。另外,在较高档位上请把 max_tokens 设大:它是「思考加回复」合计的硬上限,所以一个宽裕的力度档配上一个紧绷的输出上限,产出的是截断而不是深度。

那次扫描,当作半天的活

Anthropic 自己的文档现在就叫你这么做,而不是把设置从更早的模型搬过来——一家厂商把这句话写进迁移指南并不寻常,值得照字面执行。

  • 把其他一切钉住。一个模型快照、一份提示词、一套工具、一个 harness 版本。一次里面夹着提示词改动的力度扫描,什么也没测。
  • 在你自己的 30–50 个任务上扫全部五个档位,不是 5 个任务。任务间方差压过运行间方差,所以在同样预算下,加任务胜过在同一批任务上多跑几遍。请记录每次尝试的 token、轮次、墙钟时间与结果。
  • 报告「每完成一个任务多少钱」并带上区间,然后停在「区间与最好那档重叠的最便宜档位」。这条规则正是阻止棘轮的东西:没有它,每次扫描最后都会有人拿 0.2 个点的领先来主张 max。
  • 在模型变动时重跑,而不是按日历重跑。在 Opus 5 上胜出的那一档,并不构成对 Opus 5.5 的推荐——不同的默认值、不同的校准、不同的工具调用行为。

如果这周只上一项改动,就上这一项:在每个请求里显式设置 effort,把档位与 token、轮次、结果一并记录,并开始在你最重要的三个工作负载上报告「每完成一个任务的成本」。本文其余部分都是「这个数字为什么会让你意外」的理由——一个回报在一个任务族上平、在下一个任务族上陡的旋钮,横跨八倍的价格差,而它的默认值刚刚在所有人脚下挪了一格。

常见问题

max 力度有值得用的时候吗?

有:在已发布曲线仍在上升的任务族上,以及在「一名工程师一小时的价值远超 token 账单」的一次性工作上。FrontierCode 那次扫描反对的是把 max 当成默认姿态——为一个单次运行分辨不出的差别,付默认档八倍的钱。Anthropic 自己的升级阶梯是先力度、再换模型:它的指引是当 Opus 5.5 在更高力度上的评测仍然不够时,转向 Fable 5.1。

更低的默认值是否意味着 Opus 5.5 开箱即用比 Opus 5 弱?

它意味着开箱时低一档运行。在已发布的对比里,默认力度的配置在编程类基准上仍然胜过 max 力度的 Opus 5,而每任务成本只是零头——但一次「假定同样的请求会有同样行为」的迁移,假定的是文档明确否认的事。

为什么不干脆给思考 token 设上限?

那个控制没有了。这一代的自适应思考始终开启,thinking: {"type": "disabled"} 在任何档位都返回 400;更早的 budget_tokens 形态不再被接受。剩下的杠杆是力度、作为硬上限的 max_tokens,以及面向整个循环的一份建议性任务预算。

扫描要跑多少次才有意义?

任务要够多,运行次数不必多。智能体分数的任务间方差很大,所以在同样花销下,30–50 个有代表性的任务各跑一遍,胜过 5 个任务各跑十遍——而且请报告与你当前档位的配对比较,而不是两个独立的平均值。

除了成本与质量,力度还改变什么?

延迟与工具调用的形态。更高的力度意味着每轮更多 token、更多工具调用,这会拉长每一轮的墙钟时间;更低的力度意味着更简短的调用和更少的铺垫,这可能被读成一个「跳步骤」的智能体。如果你的产品把智能体的推理展示给用户,那这个旋钮同时也是一个 UX 参数。

延伸阅读

本站:

信息来源: