Anthropic 在官方成本指南里面提供了一个选择模型的策略：不要用每token的价格来比较模型，而应该看每个任务被解出来的成本是多少。从这个角度出发，你会发现价格表上贵的模型其实往往更便宜。例如在软件工程的评测集SWE-bench Pro上，把Fable 5.1每次出力大小的 effort 设为 low，可以解出88.6%的题目，每个题目花费了0.54美元。相比之下，如果用默认设置的Sonnet 5，只能解出来77.4%的题目，但每解出一个题目需要0.84美元。虽然单价差了大约5倍，但总得来说贵的模型更便宜。
很多团队一旦看到账单高了，第一反应是把某些步骤换成单价更低的模型。这个直觉默认了成本来自单价。但真实 agent 负载里这个假设站不住。更强大的模型往往用更少的轮次、更少的工具调用、更少的重试就做了同样的事，省下来的工作量直接把单价的差价抹平了。
关于推理的成本，大家通常很直观地会去看价格表上单价是多少。但当你让 agent 去修一个 bug、出一份报表的时候，你购买的是确定的结果，而不是按字收费的字符。agent 的工作量和普通的文本补全接口完全是两码事，账单应该按结果算，不应该按单价算。
Anthropic 关于成本和智能的优化文档里有一组数据说明了这一点。按每解出一个任务来看的话，又是一副图景。默认配置下，Opus 5.5 可以解出 92.8% 的任务，每解出一个任务只需要 0.22 美元。Fable 5.1 也可以解出 92.3% 的任务，但每解出一个任务需要 1.19 美元。注意 Fable 5.1 每 token 的价格明显更高（$10 / $50 对比 Opus 5.5 的 $4 / $20）。但这里在准确率这个噪声范围内，更贵的模型并没有带来更好的结果，反而每任务成本高了约五倍。
模型的迭代也遵循同样的规律。根据文档中的测试，从 Sonnet 4.6 切换到 Sonnet 5，解题率提升了 5 个百分点，每解出任务的平均成本还降低了 15%；从 Fable 5 升级到 Fable 5.1，解题表现相当，每解出任务的花费降了 43%。
但换更强模型不等于账单自动下降。在文档的另一个基准 DeepResearch Bench II 上，Fable 5.1 把 effort 调到 high，准确率虽比前代高 2~3 个百分点，每解出任务成本却涨了 41%。单任务成本能否降低，不取决于模型有多强，而取决于这类任务中模型做的工作量能否被收住。
贵模型能在每任务成本上赢便宜模型，是因为 agent 的运行方式把费率的作用架空了。agent 每跑一轮就攒一层状态，下一轮又要把整段对话历史、工具定义、系统提示词重新发给模型。一个跑 40 轮的任务，等于把第一轮的内容发了 40 遍。不做优化的话，输入 token 会随轮数平方增长。
在生产环境里，提示词缓存承担了绝大多数重复内容。Anthropic 公布过一组来自其第一方 API 的数据：对连续 14 天里 10 万个以上的组织进行观察，在 agent 循环里，从提示词缓存里读的 token 占所有输入 token 的中位数是 84.2%，上四分位是 91.7%。在写代码的组织里中位数是 88.5%，当单任务工具调用超过 25 次时升到 90.9%，头部十分之一的组织更超过 95.9%。任务一旦跑到深处，好的 agent 循环里只有不到 1% 的输入 token 需要付全价。
但缓存读便宜很多。普通模型的缓存读一般只要输入价格的十分之一，Opus 5.5 和 Sonnet 5.5 是二十分之一，Fable 5.1 甚至只有四十分之一。因为缓存默认只存 5 分钟，而 agent 的轮次往往只是几秒，所以每轮基本都能吃到这个折扣。因此，价格表上那个吓人的输入单价，在实际中大多数时候乘的是一个打折到一折甚至零点二五折的小数。真正决定账单的是模型跑了多少轮、调了多少次工具，而不是标价。
所以在会话中间换模型来省钱，往往适得其反。因为提示词缓存要求前缀逐字节完全相同，你在中间换了一个更便宜的模型，或者改变了系统设定，整条缓存就会直接作废。
Anthropic 做过实验：10 万 token 的前缀断一次，就要按写入价重算全量。在 Fable 5.1 上这一刀要花 1.25 美元，原本读一次只要 0.03 美元，差了 50 倍；Opus 5.5 和 Sonnet 5.5 上也差了 25 倍。为了省某一步那点费率去切模型，换来的是几十倍重写代价的缓存断裂。
相比之下，调模型的工作量是顺手得多的杠杆。Anthropic 的 effort 文档给了五档：low、medium、high、xhigh、max，控制模型在思考、写文本、调工具上花多少力。更关键的是，开一个请求头就能在会话中途改 effort，而且完全不会破坏缓存。
二者结合，直觉就很明显了：想省钱，把同一个模型的 effort 调低，比换一个更便宜的模型划算很多，因为换模型会引发缓存断裂，而调 effort 不会。
那如果在一个模型上调节 effort 又省事又不破坏缓存，是不是都应该把 effort 设到最小呢？不是的。实测里 effort 的效果在不同的任务上有两种完全不同的表现。
第一类是研究和知识抽取的活。Anthropic 在 WideSearch、DeepWideSearch、BrowseComp、GDPval 几个检索分析基准上测试了 Fable 5，这些基准官方默认档是 high，往下调 effort 准确率几乎不动，成本却能一路降下来。
对于这种研究和知识抽取的任务，把 effort 从 high 调到 low，准确率只掉了 1 到 3 个百分点，但每解出一个任务的成本可以省掉三分之一到一半。中档（medium）的准确率和默认几乎一样，成本只有默认的 70% 到 87%。在四个基准里，默认的 high 相比 medium 都没有可测的精度收益。降 effort 还更快，DeepWideSearch 上每题从默认的 7.9 分钟缩到 4.5 分钟。在这些活上硬撑高 effort，纯属浪费算力。
第二类是长程工程和复杂编码，曲线很陡。在 Opus 5.5 解 SWE-bench Pro 代码缺陷的测试中，这个模型默认档是 medium，准确率高度依赖给它多少思考和计算量。medium 比 high 低约 2.5 个百分点，成本是 high 的 70%；降到 low，解题率掉约 8 个百分点，从 high 的 95.3% 掉到 87.4%，成本降到约三分之一，也就是 0.11 对 0.29 美元；升到 xhigh，准确率加约 1.4 个百分点达到 96.7%，但成本涨到 0.74 美元，是 high 的 2.5 倍。
把一档 effort 死磕在一个模型上，研究任务上浪费预算，长程编码上压太低又大面积失败。
对于这种陡峭型任务，如果有明确的验证信号（单测过不过/编不编得过），一个聪明的办法是：全部先用low跑，失败了的再用high重跑一遍。SWE-bench Pro上，全量high是95.3% / 0.29美元/题；先low再重跑失败题，准确率反而到了97.0%，每题只要0.17美元。代价是失败题要跑两遍，好处是用便宜算力过掉大部分常规题，把高effort只留给真正难的分支，总成本省了近一半，准确率还略高。
那既然用一个模型内部调整 effort 就能实现类似缓存和算力调节的效果，那为什么还要用多模型分层架构呢？Anthropic 在文档里有一个硬性标准：一个多模型分层架构要想成立，得先证明它比用同一个模型降低 effort 更划算。有很多看起来精巧的多模型分层方案，做简单的数学比较后发现，其实比用同一个模型降低 effort 还贵。
举个例子，比如顾问模式。用一个轻量级的执行者跑主循环，卡了再请更聪明的高阶模型当顾问指点。要见效，需要二者能力差距够大，且执行者真会去问。
但问题在于，执行者到底会不会问？这个恰恰是最薄弱的一环。在GPQA Diamond的198题里，官方用单跑85%的Haiku 5.5和单跑91%的Sonnet 5.5当执行者，Opus 5.5当顾问。两轮一共396次机会，执行者一次没问（0/396）。只是挂了顾问工具的定义，每次请求就多约1000个输入token，把Haiku每题成本涨12%，Sonnet涨25%，得分却和执行者单跑一样。
更麻烦的是，一旦把执行者调到低 effort 档位试图省成本，它连自己卡住了都常察觉不到，问得更少，表现甚至不如单跑。在另一项 370 题的内部代码基准上，官方测了 Opus 5.5 当执行者、更前沿档位的 Fable 5.1 当顾问：比 Opus 5.5 单跑 high effort 多 1.7 个百分点，每次尝试成本却是 2.1 倍（2.92 美元）。这点提升跟直接把 Opus 5.5 开到 xhigh 差不多，多出来的架构没换来更好的性价比。
另一个思路叫协调者模式：用最强的模型来做规划和分块，然后把大量细活丢给便宜的 worker。但在常规任务上这样去拆同样不划算。在 DeepWideSearch 上，让 Fable 5 在 low effort 下自己跑，精度和它指挥 Sonnet 5 干的复合架构完全一样，但便宜 29%。原文结论是：单纯把 effort 调低就吊打了整套架构重构。
根据官方测试，协调者模式只有在两种情况下能够真正节省成本：
一是在日常成本的长尾上买保险。很多开放性的搜索或排查任务，强模型会偶尔在某道常规题上打转或过度发挥，极少数这种轮次就把整个周期里的大头账单给吃了。让协调者把常规活甩给便宜模型，就能把最贵的那段长尾给掐掉。在BrowseComp的测试切片里，用Fable 5 + 1个Sonnet 5，平均成本砍了大约一半，90%分位从33美元降到12美元，还把”某个单模型跑了84美元却答错”的极端情况给消掉了。
二是活太大、一个上下文窗口装不下。面对 14 个公开代码包、2160 万 token 的大型缺陷排查，单靠 Fable 5.1 要 15 到 20 小时、468 到 552 美元；换成 1 个 Fable 5.1 带 25 个 Sonnet 5 并行，2.3 小时跑完，总成本降约 50%，代价是得分低 10 到 12 分。
如果你的工作是一条依赖链、能装进一个上下文窗口，或者单模型降 effort 之后已经足够，就别去搭多模型。选型的第一步永远是先给当前模型扫一遍 effort；只有在确实发现能力缺口之后，才给更强的模型在 low effort 下单跑定价，把这个数字当作接下来所有分层方案的门槛。
这套推导可以用，但要记住它的成立条件：数据来自 Anthropic 官方的技术指南，用的是他们做的 benchmark、当时的 list price 和 5 分钟缓存。文档也明确写着这些测量只有方向性，别拿你自己的业务直接套用，要在自己真实流量上重测。
另一个层面是，这篇文章虽然给出技术建议，但它也是厂商自己的立场。Anthropic 在自己的官方选型指南里提到 tuning effort 往往比换模型更划算（“Tuning effort is often a better lever than switching models”）。这句话背后有两层。
从工程角度讲，这个费率和活动量、缓存读写、跨模型缓存断裂的分析是有道理的，它确实抓到了agent账单的主要来源，也解释了为什么长轮次上下文里降级模型常常得不偿失。
但从平台方的生意来看，effort 只是厂商在自己产品里定义的一个算力旋钮。不管你在 low 还是 high 上调节，你的计算和流量都在 Anthropic 这里。它推荐你用自家的模型，这样你花钱省、系统跑得好、还不会被带走。真正让厂商亏的事，不是你调一个模型的 effort 从 high 到 low，而是你把整个调度跑到别的模型、甚至开源上面。
那具体怎么落地呢？不是照单全收”不分层、调effort”这个结论。接受账单由工作量决定这个事实，然后在搭建多模型调度、切流量给便宜模型之前，先在你自己的业务里给主力模型画一条effort曲线。把它在low effort下的每任务开销当一条底线；任何分层方案，都得先在真实账本上证明能打赢这条不用付缓存断裂代价的单模型基线。