在成本与智能之间进行优化

当一个工作负载从原型走向生产时，成本就成为首要的设计约束。能力最强的模型在大规模使用时可能过于昂贵，而最便宜的模型在质量上可能达不到要求。要管理好成本，就需要理解每个成本杠杆如何影响输出质量，因为有些杠杆会以质量为代价，有些则不会。Claude Platform 让您可以直接控制这种权衡。您可以为每个请求选择模型、effort（努力程度）级别和架构，这使您几乎可以将工作负载放置在"成本—智能"前沿曲线上的任意位置。

这些杠杆分为两类：

• 免费收益在不影响质量的情况下削减开支："prompt caching"（提示缓存）、令牌精简、针对您正在运行的模型进行提示审计、对可以等待最多 24 小时的工作使用享有 50% 折扣的批处理，以及作为最后保障的工作区支出限额。
• 权衡取舍以成本换取智能：模型选择、effort、输出上限和任务预算，以及多模型架构。

每个杠杆都附有实测结果以及何时值得使用的规则。在 Anthropic 的测量中，提示缓存是遥遥领先的最大杠杆：在本指南的基准测试中，它将智能体循环的成本降低了 2.5 到 3.7 倍，并将一个小型分诊智能体的账单削减了 83%，若再加上输入精简则达到 88%。多模型杠杆的适用范围更窄；第二个模型在两种形态下带来了回报：顾问（advisor）和编排器（orchestrator）。



从这里开始

将您的情况与某一行进行匹配。

这些结果来自 Anthropic 内部（引用的基准测试），仅具方向性，并非保证，因此请使用四步方法在您自己的工作负载上进行测量。



在不损失质量的情况下削减开支

提示缓存、令牌精简、批处理以及针对当前模型的提示审计，都能在不降低输出质量的情况下降低您的支出。有两点需要注意：批处理以延迟换取折扣；而上下文编辑这一令牌精简杠杆，在本节所测量的运行中花费超过了它所节省的。



缓存重复的上下文

在使用任何其他杠杆之前，先开启提示缓存，因为智能体任务的每一轮都会重新发送整个不断增长的对话：系统提示、工具定义以及之前的每一轮。一个 40 轮的任务会将其第一轮发送 40 次，因此任务成本大致随轮数的平方增长。缓存并不会阻止重新发送，但每次重新发送的成本约为原来的十分之一，且处理速度更快：前缀按缓存读取费率计费，即输入价格的十分之一，而每一轮仅对新增内容支付 1.25 倍的缓存写入费率。

在 Anthropic 的实测运行中，缓存读取通常是任务成本中最大的单一组成部分，这使得缓存比大多数模型选择决策更有价值。Anthropic 对 WideSearch¹ 和 DeepResearch Bench II⁷ 的运行分别在有缓存和无缓存的情况下进行了定价：

缓存的默认生命周期为 5 分钟，而智能体循环的各轮之间仅相隔数秒，因此折扣适用于每一轮的大多数令牌；图中所示的运行达到了 81% 到 90% 的命中率。节省幅度随回合深度而变化，因为较短的循环重新读取的内容更少，但在所测量的每个模型和基准上，缓存始终是最大的单一杠杆。

如果您的循环在各轮之间需要等待人工操作，请使用 1 小时缓存时长。它的写入成本更高（输入价格的 2 倍而非 1.25 倍），但在第一次避免未命中时就能收回成本，因为一次未命中会以全价重新发送整个前缀并再次写入。

设置工作量很小。自动缓存会为您放置断点；否则，Claude Code 附带的 Claude API skill 可以通过一条提示为现有集成添加缓存。以下摘录展示了该 skill 将缓存添加到产生这些测量结果的测试框架中：

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

这些断点的放置遵循显式缓存断点中的标准模式。

有三项设置可能会在任务期间破坏您的缓存。在请求之间更改 effort 会使已缓存的前缀失效，因此只在您本来就会重新缓存的地方更改它，例如在压缩边界处。在任务中途更改任务预算也会产生同样的效果，因此请在第一个请求上设置一次即可。每一次上下文编辑都会使前缀从其清除点开始失效，下一个请求需要付费重新缓存其后的所有内容，因此请以少量大批次而非大量小批次进行清除。请在自然断点处进行这三种更改，然后确认缓存读取没有下降；如果下降了，缓存诊断会显示前缀在何处发生了分歧。



精简输入和上下文令牌

大多数智能体请求都携带着从不影响答案的令牌。精简它们不会损失任何输出质量，尽管这里并非每个杠杆在测量时都节省了资金。有两个地方值得关注：

• 输入精简。 网页抓取工具中的动态过滤可将样板内容排除在抓取的页面之外，图像缩放可将视觉输入调整到合适大小，而带延迟加载的工具搜索仅在需要时加载工具定义。程序化工具调用让 Claude 从代码中运行多个工具调用，从而只有过滤后的结果进入上下文；其文档报告在智能体搜索基准上输入令牌减少了 24%，且得分更高。管理工具上下文对工具搜索、程序化工具调用、提示缓存和上下文编辑进行了比较。
• 上下文生命周期。 上下文编辑会清除过时的工具结果，而带阈值的自动压缩可防止长循环将其全部历史一直携带下去。

这些杠杆与缓存以及彼此之间相互作用，因此请按净效果来评判它们，并使用缓存诊断确认您的已缓存前缀在每次更改后仍然有效。Anthropic 为一个问题分诊智能体逐一开启这些杠杆，该智能体处理来自某公共代码仓库的 20 份带截图的真实错误报告（对于第二个面板，则是同一工作的更长变体）：

缓存完成了几乎所有的工作，而精简将总节省提升到 88%。每根柱子代表一次运行，因此 $0.10 的差异属于噪声；此处显示的差异则不是。压缩需要足够长的会话才能触发：20 个问题的运行在输入被精简后从未达到 50,000 令牌的下限，但在第二个面板的更长变体中，它触发了一次，并将账单进一步削减了 38%。

上下文编辑是这里唯一不免费的杠杆。每次清除都会重写已缓存的对话，这与提示缓存相抵触；在这次运行中，上下文编辑的花费超过了它所节省的。请将其用于在上下文窗口中腾出空间，并以少量大批次进行清除。



对可以等待的工作进行批处理

Batch API 对请求的每个令牌（包括已缓存的令牌）提供 50% 的折扣，代价是结果会在 24 小时内的任意时间到达。将所有无人等待的请求通过批处理路由，其余的保留在交互路径上。对于无人值守的智能体工作，批处理是仅次于缓存的第二大免费杠杆：评估运行、回填以及定时作业，例如令牌精简测量中问题分诊智能体的定期运行。它可以与本页上除交互性之外的所有内容结合使用，但不适用于 Claude Managed Agents 会话，因为这些会话在设计上就是交互式的（请参阅 Claude Managed Agents 定价）。



针对当前模型审计提示

每一代模型对提示的响应方式都不同，因此提示中会积累为您不再使用的模型所编写的文本。常见的情况是为弥补旧模型的不足而添加的过度具体的指令："验证两次"、"尽可能彻底"、强制性的分步流程，或手工编写的推理草稿区。较新的模型会逐字遵循这些指令，产生额外的工具轮次和额外的文字，因此账单上升而准确率没有任何提升。针对您现在运行的模型审计提示，并在每次更换模型时再次审计，是一项免费收益。

审计只需一条命令。Claude Code 附带的 Claude API skill 有一个 prompt-audit 命令，它会读取项目的提示和请求代码，并报告哪些内容是为其他模型编写的。以下简短摘录展示了它针对包含这些模式的客服台提示和请求代码运行的情况：

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

该命令随后以 diff 的形式提出其修改建议（显示了一个 hunk），并列出它有意保留不动的内容：退款窗口、语气要求和质量标准。您审阅的是一个补丁，而不是一次重写。

效果是可测量的。在一项客服台评估¹⁴中，为 Claude Opus 4.8 编写的提示在 Claude Opus 5 上每张工单的成本高出 36%，而准确率没有变化。对相同的提示运行审计后，Opus 5 既比未审计版本更便宜（便宜 14%），又更准确（97% 的工单，高于之前的 92%，这一提升超出了噪声范围）。在从 Claude Sonnet 4.6 迁移到 Claude Sonnet 5 时，审计在相同准确率下削减了 14% 的成本：

两类过时文本的代价不同。新模型过于字面遵循的指令会花费金钱：删除"验证两次"使 Opus 5 每张工单的成本降低了三分之一，删除"尽可能彻底"的效果几乎相同。不再适合模型的文本则会损失准确率：一个已退役的思考设置、相互矛盾的规则，以及与模型自身思考相冲突的手工草稿区，在 Opus 5 上被删除后各自恢复了 7 到 11 个百分点：

同样的模式也出现在工具描述和 skills 中，在那里也值得删除。



以成本换取智能

这些杠杆决定了单个模型在成本与智能之间的位置：模型选择、effort、以更高设置重新运行失败任务，以及它所处的预算和上限。从在当前模型上进行 effort 扫描开始（调整 effort）。按成本和能力从低到高，当前的模型依次为 Claude Haiku 4.5、Claude Sonnet 5、Claude Opus 5 和 Claude Fable 5（前沿模型）；模型概览提供了完整的阵容和价格。



按每任务成本比较模型

价格表是按每令牌编写的，而按每令牌计算，前沿模型看起来很昂贵：Claude Fable 5 的每令牌价格是 Claude Sonnet 5 的数倍。然而，您支付的是已完成的任务，因此请按每个已完成任务的成本来比较模型。能力更强的模型完成任务所需的工作更少：更少的轮次、更少的搜索、更少地重新读取自身上下文，以及更少的回溯。每令牌的溢价通常会被"各方面都做得更少"所抵消。

Anthropic 在 DeepResearch Bench II⁷ 上直接测量了这一点，这是一个难度足以区分各模型的研究报告基准：

尽管存在每令牌价格差距，low effort 下的前沿模型比中档模型更准确，且每任务成本低约 10%。不过它并非总是获胜。在本页的 SWE-bench Pro³ 子集上（两个模型在该子集上基本饱和，且其得分与公开排行榜不可比），单独使用 Claude Opus 5 与单独使用 Claude Fable 5 持平（91.7% 对 91.3%，在运行间噪声范围内），而成本约为后者的 60%。在更难的工作上，例如 DeepResearch Bench II 任务，Fable 的优势会重新显现。

对于大多数智能体工作负载，请从 Claude Opus 5 开始：按每令牌计算，它的成本是 Fable 5 的一半、Sonnet 5 的 2.5 倍，而在那个编码子集上它与 Fable 的准确率持平。在另一端，Claude Haiku 4.5 回答 GPQA Diamond⁹ 问题的每题成本约为 Opus 5 的十分之一，准确率为 63%，而 Opus 为 92%，并且在长编码任务上落后得更多。它适合具有可检查输出的高容量工作，而不适合长智能体循环。

排名会因工作负载而翻转，而没有任何价格表能告诉您会朝哪个方向翻转。请在您自己的流量上按每个已完成任务的成本为每个候选模型定价，包括 Claude Opus 5 和降低 effort 的前沿模型。

为工作负载的尾部定价，而不是中位数：在您最难的十分之一任务上比较模型，而不是典型任务。在典型任务上，每个模型看起来都差不多，最便宜的看起来最好，但账单是由更便宜的模型失败的那些任务决定的，因为失败的任务仍然会为其令牌计费，然后是重试，然后是失败在下游造成的任何代价。即使没有任何失败，尾部也是资金流向的地方。在一次 20 个问题的 WideSearch¹ 运行中，两个问题占据了 43% 的支出：

多模型策略的存在，正是为了将前沿智能用在那个尾部上，而不必为其余部分支付前沿费率。



调整 effort

Effort 是将模型调整到适合您任务的最直接方式。effort 参数控制模型进行多少思考、工具调用和自我验证，默认值（high）适合要求苛刻的任务。成本随所有这些活动而增长；准确率只随您的任务所需的那部分而增长。在模型的能力上限之下，最高的 effort 级别是在为任务从未用到的深度付费。

在研究和知识工作基准上（WideSearch¹、DeepWideSearch⁶、BrowseComp⁴ 和 GDPval²，均使用 Claude Fable 5），准确率对成本的曲线几乎是平的：low 放弃了 1 到 3 个百分点，换来每任务成本降低三分之一到一半；medium 以默认值 70% 到 85% 的成本达到了与默认值相同的准确率；而在这四个基准中的任何一个上，默认值相比 medium 都没有带来任何可测量的收益。在 DeepWideSearch 上，low 还以低 20% 的成本与使用 Claude Sonnet 5 工作者的编排器持平：降低 effort 胜过了架构变更。

较低的设置也更快，这在延迟是约束条件时很重要。在这些运行中，low 在 DeepWideSearch 上每个问题耗时 4.5 分钟，而默认值为 7.9 分钟。在语料库基准上（其输入无法放入任何单个上下文窗口），Fable 5 在 low、medium 和默认值下每个回合分别耗时 7.9、9.1 和 11.4 小时。

长周期编码是另一种形态。在 SWE-bench Pro³ 上，Claude Opus 5 在 medium 下放弃了约 2 个百分点换来一半的成本，在 low 下放弃了约 8 个百分点换来四分之一的成本：这是一个真正的权衡，而以更高 effort 重新运行失败任务可以将其重新变为节省。此图绘制了研究和知识工作基准以及 SWE-bench Pro 的准确率对成本曲线：

由此得出两个结论。第一，在添加第二个模型之前，先为您自己的工作负载绘制这条曲线：在这些内部测量中，一个看起来比默认单模型更便宜的多模型配置，其成本高于同一模型在较低 effort 下的成本。第二，这条曲线是任何多模型策略都必须超越的单模型基线，因此在您自己的工作负载上测量的第 2 步会跨 effort 级别建立基线。

在达到模型能力上限的工作负载上，较低的 effort 确实会损失准确率，因为在那里准确率真正随推理深度而增长。在 DeepResearch Bench II⁷ 上，每份报告都会奖励对每个子主题的深入推理，每一级 effort 都带来约 2.4 分的评分标准得分；在那条曲线上没有免费的成本削减：

仅凭任务描述无法揭示您拥有的是哪种工作负载，因此请在您自己流量的样本上扫描两到三个 effort 级别，并从曲线上读出答案。在单独的会话中测试每个级别：在会话中途更改 effort 会使缓存失效（请参阅缓存重复的上下文）并扭曲比较结果。有关参数详情，请参阅 Effort。



以更高 effort 重新运行失败任务

当任务的结果可检查时，effort 曲线上最便宜的策略不是一个固定设置：以低设置运行每个任务，并仅以更高设置重新运行失败的任务。

Anthropic 根据调整 effort 中 SWE-bench Pro³ 子集上的 effort 运行，逐任务计算了这一策略。使用 low 下的 Claude Opus 5，16% 的任务失败；将这些任务以默认值重新运行后，约 93% 通过，每个约 $0.70，而全部以默认值运行则为 91.7%、$1.39：相同的通过率，一半的成本，且已计入失败的廉价尝试。改为从 medium 开始则解决了约 94%，每个约 $0.95。小幅提升的大部分来自第二次尝试（以默认值重新运行默认值自身的失败任务得分大致相同，但花费更多），因此请为了节省而使用此策略，而不是为了提升：

有两个条件适用。第一，您需要一个失败信号（此处为基准自身的测试）；一个会放过不良工作的检查器会让这些失败漏过。第二，每个首轮失败都需要两次运行的挂钟时间，因此节省是以失败任务上的延迟为代价的。



设置预算和输出上限

大多数智能体任务运行都很便宜，但少数运行会在搜索、重新验证和过度测试上花费中位成本的许多倍。任务预算针对的就是那个尾部。模型会看到整个任务的实时令牌倒计时并进行自我调节，削减低价值的搜索、跳过冗余的验证，并及时收尾而不是陷入螺旋。

Anthropic 在 SWE-bench Pro³ 上使用 Claude Fable 5 测量了随预算收紧时的通过率和每任务成本：

宽松的预算放弃了约 2.7 个百分点的通过率，换来 18% 的成本节省，而允许的最紧预算放弃了 4.4 个百分点，换来 47% 的节省。预算在这里买到的是效率，而不是准确率。

三种控制手段承担三种不同的工作。任务预算能省钱，因为模型能看到它。max_tokens 是一个安全上限，不省任何钱。在 Claude Managed Agents 上，会话预算是两者背后的硬性美元止损。请三者都设置：一个任务预算、一个较高的 max_tokens，以及一个针对您永远不希望出现在账单上的运行的会话上限，并以工作区支出限额作为最终保障。

• 任务预算处于测试阶段（beta 标头 task-budgets-2026-03-13），适用于 Claude Opus 5、Claude Fable 5、Claude Opus 4.8 和 Claude Opus 4.7，但不适用于 Claude Sonnet 5；请先查看支持表。从接近您循环的第 90 百分位令牌用量开始，然后收紧（选择预算展示了如何收集该分布）。低于当前 20,000 令牌下限的预算会被拒绝，而非常紧的预算可能产生类似拒绝的行为。请在第一个请求上设置一次预算，因为任务中途的更改会使缓存失效。预算是建议性的，引导模型而非阻止它，因此请在您的工作负载上验证遵守情况。
• max_tokens 对单个响应设置上限，且对模型不可见，因此降低它不会让模型节约。需要那些空间的轮次会被丢弃但仍然计费。在一个内部代码仓库任务基准¹²上，16,384 令牌的上限终止了 Claude Opus 5 15% 的尝试和 Claude Fable 5 三分之一的尝试，其中没有一个被解决。受上限限制的运行每次尝试花费更少，但买到的解决数量也成比例减少，因此每个已解决任务的成本与 64,000 时相同。在该设置下没有任何内容被截断，并且在两次运行都评分的问题上，Fable 解决了 54.6% 的任务而非 36.6%（在参考文献 12 中描述的 SWE-bench Pro³ 子集的另一个切分上，为 92% 而非 90%）。重试受上限限制的尝试只会增加成本：在相同上限下它们从未成功，而在更高上限下您还要为浪费的尝试付费。对于智能体工作，请将 max_tokens 设置为 64,000（在 xhigh 或 max effort 下设置为最大值 128,000），对如此大的响应使用流式传输，将 stop_reason: max_tokens 视为失败，并通过模型可见的 effort 和任务预算来省钱。
• 是硬性止损。是对单个会话按令牌、搜索和会话时间的标价计算的美元上限。达到上限时，会话会以 暂停；提高预算即可恢复。它由平台强制执行，适用于任何有标价的模型（包括 Claude Sonnet 5），并可与建议性的任务预算结合使用。部署会将同一字段应用于每次运行。

两张 max_tokens 图表中的第一张绘制了每个上限下每次尝试和每个已解决任务的成本：

第二张绘制了每轮输出长度与上限的对比：



组合模型

多模型架构适合任务复杂度变化足够大、以至于不同步骤最好由不同模型来处理的工作负载。当您的流量混合了较小模型能可靠处理的常规工作与需要前沿能力的更难步骤时，拆分工作可以将前沿智能保留在重要的地方，同时大多数令牌按较小模型的费率计费。当工作负载缺乏这种混合时（因为其难度均匀，或者它是一条相互依赖的链），单个调优良好的模型通常是更好的选择。每个策略章节都给出了区分这两种情况的规则。

两种策略覆盖了大多数工作负载，它们的区别在于哪个模型掌控主循环：



顾问策略：上报困难决策

在 "advisor strategy"（顾问策略）中，一个成本较低的执行者模型（executor model）运行智能体循环并执行大多数轮次。当它遇到需要更深层判断的决策时，例如选择方案或从失败中恢复，它会调用一个智能程度更高的顾问模型（advisor model）以获取战略指导，然后继续执行。大多数令牌按执行者费率计费，只有偶尔的咨询按顾问费率计费。

要使用它，请将顾问工具添加到您的请求中。这一测试版功能在一个 /v1/messages 请求中于服务器端运行整个策略：执行者发出工具调用，Anthropic 运行顾问推理，执行者带着建议继续执行；您无需编写任何编排代码。在 Claude Managed Agents 上，通过在智能体的 multiagent 名册中添加一个 advisor 条目来为会话配置顾问；会话的主线程以同样的方式咨询它。Claude Code 也支持该功能；请参阅使用顾问工具上报困难决策。

决定收益的因素。 顾问只能通过执行者的调用来了解任务，因此有两件事决定了它能提供多大帮助。

第一是模型之间的差距。顾问只能提供执行者所缺乏的能力：在 GPQA Diamond⁹ 上，Claude Haiku 4.5 执行者从 Claude Opus 5 顾问那里获益巨大，Claude Sonnet 5 执行者获得了几个点的提升，而前沿执行者几乎没有获益。

第二，也是较为脆弱的一点，是执行者是否真的会去询问（即咨询率，consult rate）。低努力程度（effort）下的执行者可能不再注意到自己陷入了困境：一个在默认努力程度下对大多数任务都会咨询的配对，在降低努力程度后可能几乎不再咨询，然后得分低于执行者单独运行。该比率也因任务而异：在 DeepSWE¹⁰ 上，低努力程度的 Sonnet 5 执行者持续询问并获得了 23 个点的提升；在 SWE-bench Pro³ 上，同一个执行者停止了询问。当执行者确实询问时，它能完成大部分差距的弥合。在下图的各个配对中，顾问弥合了与更强模型之间 60% 到 90% 的差距，而更强模型只在咨询时才需付费，这使得成本方面的优势成为可能：

咨询率会对提示作出响应。仅使用工具的内置描述时，执行者调用不足，尤其是在编码工作中，因此顾问工具文档提供了一个系统提示，要求在实质性工作之前调用一次、在完成之前调用一次，每个任务大约两到三次调用。接下来测量的编码配对以该节奏运行，每个任务大约两次咨询。该页面还介绍了如何推动调用不足的执行者，以及如何在客户端限制调用次数以控制成本。因此请关注咨询率：通过提示引导它、测量它，并在它崩溃时恢复执行者的努力程度。

何时在成本上划算。 当几次简短的咨询（按顾问费率计费）取代了在整个任务中运行顾问模型时，顾问就能省钱。当顾问模型的定价远高于执行者模型时效果最好，因此最具成本效益的配置是前沿顾问搭配中端执行者。即使在范围的顶端，配对也能站得住脚，因为建议还能节省执行者令牌：被告知正确方案的执行者会探索更少的死胡同，这可以抵消咨询的成本。

在一个内部智能体编码基准¹¹上，使用普通 API 智能体运行，Claude Opus 5 执行者搭配 Claude Fable 5 顾问是所测量的最准确配置：85.7% 的尝试得到解决，每次尝试 $8.40。它位于穿过每个模型自身努力程度设置的曲线之上，但仅比其中最好的高出一两个点（Opus 单独在默认设置下为 84.4%、$8.50，Fable 单独在 medium 下为 83.4%、$8.20），单次运行无法将其与噪声区分开。Fable 单独在 medium 努力程度下达到与该配对大致相同的准确率（83.4% 对比 85.7%），花费也大致相同（每次尝试 $8.20 对比 $8.40）：

早先通过 Claude Code 的顾问模式进行的测量得出了相同的排序。请将此结果视为一种需要在您的工作负载上测试的形态，而非一种节省：在范围的顶端，顾问以前沿价格换取少量准确率，而成本优势属于能力差距更大的配对，例如下面的图表阅读案例。延迟成本就是咨询本身：在此基准上每个任务大约两次额外的前沿模型调用，每次都在任务的关键路径上。

何时比提高努力程度更划算。 在能力差距更大且工作负载的准确率对努力程度有响应的情况下，一个咨询顾问的低努力程度执行者可能是比提高执行者自身努力程度更便宜的升级方式，因为顾问只在需要它的任务上付费。

在 Chartography¹³（一个在 Claude Managed Agents 上使用其顾问运行的公开图表阅读基准）上，low 努力程度的 Claude Opus 5 执行者搭配 Claude Fable 5 顾问得分 67.5，每个任务 $0.60。这高于穿过任一模型自身努力程度设置的曲线（Opus 单独在 low 和 medium 之间从 49 升至 75，花费 $0.38 到 $0.94），尽管执行者自身的 medium 和默认设置仍保持最高分，价格分别为 1.6 倍和 3.3 倍：

低努力程度的执行者在 86% 的任务上咨询了顾问，这正是 SWE-bench Pro 配对未能满足的条件。在依赖此配置之前，请在您的智能体循环中测量咨询率。

无论采用何种配对，首先为顾问模型单独在低努力程度下定价；这是需要超越的基线。在每次模型发布时重新检查，因为发布会同时改变能力差距和价格比率。

何时适用。 顾问策略适合轮次大多是机械性的但优秀计划很重要的工作负载：编码智能体、计算机使用以及多步骤研究流水线。当每个轮次确实都需要前沿能力、当没有什么可计划的（单轮问答）、或者当您的执行者已经接近顾问的能力时，它就不太适合。



编排者策略：委派批量工作

在 "orchestrator strategy"（编排者策略）中，前沿模型掌控循环。它分解任务，将子任务分派给成本较低的工作者模型（worker model），并合并它们的结果。编排者自身的对话记录保持简短，因为工作者承担了令牌密集的探索，因此大多数令牌按工作者费率计费，而计划和综合仍来自前沿模型。

要构建一个编排者，请使用 Claude Managed Agents 中的多智能体编排：配置一个协调者智能体（即编排者）和一个工作者智能体名册，每个智能体都有自己的模型。有关使用 Claude Fable 5 协调者和 Claude Sonnet 5 工作者的完整可运行示例，请参阅 Claude Cookbook 配方协调者模式：大模型用于规划，小模型用于执行。

当工作者可以并行运行时，此模式可节省实际耗时：在语料库基准⁸上，协调者以平台文档规定的 25 个并发工作者上限运行时，一个回合耗时略多于 2 小时，而单独运行则需 11.4 小时。它仅在两种测量情形下省钱。对于单个模型可以独自处理的工作，同一模型在较低努力程度下每次都更便宜。

情形 1：为常规工作的成本长尾提供保险。 单独运行的前沿模型偶尔会在它通常能解决的常规问题上陷入螺旋。由于您无法提前知道哪些会如此，少数此类运行会主导账单。将常规工作交给成本较低的工作者的协调者可以限制该长尾，因为任何螺旋现在都按工作者费率发生。

Anthropic 在 BrowseComp⁴ 的一个刻意简单的切片上测量了这一点（10 个单独模型能可靠解决的问题；50 次委派运行和 70 次单独运行）。Claude Fable 5 协调者搭配一个 Claude Sonnet 5 工作者的平均成本略低于 Fable 单独运行的一半，在第 90 百分位约为三分之一（$12 对比 $33），而单独模型最昂贵的单次运行（$84）也是错误的：

委派在常规的、通常可解决的那部分工作上划算，这与"工作者是用来处理难题的"这一直觉相反。在完整的、更难的 BrowseComp 集合上，经济性发生了逆转。如果您的流量在常规任务上有较长的成本长尾，这是首先要测量的编排者情形。

情形 2：大于一个上下文窗口的工作。 单独模型必须串行处理如此大的输入，一次一个 "context window"（上下文窗口），每次都要付费重新读取自己的状态。工作者各自读取自己的分区，并行且按工作者费率。仍能放入一个上下文窗口的阅读密集型工作是模型选择问题，而非委派问题：仅就阅读成本而言，只有当没有单个上下文能容纳该工作时，编排者才会胜出。

Anthropic 为此情形构建了一个基准⁸：一个由 14 个公开 Python 包组成的 2160 万令牌语料库，植入了 130 个缺陷，对任何上下文窗口来说都太大。降低努力程度无济于事，因为账单就是语料库读取本身：Claude Fable 5 单独运行在每个努力程度设置下每回合花费 $720 到 $764，只有其准确率发生变化。协调者配置的成本比其中任何设置都低 60% 以上，得分比 medium 或默认设置下的 Fable 低 2 到 6 个点，同时完全击败了 Claude Sonnet 5 单独运行的基线：

令牌核算说明了原因。两份账单大部分都是从缓存提供的语料库读取：协调者配置每回合读取约 5.7 亿个缓存令牌，几乎是单独模型约 2 亿个的三倍，但成本仍不到一半，因为其读取按 Claude Sonnet 5 的缓存读取费率而非 Claude Fable 5 的费率计费。默认努力程度下的 Fable 5 仍保持峰值准确率，成本是协调者配置的 2.8 倍，因此这里的委派买到了大部分准确率，而非全部。

何时委派不划算。 只有当有批量工作可以移交时，编排者才能买到东西：许多独立的部分，理想情况下多到一个上下文窗口装不下。当工作是一条相互依赖的链，或者能放入单个上下文时，编排者要为计划、移交和合并付费，而单个模型可以免费获得这些。在所测量的每一个此类情形中，协调者的模型单独在较低努力程度下都胜出。

BrowseComp⁴ 在一个基准内部展示了这一边界。委派在常规切片上划算，而在完整的、更难的集合上失利，在那里前沿模型单独运行以低 22% 到 30% 的成本达到了协调者配置的准确率。独立的外部研究报告了相同的模式⁵。如果工作是一条链、能放入一个上下文且没有较长的成本长尾，或者单个模型在较低努力程度下已经达到您的标准，就不要构建编排者。



在策略之间进行选择

大多数情形归结为一个问题：工作是拆分为独立的部分，还是通过一连串相互依赖的步骤得出一个答案？策略表将这两种答案映射到两种策略。

如果您不确定，先不要构建任何东西：

1. 首先在您当前的模型上扫描努力程度。这是本页最便宜的实验，大多数工作负载到此为止。
2. 如果扫描显示存在差距，为更强的模型单独在低努力程度下定价。这是顾问配对必须超越的数字，而本页上超越它的配对都是执行者确实进行了咨询的配对。

本页的多模型结果是与同一模型在较低努力程度下以及与下一级模型单独运行进行比较评判的。这就是要在您自己的工作负载上运行的比较，也是第一步是努力程度扫描的原因。

当您确实添加顾问时，它是一个工具定义，而非重新架构。



在您自己的工作负载上测量

本页的数字来自 2026 年 7 月和 8 月，按当时的标价计算，并会随着模型和价格的变化而漂移。您的上报率、任务拆分的干净程度以及对话记录长度也会影响它们。方法保持不变：

1. 从生产日志中提取一些任务，按真实流量加权，并为每个任务编写结果检查：测试通过、工单关闭、行数正确。在得分旁边记录每个任务的成本：将每个响应的 usage 中的四个令牌计数按各自的费率定价，并在任务的所有请求中求和（用量与成本 API 报告汇总值）。
2. 在各个努力程度级别（而不仅是默认级别）上为各模型层级建立基线，并绘制得分与支出的关系图。多模型配置必须击败单个模型的整条曲线。
3. 如果曲线显示存在努力程度无法弥合的差距，添加适合的多模型策略并重新运行测试套件。
4. 在切换之前，在一个流量切片上以影子模式运行胜出者，然后保持测试套件持续运行。

以下示例按 Claude Opus 5 的标价计算一个请求的第 1 步成本：

在智能体循环中，缓存读取项通常是四项中最大的；如果不是，请检查缓存是否已启用。当启用顾问工具或压缩时，某些令牌仅在 usage.iterations 中报告，而不在顶层总计中，因此请改为对 usage.iterations 求和，并按顾问模型的费率为 advisor_message 条目定价。

下表按尝试顺序列出了各个杠杆：



引用的基准

所有测量均为 Anthropic 内部对这些基准的运行。除非另有说明，成本为按 2026 年 8 月标价计算的美元；Claude Sonnet 5 的数字使用每百万输入和输出令牌 $2 和 $10。标注为"名义美元"的图表按这些费率为每个请求的令牌计数定价，而非报告发票金额。

1. WideSearch： Wong 等，"WideSearch: Benchmarking Agentic Broad Info-Seeking"，arXiv:2508.07999，2025。广泛的网络研究任务，按多行表格的完整性和准确性评分；200 个问题，每个配置 3 次运行。缓存图表和努力程度图表来自不同的运行，因此每个问题的成本略有不同。成本集中度图表是一次单独的 20 个问题的运行，每个问题 3 次运行，按每请求计费记录计算成本。
2. GDPval： OpenAI，"GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks"，2025。按任务评分标准评分的知识工作交付物；对已发布黄金集的 210 个任务的运行，每个任务一次尝试。由 Claude 模型评分，因此绝对分数可能与已发布结果不同。
3. SWE-bench Pro： Scale AI，"SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?"，2025。为与 Anthropic 的评估框架兼容而选取的 482 个问题的子集；分数与公开排行榜不可比。默认努力程度下的 Claude Opus 5 为两次运行的平均值；降低努力程度的设置为单次运行。上报数字逐任务来自这些运行：先 low，然后对其失败项使用默认设置，在各运行配对中解决了 92.5% 到 93.6%，约 $0.70；先 medium，93.8% 到 94.2%，约 $0.95；默认设置对其自身失败项重新运行，94.0%，$1.58；全部使用默认设置，90.9% 到 92.5%，$1.39。顾问图表上的 Claude Sonnet 5 执行者配对来自同一 2026 年 8 月系列在此子集上的运行：Sonnet 加 Opus 配对运行了两次（一次运行和一次精确复现），低努力程度配对运行了一次；任务预算数字为同一子集上每个预算一次运行。比较模型中的 Claude Fable 5 数字是 2026 年 7 月的单次运行，也是任务预算图表的无预算基线；每次有预算的运行都完成了全部 482 个问题，没有框架错误。
4. BrowseComp： Wei 等，"BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents"，OpenAI，2025。努力程度数字使用 500 个问题的切分，每个设置一到三次运行。成本保险图表使用来自 26 个问题切片中的 10 个可靠解决的问题，50 次委派运行和 70 次单独运行（期望值为每次运行 $6.45 对比 $11.99）；委派数字带有约 20% 的测量区间。
5. Kim 等，"Towards a Science of Scaling Agent Systems"，arXiv:2512.08296，2025。独立的外部研究，仅引用其关于委派何时不划算的结论方向，不引用任何数字。



后续步骤