Anthropic 博客作者 Addy Osmani：选 Claude 模型先调 effort 档位，再换模型

Anthropic 在 11 月 9 日发布的官方博客中给出了一个明确的起步建议：大多数编码和知识工作从 Opus 5.5 的 medium effort 开始。这不是因为 Opus 5.5 是最强的模型——Fable 5.2 才是——而是因为它在成本和能力的平衡点上。Opus 5.5 每百万 token 的输入输出价格是 4 美元和 20 美元，恰好是 Fable 5.2（8 美元和 40 美元）的一半。

但这篇博客真正值得注意的不是起步推荐，而是它提出的调节顺序。作者 Addy Osmani 写道，在换模型之前，先调 effort 档位。effort 是一个比模型切换更细的旋钮，同时控制成本和能力的变化幅度。超过 high 之后，再升一档的成本可能已经等于换一个大模型。反过来，降一档也可能得到你需要的结果，只是费率更低。

这个建议背后有具体的基准数据支撑。在 Anthropic 自测的 Terminal-Bench 3.0 上，上一代 Fable 5.1 在 max effort 下得分 58.0%，而 Opus 5.5 在 high effort 下得分 58.9%，用的 token 量只有前者的一半。在 FrontierCode 2.0 上，Fable 5.2 在 high effort 下得分 45.3%，与 Opus 5.5 在 max effort 下的 45.5% 基本持平，但每任务成本约为后者的一半。这些数据说明成本与能力的关系在任务层面不是线性的：更便宜的模型在更高 effort 下可以追平甚至超过更贵的模型。

在 SWE-bench Pro 上，Opus 5.5 从 medium 到 high 大约提升 2.5 分，成本增加约 43%（从 high 的 70% 升到 100%）；从 low 到 medium 大约提升 5.5 分，成本约为 low 的两倍（从 high 的三分之一升到 70%）。这意味着如果你当前在 medium 上遇到瓶颈，先试 high 往往比直接跳到 Fable 5.2 更划算。只有当 Opus 5.5 在 high effort 下仍然不够用时，才应该考虑升级到 Fable 5.2。

对于需要混合使用多个模型的场景，博客给出了一个核心原则：把子代理放在更便宜的模型上，把判断和代码编辑留在主模型上。子代理适合做搜索文件、跑测试、读日志这类工作——出错时容易发现，而且判断性的决策本来就由主模型来做。当模型不够用时，Osmani 建议按顺序执行：先确认模型能否自我验证（通过测试、构建或调用端点的脚本），再升一档 effort，最后才换到更大的模型并从更低的 effort 起步。在内部缺陷搜索基准上，Opus 5.5 作为主模型调度最多 25 个 Sonnet 5.5 工人处理约 2200 万 token 的源代码，成本比 Opus 5.5 单独运行低约三分之一，得分基本持平。