Claude Fable 5.2 比 Opus 5.5 贵一倍，哪些任务值得换？

11 月 9 日，Anthropic 发布 Claude Fable 5.2 和 Mythos 5.2。Fable 5.2 的 API 基础输入、输出单价都是 Opus 5.5 的两倍，但官方仍建议多数编码和知识工作先从 Opus 5.5 开始，把 Fable 留给更难、更开放的长任务。价格差是确定的；完成一项任务的账单与结果是否值得这笔钱，还不能从单价直接推出。Mythos 虽与 Fable 基于同一底层模型，却需要组织通过验证计划才能申请访问，不是可以随手切换的公开选项。

官方为何仍建议多数任务从 Opus 5.5 开始？

设想今天有两项开发工作。一项是边界清楚的接口修改：已有测试、改动范围可控，开发者能随时审阅；另一项是跨越多个模块的旧服务迁移：需求有空白，代理要长时间读代码、设计、修改、测试，再处理失败。前者用更贵的型号不一定带来可见收益；后者如果一次错判会让大量后续工作重做，就值得认真比较更强模型能否减少返工。这是选型场景，不是我们已经跑完的对照实验。

Claude Fable 5.2 与 Mythos 5.2 发布公告将 Fable 和 Mythos 放在最开放、最有难度的技术工作上，同时把 Opus 5.5 称为日常主力，建议多数编码与知识任务先用它；Claude 模型总览也写明，不确定选什么时先从 Opus 5.5 开始，只有当任务需要长程推理，或 Opus 在更高 effort（请求让模型投入的思考深度档位）下仍过不了自己的验收时，再考虑 Fable。这里给的是厂商产品建议，并非独立测试的成功率。

官方举出的任务尺度很大：一组早期模型参与把关键生产服务从 Python 迁至 Rust；另一次实验里，Fable 5.2 协调逾 1000 个代理，运行八天制作可在笔记本启动的操作系统原型。这些案例说明厂商想展示怎样的长任务，而不是说每个团队都需要千个代理，更不证明普通补丁也会得到同样收益。迁移案例使用的是较早版本，不能被改写成公开型号在本站复现的记录。发布页另展示与硬件团队合作设计的三件电子设备；官方称三件均能工作且不需修改电路，这是一项有实物的厂商实验，不代表模型能独立完成采购、制造和验收。要不要升级，先看自己任务的失败代价，而非只看演示规模。

把任务类型分开，能避免一种常见的误判：用 Fable 的复杂案例证明日常工作该全面换型。发布页没有这样建议。升级可以是一条任务级选择，而不必把现有全部请求改道；简单、可快速复核的工作继续留在已达标的模型上，真正长时、开放且代价高的工作才进入试验名单。

FrontierCode 的“约半成本”为什么不推翻两倍 token 单价？

官方型号专页和模型总览列出的 API 基础价相同：Fable 5.2 每百万输入 token 8 美元、每百万输出 token 40 美元；Opus 5.5 分别是 4 美元和 20 美元。这是按 token 计的基础价格，两个方向确实都是两倍。上下文窗口同为 100 万 token、单次最大输出同为 12.8 万 token，是规格上限，并非任一任务都会消耗到上限，也不应理解为可在 100 万输入之外再额外生成 12.8 万输出。

若只看一个假设请求，不使用缓存、fast mode、Batch 或其他加价服务，输入 10 万 token、输出 1 万 token，则 Fable 基础价按 0.1×8＋0.01×40 计算，为 1.20 美元；Opus 按 0.1×4＋0.01×20 计算，为 0.60 美元。这是同样 token 数的算术，不是实际账单。真实工作中，更高的 effort 可能产生更多思考与输出，模型也可能用更少轮次完成，失败重试、人工审阅与缓存命中还会改写总账。

若启用了缓存，输入还会分成写入和命中读取，不应把所有输入都乘基础价。Fable 专页列出的五分钟缓存写入、小时缓存写入和读取价格分别为每百万 token 10、16 和 0.20 美元。这是 Fable 自身的费率，不是与 Opus 缓存价格的对照，也不能与普通输入价格混为一栏。

公告里的另一组数字来自 Anthropic 自己的 FrontierCode 2.0 评测。它评估模型提交的代码修改是否会被开源仓库维护者接受合并；下面的百分数是该评测成绩，不是任意项目的成功率。Fable 5.2 在 High effort 得 45.3%，Opus 5.5 在 Max effort 得 45.5%；厂商称前者在这组测试中每任务成本约为后者的一半。这两个点不是同一 effort 档，也不是“所有任务用 Fable 更便宜”。表格中的 Fable Xhigh 49.1% 是另一个设置下的厂商成绩，不能接在 45.3% 后面当成同成本直接比较。图上的曲线可帮助读者看清准确率与单位任务成本之间确实存在不同取舍，但它没有替自己的代码库测出成功率。

对采购或工程负责人，比较单位应当是“满足质量门槛的一项完成任务”：把输入、输出、缓存、失败重跑与人工复核一起记下来。若某项任务用 Opus 一次就达标，Fable 多花的钱未必值得；若 Opus 需要不断返回同一处修复、Fable 能在固定验收下明显减少重试，就有了值得进一步试的方向。后一句仍是待验证的条件判断，不是本站实测结果。

API 与 Claude Code 的默认 effort，不能混写成一个值

同一型号从不同入口进入，默认设置未必相同。Claude 模型总览与Fable 5.2 型号专页列的是 Claude API 默认值：Fable 5.2 为 high，Opus 5.5 为 medium。但发布公告在解释 Fable 的效率时，特意写明 Claude apps 和 Claude Code 的默认档位是 medium。因此，“Fable 默认 high”只在这里的 API 表格口径下成立，不能拿去概括所有入口；也不能未经核对就断言 Claude Code 中 Opus 与 Fable 的全部配置相同。

这点影响选型实验。拿两个默认 API 请求比较，结果可能同时反映型号差异与默认 effort 差异。若要比较能力，应固定任务、输入和验收标准，显式记录两个实际模型 ID、入口与 effort；若要比较“按默认配置直接用”的真实体验，则保持各自默认，但诚实标明比较了两项变量。前一种回答“同条件下哪一个更适合”，后一种回答“这个入口现在直接选哪个更合适”，不该互相冒充。

Fable 5.2 的 型号专页还写明：自适应思考始终开启，不能关闭，只能用 effort 调节深度；强制 tool_choice 为 any 或指定 tool 会返回 400。对现有 API 调用方，这比“把模型 ID 改一下”更具体：先核请求参数和实际入口，再谈性能比较。这里的 400 是官方文档记载的参数边界，接入前应检查现有请求是否受影响。

Mythos 5.2 与 Fable 5.2 同底层，入口却不是一回事

官方公告写明，Fable 与 Mythos 是同一个底层模型，但 Fable 加上针对网络安全和生物领域的保护；Fable 型号专页称 Mythos 5.2 具有相同能力、规格和价格，仅向通过 Anthropic 验证计划的组织开放。因而，不应把“同底层”翻译成“所有用户都可在下拉框里切换 Mythos”，更不能把某个安全任务受 Fable 拦截说成只需换型号即可解决。

发布公告把有益的网络安全或生物医学研究分别指向相应验证计划。它还提到部分企业客户能通过 Claude Security 产品使用包括 Mythos 5.2 在内的能力；产品中的能力入口不等于普通账号取得 Mythos API 权限。是否获准、能在哪个产品与地区使用、组织承担什么规则，需要按实际授权核对；本文没有申请账号，更没有替任何团队确认审批结果。

还有容易被预算讨论遮住的数据条件。官方型号专页规定 Fable 5.2 需要 30 天数据保留；零数据保留组织若未经 Anthropic 明确授权，不能使用该型号。处理敏感代码、客户资料或有特定留存要求的工作，先核自己的组织设置和合同，不要因为模型更适合难题就假设现有 ZDR 规则原样适用。不同用途的安全准入和数据保留是两道门，价格表没有替你回答它们。

真要换，先挑一项会失败的长任务做窄对照

假设团队积压着一段跨仓库的迁移工作：涉及多处调用、回归测试和交接文档，现有流程常在最后一步露出漏改。别先让全站流量切换模型。先确认自己的地区、组织账户和 API、Claude Code 或应用入口实际可用 Fable 5.2，并核对对应渠道计费与数据保留条款，再拿真实资料测试。取一项可在隔离环境完成的任务，固定输入快照和成功条件；例如必须通过同一组测试、人工审阅不得发现关键遗漏、变更能在给定时间内解释清楚。先用现有 Opus 流程得到基线，再按相近的工具权限和努力档位试 Fable；若比较产品默认体验，另列一组，不把它混进同条件结果。

开始前为每个候选设定最高总支出、最多请求数和可接受的人工返工分钟数，质量门槛保持相同。达到任一上限仍未达标，就停止该候选试验，不扩大替换，维持现有 Opus 流程。每轮记录实际模型 ID、入口、effort、输入与输出 token、缓存写入和读取、请求次数、失败重试、人工返工分钟数，以及最终是否达标。把达到质量门槛的任务作为分母，再看总模型费用与人工代价。低样本只会给“值得继续试吗”的线索，不足以推出“整个团队应该迁移”；任务原本就能稳定完成，继续用 Opus 是完全合理的结果。价格若涉及税费、云渠道或其他服务，也要与官方 API 基础价另列，不能把本篇算例冒充当地账单。

Anthropic 在公告中展示另一项更极端的长任务：约 1000 个代理把费马大定理的形式化证明工作推进至完成，Fable 5.2 耗时约 30 小时。官方曲线对 Fable 与 Opus 各仅运行一次，两组均采用约 1000 个代理；到第 18 小时各从上次保存的进度再续跑 12 小时。Fable 在这次实验中完成；公告正文写明 Opus 在第 18 小时完成 26%，此后 12 小时几乎没有再推进。它有助于说明为什么长程任务值得单独测，但单次厂商实验、特定代理编排和数学目标，不能预测普通项目的时间或费用。没有必要把每个工单都升级成这样的实验。

现在可以做的选择很朴素：日常任务先按官方建议从 Opus 5.5 开始；当一项复杂长任务在明确定义的验收门下反复失败，再让 Fable 5.2 参加有预算上限的小规模对照。等拿到自己任务的达标率与总成本，才决定是否扩大。若组织需要零保留或受限领域能力，则先解决准入与数据政策，再谈型号；再好的厂商曲线也不能替代这两道门。