Article · AI translation
目前 Claude 产品线有 4 款普遍可用的模型：Claude Haiku 5.5、Claude Sonnet 5.5、Claude Opus 5.5 和 Claude Fable 5.2。Claude Mythos 5.2 是我们在网络安全和生命科学研究方面能力最强的模型，可通过我们的验证计划使用。
如果你基于 Claude Platform 开发，或在 Claude Code 中工作，可能会想知道常见任务该用哪个模型。本文将帮助你回答这个问题，并理解其中的取舍。
简而言之
简短的答案是：大多数工作都应该从 Opus 5.5 开始，使用其默认的中等投入程度。
它成为 Claude Code 默认模型是有原因的。它每个输入和输出 token 的成本都是 Fable 5.2 的一半，也是我们建议用于大多数编程和知识工作的起始模型。
在此基础上：
对于范围明确的日常工作，例如修复漏洞或按规格说明开发功能，可改用 Sonnet 5.5。不过，规格说明清晰并不意味着就该使用 Sonnet。迁移或性能优化也可能有清晰的规格说明，但仍然难到需要使用 Opus 5.5；如果是大型项目，则可能需要 Fable 5.2。
对于分类、路由和信息提取等最简单的大批量工作，可进一步改用 Haiku 5.5。Haiku 5.5 也适合用于处理较大模型附带任务的子代理。
对于编程、金融和科学领域最困难的技术项目，可升级到 Claude Fable 5.2。如果 Opus 5.5 在高投入程度下仍无法胜任，或者需要长时间无人值守地运行，也可升级。
在更换模型之前，先试着调整投入程度。这是调节成本和能力的更精细方式。超过高投入程度后，再提高一个等级的成本可能与换用更大的模型相当，因此请结合自己的工作比较两者。如果已超过高投入程度，就测试以较低投入程度使用更高一级的模型。反过来，降低一个等级也可能以更低的成本获得所需结果。
当模型需要思考更久、调用更多工具或更充分地检查自己的工作时，提高投入程度会有所帮助。但请记住，这也会增加延迟。此外，提高投入程度无法赋予模型原本不具备的知识或技能。要获得这些能力，仍需升级模型。
按任务选择模型
任务 起始模型 起始投入程度 原因
日常工程开发与调试；涉及多个 PR 的功能开发 Opus 5.5 中等（默认），然后提高至高 在日常任务中平衡成本与能力。
分类、路由、标记和大批量信息提取 Haiku 5.5 中等（默认） 该模型系列中成本和延迟最低。
搜索文件、读取日志或进行总结的子代理 Haiku 5.5 或 Sonnet 5.5 模型默认值 错误答案容易发现，而且需要判断的事项终归由主模型处理。
聊天和交互式会话 Sonnet 5.5（如果是大批量的简单聊天，则用 Haiku 5.5） 低或中等 Sonnet 5.5 速度快，尤其是在低或中等投入程度下。
范围明确的编程任务，如修复漏洞、迭代功能和按规格说明开展工作 Sonnet 5.5 中等，较难的任务则提高至高 它能很好地处理范围明确的任务，而每个 token 的价格只有 Opus 5.5 的一半。
日常文档、幻灯片和电子表格 Sonnet 5.5 高（默认；在 Claude Code 中为中等） 它迭代速度快，也有很强的设计眼光。对于复杂的财务模型，或需要根据大量源材料制作的文档，请从 Opus 5.5 开始。
反复运行的代理任务，例如调查、审查或起草 Sonnet 5.5 中等 定义明确且重复执行的任务通常不需要更大的模型。
计算机操作和大量使用视觉能力的工作流程 Opus 5.5 中等 这些任务需要在大量屏幕截图和图像之间进行长时间的代理循环，属于 Opus 5.5 专为之设计的长时间代理工作。
大型重构与迁移、架构规划，以及领导多个子代理 Fable 5.2 中等，然后提高至高（API 默认值为高） 它是 Anthropic 在技术领域能力最强的普遍可用模型。
深度研究，以及科学或定量分析 Fable 5.2 中等，然后提高至高（API 默认值为高） 它专为编程、金融和科学领域最困难的技术项目而打造。
你还不确定：Opus 5.5，medium（默认）。Claude Code 在 Pro、Max、Ultra、Team、Enterprise 和 Anthropic API 上默认使用它，平台文档也建议以它作为起点。
4 款模型并排对比
Haiku 5.5 Sonnet 5.5 Opus 5.5 Fable 5.2
适用于：大批量、成本敏感的任务；为范围明确的任务提供快速、可靠的帮助；我们处理复杂编码和知识工作的日常主力；最具挑战性、开放式的技术工作
相对延迟：最快；快；中等；中等
每百万 token 的输入／输出价格：提示词不超过 100K token 时为 $0.10／$0.50，超过 100K 时为 $0.50／$2.50；$2／$10；$4／$20；$8／$40
每百万 token 的缓存读取价格：不超过 100K 时为 $0.01，超过 100K 时为 $0.05；$0.10；$0.20；$0.20
上下文窗口：1M token；1M token；1M token；1M token
最大输出：128K token；128K token；128K token；128K token
API 上的思考模式：自适应，默认开启，可以关闭；自适应，默认开启，between_tools 会跳过前期思考；自适应，始终开启；自适应，始终开启
API 上的默认努力程度（Claude Code 可能不同；/effort status 可显示你的设置）：medium；high（Claude Code 中为 medium）；medium；high（Claude Code 中为 medium）
快速模式：否；否；是；是
以上价格为 Claude API 标价。基准测试结果见 Fable 5.2 页面。
权衡取舍
选择模型时，你也在做取舍。例如，选择更大的模型，意味着你选择能力而非低延迟。以下是需要考虑的主要权衡。
能力与每项已完成任务的成本
一般来说，较大的模型每 token 成本更高、能力也更强，但从任务层面看，成本与能力之间的这种权衡并非总是成立。
每 token 价格更高，并不一定意味着每项任务的成本更高，或结果更好。正如我们在《Spending your effort》中所展示的，在 Anthropic 运行的 Terminal-Bench 3.0 测试中，上一代 Fable 5.1 在 max 设置下得分为 58.0%，而 Opus 5.5 在 high 设置下以一半的 token 用量取得了 58.9% 的得分。
对于最难的工作，价格差距可能缩小。在 FrontierCode 2.0 上，Fable 5.2 在 high 设置下的得分与 Opus 5.5 在 max 设置下大致相当（45.3% 对 45.5%），而每项任务的成本约为后者的一半。因此，在困难任务上将 Opus 5.5 的努力程度提高到 high 以上之前，先测试 Fable 5.2。对于日常工作，Opus 5.5 的 medium 设置仍是起点。基准测试结果见发布文章。
不过，Claude Platform 对成本和智能水平的测量也显示了小模型的局限。小模型通常适合输出可检查的大批量工作，但不太适合长时间的智能体循环。
比较 2 个模型时，除了典型任务，也要计算任务集中最难任务的成本，因为最难的任务占了大部分开支。在一项包含 20 道题的搜索基准测试中，其中 2 道题占了总开支的 43%。
延迟与准确率的权衡
速度更快的配置能更早完成任务，但也可能出现更多遗漏。选择模型和努力程度之前，先考虑用户能等待多久。对于需要用户等候的回复，可以从 Sonnet 5.5 的 low 或 medium 设置开始。
新一代模型通常比前代更快。Fable 5.2 生成输出的速度比 Fable 5.1 最多快 30%。Sonnet 5.5 的运行速度比 Sonnet 5 快 30%。
努力程度与延迟大致相关。需要判断准确率的提升是否值得额外的延迟。例如，在 SWE-bench Pro 上，与 high 努力程度设置相比，Opus 5.5 在 medium 设置下得分低约 2.5 个百分点，成本约为其 70%；在 low 设置下得分低约 8 个百分点，成本约为其 1/3；在 xhigh 设置下得分高约 1.4 个百分点，成本为 high 的 2.5 倍。
提供自我验证的方法，往往比调整努力程度更具成本效益，增加的延迟也更少。当模型不足以胜任某项任务时，请按以下顺序采取措施：
检查模型能否通过测试、构建或调用端点的脚本来验证自己的工作。
将努力程度提高 1 级。
换用高 1 档的模型，并从低于你在较小模型上所用设置的努力程度开始。
如果可以自动检查结果，就先以低档位运行所有任务，只对失败的任务以高档位重新运行。在同一个 SWE-bench Pro 子集上，Opus 5.5 先以低档位运行、再以高档位重跑失败任务，以每项约 $0.17 的成本通过了约 97% 的任务；相比之下，所有任务都以高档位运行时，通过率为 95.3%，每项成本为 $0.29。
如果需要同一模型更快回复，可以付费提速，而不必牺牲能力。在 Claude API 上，Opus 5.5 和 Fable 5.2 都提供快速模式，以更高的价格换取更快的输出速度。
上下文与成本的权衡
当前这一代的每个模型都有 100 万 token 的上下文窗口。长上下文有助于模型完成任务，但每一轮都会重新发送上下文，因此每轮都要付费。尽管如此，在长时间运行中，大部分输入通常按缓存读取计费。
Opus 5.5 的缓存读取费用为每 100 万 token $0.20，Sonnet 5.5 为 $0.10。Fable 5.2 的缓存读取费用同样是 $0.20，因此在大量使用缓存的长时间运行中，Fable 与 Opus 的成本差距主要来自未缓存的输入和输出，而 Fable 在这两项上的每 token 成本是 Opus 的 2 倍。
在《What a task costs on Opus 5.5》中，上下文为 150K token 时，一轮的缓存读取费用约为 $0.03；为 20K token 时，费用约为 $0.004。
由此可以得出的一个结论是：主模型越大，保持主上下文精简就越重要。让昂贵模型的上下文用于决策，让更便宜的子智能体处理冗长的阅读工作。
Haiku 5.5 是唯一一个 token 价格随提示长度变化的模型。提示不超过 100K token 时按较低档位计费，超过 100K 时按该费率的 5 倍计费。长提示档位的每 token 价格仍只有 Sonnet 5.5 的 1/4。因此，Haiku 5.5 在短提示下最划算，此时其输入价格仅为 Sonnet 5.5 的 1/20。
如果每次调用都需要长提示，应按每项已完成任务的成本比较 Haiku 5.5 与 Sonnet 5.5，而不是只看标价。
混合使用模型
在自然的间歇点切换
提示缓存归写入它的模型所有。切换到新模型后的第 1 轮，需要为整个对话支付缓存写入费用。要缩短这一轮的上下文，可以先在 Claude Code 中运行 /compact，或带着一份简短的书面计划开启新会话。在 API 上，应以迄今工作内容的摘要开启新模型的对话，而不是提供完整历史记录。
每个思考块都会记录生成它的模型，而每个模型只能读取部分其他模型的思考块。在 Claude API 和 Google Cloud 上的 Claude Models（由 Google 管理）中，Opus 5.5 可以读取 Sonnet 5.5 和 Haiku 5.5 的思考块；Sonnet 5.5 可以读取 Haiku 5.5 的思考块；Fable 5.2 可以读取 Opus 5.5、Sonnet 5.5 和 Haiku 5.5 的思考块。在 Claude API 上，Fable 5.1 可以读取 Opus 5.5 的思考块。
向下切换档位会丢失先前的推理，因为模型绝不会读取更高档位模型的思考块。其他切换也可能导致推理丢失。当新模型无法读取先前模型的思考块时，API 会丢弃这些思考块，但请求仍会成功。随后，新模型将在没有这些推理的情况下工作。
《Preserved thinking》列出了所有情况。从 Fable 5.2 切换到任何其他正式发布的模型，通常都会丢失其推理。
让子智能体使用较小的模型
子智能体在自己的上下文窗口中运行，并返回一份摘要。其 token 按所用模型的费率计费。在 Claude Code 中，在子智能体的定义中设置 model: haiku 或 model: sonnet。CLAUDE_CODE_SUBAGENT_MODEL 环境变量为未指定模型的子智能体设置默认模型。
将其保存为 .claude/agents/log-reader.md：
让小模型处理容易发现错误的工作，例如查找文件、运行测试和阅读日志。代码修改和需要判断的工作则交给主模型。小模型误读搜索结果时，主模型会打开错误的文件，并为此消耗 token。
在当前版本的 Claude Code 中，内置的 Explore 子代理使用你当前会话所用的模型运行，而不再总是使用 Haiku。在 Claude API 上，该模型的上限是 Opus。要降低探索成本，请自行定义一个名为 Explore、设置为 model: haiku 的子代理。你可以通过 ANTHROPIC_DEFAULT_HAIKU_MODEL 固定 haiku 别名所使用的模型。
在 Anthropic API 上，haiku 别名现在指向 Haiku 5.5，这需要 Claude Code v2.1.293 或更高版本。在 Amazon Bedrock、Google Cloud、Microsoft Foundry 和 AWS 上的 Claude Platform 中，它仍指向 Haiku 4.5。详情见 Claude Code 的模型配置文档。
Claude Code 还有 opusplan 别名：它在计划模式下用 Opus 制定计划，然后用 Sonnet 执行计划。这会让 Sonnet 负责修改代码。上述建议则反过来：让主模型负责修改代码，只把出错后容易发现的问题交给较小的模型。在将 opusplan 设为默认选项之前，请先在自己的任务上衡量其效果。
将棘手决策升级交由顾问处理
顾问工具（测试版）将速度更快、成本更低的执行模型与能力更强的顾问模型配对。执行模型运行任务，并可在中途向顾问寻求指导。大部分 token 按执行模型的费率计费。只有当顾问具备执行模型所缺少的能力，且执行模型主动征询意见时，顾问才能提供帮助；执行模型在低推理强度下征询意见的频率较低。
可能划算的场景：大多数轮次都是常规操作的智能体任务。平台的成本指南态度谨慎：在其顾问配置表列出的 4 种配对中，没有一种明显优于单独使用相应执行模型，而且只有执行模型咨询顾问时，顾问才能发挥作用。先衡量你的执行模型咨询顾问的频率，并检查它支持哪些顾问。例如，Sonnet 5.5 执行模型支持 Fable 5.2、Opus 5.5、Opus 5 和 Sonnet 5.5 作为顾问，而 Fable 5.2 执行模型只支持 Fable 5.2 或 Mythos 5.2。
收效不大的场景：在一项内部编码基准测试中，其中一种配对以高推理强度的 Opus 5.5 作为执行模型、Fable 5.1 作为顾问。它的得分为 90.1%，每次尝试花费 2.92 美元。与单独使用高推理强度的 Opus 5.5 相比，得分高出 1.7 个百分点，费用却约为其 2.1 倍。这样的提升处于不同次运行间波动的边缘，而且与提高推理强度可能带来的提升大致相当。
将大批量工作委派给成本更低的工作模型
前述子代理在一个主模型维持对话脉络的同时处理辅助任务。这里的模式适用于工作量超过一个上下文窗口的任务：由顶级模型领头，拆分任务，把各部分并行交给许多成本更低的工作模型，再合并返回的结果。在一项涉及约 2200 万 token 源代码的内部缺陷搜索基准测试中，由 Opus 5.5 领头、Sonnet 5.5 充当工作模型（同时最多 25 个）的方案，成本比单独使用默认推理强度的 Opus 5.5 低约三分之一，得分则大致相同。
在 Claude Platform 上，Claude Managed Agents 中的多智能体编排提供一个协调智能体和一组工作智能体。如果任务只是一串相互依赖的步骤，或者能放进一个上下文窗口，就无需采用它。在这些情况下，规划和合并的成本超过所节省的成本。《何时将子代理并入主智能体循环》介绍了何时单个智能体循环比一组子代理效果更好。
迁移前检查兼容性
模型选择主要取决于能力和成本，但并非总能只改模型名称而不改其他内容。当前所有模型都支持工具使用和图像输入，但在将请求从一个模型迁移到另一个模型前，仍有一些差异需要测试。
Fable 5.2 将保留的思考内容扩展到所有 API 账户。如果 Fable 5.2 的某个思考内容块之前的任何内容发生变化，包括系统提示词、工具或更早的消息，API 就会以 400 错误拒绝请求，除非你选择允许丢弃受影响的思考内容。如果你通过 Claude Code、Claude Agent SDK 或 Claude Managed Agents 构建请求，就无需做任何更改。如果你自己的代码会编辑历史记录，请确保只在末尾追加，并在切换前进行测试。
思考。Opus 5.5 和 Fable 5.2 始终会进行思考，关闭思考的请求会返回错误。Sonnet 5.5 默认会进行思考，between_tools 会将思考限制在工具调用之间。Haiku 5.5 默认会进行思考；在 high 或更低的 effort 级别下，你可以关闭思考。对于所有这些模型，都应按类型读取内容块，因为响应可能以思考块开头。
强制使用工具。在 Sonnet 5.5、Opus 5.5 和 Fable 5.2 上，将 tool_choice 设为 any 或 tool 会返回 400 错误。应发送 auto，将工具标记为 strict: true，并在提示词中说明何时使用该工具。
计算机使用。Opus 5.5、Sonnet 5.5、Haiku 5.5 和 Fable 5.2 仅通过 Claude API 和 Google Cloud 上的 Claude Models（由 Google 管理）中的 computer_toolset_20260801 工具集支持计算机使用。
从 Haiku 4.5 迁移到 Haiku 5.5。用 effort 级别替换 budget_tokens，并移除非默认的 temperature、top_p 和 top_k 值，否则会返回 400 错误。消息应以用户轮次结束，因为以供模型续写的助手最终轮次结束也会返回 400 错误。
安全回退。Opus 5.5、Sonnet 5.5 和 Fable 5.2 运行安全分类器，最常标记网络安全和生物学内容。在 Claude Code 中，被标记的请求可能会在较旧的模型上重新运行，记录中的通知会告知你使用了哪个模型。Fable 5.2 沿用 Fable 5.1 使用的回退模型。被标记的网络安全请求会回退到 Opus 4.8，被标记的生物学请求会回退到 Opus 5。
如果一个系统运行多个模型，应按其中要求最严格的模型构建每个请求：保持历史记录只追加，发送带有 strict 工具的 tool_choice: auto，按类型读取内容块，并将提示词和工具描述写得足够精确，以适应理解最为字面的模型。这样，一个步骤就可以在不同档位之间升降，而无需修改代码。当路由规则很简单时，例如每种步骤类型对应一个模型，应让代码选择模型，而不是让模型来选。
用自己的工作进行测量
上文的 SWE-bench Pro 和 Terminal-Bench 等已发布结果可以帮助你选定初始模型。然后，在决定采用之前，用自己的任务测试候选模型。
抽取一批真实任务作为样本。为每项任务编写结果检查标准，例如测试通过、工单关闭或行数正确。
让每个候选模型分别以 2 或 3 个 effort 级别运行，每次运行都使用独立会话，以免共享缓存。根据每条响应的 usage 字段记录每项已完成任务的成本。
绘制得分与支出的关系图。只有当多模型配置优于图上每一个单模型结果点时，才保留它。
正式切换之前，先让胜出的方案在部分真实流量上以影子模式运行。
要在 Claude Code 中快速检查，可用 /model 在 2 个模型上运行待办任务中的同一项任务，并比较 /usage 报告的结果。
了解更多
《使用 Claude Sonnet 5.5 构建应用》介绍何时选择 Sonnet 而非 Opus，以及定价、迁移和调优。
《在 Claude 和 Claude Code 中充分发挥 Opus 5.5 的能力》介绍如何为 Opus 5.5 编写提示词，以及如何引导长时间运行的任务。
《一项任务在 Opus 5.5 上的成本》分析 effort、模型选择和子代理的成本。
在 Claude 博客上，《为你的用例选择最佳 Claude 模型》和《在 Claude Code 中选择模型与 effort 级别》提供了更深入的介绍。
在文档中，请参阅《选择模型》、《优化成本与智能水平》、《Effort》、《Claude Code 模型配置》和《子代理》。