Claude 模型怎么选：Fable、Opus、Sonnet 还是 Haiku

Claude 的模型越来越多，该从哪款用起，什么时候值得升级？Addy Osmani 在 Claude 开发者博客里，把 Fable、Opus、Sonnet、Haiku 的任务分工、费用和混用方法放在一起讲清楚了。以下是全文翻译。

该选哪款 Claude 模型，各自要花多少钱，又该怎样搭配使用。

当前 Claude 产品线有四款普遍可用的模型：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，并把 effort 设为默认的 medium。

它成为 Claude Code 的默认模型是有原因的。它的输入和输出 token 单价都是 Fable 5.2 的一半；对于大多数编程和知识工作，我们都建议从它开始。

在此基础上：

• 范围清楚的日常工作，可以降到 Sonnet 5.5，比如修复 bug，或按明确规格开发功能。不过，规格清楚并不意味着一定该用 Sonnet。迁移或性能优化即便有清晰规格，仍可能难到需要 Opus 5.5；规模较大的任务，甚至需要 Fable 5.2。
• 最简单、调用量又大的工作，可以进一步降到 Haiku 5.5，比如分类、路由和信息提取。让子 Agent 分担大模型的辅助任务时，Haiku 5.5 也很合适。
• 编程、金融和科学领域最困难的技术项目，可以升到 Claude Fable 5.2。当 Opus 5.5 开到 high 仍达不到要求，或者需要长时间无人值守运行时，也可以升级。

换模型之前，先试着调整 effort。对于成本和能力，它是一个更细的调节旋钮。超过 high 后，再升一级的成本，可能已经相当于换用更大的模型，所以两种方案都应放到自己的工作上比较。如果已经超过 high，不妨试试更高一档模型配较低的 effort。反过来，effort 降一级，也可能以更低的费用拿到你需要的结果。

模型需要更长时间思考、调用更多工具，或者更充分地检查自己的工作时，提高 effort 会有帮助。但也要记住，这会增加延迟。另外，提高 effort 并不会赋予模型原本不具备的知识或技能。要补上这部分能力，仍然需要换更强的模型。

按任务选模型

四款模型放在一起看

以上为 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 下得分为 58.9%，消耗的 token 却只有一半。

在最难的工作上，价格差距可能缩小。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 的成本与智能水平测量也显示了小模型的局限。它们通常适合输出可检查的大批量工作，不太适合很长的 Agent 循环。

比较两款模型时，除了典型任务，也要给任务集中最难的那些任务算一笔账，因为它们可能占掉大部分开销。在一项包含 20 道题的搜索基准中，两道题就占了 43% 的费用。

延迟与准确率

更快的配置会更早完成任务，也可能漏掉更多东西。选择模型和 effort 之前，先想清楚用户能等多久。对于需要用户等待的回复，可以先从 Sonnet 5.5 的 low 或 medium 开始。

新一代模型通常比上一代更快。Fable 5.2 的输出生成速度比 Fable 5.1 最高快 30%；Sonnet 5.5 的运行速度比 Sonnet 5 快 30%。

effort 与延迟大体相关。你需要判断，准确率的提升是否值得额外等待。例如，在 SWE-bench Pro 上，Opus 5.5 的 medium 比 high 低约 2.5 个百分点，成本约为 high 的 70%；low 低约 8 个百分点，成本约为三分之一；xhigh 高约 1.4 个百分点，成本则是 high 的 2.5 倍。

很多时候，给模型提供自我验证的办法，比调整 effort 更划算，增加的延迟也更少。当模型还不能胜任任务时，按以下顺序尝试：

1. 确认模型能检查自己的工作，例如运行测试、执行构建，或运行调用目标端点的脚本。
2. 把 effort 提高一级。
3. 换到更高一档模型，起步 effort 设得比之前的小模型低一些。

如果可以自动检查结果，可以先把所有任务都设为较低的 effort，只把失败的任务拿到较高的 effort 重跑。在同一个 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 单价都是两倍。

《What a task costs on Opus 5.5》中算过，上下文为 150K token 时，一轮缓存读取约 $0.03；20K token 时约 $0.004。

由此可以得到一个启示：主模型越大，保持主上下文精简就越重要。把昂贵模型的上下文留给决策，让便宜的子 Agent 承担大量阅读。

Haiku 5.5 是唯一一款 token 单价随提示词长度变化的模型。不超过 100K token 的提示词按较低档计费，超过 100K 则按五倍的费率计费。即使进入长提示词档，它的 token 单价仍只有 Sonnet 5.5 的四分之一。因此，Haiku 5.5 在短提示词上的成本优势最大，输入单价只有 Sonnet 5.5 的二十分之一。

每次调用都需要很长的提示词时，比较 Haiku 5.5 和 Sonnet 5.5，应看完成一个任务的成本，而不是价目表上的单价。

搭配使用不同模型

在自然的阶段节点切换

提示词缓存属于创建它的模型。切换模型后的第一轮，整段对话都要按缓存写入价格计费。要缩小这一轮的输入，可以先在 Claude Code 中运行 /compact，或开启新会话，并提供一份简短的书面计划。使用 API 时，让新模型的对话从此前工作的摘要开始，而不是带上完整历史。

每个思考块都会记录生成它的模型，而每款模型只能读取部分其他模型的思考块。在 Claude API 和 Claude Models on Google Cloud（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 切换到其他任何普遍可用模型，都会丢失它的推理。

让子 Agent 使用较小的模型

子 Agent 在自己的上下文窗口里运行，最后返回摘要。它消耗的 token 按所用模型的价格计费。在 Claude Code 中，可以在子 Agent 定义里设置 model: haiku 或 model: sonnet。环境变量 CLAUDE_CODE_SUBAGENT_MODEL 则为未指定模型的子 Agent 设置默认值。

将下面的内容保存为 .claude/agents/log-reader.md：

---
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 子 Agent 使用会话所选模型，不再总是使用 Haiku。在 Claude API 上，它最高使用 Opus。要降低探索成本，可以自行定义一个名为 Explore 的子 Agent，并设置 model: haiku。还可以用 ANTHROPIC_DEFAULT_HAIKU_MODEL 固定 haiku 别名实际指向的模型。

在 Anthropic API 上，haiku 别名现在指向 Haiku 5.5，需要 Claude Code v2.1.293 或更新版本。在 Amazon Bedrock、Google Cloud、Microsoft Foundry 和 Claude Platform on AWS 上，它仍指向 Haiku 4.5。具体情况可参阅 Claude Code 的模型配置文档。

Claude Code 还有 opusplan 别名：在规划模式中用 Opus 制订计划，再由 Sonnet 执行。这意味着代码修改会由 Sonnet 完成。上面的建议恰好相反：把代码修改留给主模型，只让较小的模型做那些错误容易被发现的工作。将 opusplan 设为默认之前，先在自己的任务上测一测。

把困难决策交给顾问

顾问工具（advisor tool，beta）把速度更快、价格更低的执行模型与更强的顾问模型配在一起。执行模型负责运行任务，也可以在执行过程中向顾问求助。大部分 token 按执行模型的价格计费。只有顾问能补上执行模型缺少的能力，而且执行模型确实去咨询时，它才有帮助；effort 较低时，执行模型求助的频率也更低。

可能划算的场景，是大部分步骤都比较常规的 Agent 工作。平台成本指南对此持谨慎态度：顾问配对表中的四种组合，没有一种明显优于单独使用执行模型，而顾问也只有在被咨询时才帮得上忙。先测量执行模型实际向顾问求助的频率，也要检查它支持哪些顾问。例如，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，比单独使用 high 的 Opus 5.5 高 1.7 个百分点，费用却约为 2.1 倍。这样的增益接近不同运行间的波动幅度，也大致相当于提高 effort 所能带来的提升。

把大批量工作交给便宜的执行模型

前面说的子 Agent 模式，是由一个主模型保持整体线索，子 Agent 处理辅助任务。这里的模式则面向一个上下文窗口容纳不下的工作：由顶级模型统筹、拆分任务，把各部分并行交给许多更便宜的执行模型，再合并结果。在一项涉及约 2200 万 token 源代码的内部缺陷搜索基准中，Opus 5.5 统筹 Sonnet 5.5 执行模型，最多同时运行 25 个，成本比单独使用默认 effort 的 Opus 5.5 低约三分之一，得分大致相同。

在 Claude Platform 上，Claude Managed Agents 的多 Agent 编排提供一个协调 Agent 和一组执行 Agent。如果工作只有一条相互依赖的步骤链，或者一个上下文窗口就放得下，就不必使用它。这种情况下，规划和合并结果花的钱，会超过省下来的钱。《When to fold subagents into your main agent loop》讨论了什么时候一个 Agent 循环比子 Agent 团队更合适。

迁移前检查兼容性

选模型主要是在权衡能力与成本，但并不是任何时候都只改一个模型名称就行。这一代的所有模型都支持工具调用和图片输入，不过在把请求从一个模型迁到另一个模型之前，有些差异需要测试。

• Fable 5.2 将思考保留（preserved thinking）扩展到了所有 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 和 Claude Models on Google Cloud（Google 托管）上的 computer_toolset_20260801 工具集支持电脑操作。
• 从 Haiku 4.5 迁移到 Haiku 5.5。用 effort 等级替换 budget_tokens，删除非默认的 temperature、top_p 和 top_k 值，否则会返回 400 错误。让 messages 以用户轮次结尾；如果最后一轮是让模型继续补写的 assistant 消息，也会返回 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 报告。

延伸阅读

• 《Building with Claude Sonnet 5.5》介绍何时应选 Sonnet 而不是 Opus，以及价格、迁移和调优。
• 《Getting the most out of Opus 5.5 in Claude and Claude Code》介绍 Opus 5.5 的提示方法，以及怎样引导长时间运行。
• 《What a task costs on Opus 5.5》分析 effort、模型选择和子 Agent 的费用。
• Claude 博客中的《Choosing the best Claude model for your use case》和《Picking a model and effort level in Claude Code》有更深入的讨论。
• 文档部分可参阅《Choosing a model》《Optimizing for cost and intelligence》《Effort》，以及 Claude Code 的模型配置和子 Agent 文档。

参考链接

• 原文：https://claude.dev/blog/which-claude-model-should-you-build-with/
• Fable 5.2 产品页：https://www.anthropic.com/claude/fable
• 怎样分配 effort：https://claude.dev/blog/spending-your-effort/
• Fable 5.2 与 Mythos 5.2 发布文章：https://www.anthropic.com/claude-fable-and-mythos-5-2
• 成本与智能水平优化：https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence
• 快速模式：https://platform.claude.com/docs/en/build-with-claude/fast-mode
• Opus 5.5 长上下文编程会话：https://claude.com/blog/claude-opus-5-5-built-for-coding-sessions-that-use-more-context
• Opus 5.5 完成任务的成本：https://claude.dev/blog/what-a-task-costs-on-opus-5-5/
• 思考保留：https://platform.claude.com/docs/en/build-with-claude/preserved-thinking
• Claude Code 模型配置：https://code.claude.com/docs/en/model-config
• 顾问工具：https://platform.claude.com/docs/en/agents-and-tools/tool-use/advisor-tool
• 多 Agent 编排：https://platform.claude.com/docs/en/managed-agents/multiagent-orchestration
• 何时把子 Agent 并入主 Agent 循环：https://claude.com/resources/articles/building-agents-when-to-fold-subagents-into-your-main-agent-loop
• 使用 Claude Sonnet 5.5 开发：https://claude.dev/blog/building-with-claude-sonnet-5-5/
• 充分发挥 Opus 5.5 的能力：https://claude.dev/blog/getting-the-most-out-of-opus-5-5/
• 按用途选择 Claude 模型：https://claude.com/blog/claude-models-explained-choosing-the-best-model-for-your-use-case
• 在 Claude Code 中选择模型与 effort：https://claude.com/blog/claude-model-and-effort-level-in-claude-code
• 模型选择：https://platform.claude.com/docs/en/about-claude/models/choosing-a-model
• 成本与智能水平优化：https://platform.claude.com/docs/en/about-claude/models/optimizing-for-cost-and-intelligence
• effort 设置：https://platform.claude.com/docs/en/build-with-claude/effort
• Claude Code 子 Agent：https://code.claude.com/docs/en/sub-agents