Claude Code 最佳模型
日常编码从 Sonnet 5 开始，复杂或高风险工作升级到 Opus 5，最难的长时任务再用 Fable 5.1，范围明确的辅助工作交给 Haiku 4.5。
对多数日常仓库工作来说，Claude Code 最佳模型是 Claude Sonnet 5。它是效率优先的默认选择：响应快、能力强、原生支持 100 万 token 上下文，而且 token 单价低于 Opus 和 Fable。如果正确性比吞吐量更重要，或者任务模糊、涉及架构、出错代价高，就直接从 Claude Opus 5 开始。范围窄且有明确验收方法的工作用 Claude Haiku 4.5；要求极高、周期很长并且 Opus 仍无法完成的任务再用 Claude Fable 5.1。
这是一套任务路由策略，不是通用排行榜。Anthropic 的通用模型指南建议多数工作从 Opus 5 起步；Claude Code 的别名说明则把 Sonnet 定位为日常编码模型，把 Opus 定位为复杂推理模型。本文面向希望优化“每个合格改动成本”的读者，因此把 Sonnet 作为日常默认；能力优先的团队从 Opus 开始也完全合理。
如果要比较不同服务商的低成本档位，请看 Claude Haiku 4.5 和 GPT-5.6 Luna 编程对比。它把 Claude Code 协议适配与 token 单价分开，并按合格任务成本比较，不声称存在通用赢家。
事实核查：2026 年 9 月 8 日。 本文是基于资料的选型指南，依据 Anthropic 当前的模型、Claude Code 配置、价格、成本、subagent 与网关文档，以及 OmniaKey 当前目录源码。我们没有运行四模型受控 benchmark，因此下文是可复现的起始策略，不是“某个模型在所有仓库都获胜”的实测结论。
Claude Code 最佳模型速查
| 模型 | 在 Claude Code 中最适合的任务 | 上下文 | Anthropic 输入 / 输出 | OmniaKey 输入 / 输出 |
|---|---|---|---|---|
| Claude Sonnet 5 | 日常编码、功能开发、常规调试、多数 subagent | 1M | $2 / $10 | $0.84 / $4.20 |
| Claude Opus 5 | 架构、隐蔽 bug、大范围重构、高代价故障 | 1M | $5 / $25 | $1.40 / $7 |
| Claude Fable 5.1 | 高难度推理与最长时间的自主工作 | 1M | $10 / $50 | $2.80 / $14 |
| Claude Haiku 4.5 | 快速搜索、分类、摘要、小型机械任务 | 200K | $1 / $5 | $0.28 / $1.40 |
价格单位均为每百万输入 / 输出 token 的美元，不含 prompt cache、长上下文、fast mode 或工具费用。Anthropic 和 OmniaKey 是不同的计费边界：OmniaKey 一栏是 2026 年 9 月 8 日核查的仓库目录报价，不是根据 Anthropic 当前官方价格计算出的折扣，也不是 Anthropic 订阅额度。安排生产预算前，请到模型目录确认当前路由与价格。
如果今天只采用一条规则：效率优先时默认用 Sonnet 5，再按任务升级。最佳模型不是 benchmark 数字最大的模型，而是能稳定交付合格改动且总成本最低的模型。
为什么 Sonnet 5 是最佳日常默认模型
Anthropic 把 Sonnet 5 描述为速度与智能的最佳组合，Claude Code 的 sonnet 别名也面向日常编码。它适合作为以下任务的起点：
- 实现范围明确且有清晰验收条件的功能；
- 在少量文件中追踪熟悉的错误；
- 随代码改动一起编写或更新测试；
- 审查范围聚焦的 pull request；
- 把已经确定的设计实现为代码；
- 通过 subagent 协调常规仓库调查。
Sonnet 5 原生支持 1M 上下文，因此选择它不再意味着放弃当前 Opus 与 Fable 的长上下文。但上下文容量不等于模型能力。100 万 token 可以装下更多证据，却不能保证模型一定找到正确架构或隐蔽故障。
需要固定评测版本时，请使用准确模型 ID：
/model claude-sonnet-5
不带日期的 Claude 5 API ID 也是固定 snapshot。Claude Code 别名仍可能按服务商解析成不同版本，也会随推荐变化；准确 ID 更容易复现实验。
什么时候应该升级到 Claude Opus 5
当任务最昂贵的部分是推理而不是打字时，选择 Claude Opus 5。典型信号包括：
- bug 跨越多个服务，而且最直观的解释是错的；
- 仓库陌生，需求还留下重要设计选择；
- 架构或迁移决策一旦出错就很难回滚；
- 大型重构必须保留散落在多个文件中的隐式行为；
- 安全、账务或数据完整性错误的修正代价很高；
- Sonnet 已拿到相关上下文并认真尝试，却仍然得出错误结论。
Opus 5 的 token 更贵，但 token 单价不等于完成任务的成本。困难任务中，更强模型可能用更少的失败循环和人工修正交付合格结果。对于验收标准精确的单文件修改，这种优势可能没有发挥空间。
/model claude-opus-5
Anthropic 的能力优先方案会让多数工作从 Opus 5 开始，再向下优化。遗漏边界情况的代价很高时，这是一套合理策略。公开证据、effort 行为、迁移说明和限制详见 Claude Opus 5 评测；如果只需在两款模型间选择，请看 Claude Opus 5 和 Sonnet 5 对比。
Fable 5.1 什么时候值得溢价
Claude Fable 5.1 是 Anthropic 已广泛发布模型中能力最强的一款。Claude Code 把 Fable 家族定位为处理“大于一次工作时段”的任务：长时间自主会话、高难度推理，以及需要先调查再行动并持续验证的工作。
因此 Fable 5.1 是专家型号，不是常规默认。以下情况值得测试：
- Opus 5 已认真尝试，根因调查仍然没有结论；
- Opus 5 使用
xhigh或max后仍无法通过高难度评测； - 工作必须在数小时、多种工具和多类产物之间保持连贯；
- 失败代价足够高，而且你的评测数据证明溢价值得。
不要只因为仓库文件多就支付 Fable 价格。清晰范围、聚焦上下文和可靠验收测试通常比模型档位更重要。只有问题本身触及 Opus 的能力边界时，Fable 才体现价值；提示词写得不清楚不是升级理由。
/model claude-fable-5-1
Fable 5.1 需要 Claude Code v2.1.255 或更高版本。除非手动覆盖，fable 别名会解析到 Fable 5.1；v2.1.255 之前它解析到 Fable 5。Fable 从来不是任何账户类型的默认模型，选择器是否显示还取决于组织、服务商和 usage credits 可用性。
Claude Fable 5.1 评测与 API 指南详细说明了始终开启的 adaptive thinking、更低的 cache read 价格、迁移限制和准确 ID。只有刻意评测旧版本时，才需要查看之前的 Fable 5 模型页和 Fable 5 价格指南。
Haiku 4.5 适合放在哪里
Claude Haiku 4.5 是 Anthropic 当前对比中速度最快的模型，上下文为 200K。任务范围窄、成功条件明确且错误容易被发现时，它很合适：
- 主智能体开始前查找文件或符号；
- 汇总范围有限的日志或测试输出；
- 按已知分类体系整理 issue；
- 在确定性测试保护下做重复修改；
- 回答上下文中现有代码的聚焦问题。
如果一个小错误会导致多次昂贵重试，Haiku 就不再经济。它遗漏跨文件关系、误解陌生领域或需要反复纠正时应立即升级。当前模型表没有为 Haiku 4.5 提供与其它三款相同的 effort 控制，因此不要假设它能像 Sonnet、Opus 或 Fable 一样调节。
可以在专用轻量 subagent 的 frontmatter 中指定模型：
---
name: quick-researcher
description: Finds files and summarizes evidence for a scoped repository question
model: haiku
---
没有填写 model 时，Claude Code subagent 会继承主会话模型。把范围明确的调查固定为 haiku，可以避免每次委派搜索都使用主会话的 Opus 或 Fable 档位。普通实现或审查 subagent 更适合从 Sonnet 开始。
模型与 effort 要解决不同问题
模型选择和 effort 解决的不是同一种失败。Fable 5.1、Opus 5 和 Sonnet 5 都支持 adaptive thinking 与 effort 控制；当前 Claude API 对三者的默认值都是 high。从默认值开始，并且每次只改变一个变量。
问题本身太难时换模型。 Claude 已拿到相关文件、工具和说明，也认真调查过，却仍然得出错误结论，此时应从 Haiku 升到 Sonnet、Sonnet 升到 Opus，或 Opus 升到 Fable。
当前模型需要更深推理时提高 effort。 任务需要更多规划、长时分析或验证时再提高。更高 effort 可能提高完成率，也会增加延迟和输出 token 成本。
两者之前先修上下文。 模糊需求、过期的 CLAUDE.md、缺失文档或不可用工具，不能靠消耗更多 token 稳定解决。先提供清晰的成功条件和必要证据。
Anthropic 当前选型指南指出，调整 effort 往往比更换模型更有效。请在自己的工作负载上验证：如果更高 effort 的 Opus 仍不能通过验收，Fable 5.1 才是下一能力档。
best、fable 与 opusplan 到底选什么
Claude Code 别名使用方便，但并不都是固定模型 ID。
| 选择方式 | 当前行为 |
|---|---|
sonnet | 当前服务商配置的最新 Sonnet；面向日常编码 |
opus | 当前服务商配置的最新 Opus；面向复杂推理 |
fable | 最新 Fable；除非覆盖，目前是 Fable 5.1 |
best | 最新的可用 Fable；不可用时退回与 opus 相同的选择 |
opusplan | 计划模式使用 Opus，执行阶段使用 Sonnet |
| 准确 API ID | 当前服务商提供该模型时，固定到请求的 snapshot |
直连 Anthropic API 时，opus 和 sonnet 当前分别解析到 Opus 5 与 Sonnet 5。其它服务商可能把这些别名解析到旧版本。网关会改变请求目的地，也可以定义自己的模型选项；它不会让别名自动成为跨服务商保证。
交互式会话可以为了方便使用别名。评测、自动化、事故复现，以及必须记录实际运行模型的场景，都应使用准确 ID。
一套可执行的模型路由策略
按任务边界切换，不要每几轮就换一次模型：
- 日常功能与维护从 Sonnet 5 的默认 effort 开始。
- 小而独立、输出可确定验证的 subagent 使用 Haiku 4.5。
- 如果任务一开始就很模糊、涉及架构或失败代价高，直接使用 Opus 5。
- 如果失败原因是推理深度不足，先提高 Opus effort，再支付 Fable 溢价。
- 只有高难度任务或内部评测证明有必要时才使用 Fable 5.1。
- 困难决策解决、后续执行变得机械后再切回 Sonnet。
长会话中切换模型可能降低 prompt cache 复用率，让下一轮更慢、更贵。尽量在干净的任务边界切换。开始无关工作时，/clear 通常比把旧会话带到新模型更合适。
用合格改动比较模型，不凭印象
要管理这个指标背后的上下文和会话成本，可参考降低 Claude Code token 消耗指南。它说明如何减少反复携带的上下文，又不把评测任务人为变简单。
公平的本地评测必须固定仓库状态、提示、工具、权限、effort 与验收测试。建立一组能代表真实工作的任务：
| 任务类型 | 示例 | 记录指标 |
|---|---|---|
| 常规修改 | 新增经过验证的字段和测试 | 通过率、延迟、修正时间 |
| 调试 | 复现并修复隐蔽回归 | 根因、重试次数、是否跑测试 |
| 重构 | 跨 package 修改接口 | 漏掉的调用点、构建结果 |
| 审查 | 检查包含已知缺陷的改动 | 有效召回、误报 |
| 架构 | 提出可回滚迁移方案 | 约束覆盖、决策质量 |
| Subagent | 搜索并汇总限定证据 | 准确率、token、响应时间 |
智能体输出有随机性，每个任务应运行多次。记录验收结果、人工修正分钟数、总耗时、输入 token、cache token、输出 token 与工具调用。token 单价高一倍的模型仍可能有更低的合格改动成本；便宜模型能通过同一测试时，它才是该任务类型更好的选择。
第一轮对比不要同时改变模型和 effort。先固定默认 effort 比较模型，再对准备采用的模型测试不同 effort。否则无法判断差异来自模型能力还是推理预算。
在 OmniaKey 上切换模型
接入步骤见 Claude Code 配置指南。Anthropic 兼容端点配置完成后，用 /model 选择准确且受支持的 ID：
/model claude-haiku-4-5
/model claude-sonnet-5
/model claude-opus-5
/model claude-fable-5-1
如果当前模型没有出现，请升级 Claude Code：Sonnet 5 需要 v2.1.197 或更高版本，Opus 5 需要 v2.1.219 或更高版本，Fable 5.1 需要 v2.1.255 或更高版本。运行 claude update，重新打开模型选择器，并在在线模型目录确认路由。
需要可复现结果时，请请求准确模型并检查响应中的模型与用量，不要假定别名行为或静默 fallback。可用性会随服务商、组织和路由变化；出错时应停止执行，不能把错误当成“另一模型已完成任务”的证据。
Claude Code 是为 Claude 模型设计的。Anthropic 表示网关可以代理受支持的 API 格式，但不支持通过网关把 Claude Code 路由到非 Claude 模型。如果要在 Claude、GPT 或 Gemini 之间选择，应使用支持目标协议的智能体。更广的型号问题见编码智能体模型家族指南，产品选择见 Claude Code vs Codex 对比。
如果要直接比较两款日常均衡模型，请看 Claude Sonnet 5 和 GPT-5.6 Terra 编程对比。它把模型选型与 Claude Code、Codex 的智能体选型分开处理。
最终建议
对希望优化日常吞吐与成本的多数开发者来说，Claude Sonnet 5 是 Claude Code 最佳默认模型。任务一开始就模糊或出错代价高时直接用 Opus 5，范围明确的辅助工作用 Haiku 4.5；只有 Opus 在合适 effort 下仍无法通过的长时高难度工作才升级到 Fable 5.1。
把它当成初始路由策略，最终阈值应由你自己的合格改动数据决定。
常见问题
Claude Code 最佳模型是什么？
多数日常编码以效率为先时，Claude Sonnet 5 是最佳默认模型。复杂架构、隐蔽调试和高代价故障若以能力为先，Claude Opus 5 更适合作为起点。Fable 5.1 面向最难的长时工作，Haiku 4.5 适合简单且范围明确的任务。
Claude Code 用 Opus 一定比 Sonnet 好吗？
不一定。Opus 在困难和模糊任务上能力更强，Sonnet 在常规工作中更快、更便宜。Anthropic 通用模型指南让多数工作从 Opus 开始；Claude Code 则把 Sonnet 标为日常编码模型。应根据失败代价选择，并用合格改动衡量。
应该使用 Fable 5.1 还是 Fable 5？
新评测应使用 Fable 5.1。它是更新版本，当前受支持客户端的 fable 别名会解析到它，而且基础输入 / 输出价格不变、cache read 成本更低。只有需要复现旧模型结果时才固定 Fable 5。
大型仓库都应该使用 Fable 5.1 吗？
不应该。仓库规模本身不足以证明 Fable 值得。先提供聚焦上下文并测试 Sonnet 或 Opus，只有问题确实漫长、模糊并超过便宜模型能力时再评测 Fable。
Claude Code subagent 应该使用什么模型？
范围窄、检查标准明确的搜索、分类和摘要用 Haiku；实现、审查和协调从 Sonnet 开始。只有 subagent 自己的任务也需要高能力时，才继承 Opus 或 Fable。
更高 effort 等于更好的模型吗？
不等于。模型决定能力上限，effort 决定受支持模型投入多少推理。模型在合适 effort 下认真尝试仍解决不了时再升级；任务只是需要更深分析时，应先提高 effort。
Claude Code 能使用 GPT 或 Gemini 模型吗？
不能。Anthropic 明确把 Claude Code 设计为使用 Claude 模型，也不支持通过网关路由到非 Claude 模型。需要 GPT 或 Gemini 时应选择 Codex、Cursor、Cline、aider 等兼容智能体。
已核查来源
以下官方来源均为英文页面。