Claude Opus 5 vs Claude Fable 5：Fable 值得多花一倍吗？
这个结论不是“Opus 5 全面打败 Fable 5”。Anthropic 仍把 Fable 5 定义为广泛发布模型中的最高能力档，同时把 Opus 5 定位为复杂智能体编程与企业工作的起始选择。真正改变的是举证责任：按照 Anthropic 公布的基础 Token 单价，Fable 是 Opus 的两倍，因此现在应该由 Fable 在具体工作负载中证明额外能力可以赚回溢价。
Claude Opus 5 vs Fable 5：30 秒完成选择
| 你的情况 | 默认选择 | 什么时候改变选择 |
|---|---|---|
| 大多数复杂编程、代码审查、浏览器操作和企业任务 | Opus 5 | 某个任务簇连续未通过验证，再测试 Fable |
| 长时间、极限难度、失败后会丢失大量工作的智能体 | Opus 5 起步，保留 Fable 升级 | 回放数据证明 Fable 明显提高整条 trace 的验收率 |
| 高价值研究、规划或审查 | Opus 5 完成主任务，Fable 做选择性独立复核 | 复核节省的人工时间或风险高于模型溢价 |
| 高频、可自动验证的执行任务 | Opus 5 或更低成本模型 | 不要因为任务“看起来复杂”就默认使用 Fable |
| 需要零数据留存或更严格留存策略 | 优先核对 Opus 5 路由 | Fable 5 的官方渠道有额外留存要求 |
| 网络安全、生物或容易触发分类器的任务 | 先确认授权与路由政策 | 不要把 fallback 返回结果误计为 Fable 表现 |
最实用的初始政策是：
低成本模型处理常规任务
↓ 验证失败
Opus 5 处理高难度任务
↓ 仍失败 / 任务价值极高
Fable 5 升级或独立复核
↓
人工确认与可回滚结果这不是永久架构。它只是一个比“所有困难任务都用最贵模型”更容易验证的起点。
先确认你在哪个入口做选择
Opus 5 vs Fable 5 同时包含三种搜索意图。如果不先区分入口，文章很容易答非所问。| 使用入口 | 用户真正要决定什么 | 本文给出的答案 |
|---|---|---|
| Claude App | 聊天或一次性复杂任务应该点哪个模型 | 日常高难度工作先用 Opus；只有明显需要最高能力时再用 Fable |
| Claude Code 或其他 Coding Agent | 实现、调试、规划、审查分别用哪个 | Opus 负责大多数实现与工具执行；Fable 只在已测任务上做升级、规划或复核 |
| API 与 Agent 平台 | 默认路由、成本、监控和回滚怎么设计 | 使用任务级路由，不要把单一模型硬编码为所有流量的永久默认值 |
本文重点服务第三类生产团队，也覆盖第二类 Coding Agent 选型。Claude App 的套餐额度、默认模型和产品内限制会变化，不在这里展开。
Opus 5 发布后，真正改变了什么
Anthropic 在 2026 年 7 月 24 日发布 Opus 5，并明确把它描述为接近 Fable 5 能力、但价格只有一半的日常高端模型。与此同时，Fable 5 仍被定义为 Anthropic 能力最强的广泛发布模型，面向最困难推理和长周期智能体。
这两个定位并不矛盾：
- “最高能力” 描述模型家族的能力上限；
- “默认选择” 描述综合质量、成本、延迟、限制和可控性后的生产起点；
- “最适合你的任务” 只能由匹配工作负载的评测决定。
Opus 5 还拥有更新的可靠知识截止时间。Anthropic 当前模型表记录 Opus 5 为 2026 年 5 月，Fable 5 为 2026 年 1 月。对快速变化的框架、软件包和 API，这可能减少一部分过时知识问题，但不能替代联网检索、代码库事实或外部验证。
只比较会改变生产决策的规格
| 维度 | Claude Opus 5 | Claude Fable 5 | 选型影响 |
|---|---|---|---|
| Anthropic 定位 | 复杂智能体编程与企业工作的起始选择 | 广泛发布模型中的最高能力档 | 先用 Opus，再要求 Fable 证明增量价值 |
| 官方基础 Token 单价 | 输入 $5 / 输出 $25 每百万 Token | 输入 $10 / 输出 $50 每百万 Token | Fable 的基础费率为 2× |
| 上下文与最大输出 | 100 万 / 12.8 万 Token | 100 万 / 12.8 万 Token | 容量相同，真实长上下文质量仍需测试 |
| 可靠知识截止时间 | 2026 年 5 月 | 2026 年 1 月 | Opus 对近期开发知识可能更有优势 |
| 相对延迟 | 中等 | 较慢 | 交互式工作更适合从 Opus 开始 |
| Adaptive thinking | 默认开启；effort 不高于 high 时可关闭 | 始终开启，不能关闭 | Opus 对低推理请求更可控 |
| Effort | low、medium、high、xhigh、max | 支持 effort 控制 | 不匹配 effort 的结果不能直接判胜负 |
| Fast mode | Claude API 研究预览，官方费率翻倍 | 不作为本次基础对比项 | 需要速度时应单独核算，不能混入基础价格 |
| 数据留存 | Anthropic 称一般接入无模型特定留存要求 | 官方记录 30 天留存且不支持零数据留存 | 治理要求可能直接排除 Fable |
| 分类器与拒绝 | 官方预计比 Fable 少约 85% 干预 | 有额外分类器和拒绝处理 | 高限制任务要把拒绝与 fallback 纳入验收 |
这些是 Anthropic 渠道的模型事实，不自动等同于每个网关、云平台、地区或合同条款。部署时应以组织实际使用的 EvoLink 路由和合同为准。
如何读懂 Opus 5 与 Fable 5 的评测
发布首日最容易犯的错误，是把每张图都读成“Opus 赢了 Fable”。正确做法是同时查看任务、effort、成本口径、fallback 和证据来源。
| 证据 | 配置与来源 | 可以支持什么 | 不能证明什么 |
|---|---|---|---|
| CursorBench 3.2 | Anthropic 发布评测；Opus 5 max 与 Fable 峰值比较 | Opus 在该编码 harness 中接近 Fable，且每任务成本约为一半 | 所有仓库、工具栈和 Coding Agent 都能持平 |
| OSWorld 2.0 | Anthropic 发布评测 | Opus 在受测计算机操作任务上具备很强的成本效率 | 每个浏览器或桌面工作流都更快、更可靠 |
| Frontier-Bench v0.1 | Anthropic 内部运行；发布脚注说明两模型拒绝时可由 Opus 4.8 fallback | Opus 在该 harness 与成本区间表现强 | 原始请求模型独立完成了每个计分任务 |
| ARC-AGI-3 30.16% | ARC Prize 验证 Opus 5 high effort | Opus 在该新颖问题评测取得经验证成绩 | 与 Fable 的直接胜负；公开验证表没有匹配 Fable 行 |
| Artificial Analysis 当前模型页 | 当前可见组合为 Opus Low 与 Fable Max，并显示 Fable fallback | 提供独立的价格、延迟与能力观察 | 同 effort、同路由条件的公平对决 |
| 发布后的用户讨论 | 少量早期真实体验 | 帮助提出“规划、调查、执行、审查是否应分工”等测试假设 | 稳定的普遍模型行为 |
编程与智能体应该怎样分配工作
“编程能力”不是一个任务。生成实现、查根因、规划、多工具执行和最终审查，对模型的要求不同。
| 工作负载 | 建议默认 | 升级或拆分条件 | 应监测什么 |
|---|---|---|---|
| 仓库级功能实现 | Opus 5 | 测试持续失败或需要重新设计总体方案 | 测试通过率、越界改动、修复次数 |
| Bug 定位与根因分析 | Opus 5 | 多次推翻假设、影响范围很大或错误成本极高时测试 Fable | 首个正确根因、无效调查步骤、回归缺陷 |
| 代码审查 | Opus 5 | 高风险合并可增加 Fable 独立二审 | 真阳性、误报、重复问题、人工复核时间 |
| 多 Agent 规划与编排 | Opus 5 起步 | 长 trace 反复偏航时，测试 Fable 规划或最终合并审查 | 计划返工、子任务冲突、状态丢失 |
| 子 Agent 批量执行 | Opus 5 或更低成本模型 | 单个任务验证失败时再升级 | 每个成功子任务成本、重试率 |
| 浏览器与计算机操作 | Opus 5 | 关键步骤无法恢复或持续卡在工具循环 | 步骤完成率、恢复率、总操作数 |
| 长文档研究与综合 | Opus 5 | 高价值交付可用 Fable 做独立反证 | 引用正确性、遗漏、人工核验时间 |
| 长时间自主智能体 | Opus 5 + checkpoint | 失败会丢失数小时工作，且回放证明 Fable 更稳定 | checkpoint 恢复、工具循环、完整验收率 |
社区早期讨论提出了一种值得测试的分工：让 Fable 负责规划、困难调查或最终复核，让 Opus 负责大部分实现和工具执行。这是合理的评测假设，但目前不是可直接推广的事实。团队应先确认这种拆分是否真的降低总成本，而不是因为调用了两个高端模型反而增加延迟和上下文传递损耗。
Fable 值得 2× 成本的临界点
官方基础费率正好是两倍，但生产经济不能只看费率。先从一个严格简化的模型开始：
每个可验收任务的模型成本 = 每次尝试成本 ÷ 首轮验收率C，Fable 为 2C，那么 Fable 仅靠模型调用成本取胜，需要满足：Fable 验收率 ÷ Opus 验收率 > Fable 单次成本 ÷ Opus 单次成本
即：Fable 验收率 > 2 × Opus 验收率| 假设场景 | Opus 验收率 | Fable 验收率 | Opus 每个验收结果 | Fable 每个验收结果 | 模型成本结论 |
|---|---|---|---|---|---|
| 高频实现任务 | 80% | 90% | 1.25C | 2.22C | Fable 约高 78% |
| 困难调试任务 | 60% | 90% | 1.67C | 2.22C | Fable 约高 33% |
| Opus 很不稳定的窄任务簇 | 45% | 95% | 2.22C | 2.11C | Fable 才可能略低 |
Fable 真正可能赚钱的地方，是减少模型成本之外的损失：
完整成功任务成本 =
模型调用
+ 重试与 fallback
+ 工程师复核时间
+ 修复与回滚
+ 错误上线或任务失败的预期损失
÷ 可验收交付数量如果一次错误根因判断会让工程师浪费半天，或者一个多小时 Agent 失败后必须全部重跑，Fable 只要降低少量失败就可能值回溢价。反过来，对能自动运行测试、失败后几分钟即可重试的任务，Fable 很难证明 2× 费率合理。
EvoLink 路由价格可能与 Anthropic 官方价不同，也可能独立变化。实际预算应读取两个产品页的实时价格模块，而不是把当前网关价格永久写进本文。
四种可落地的生产路由
| 架构 | 适合什么情况 | 优点 | 主要风险 |
|---|---|---|---|
| Opus-only | 质量已达标、任务可验证、流量较大 | 简单、成本可控、上下文无需跨模型 | 极限任务可能留下能力缺口 |
| Opus 默认 → Fable 升级 | 大多数生产 Agent | 把 Fable 成本集中在真正失败的请求 | 升级条件过宽会让成本失控 |
| Fable 规划/审查 + Opus 执行 | 长 trace、复杂拆解、高价值交付 | 把最高能力集中在少数关键节点 | 跨模型上下文传递、延迟和重复 Token |
| Opus 与 Fable 双路独立输出 | 法律、金融、科研等高价值结果 | 可发现单模型盲点 | 成本最高，必须有明确仲裁规则 |
Opus-only
当任务有自动测试、结构化验证或稳定人工 rubric，而且 Opus 已达到验收门槛时，不需要为了理论能力上限增加第二条高端路由。先把 effort 调到合适等级，再决定是否升级模型。
Opus 默认，Fable 失败升级
这是最适合大多数 EvoLink 用户的起点。升级信号应该可观测，例如：
- 自动验证失败；
- 工具调用连续不合法；
- 多轮后仍无法收敛；
- 模型对关键结论给出低置信度；
- 任务价值或失败损失超过预设阈值；
- 某个任务簇已通过回放证明 Fable 明显占优。
不要使用“Prompt 很长”“任务看起来复杂”这类模糊条件，否则 Fable 会逐渐吞掉全部高端流量。
Fable 规划或审查，Opus 执行
这种模式的价值不在于让两个模型重复完成同一任务，而是把工作拆成不同角色：
Fable：形成计划、指出高风险假设或做最终反证
Opus：执行代码修改、工具调用、验证与修复只有当规划质量确实减少执行返工时，这个结构才有意义。评测时必须把规划 Token、跨模型摘要损失和额外等待时间算进去。
双路独立审查
对单次错误代价极高的交付，可以让 Opus 和 Fable 在彼此不可见的情况下独立分析，再由规则或人工仲裁。它适合少量高价值任务，不适合当作普通生产默认值。
在 EvoLink 评估 Claude Opus 5Safeguard、数据留存和 fallback 可能推翻质量结论
stop_reason: "refusal"；如果只看 HTTP 状态码，监控系统可能把拒绝错误计为成功。开启 fallback 后，最终结果也可能来自另一模型。因此每条评测和生产日志至少要记录：
| 字段 | 为什么需要 |
|---|---|
| requested model | 用户或路由最初选择了什么 |
| served model | 最终实际生成结果的模型 |
| effort 与输出预算 | 判断不同调用是否具备可比性 |
| refusal 与 classifier | 区分质量失败和政策拒绝 |
| fallback reason | 解释为什么发生模型切换 |
| 各阶段 Token 与延迟 | 计算完整路径成本 |
| 最终验收结果 | 防止把“有输出”误当成“任务成功” |
数据治理也可能先于质量决定模型。Anthropic 为 Fable 5 记录了 30 天数据留存和不支持零数据留存；Opus 5 一般接入没有模型特定留存要求。这些事实仍需映射到组织实际使用的网关、地区和合同，不能只看模型名称。
如何把 Fable 流量安全迁移到 Opus 5
迁移不应该从“把 model 字符串全部替换”开始，而应该从任务分类和历史失败开始。
| 阶段 | 要做什么 | 进入下一阶段的门槛 |
|---|---|---|
| 1. 历史回放 | 准备 50–200 个代表性任务，包含成功、昂贵失败和极限案例 | 覆盖真实工具、上下文和验收标准 |
| 2. 匹配对测 | 使用相同权限、工具、超时和 retry；明确 effort 与输出预算 | 结果可以按任务簇比较 |
| 3. Shadow | Opus 不影响线上结果，仅与现有 Fable 路径并行记录 | 无安全、格式或工具调用阻断 |
| 4. Canary | 先把 10%–25% 合适流量切到 Opus | 验收率、人工复核和 P95 延迟达标 |
| 5. 分任务放量 | 只扩大已通过门槛的任务簇 | 成功任务成本持续优于旧路径 |
| 6. 保留升级与回滚 | Fable 继续处理已证明有优势的任务 | 任何异常都能按任务簇回退 |
建议至少设置这些验收门槛：
- 首轮可验收率不能明显下降；
- 工具调用格式错误不能增加；
- 人工修复时间与重试次数不能抵消 Token 节省；
- P95 完成时间符合用户体验；
- 拒绝和 fallback 能被正确归因；
- 高价值失败样本必须单独审核，不能被平均数掩盖。
如果团队还没有可靠验收器，先不要把 Fable 全量替换成 Opus。没有验收标准时，“看起来不错”会同时高估两个模型。
一套可复现的对测协议
- 按业务价值和失败类型给任务分层，不要只按 Prompt 长度分类。
- 使用生产中的真实上下文、工具 Schema、权限和 repository state。
- 为两条路径记录明确的 effort、输出预算、超时和 retry 规则。
- 对高方差 Agent 任务重复运行，不用一次结果代表模型能力。
- 盲评正确性、范围遵守、工具有效性、完成度和修复工作量。
- 同时记录 requested model 与 served model，剔除无法归因的 fallback 结果。
- 计算每个任务簇的成功任务成本，而不是只计算全局平均值。
- 把路由门槛写入版本化策略，并保留旧策略以便回滚。
推荐的最小数据结构是：
task_class
requested_model
served_model
effort
input/cache/output_tokens
tool_calls
refusal_and_fallback
wall_clock_time
review_minutes
accepted
failure_reason在 EvoLink 上，把模型选择集中在路由层，可以让应用继续使用同一个客户端与 API key，同时逐步修改默认、升级和回滚策略。这样做的价值不只是少改代码，而是能在同一套观测口径下比较不同模型。
不同团队应该怎样选
| 团队 | 建议起点 | 不应忽略的条件 |
|---|---|---|
| 独立开发者或小团队 | Opus 5 作为高端默认 | 不要为少量任务过早建设复杂双模型架构 |
| Coding Agent 产品 | Opus 执行，保留 Fable 任务级升级 | 把根因分析、规划和审查分别计分 |
| 高频企业自动化 | Opus 或更低成本模型处理主流流量 | 优先关注成功任务成本与延迟 |
| 高价值研究与专业审查 | Opus 主任务 + 选择性 Fable 独立复核 | 建立引用、事实和人工仲裁规则 |
| 长时间自主 Agent | Opus + checkpoint，从小比例测试 Fable | 评估整条 trace，不只看最后答案 |
| 数据治理严格的组织 | 先核对 Opus 5 路由资格 | 把模型、提供渠道、地区和 retention 一起审批 |
目前仍不知道什么
截至 2026 年 7 月 25 日，公开证据仍有明显缺口：
- 缺少覆盖多种工作负载、完全匹配 effort 和 fallback 条件的独立对比；
- 发布首日社区体验样本很少，而且 Prompt、工具和订阅入口不一致；
- Fable 的“最高能力”在什么任务上能稳定转化为更低返工，仍需按业务验证；
- 不同 Agent harness 可能比基础模型名称更影响结果；
- EvoLink 尚需积累足够的匿名化长期路由数据，才能给出跨用户的稳定任务分层结论。
因此，本文的建议是可执行的生产起点，不是永久排行榜。出现独立同配置评测、模型行为更新、路由价格变化或 EvoLink 第一方结果后，应更新证据表和路由门槛，而不是只修改发布日期。
最终建议
所以问题不应该是“永久选 Opus 还是 Fable”，而应该是：
哪些任务 Opus 已经足够好？
哪些任务 Fable 能证明增量价值？
怎样让路由根据验证结果自动选择？资料来源
- Anthropic：Introducing Claude Opus 5
- Anthropic：Claude Opus 5 的功能与行为变化
- Anthropic：Claude 模型概览
- Anthropic：Claude Fable 5 与 Claude Mythos 5
- Anthropic：Claude API 价格
- ARC Prize：Claude Opus 5 验证结果
- Artificial Analysis：Opus 5 与 Fable 5 当前配置对比
- RuBench：部署路径与 safeguard fallback 对评测归因的影响
- ClaudeCode 社区：Opus 5 与 Fable 5 的首日使用讨论（仅用于发现测试问题，不作为模型事实）
常见问题
Claude Opus 5 比 Claude Fable 5 更好吗？
不能笼统下结论。Opus 5 在若干发布评测中领先或接近 Fable，官方基础 Token 单价只有一半；Anthropic 仍把 Fable 5 定位为广泛发布模型中的最高能力档。对多数生产任务先测试 Opus，对已证明有 Fable 优势的极限任务保留升级路由。
Claude Fable 5 为什么仍然更贵？
Fable 5 的产品定位是最困难推理和长周期智能体的最高能力档。价格反映产品层级，不保证它在每个任务上都比 Opus 5 更好，也不代表使用 Fable 一定能降低成功任务成本。
Claude Fable 5 值得多花一倍吗？
只有当它带来的新增可验收结果、更少人工复核或更低失败损失足以覆盖溢价时才值得。对可自动验证、失败后能快速重试的任务，Opus 通常更容易获得更好的成本效率。
编程智能体应该选 Opus 5 还是 Fable 5？
先让 Opus 5 处理实现、工具调用和大多数代码审查。对无法收敛的极限任务，或者回放数据证明 Fable 在规划、调查或最终复核上明显占优时，再升级到 Fable。
能让 Fable 规划、Opus 执行吗？
可以，这是一种值得测试的混合路由。但必须把规划调用、上下文传递、额外延迟和重复 Token 算进总成本。只有规划质量确实减少执行返工时，这个结构才优于 Opus-only。
Opus 5 在 Benchmark 中超过 Fable 5 了吗？
Anthropic 报告 Opus 5 在部分评测中领先 Fable，在另一些评测中接近。这些是任务与配置特定的结果。ARC Prize 验证了 Opus 5 的 ARC-AGI-3 成绩，但公开表中没有匹配的 Fable 分数；其他独立页面也可能比较不同 effort 或带 fallback 的路径。
两个模型都支持 100 万上下文吗？
是。Anthropic 为两者都记录了 100 万 Token 上下文和 12.8 万最大输出。相同容量不代表长上下文检索、指令遵循、工具调用和最终完成率相同，应回放真实长 trace。
哪个模型延迟更低？
Anthropic 当前模型概览把 Opus 5 标为中等延迟，把 Fable 5 标为较慢。实际完成时间还受到 effort、thinking Token、输出长度、工具循环、重试和路由状态影响。
从 Fable 迁移到 Opus 需要重写 Prompt 吗？
不一定需要全面重写，但必须重新测试。两个模型的 thinking 行为、effort 敏感度、工具轨迹和输出风格可能不同。先运行历史回放与 shadow，再根据失败类型调整 Prompt 和路由规则。
如何确认 Fable 请求没有被 fallback？
不要只记录最初请求的模型名。日志必须同时记录 requested model、served model、refusal、classifier 和 fallback reason，并把各阶段 Token、延迟和最终验收结果归因到完整路径。
