把最强模型设成所有请求的默认值，通常只是把预算问题藏起来；把最便宜模型当成“性价比最高”，则可能把钱花在重试、返工和人工检查上。Claude 当前四档模型更像四种运行策略，而不是一条从差到好的永久排名。
截至 2026 年 8 月 15 日，一个实用的起点是：高吞吐、低失败代价的任务先试 Haiku 4.5；需要稳定处理代码、分析、内容与工具调用时试 Sonnet 5；复杂、长时间 Agent 与企业工程先用 Opus 5 建立能力基线；只有任务确实卡在能力上限，才把 Fable 5 加入对照。最终保留的不是“名气最大”的模型，而是能以最低总成本持续通过你验收的模型。
先确认你比较的是模型，还是产品
claude-fable-5、claude-opus-5、claude-sonnet-5 和 claude-haiku-4-5-20251001 是 Claude API 的模型 ID。Claude 应用、Claude Code、Amazon Bedrock、Google Cloud 与其他入口会在这些模型外再叠加账户计划、模型选择器、工具、权限、限额和计费方式。
因此，两个问题不能混在一起：
- API 选型关心每百万 token 单价、上下文、输出上限、thinking 配置、延迟和请求成功率；
- Claude Code 或聊天产品选型还要看订阅计划、账户可见性、usage credits、客户端行为和工具链。
下表的价格只属于 Anthropic 直接 Claude API 的标准 token 价，不是 Pro、Max 或第三方网关的承诺。你的账户里看不到某个模型时，先查产品与计划，而不是从 API 文档推断自己一定能用。
四档当前规格会怎样改变决策
Anthropic 的 current models overview 给出的现行对照如下：
| 当前模型 | 标准输入 / 输出价 | Context / 最大输出 | 官方定位 | 先验证什么 |
|---|---|---|---|---|
| Haiku 4.5 | $1 / $5 | 200K / 64K | 最快、近前沿能力 | 大批量简单任务是否已达到质量线 |
| Sonnet 5 | $2 / $10 | 1M / 128K | 速度与能力的平衡 | 日常复杂任务能否一次通过 |
| Opus 5 | $5 / $25 | 1M / 128K | 复杂 Agent 编码与企业工作 | 更深推理是否减少人工纠偏 |
| Fable 5 | $10 / $50 | 1M / 128K | 广泛发布模型中的最高能力 | 能力提升是否覆盖两倍 Opus 单价 |
单位都是每百万输入/输出 token 的美元价格。Sonnet 5 的价格尤其需要注意日期：Anthropic 旧 pricing 表仍保留“9 月涨到 $3/$15”的历史安排，但 Sonnet 5 公告在 2026 年 8 月 10 日更新，说明 $2/$10 已改为永久价格；更新后的英文 model overview 也使用 $2/$10。迁移或上线前仍应重新核对官方页面。
表格只能帮你删掉明显不合适的候选。200K context 不够，就不能只因为 Haiku 便宜而硬塞；任务每天要跑百万次，也不能无视 Fable 的单价。更常见的情况是 Haiku 与 Sonnet、Sonnet 与 Opus 之间存在重叠，答案必须来自你的数据。
Thinking 配置让“只换模型名”变得危险
四个模型并不共享完全相同的推理控制方式。Fable 5 的 adaptive thinking 永远开启；Opus 5 与 Sonnet 5 默认使用 adaptive thinking，并通过 effort 控制深度；Haiku 4.5 支持可选的 manual extended thinking，但不接受 adaptive 模式。
这会产生真实迁移故障。把 Haiku 的 thinking: { type: "enabled", budget_tokens: ... } 原样带到 Sonnet 5，可能返回 400；Sonnet 5 也不接受非默认的 temperature、top_p 或 top_k。同时，Sonnet 5 的 tokenizer 与前代不同，相同文字可能产生更多 token，旧版本的预算不能直接复用。Anthropic migration guide 列出了各迁移方向的差异。
生产换模至少要重新检查：
- 使用准确模型 ID，而不是把无日期 ID 当成自动升级的
latest； - thinking、effort、sampling 与
max_tokens是否兼容； - 同一批 prompt 的实际 input、thinking 和 output token；
- 工具调用、流式响应、拒绝和 fallback 是否仍按预期处理；
- P50/P95 延迟、超时与重试率有没有改变。
模型 ID 与版本说明 明确指出，4.6 及之后的无日期 ID 仍是固定快照，不是会自动换权重的常青别名。
不按“最强”选，按失败代价选
如果任务错一次只会进入自动复核队列，先从便宜模型开始更合理；如果错误会合并坏迁移、生成错误财务分析或让 Agent 连续运行数小时，应该先从更强模型建立能力基线，再向下找省钱空间。
Haiku 4.5 适合边界明确、吞吐量大、延迟敏感的分类、抽取、短摘要和子代理任务。前提是你能自动发现错误，并且 200K context 与 64K 输出足够。
Sonnet 5 是很多日常 API 工作负载的自然候选：代码生成、数据分析、内容处理、视觉理解与工具调用都在官方定位范围内。它的价值不是“永远第二强”，而是在速度、1M context 和 $2/$10 之间提供更宽的可用区间。
Opus 5 值得用于复杂系统工程、大范围重构、多小时自主编码、深层推理和高失败代价任务。Opus 5 说明 还提醒：thinking 默认开启，xhigh 或 max effort 需要为 max_tokens 留出足够空间。更高 effort 不是免费质量按钮，它同时影响 token 与延迟。
Fable 5 是能力上限候选，面向长时间 Agent、复杂研究和需要持续判断的任务。Anthropic 的 Fable 5 发布说明 称其为最强的广泛发布模型，同时披露更严格的安全分类器可能误拦一小部分无害请求。对于可能触及安全边界的工作负载，拒绝与 fallback 必须进入验收和成本记录。
用 8 到 20 个真实样本算“合格结果成本”
官方的 model selection guide 建议用自己的 prompts 与 data 做评估。一个可操作的做法是从线上或历史工单抽取 8 到 20 个有明确验收标准的任务，覆盖常见、困难和边缘情况。
所有候选使用相同输入、工具、权限、时间盒和停止条件。不要一边给 Opus 完整上下文，一边让 Haiku 猜缺失文件；也不要把 Claude Code 的成熟工具链与一段裸 API 调用伪装成纯模型对比。
每次运行至少保存这些数据：
| 记录 | 合格定义 |
|---|---|
| 任务结果 | 通过测试、schema、事实核对或人工 rubric，而不是“给出了回答” |
| 总 token | input、cache、thinking、output 分开，使用实际 usage |
| 时间 | 首次完整通过验收的墙钟时间与 P95，而非首 token 时间 |
| 摩擦 | 超时、拒绝、工具错误、无效循环、fallback 与重启 |
| 人工 | 澄清、审批、手改、审查和恢复上下文所花时间 |
| 返工 | 上线前后因错误撤回或重做的次数与成本 |
最终比较：
每次合格结果成本 =（模型费用 + 人工成本 + 返工成本）÷ 通过验收的任务数
如果 Haiku 单次调用只要 Sonnet 的一半，但需要两倍重试，它未必更便宜；如果 Fable 单价是 Opus 的两倍，却只在一两个极难任务上改善结果，就应只路由那些任务，而不是替换全量流量。
一个更稳的上线办法
新系统可以从两端选一种起点。成本敏感、能自动验收时，从 Haiku 开始，只有明确能力缺口才升级；错误代价高、任务复杂时，从 Opus 建立可接受结果，再逐步降低 effort 或换到 Sonnet/Haiku。两种路径都比根据模型名字直接下注更容易解释。
上线时保留一个小比例的挑战流量，并设置能观察到的升级条件，例如 schema 连续失败、工具循环超过阈值、事实置信不足、上下文超过容量或任务进入高风险队列。先让路由规则来自失败数据，再考虑多模型编排。
如果你的真正问题是 Claude Code 与 Codex 的权限、界面、团队工作流和订阅额度，而不是四个 API 模型本身，请转到 Claude Code vs Codex。如果是 API 选型，先在 Anthropic Console 用同一批小样本跑 Haiku/Sonnet 或 Sonnet/Opus 两档；只有结果没有达到验收线时，再把更高一档加入对照。
