成本按每个任务算，
几种省钱做法的实测结论反转
Anthropic 官方文档第一次给每个降本手段都配上自家实测数据。把记账单位从每 token 换成每完成一个任务之后，有验证器时「低档全跑，只重跑失败的任务」能在同等通过率下把每任务价钱压到一半；多模型架构只在两种被测到的情形下省了钱；压低 max_tokens 省不到钱。
官方把不动质量的手段排在最前
官方文档把降本手段分成两类：一类不动质量，一类拿质量换钱。这页的测量以 agent 循环为主，也就是模型带着一套工具反复跑很多回合来完成一个任务，另有几组是问答类基准。不动质量的手段里，提示缓存远远排在第一。
agent 每跑一回合，都要把系统提示、工具定义和此前的完整对话重新提交一次。一个 40 回合的任务里，第一回合的内容被提交了 40 次，任务成本大致随回合数的平方增长。这里的 token 是模型计量和计价的最小单位，大致相当于一个词或半个词，输入和输出分别计费。
提示缓存不改变重复提交这个行为，只改变重复内容的价格。请求开头那段连续不变的内容叫前缀，缓存从第一个 token 开始逐字节匹配。命中已保存的前缀时，缓存读按输入价的十分之一收费；本轮新增的内容作为缓存写，五分钟档按输入价的 1.25 倍计费，一小时档按 2 倍计费。缓存默认存活 5 分钟，而 agent 循环的回合之间只隔几秒，所以折扣对每一回合的大部分 token 都生效。
一组 issue 分诊实验把账单拆得更细。模型是 claude-sonnet-5，跑在一个大型公开仓库的冻结快照上，处理 20 个带截图的真实 bug 报告。缓存一项省掉 83%，加上输入裁剪总共省掉 88%。
长任务变体的 token 量是前者的 2.6 倍，基线 $8.56，开缓存后降到 $1.34，上下文压缩触发一次后再降到 $0.83，又少 38%。任务要跑得够长，压缩才会触发：20 个 issue 那轮在输入裁剪之后再也没到过 50,000 token 的触发下限。
有三个设置会在任务中途打断缓存：改 effort、中途改任务预算、每次上下文清理。官方的说法是三者都放在自然断点上做，做完确认缓存读没有下降；其中任务预算建议在第一次请求就设定好、之后不再改动。缓存本身的请求结构怎么设计、断点怎么放，站内另有专篇，这里不重复。
不急着要结果的请求还可以走批处理。每个 token 打五折，连缓存过的 token 也打折，代价是结果在 24 小时内任意时刻返回。Claude Managed Agents 的会话不支持，因为那套托管运行环境（会话、沙箱和计费都在平台侧）本来就是交互式的。
上下文清理把过期的工具返回结果从上下文里清掉，而每清一次都会重写已经缓存的对话，与提示缓存相互抵消。在这次测量的运行里，它花掉的比省下的多。按官方的定位，它是用来给上下文窗口腾地方的，不是用来省钱的，而且应当分几大批清、不要清很多小批。
为上一代模型写的提示词，是一笔隐形税
每代模型对提示的反应不一样，提示词里会沉淀下为旧模型加的话，典型是 "verify twice"、"be maximally thorough"、一套强制的分步流程，以及自建的思考草稿区。新模型会照字面执行，于是多跑几轮工具、多写一堆字，账单涨了准确率没涨。
官方在一个客服工单评测上量了这件事：44 张工单、六份为旧模型写的提示词、确定性判分，准确率变化小于约 5 点按噪声处理。
| 配置 | 准确率 | 每工单成本 | 这一步换到了什么 |
|---|---|---|---|
| Claude Opus 4.8 + 旧提示词 | 89.5% | 2.52 分 | 起点 |
| Claude Opus 5 + 同一份旧提示词 | 91.8% | 3.43 分 | 贵 36% 准确率没有变化 |
| Claude Opus 5 + 审计后的提示词 | 97.0% | 2.93 分 | 便宜 14% 准确率升到 97% |
| Claude Sonnet 4.6 + 旧提示词 | 81.1% | 1.72 分 | 起点 |
| Claude Sonnet 5 + 同一份旧提示词 | 83.9% | 1.61 分 | 准确率差异在噪声内 |
| Claude Sonnet 5 + 审计后的提示词 | 85.6% | 1.39 分 | 省 14% 准确率不变 |
换上新模型但沿用旧提示词，每张工单比旧模型配旧提示词贵 36%，准确率没有变化。审计过同一批提示词之后，Claude Opus 5 比未审计版便宜 14%，准确率从 92% 升到 97%，这个增益超出噪声，95% 置信区间是 3 到 8 点。Claude Sonnet 4.6 到 Claude Sonnet 5 那条迁移线上，审计省掉 14%，准确率不变。
官方把陈旧文本的代价分成两类，逐条测出来的结果支持这个分法：被新模型照字面执行的那类花的是钱，不再适配这个模型的那类花的是准确率。
去掉 "verify twice" 让 Claude Opus 5 每张工单的成本降了三分之一，去掉 "be maximally thorough" 差不多同样多。而已废弃的 thinking 设置、互相矛盾的规则和自建的思考草稿区这三项去掉之后，在 Claude Opus 5 上各恢复 7 到 11 点准确率。官方还提醒同样的写法也会出现在工具描述和 skill 里，值得一并清理。
不碰质量的手段到这里用尽，余下每一个控制项都在拿质量换成本。
记账单位换了，模型排序就变了
价目表按 token 定价，按 token 看最强的那个模型价格高出很多：Claude Fable 5 的每 token 价格是 Claude Sonnet 5 的好几倍。但付钱买的是做完的任务，不是 token。能力更强的模型做完同一件事需要的动作更少：回合更少、搜得更少、少反复读自己的上下文、少走回头路。每 token 的溢价经常被「每件事都少做一点」抵消掉。
官方在一个研究报告基准上直接量了这件事。DeepResearch Bench II 的 50 题子集跑了 3 次，由 Claude Opus 4.6 判分。
| 配置 | 评分 | 每个任务的完成成本 |
|---|---|---|
| Claude Fable 5 · 低档 | 60.2 分 | $0.76 |
| Claude Sonnet 5 · 默认档 | 56.0 分 | $0.84 |
最强模型开低档比中档模型开默认档更准，而且每任务便宜约 10%，尽管它的每 token 价格约是后者的 5 倍。这批运行早于 Claude Opus 5 发布，所以这组对比里没有 Claude Opus 5。
这种反转并非每次都出现。SWE-bench Pro 是一个长周期软件工程基准，任务是在真实仓库里改代码并通过仓库自己的测试；在这页用的那个子集上，两个模型基本打平而便宜的那个只花约六成：Claude Opus 5 单跑 91.7%，Claude Fable 5 单跑 91.3%，差距在运行间噪声内。所以官方给的起点建议不是一律选最强的，而是多数 agent 工作量从 Claude Opus 5 起手：它的每 token 价格是 Claude Fable 5 的一半、Claude Sonnet 5 的 2.5 倍，而在这个编码子集上追平了 Claude Fable 5 的准确率。
排序会随工作量翻转，而价目表看不出会往哪边翻，所以官方要求在自己的流量上按每个任务的完成成本给每个候选定价，其中包括 Claude Opus 5 和降了档的最强模型。
官方把定价放在最难的那一成任务上，不是典型任务。典型任务上所有模型看着都差不多，便宜的那个看着最好；账单其实是被便宜模型做不完的那批任务决定的，因为失败的任务照样计费，然后还要付重试的钱和失败带来的下游代价。
而且就算什么都没失败，钱也集中在尾部。20 题 WideSearch 跑 3 次，Claude Fable 5，按每一次任务的计费记录算合计 $421。
所以真正要先问的不是换哪个模型，而是同一个模型的努力级别该设到哪一档。
effort 的成本曲线有两种形状
努力级别，也就是 effort，是同一个模型内部最直接的成本调节项。它控制模型思考多少、调用多少次工具、自我核对多少遍，档位是 low、medium、high，默认档就是 high。成本随这些活动量涨，准确率只随任务真正需要的那部分涨；在模型能力上限以下，最高那几档买的是任务用不到的深度。
官方扫出来的曲线有两种形状，结论恰好相反。第一种出现在研究和知识工作上，曲线近乎是平的；第二种出现在长周期编码上，曲线是陡的。
| 基准 | 低档 | 中档 | 默认档 |
|---|---|---|---|
| WideSearch 广泛搜网页并填出一张多行表格 | 78.5% / 约 $2.9 | 79.8% / 约 $4.2 | 80.0% / 约 $5.9 |
| DeepWideSearch 同时要求收集很多行与多跳检索 | 64.9% / 约 $3.4 | 65.9% / 约 $4.6 | 66.4% / 约 $6.1 |
| BrowseComp 浏览类 agent 找难找的事实 | 78.5% / 约 $4.2 | 81.5% / 约 $5.3 | 81.3% / 约 $6.15 |
| GDPval 真实经济价值的知识工作交付物 | 83.5% / 约 $1.45 | 84.0% / 约 $2.25 | 83.1% / 约 $3.2 |
四个基准均为 Claude Fable 5。WideSearch 与 DeepWideSearch 每点 3 次运行；BrowseComp 的图注写 3 次，而出处清单写的是每档 1 到 3 次；GDPval 每点 1 次运行且成本含判分。
四组指向同一个方向：低档让出 1 到 3 点，每任务成本只要三分之一到一半；中档追平默认档的准确率，只花默认档的 70% 到 85%；默认档在这四个基准上相对中档都没买到可测的收益。BrowseComp 与 GDPval 的默认档没有比中档更准，图上还略低一点。
低档也更快，延迟是约束时这一点有用。DeepWideSearch 上低档每题 4.5 分钟，默认档 7.9 分钟；那个超大语料基准上低档、中档、默认档每轮分别是 7.9、9.1、11.4 小时。官方另给了一条同向的对照：DeepWideSearch 上低档还追平了一个「协调者加一个 Claude Sonnet 5 worker」的配置，且便宜 20%，也就是调低努力级别赢过了换架构。
第二种形状出现在长周期编码上。Claude Opus 5 跑 SWE-bench Pro 482 题子集时，中档让出约 2 点，成本只要一半；低档让出约 8 点，成本只要四分之一。这是一笔明确的取舍，不是免费午餐。同一个参数在两类工作上性质完全不同。
还有一类工作量会触及模型的能力上限，在那上面每一档都确实买到分数。
只看任务描述，判断不出它属于哪一类，只能从实际流量取样扫两三档，从曲线上读答案。每档要单独开一个会话跑，因为在会话中途改 effort 会让缓存失效，把成本对比扭曲掉。
官方从这条曲线上推了两件事。一是在这批内部测量里，有一个多模型配置看起来比默认档单模型更便宜，实际比同一个模型调低档还要贵。二是这条单模型曲线就是任何多模型策略必须先打败的基线。
输出侧的三个控制项
effort 调的是一个任务投入多少活动量，输出侧控制的是允许它花到什么程度。失败重试、任务预算和 max_tokens 看起来是一类，实际只有前两个能省钱，区别在于模型能不能看到这个限制。
产出可以自动校验时，固定跑某一档本身就是浪费
最省的策略不是挑一个固定档，而是全部跑低档、只把失败的用高档重跑。Claude Opus 5 在同一批 SWE-bench Pro 任务上的点值如下。
低档跑时有 16% 的任务失败。把这批失败的交给默认档重跑之后，通过率追上默认档全跑，每题价钱约是一半。官方点明了一处限定：这里的小幅提分主要来自「有第二次尝试」，不是来自「档位更高」，因为让默认档重跑它自己失败的那些任务也只到 94.0%，成本却升到 $1.58。所以这套策略是为了省钱，不是为了那点提分。
它的第二个前提是延迟：每个第一遍就失败的任务要付两次运行的墙钟时间，省下的钱是用失败任务的延迟换的。
任务预算能省钱，因为模型看得见它
大多数 agent 任务跑得便宜，少数会在搜索、反复验证和过度测试上花掉中位数的好几倍，任务预算针对的就是这条尾巴。模型看到整个任务的 token 倒计时会自己收敛：砍掉低价值搜索、跳过冗余验证、该收尾就收尾而不是继续打转。
宽松预算让出约 2.7 点，省下 18% 的成本；最紧的预算让出 4.4 点，省下 47%。官方的定性是这里预算买到的是效率，不是准确率。
官方的起点建议是从循环的 90 分位 token 用量附近起步，再逐步收紧；低于当前 20,000 token 的下限会被拒绝，预算过紧会出现类似拒答的行为。它应当在第一次请求设定后就不再改动，中途修改会让缓存失效。它是建议性的，引导模型而不是强行停住它，所以要在自己的工作量上验证遵守情况。
max_tokens 压低省不到钱，因为模型看不见它
它只规定单次响应最多输出多少 token，对模型不可见，压低它不会让模型主动节省。需要那个空间的回合被丢掉，而且照样计费。
16,384 的上限终止了 Claude Opus 5 的 15% 尝试和 Claude Fable 5 的三分之一尝试，被终止的尝试没有一次解出。压低上限确实减少了单次尝试的支出，但解出的题按比例更少，于是每解出一题的成本在两档上限下一样。64,000 时没有任何回合被截断，Claude Fable 5 解出 54.6% 而不是 33.3%；在 SWE-bench Pro 子集的另一个切片上是 92% 而不是 90%。
单回合的输出分布解释了为什么一个看着宽松的上限能造成这么大差别。
极少数长回合决定了大量任务能否完成。重试被截断的尝试只会加成本：同样上限下它们从来没成功过，换更高上限还要为浪费掉的那一次付钱。官方的建议是 agent 工作把 max_tokens 设成 64,000，在 xhigh 或 max 档设成最大值 128,000，这么大的响应要用流式，并把 stop_reason: max_tokens 当作失败处理，省钱交给模型看得见的那两个控制项。
| 控制项 | 模型看得见吗 | 负责哪件事 | 撞线时 |
|---|---|---|---|
| 任务预算 建议性，beta | 看得见 | 让模型主动收敛，能省钱 | 引导而非强行停住，需验证遵守情况 |
max_tokens单次响应上限 | 看不见 | 防止单次响应无限增长的安全阀，本身省不到钱 | 返回 stop_reason: max_tokens，当失败处理 |
| 会话预算 Claude Managed Agents | 平台侧强制 | 硬性美元停止，按牌价对 token、搜索和会话时长计算 | 会话暂停并返回 stop_reason: budget_reached，抬高预算可继续 |
会话预算对任何有牌价的模型都生效，包括 Claude Sonnet 5，并且能和建议性的任务预算叠加。官方建议三者一起设，外面再套一层工作区花费上限兜底。这些控制都还在一个模型内部，调完仍不够，才轮到加第二个模型。
第二个模型什么时候值得加
多模型架构是当下常见的降本方案，官方这页的实测结论比流行说法克制得多。它适合的是任务难度参差的工作量：例行部分由便宜模型稳定完成，少数环节才需要顶级能力，这样大部分 token 按便宜模型计价而顶级能力仍在该在的地方。反过来，如果各环节难度接近，或者整件事是一条前后依赖的链，通常还是单个调好的模型更合适。
官方只讲两种形状，区别在主循环在谁手里。顾问式让便宜模型当执行者握住主循环，遇到需要判断的地方调用一次强模型、取回一份方案，然后继续往下做；协调者式让强模型握住主循环，把任务拆开派给若干便宜的 worker，再把结果合起来。
顾问式：增益跟着求助率走
顾问式的成败卡在两个变量上。第一个是两个模型之间的能力差，顾问只能补上执行者本来没有的能力。GPQA Diamond 上，Claude Haiku 4.5 执行者从 Claude Opus 5 顾问那里得到很多，Claude Sonnet 5 执行者得到几点，最强模型当执行者时几乎什么也得不到。
第二个变量更脆弱：执行者会不会开口求助。求助率指实际调用顾问的任务占比。六组配对摊开看，实得增益基本跟着求助率走。
执行者确实求助时，顾问补上了到更强模型那段差距的 60% 到 90%，而更强的那个模型只在咨询的那几次上付钱，成本上能不能划得来就取决于这一点。最后一行是反面：同一个低档执行者只对 7% 的任务求助，配对成绩反而比执行者单跑低 5.4 点。执行者在低档上会意识不到自己卡住了。
求助率能被提示词拉起来。只给顾问工具自带的说明时执行者会问得不够，编码任务上尤其明显；官方给的系统提示要求动手前问一次、收尾前问一次，大约每个任务两到三次咨询。所以求助率是需要提示、需要测量、需要持续观察的量。
成本上什么时候划得来，官方的结论很克制。它省钱的前提是几次简短咨询替代了「整个任务都用顾问那个模型跑」，所以顾问的模型得比执行者贵不少，最划算的形状是强模型给中档模型当顾问。两组实测如下。
| 内部编码基准（370 个仓库任务） | 解出 | 每次尝试 |
|---|---|---|
| Claude Opus 5 执行 + Claude Fable 5 顾问 | 85.7% | $8.40 |
| Claude Opus 5 单跑默认档 | 84.4% | $8.50 |
| Claude Fable 5 单跑中档 | 83.4% | $8.20 |
| Claude Opus 5 单跑低档 | 74.3% | $1.9 |
| Claude Opus 5 单跑中档 | 82.1% | $4.5 |
| Claude Fable 5 单跑低档 | 78.7% | $5.4 |
| Claude Fable 5 单跑默认档 | 85.1% | $11.9 |
纯 API agent，2026 年 8 月。默认档设置与配对都是每题五次尝试，降档设置各一次。配对平均每次尝试约两次顾问咨询。一两点的差异在运行间噪声内。
| Chartography（读图） | 低档 | 中档 | 默认档 |
|---|---|---|---|
| Claude Opus 5 单跑 | 49 分 / $0.38 | 75 分 / $0.94 | 79 分 / $1.95 |
| Claude Fable 5 单跑 | 55 分 / $0.81 | 73 分 / $1.44 | 74 分 / $1.74 |
| Claude Opus 5 低档执行 + Claude Fable 5 顾问 | 67.5 分 / $0.60（两次运行散点 65 分 / $0.47 与 70 分 / $0.73） | ||
Chartography 的发布方 Surge AI 发布的 100 题全集，2026 年 8 月，跑在 Claude Managed Agents 上，每种配置各跑两次取均值，运行间离散度 4 到 10 点。
配对是测到的最准配置，但它只比两个模型各自最好的那个点高一两点，而单次运行分不开这点差距和噪声。官方对这个结果的定性是把它视为一种需要在自己工作量上验证的模式，而不是省钱的承诺，并说明成本上真正划得来的情形属于能力差更大的那些配对。
读图那组是另一种情形，顾问式在这里赢过了给执行者加档。Chartography 上，Claude Opus 5 低档执行加 Claude Fable 5 顾问得 67.5 分、每题 $0.60，落在两个模型各自效率曲线之上；而 Claude Opus 5 单跑从低档到中档是 49 分 / $0.38 到 75 分 / $0.94。执行者自己的中档和默认档仍然拿着最高分，代价是配对价钱的 1.6 倍和 3.3 倍。这组配对里的低档执行者对 86% 的任务咨询了顾问，而 SWE-bench Pro 那组恰恰没有满足这个条件。
顾问式适合大部分回合偏机械、而方案质量决定结果的工作：编码 agent、计算机操作、多步研究流水线。不适合的情形有三种：每个回合都确实需要顶级能力；任务是无需规划的单轮问答；或者执行者本身已经接近顾问的能力。
协调者式：省钱的地方是例行工作的成本尾巴
协调者式只在两种被测到的情形下省了钱。第一种是给例行工作的成本尾巴上保险。强模型单跑偶尔会在一道本来能做对的例行题上打转，而事前分不出是哪几道，于是这几次占掉大部分账单。把例行工作交给便宜 worker 就把这条尾巴按住了，因为打转现在发生在 worker 的价钱上。
官方的表述是委派侧平均花的略低于单跑的一半、90 分位上约三分之一；按表里的期望值算，$6.45 对 $11.99 约为单跑的 54%，也就是略高于一半。官方点出的反直觉之处是，委派省钱发生在例行、本来能做对的那部分工作上，跟「worker 是用来做难题的」这个直觉正好相反。边界与这个结论同源：换到完整的、更难的 BrowseComp 集上，经济性反转了。
第二种是工作量大过一个上下文窗口。单模型只能一段一段串着读，每过一遍都要为重读自己的状态付钱；worker 各读自己那一片，并行且按便宜价计费。官方为这种情形专门构造了一个基准：2,160 万 token 的语料，取自 14 个公开 Python 包源码，植入 130 个缺陷，确定性判分。
在这个工作量上降低 effort 帮不上忙，因为成本主要就花在读那 2,160 万 token 的语料上：Claude Fable 5 单跑每轮 $720 到 $764，所有努力级别都落在这个区间内，只有准确率在动。协调配置比 Claude Fable 5 的任何一档单跑便宜 55%，比 Claude Fable 5 的中档或默认档低 3 到 7 点，同时明显好过 Claude Sonnet 5 单跑。
token 账说明了为什么。协调配置读得比单跑更多，3,200 万输入 token 对 1,450 万，却仍然更便宜，因为按 worker 价分片读比按顶级价反复重读便宜。Claude Fable 5 默认档仍然保持最高准确率，代价是协调配置成本的 2.3 倍，所以委派在这里买到的是大部分准确率而不是全部。
F1 兼顾找得全不全和判得准不准，它的绝对值只在这套语料构建里有意义。
只有真的有一批工作可以交出去才值得，最好是多到装不进一个上下文窗口。当整件事是一条依赖链，或者装得进一个上下文，协调者要为一次规划、一次交接和一次合并付费，而单个模型不必为这些付费。完整的、更难的 BrowseComp 集上，强模型单跑以比协调配置低 22% 到 30% 的成本达到了同样的准确率。官方的一般结论是，在每一个被测到的这类情形里，协调者那个模型自己调低档都更划算。原文另引了一份关于 agent 系统规模化的外部研究印证这个方向，但明确只取方向、不取其中任何数字。
官方给的判断顺序因此是明确的：先扫同一个模型的 effort 曲线，这是这页上最便宜的实验，多数工作量到这里就结束了；仍有缺口，再测更强模型单跑低档的价格，那个数才是配对需要打败的对象。而这页上真正打败了它的那些配对，都是执行者确实开口求助的那些。官方对落地成本的说法是，加一个顾问是一个工具定义，不是一次架构重做。
在自己的流量上怎么量
这页的数字来自 2026 年 7 月和 8 月，按当时的牌价，会随模型和价格漂移。自己的升级率、任务能不能干净拆开、对话有多长，也都会把这些数字挪位置。量法不变，官方给了四步。
取样，并定好结果检查项
从生产日志里按真实流量比例抽一批任务，为每个任务定好结果检查项（测试通过、工单关闭、行数对得上），并把每任务成本记在分数旁边。
各档模型都跨努力级别跑一遍基线
不只跑默认档，把分数与花费的关系画出来。多模型配置必须打败单模型的整条曲线。
只在曲线出现缺口时才加多模型架构
曲线上出现努力级别填不上的缺口，才加合适的多模型策略并重跑整套评测。
先跑影子流量，再切换
赢的那个先在一小片流量上跑影子流量，再切换，然后让这套评测一直跑着。
每任务成本的算法是把每次响应 usage 里那四个 token 计数各按自己的价率计价，再按任务累加：输入按输入价，五分钟档缓存写按输入价的 1.25 倍，缓存读按输入价的 0.10 倍，输出按输出价。官方示例用的是 Claude Opus 5 的牌价。
# 每百万 token 的价格取自价目表；换模型只改这两行
INPUT_PER_MTOK = 5.0 # Claude Opus 5
OUTPUT_PER_MTOK = 25.0
usage = response.usage
cost = (
usage.input_tokens * INPUT_PER_MTOK
# 缓存写按输入价的 1.25 倍（五分钟档）；缓存读按 0.1 倍
+ (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
+ (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
+ usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
官方另给了一条自检：agent 循环里缓存读通常是这四项里最大的一项，如果不是，就该检查缓存到底有没有生效。
开了顾问工具或上下文压缩时，有些 token 只在 usage.iterations 里报，不进顶层合计，所以要按 usage.iterations 逐项累加，并把 advisor_message 那些条目按顾问模型的价率计价。
这页最后按尝试顺序排了一张开关表，顺序是免费的手段在前、有取舍的在后、多模型最后评估。具体读数会随模型和牌价漂移，这套量法不会。
口径与限制
全部实测结果都是 Anthropic 内部运行这些基准得到的，不是第三方复现，也不是发票金额；标 notional USD 的图是把每次请求的 token 数按牌价计价。除另有注明外，成本均按 2026 年 8 月牌价计算，Claude Sonnet 5 按每百万 token 输入 $2、输出 $10 计。原文自己写明这些结果是方向性的、不构成保证。
| 基准 | 可比性限制 |
|---|---|
| SWE-bench Pro | 用的是为适配 Anthropic 评测框架挑出的 482 题子集，分数不可与公开榜单比较；max_tokens 那组用的是从中再分层抽出的 100 题子集，与 482 题的分数也不可比 |
| Chartography | 由 Claude Sonnet 4.6 判分且带工具运行，只在本页各配置之间可比，不可与公开榜单比较 |
| GDPval | 由 Claude 模型判分，绝对分可能与已发布结果不同 |
| DeepResearch Bench II | 由 Claude Opus 4.6 判分，原基准用的是另一个判分模型，Anthropic 的判分模型可能偏向自家风格；这批运行早于 Claude Opus 5，所以模型对比那张图里没有 Claude Opus 5 |
| 超大语料基准 | F1 绝对值只在这套语料构建里有意义 |
运行次数。SWE-bench Pro 上 Claude Opus 5 默认档是两次运行均值，降档设置都是单次；max_tokens 64,000 那组是单次运行；内部编码基准每种配置各跑一次；GDPval 每点一次运行。
两处都是官方文本，无法判定哪个为准，故本文不采用任一说法作为定论，也不影响任何点值本身。
① 任务预算那张图的图注写的是 35k = mean of two runs（35,000 档为两次运行均值），而出处清单第 3 条写的是 the task-budget figures are one run per budget（每个预算档各一次运行）。出处清单另写明每一次带预算的运行都完整跑完了 482 题且没有出现框架错误。
② 顾问机制那张图的图注写的是 SWE-bench Pro 与编码任务每种配置各跑一次，而出处清单第 3 条把该基准上的两组配对分开写：默认档那组跑了两次（a run and an exact replication），低档那组一次。
噪声带。客服工单评测里准确率变化小于约 5 点属噪声，Claude Opus 5 的准确率增益 95% 置信区间是 3 到 8 点，Claude Sonnet 的准确率差异在噪声内；分诊那组约 $0.10 以内属噪声；Chartography 两次运行间离散度 4 到 10 点；超大语料基准里 $720 到 $764 属种子噪声；内部编码基准里一两点的差异在运行间噪声内。
两个 BrowseComp 切片不能混用。成本保险那组用的是「单模型能稳定做对的 10 题」，取自 26 题切片，委派侧成本带约 ±20%；努力级别那组用的是 500 题切片。
外部引用。原文引的那份关于 agent 系统规模化的研究（Kim 等人）只用于印证「什么时候委派不划算」这个方向，原文明确不取其数字。
实现差异。DeepSWE 那组用的是客户端顾问循环而非顾问工具；Chartography 的求助率对照是在 Messages API 上带一套容器工具重跑同配置得到的。