Anthropic 指南：Claude 开发该选 Haiku 5.5、Sonnet 5.5、Opus 5.5 还是 Fable 5.2

目前 Claude 产品线有四款正式可用的模型：Claude Haiku 5.5、Claude Sonnet 5.5、Claude Opus 5.5 和 Claude Fable 5.2。Claude Mythos 5.2 是我们在网络安全与生命科学研究方面能力最强的模型，需通过我们的验证计划使用。

如果你在 Claude 平台上开发，或者日常使用 Claude Code，可能会想知道常见任务该选哪个模型。本文就来回答这个问题，并聊聊该如何权衡取舍。

太长不看

简单说：大多数工作都应该从 Opus 5.5 的默认努力档位开始，medium。

它成为 Claude Code 默认模型是有原因的。每输入、输出 token 的成本只有 Fable 5.2 的一半，也是我们建议大多数编程和知识工作优先尝试的模型。

在此基础上：

• 范围明确的日常工作，比如修 bug 或按规格实现功能，可以降到 Sonnet 5.5。不过，规格清晰不代表就该用 Sonnet：迁移或性能优化同样可以有清晰的规格，但难度依然足以用 Opus 5.5，大型任务则用 Fable 5.2。
• 最简单、量大的工作，比如分类、路由和抽取，可以再降到 Haiku 5.5。Haiku 5.5 也很适合作为子智能体，替更大的模型处理旁支任务。
• 编程、金融和科学领域最难的技术项目，则要升到 Claude Fable 5.2。当 Opus 5.5 在 high 下仍不够用，或者需要长时间无人值守运行时，也应当升级。

换模型之前，先试试调整努力档位。在成本和能力上，这都是更精细的旋钮。超过 high 之后，再升一档努力的成本可能抵得上换更大的模型，所以要在自己的任务上把两者都测一测。如果已经超过 high，不妨改用更高一级模型、更低一档努力来测试。反过来，降一档努力也可能以更低的成本拿到你需要的结果。

当模型需要思考更久、调用更多工具或更多次检查自己的工作时，提高努力档位会有帮助。但要记住，这也会增加延迟。另外，提高努力档位不会让模型凭空获得它没有的知识或技能；要补上这些，还是得换更强的模型。

按任务选模型

四款模型横向对比

价格为 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 平台的成本与智能测量也显示了小模型的局限。它们通常擅长输出可核验的高并发工作，但不太适合长时间的智能体循环。

对比两个模型时，除了典型任务，也要把最难的几个任务单独算价，因为花费大头都在最难的任务上。在一个 20 道题的搜索基准测试里，两道题就占了 43% 的花费。

延迟与准确率

更快的配置完成得更早，但也可能漏掉更多。选定模型和努力等级之前，先想清楚人能等多久。对于需要人等待的回复，Sonnet 5.5 从 low 或 medium 起步。

新一代模型通常比前代更快。Fable 5.2 的生成速度比 Fable 5.1 快最多 30%。Sonnet 5.5 比 Sonnet 5 快 30%。

努力等级与延迟大致相关。要判断多出来的准确率是否值得额外的延迟。例如在 SWE-bench Pro 上，Opus 5.5 在 medium 档的得分比 high 档低约 2.5 分，成本约为后者的 70%；在 low 档得分低约 8 分，成本约为三分之一；在 xhigh 档得分高约 1.4 分，成本是 high 档的 2.5 倍。

通常，提供自我验证的手段比调整努力等级更划算，增加的延迟也更少。当模型不足以完成任务时，按以下顺序处理：

1. 确认模型能自行验证结果，比如用测试、构建，或调用接口的脚本。
2. 把努力等级提高一档。
3. 换用更高一级的模型，起步的努力等级比在小模型上用的更低。

如果能自动检查结果，就让所有任务都在低等级下运行，只把失败的任务用高等级重跑。在同一个 SWE-bench Pro 子集上，Opus 5.5 在 low 档运行、失败任务用 high 档重跑，通过率约 97%，每题约 $0.17；而所有任务都用 high 档时通过率 95.3%，每题 $0.29。

如果想让同一个模型回复得更快，可以花钱买速度，而不必牺牲能力。在 Claude API 上，Opus 5.5 和 Fable 5.2 都提供快速模式，输出速度更高，价格也更贵。

上下文与成本

当前这一代模型都有 1M token 的上下文窗口。大上下文有助于模型完成任务，但每一轮都会产生成本，因为每轮都要重新发送。话虽如此，在长时间运行中，大部分输入都按缓存读取计费。

Opus 5.5 的缓存读取价格为每百万 token $0.20，Sonnet 5.5 为 $0.10。Fable 5.2 同样是 $0.20，所以在缓存占比很高的长时间运行中，Fable 与 Opus 的差距就落在未缓存输入和输出上，而 Fable 每 token 的价格是 Opus 的两倍。

在Opus 5.5 上任务要花多少钱一文中，上下文为 150K token 时，一轮的缓存读取成本约 $0.03；20K 时约 $0.004。

由此可以得出一点：主模型越大，精简主上下文就越重要。把昂贵模型的上下文留给决策，让更便宜的子智能体去做冗长的阅读。

Haiku 5.5 是唯一按提示词长度分档计价的模型。不超过 100K token 的提示词按较低档计费，超过 100K 则按五倍费率计费。长提示词档的价格仍是 Sonnet 5.5 每 token 价格的四分之一。所以 Haiku 5.5 在短提示词上最划算，其输入价格只有 Sonnet 5.5 的二十分之一。

如果每次调用都需要长提示词，就比较 Haiku 5.5 和 Sonnet 5.5 的每完成一个任务的成本，而不是标价。

混合使用模型

在自然的断点处切换

提示词缓存归属于写下它的那个模型。在新模型上的第一轮对话，整段对话都要按缓存写入的价格计费。想让这一轮更省，可以在 Claude Code 里先运行 /compact，或者开一个新会话，先写一份简短的计划。在 API 上，开启新模型的对话时，用一份到目前为止的工作摘要代替完整历史。

每个思考块都会记录生成它的模型，而每个模型只能读取部分其他模型的思考块。在 Claude API 和 Google Cloud 上的 Claude 模型（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 会丢弃这些块，请求仍然成功。新模型随后就在没有那段推理的情况下继续工作。

保留思考列出了所有情况。从 Fable 5.2 切换到任何其他正式可用模型，一般都会丢失它的推理。

把子智能体放到更小的模型上

子智能体在自己的上下文窗口中运行，最后交回一份摘要。它的 token 按所运行模型的费率计费。在 Claude Code 中，可以在子智能体的定义里设置 model: haiku 或 model: sonnet。环境变量 CLAUDE_CODE_SUBAGENT_MODEL 为没有指定模型的子智能体设置默认值。

把它保存为 .claude/agents/log-reader.md：

CODEMarkdown

---
name: log-reader
description: Reads test output and logs, and reports each failing case. Use after a test run.
tools: Read, Grep, Glob, Bash
model: haiku
---

Read the logs you're given. For each failure, report the file, the test name and the first error line. Don't edit any files.

小模型只用来做错了也容易发现的工作，比如查找文件、运行测试、读日志。代码修改和需要判断的事留给主模型。小模型一旦误读搜索结果，主模型就会打开错误的文件，白白消耗 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。

把困难决策交给顾问

顾问工具（beta）把一个更快、更便宜的执行模型和一个更强的顾问模型配成一对。执行模型负责任务，中途可以向顾问寻求指导。大部分 token 按执行模型的价格计费。只有当顾问能补上执行模型欠缺的能力、且执行模型主动求助时，顾问才发挥作用；而在低 effort 下，执行模型求助的频率更低。

可能划算的场景：大部分轮次都是常规操作的智能体任务。平台的成本指南态度谨慎：其顾问表里的四组搭配中，没有一组明显胜过单用执行模型，而且顾问只有在执行模型咨询它时才能帮上忙。先测量执行模型的咨询率。确认执行模型接受哪些顾问。例如 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 执行模型在 high 下配 Fable 5.1 顾问，跑一个内部编程基准。得分 90.1%，每次尝试花费 2.92 美元。比单用 Opus 5.5 在 high 下高 1.7 个百分点，花费约为 2.1 倍。这种幅度的提升已接近运行间噪声的边缘，大致相当于提高 effort 能换来的收益。

把批量工作交给更便宜的 worker

上文提到的子智能体负责处理支线任务，同时由一个主模型保持主线。这种模式针对的是超出单个上下文窗口的工作。由顶级模型牵头，拆分任务，把各块并行交给许多更便宜的 worker，再合并返回的结果。在一个约 2200 万 token 源代码的内部缺陷搜索基准上，Opus 5.5 牵头、Sonnet 5.5 作为 worker（最多同时 25 个），成本比单用 Opus 5.5 在默认 effort 下低约三分之一，得分大致相当。

在 Claude Platform 上，Claude Managed Agents 中的多智能体编排提供一个协调者智能体和一组 worker。如果只是一条有依赖关系的步骤链，或者工作能装进一个上下文窗口，就不要用它。在这些场景里，规划和合并的开销超过省下的成本。何时把子智能体并入主智能体循环讨论了单个智能体循环何时胜过一组子智能体。

迁移前先检查兼容性

模型选择主要是能力和成本的问题，但你不能总是只改模型名、其他什么都不动。当前所有模型都支持工具调用和图像输入，但在把一个请求从一个模型迁到另一个模型之前，有些差异需要测试。

• 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 或更低时可以关闭思考。对所有这些模型，都要按 type 读取内容块，因为响应可能以思考块开头。
• 强制使用工具。在 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 上的 computer_toolset_20260801 工具集以及 Google Cloud 上的 Claude Models（Google 托管）支持计算机使用。
• 从 Haiku 4.5 迁移到 Haiku 5.5。将 budget_tokens 替换为 effort 级别，并去掉非默认的 temperature、top_p 和 top_k 值，这些值会返回 400 错误。以用户轮次结束 messages，因为让模型继续的最终助手轮次也会返回 400 错误。
• 安全回退。Opus 5.5、Sonnet 5.5 和 Fable 5.2 运行安全分类器，最常标记网络安全和生物学内容。在 Claude Code 中，被标记的请求可以在较旧的模型上重新运行，转录中的通知会告诉你使用的是哪个。Fable 5.2 保留 Fable 5.1 使用的回退模型。被标记的网络安全请求回退到 Opus 4.8，被标记的生物学请求回退到 Opus 5。

如果一个系统运行多个模型，请为其中最严格的模型构建每个请求：保持历史记录仅追加，使用严格工具发送 tool_choice: auto，按 type 读取内容块，并精确编写提示词和工具描述，以满足最字面的模型。这样，步骤可以在不更改代码的情况下向上或向下移动一个层级。当路由规则很简单时，例如每种步骤类型一个模型，让代码选择模型，而不是让模型选择。

在你自己的工作上进行测量

已发布的结果，如上面的 SWE-bench Pro 和 Terminal-Bench 数字，可以为你提供一个起始模型。然后在提交之前，在你自己的任务上测试候选模型。

1. 抽取真实任务的样本。为每个任务编写结果检查，例如通过的测试、关闭的工单或正确的行数。
2. 以两到三个 effort 级别运行每个候选模型，每个都在自己的会话中运行，以便运行不共享缓存。从每个响应的 usage 字段记录每个已完成任务的成本。
3. 绘制分数与支出的关系图。仅当多模型设置在该图表上优于每个单模型点时，才保留它。
4. 在切换之前，在真实流量的一小部分上以影子模式运行获胜者。

要在 Claude Code 中快速检查，请使用 /model 在两个模型上运行你积压中的一个任务，并比较 /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 模型配置 和 子智能体。