多数复杂任务先试 Claude Opus 5.5。按 2026 年 9 月 23 日的 Claude 直接 API 标准价格，它的新输入、输出、缓存写入和缓存读取单价都低于 Fable 5.1。Fable 5.1 值得保留在候选名单里：当你的高难推理或长时间 Agent 任务，在 Opus 5.5 提高 effort 后仍达不到验收标准，再用相同任务比较 Fable 的通过率、时间和总成本。这也是 Anthropic 当前的模型选择建议所给出的顺序。
这个结论针对按 token 计费的 Claude 直接 API 标准模式。它不等于 Claude Pro、Max 或 Claude Code 的订阅额度，也不能直接套用到 Fast、Batch、云平台或第三方网关。下面先把四档型号的位置说清，再拆开价格与能力证据。
四档 Claude 模型，先按任务选起点
| 起点 | 适合先试的任务 | 什么时候往上看 | 标准 API 新输入 / 输出，美元每百万 token |
|---|---|---|---|
| Haiku 4.5 | 大批量分类、抽取、短响应，失败容易自动识别 | 准确率或复杂步骤达不到验收线 | $1 / $5 |
| Sonnet 5 | 日常编码、数据处理、内容与一般工具调用 | 多步骤任务反复失败，或人工修复过多 | $2 / $10 |
| Opus 5.5 | 复杂编码、研究和需要持续推进的 Agent；也是本文两款模型的默认试跑起点 | 调高 effort 并优化任务后仍有明确能力缺口 | $4 / $20 |
| Fable 5.1 | 对高难推理、长时间 Agent 有更高能力要求，且已有任务集能验证收益 | 用合格任务成本决定是否保留，而非只看型号等级 | $10 / $50 |
价格来自 Anthropic 费率表，任务定位参照官方选型指南。这张表给的是起点，不是“Haiku 一定能完成抽取”或“Fable 一定比 Opus 更准”的承诺。真正的分界线是你的失败模式：可批量验证的简单任务先压低单次成本；需要复杂推理时从 Opus 5.5 建立基线；只有基线不足才支付 Fable 的溢价。
Opus 5.5 与 Fable 5.1：价格差已经没有缓存反转
两款模型的直接 API ID 分别是 claude-opus-5-5 和 claude-fable-5-1。官方规格均列出 100 万 token 上下文窗口与标准模式 12.8 万 token 最大输出。价格须按同一种计费入口、同一类 token 比较：
| 标准 Claude 直接 API，美元／百万 token | Opus 5.5 | Fable 5.1 |
|---|---|---|
| 未缓存的新输入 | $4 | $10 |
| 输出 | $20 | $50 |
| 5 分钟缓存写入 | $5 | $12.50 |
| 1 小时缓存写入 | $8 | $20 |
| 缓存读取 | $0.20 | $0.25 |
数据见 Anthropic 价格页。在各类 token 用量相同且为正的前提下，Opus 5.5 的 token 账单一定更低。尤其是缓存读取，旧版 Opus 5 的 $0.50 高于 Fable 5.1 的 $0.25；换成 Opus 5.5 的 $0.20 后，不能继续套用旧文中“读缓存够多，Fable 就更便宜”的临界式。
例如，一组请求共使用 10 万未缓存输入、2 万输出和 20 万缓存读取，没有缓存写入或其他费用。按表内每百万 token 单价计算，Opus 5.5 是 0.1×4 + 0.02×20 + 0.2×0.20 = $0.84；Fable 5.1 是 0.1×10 + 0.02×50 + 0.2×0.25 = $2.05。这是相同用量的算账例子，并非两款模型运行同一任务的实测账单。模型可能生成不同长度、调用不同次数工具，甚至产生不同的重试次数。
有两组常见数字不能混用：Opus 5.5 的新输入、输出和缓存写入标价比 Opus 5 低 20%；Anthropic 报告的典型任务成本低约 40%，同样是与 Opus 5 比，且包含 token 用量变化。发布说明没有说它比 Fable 5.1 的真实任务成本固定低 40%。此外，Opus 5.5 Fast 是另一档价格，不能拿其延迟优势与标准模式的 $4/$20 混算。
能力怎么比：公开分数能提示方向，不能代替你的验收
Anthropic 的 Opus 5.5 发布资料给出 Terminal-Bench 4.0 的 66.4% 对 55.8%，以及 CursorBench 4.0 的 57.8% 对 51.8%（前者均为 Opus 5.5，后者为 Fable 5.1）。这些是有测试环境和设置的厂商报告，不是本文复现的结果。特别是 Opus 5.5 的表格成绩大多使用 max effort，Terminal-Bench 使用 xhigh；不能把这些分数当作默认 medium 的通过率，再与默认模式价格拼成一条“质量更高且成本更低”的实测结论。
API 默认 effort 也不同：Opus 5.5 为 medium，Fable 5.1 为 high，见选型指南。做自己的对照时，先记录各自默认设置的结果，再单独记录提高 Opus effort 后的结果；不要把不同设置的费用、延迟和通过率塞进同一行。对于你自己的任务，“更强”应表现为更高的验收通过率、更少的人工返工，或在约定时限内完成更困难的工作。
从 Opus 5.5 升级到 Fable 5.1，先找出失败在哪里
拿一批真实任务做小规模试跑：包含常见请求、复杂请求和曾经失败的边缘案例，输入、工具权限、超时与停止条件保持一致。每项任务写出可核验的终点，如测试通过、结构化输出能通过 schema、引用与原文一致，或 Agent 实际完成操作。只统计 HTTP 200、模型自称“已完成”，会高估可用性。
对每个配置记录首次通过率、重试后通过率、失败原因、墙钟时间、实际新输入／缓存写入／缓存读取／输出 token、工具费用，以及审核和返工时间。然后比较：
每个合格任务成本 =（API 与工具费用 + 重试费用 + 人工审核和返工成本）÷ 合格任务数
若 Opus 5.5 在默认 medium 已稳定通过，就没有仅凭型号名称升级的理由。若失败集中在复杂推理或长时间任务，先优化提示和工具流程，再提高 Opus 的 effort；到 xhigh 或 max 仍不达标，才按官方建议测试 Fable 5.1。Fable 单次 token 更贵，但如果它减少足够多的失败、重试或人工修复，合格结果的总成本仍可能更低。是否发生这种反转，只能用你的任务数据回答。
接入前，核对版本和计费入口
新项目应在请求和用量记录里写清模型 ID，避免把旧 claude-opus-5 的缓存价格留在预算表中。已有集成迁往 Opus 5.5 时，还要检查 thinking、强制工具选择、计算机使用工具等兼容变化；Opus 5.5 迁移说明承接具体改法。Fable 5.1 专题可用于核对其规格与接入条件。
最后把报价入口分开：本文数字是标准 Claude 直接 API。Batch、Fast、美国限定推理、Bedrock、Google Cloud 或其他平台可能采用不同价格；Claude 订阅套餐还有各自的使用额度规则。先确定自己实际付费的入口，再拿对应费率和真实 usage 复算，才能决定让 Haiku、Sonnet、Opus 或 Fable 承担哪一类请求。
