在 Claude Fable 5.2 与 Opus 5.5 之间，日常编码先从 Opus 开始。遇到模糊调试、困难的迁移或超出 Opus 基线的长项目，再测试 Fable。Anthropic 推荐这种升级模式。它的基准提升支持你试一试，但最终要看你的验收测试和审阅投入，判断切换是否划算。
更强的模型要靠「完成你能接受的工作」来证明自己。这可能意味着找到隐藏依赖、拒绝一次高风险重写，或者在错误假设上少绕几轮。
把这些结果留在 HiFox 的任务里，模型决策才有证据。真正有用的比较，是每个美元和每个审阅小时换来了多少被接受的工作。
Anthropic 的基准说明了什么
Anthropic 的 Fable 5.2 公告称，在两项评测上编码分数高于 Opus 5.5。这些是厂商报告的结果，此处引用仅为提供背景。本文没有独立复现的正面对比，也没有原创模型测试。
| Anthropic 报告的评测 | Fable 5.2 | Opus 5.5 | 差值 |
|---|---|---|---|
| FrontierCode 2.0 | Xhigh effort 下 49.1% | 45.5% | 3.6 个百分点 |
| FrontierSWE v2 | 69.9% | 62.3% | 7.6 个百分点 |
公告说明，除非另有标注，分数使用可用的最高 effort。这一点很重要：只写模型名，并不能描述你正在比较的配置。
Anthropic 还报告 Fable 在 High effort 下 FrontierCode 得 45.3%，接近 Opus 在 Max effort 下的 45.5%，而每个任务成本约为一半。把这理解为特定评测下的效率主张，不能证明在你的仓库上也能省这么多。
官方模型概览列出 Fable 的标准 API 价格为每百万输入 Token $8、输出 Token $40；Opus 分别为 $4 和 $20（2026 年 11 月 10 日核对）。两者都标称 100 万 Token 上下文窗口和 128,000 Token 最大输出。
Fable 标价是 Opus 的两倍。任务总成本仍取决于 Token、重试、工具和 effort。更长的上下文窗口本身并不构成优势。
按编程任务选择，再逐级升级
问题和验证方法都清楚时，用 Opus 作基线。当工作卡在基线无法消除的不确定性上，再换 Fable。下面的路由规则是编辑建议，不是每个任务类别的实测排名。
| 任务 | 起点 | 测试 Fable 的理由 | 验收证据 |
|---|---|---|---|
| 日常编码 | Opus 5.5 | 规格清楚但反复失败 | 聚焦测试与审阅过的 diff |
| 模糊调试 | 带复现的 Opus | 多个可能原因仍未排除 | 回归测试与因果解释 |
| 跨系统迁移 | 先让 Opus 做有界切片 | 架构约束阻碍推进 | 兼容性检查与回滚方案 |
| 长 Agent 项目 | Opus 负责有界里程碑 | 规划或集成反复出问题 | 被接受的里程碑与集成测试 |
哪些日常编码任务应留在 Opus？
有界改动如果已经达到质量线，就留在 Opus。例如增加一个带校验的 API 字段、扩展测试夹具，或修改错误信息且调用方明确。
开始前写验收标准。改 API 时，写明请求形状、响应形状、校验行为和兼容性预期。提示词含糊，会让日常任务看起来像推理失败。
如果 Opus 一次就给出可接受的补丁，更高的基准分数并不能给你多少切换理由。如果成本或延迟成为约束，再单独试更小的模型。我们关于 Sonnet 与 Opus 的任务指南讨论了相邻的选择。
什么时候模糊调试值得上 Fable？
等你有了复现、日志和失败假设的书面记录再升级。让 Fable 先给可能原因排序，并提出能区分原因的测试，再改代码。
例如，间歇性队列故障可能来自超时、重复投递或状态恢复错误。有用的调查会用证据把这些原因分开。再包一层重试，可能只是掩盖症状，缺陷仍在。
设定停止条件：如果下一轮不能产生新证据，就回到埋点或人工调查。在同一个假设上继续烧 Token，不会改善诊断。
迁移任务该怎么测 Fable？
给每个模型同一段有代表性的迁移切片，包含一个别扭的依赖、一个兼容性边界，以及一个可度量、必须保持不变的行为。
Anthropic 描述过用较早版本的 Fable 5.2 做生产环境 Python 到 Rust 迁移，并报告启动速度约提升 26 倍。那是针对特定服务的厂商案例，不是你迁移项目的预测。
用语义保持、部署约束和回滚准备度来评判切片。扩大范围前，要求模型记录未解决的假设。
更长的 Agent 项目有什么不同？
选择完成标准可观察的里程碑。把规划、实现和集成审阅分开，避免一份看似合理的计划替代可工作的结果。
Anthropic 报告过一个为期 8 天、涉及 1,000 多个子 Agent 的操作系统实验。这展示了其实验规模，不是推荐的团队配置。你的第一次试用可以只做一个困难里程碑，并设定固定预算。
更广泛的比较，可以看我们关于为长任务选择 Agent 的指南。
做一次可信的对比
有用的本地评估要保持起始条件稳定，并衡量被接受的产出。比较相同的仓库版本、任务说明、工具、权限和测试环境，并明确记录 effort 设置。重复运行有代表性的任务，因为一次成功可能来自运气或特别有利的问题。
在四类任务上都取小样本。审阅输出前先定义验收评分表，然后记录：
- 补丁是否通过功能测试和回归测试。
- 审阅者是否接受实现。
- 模型与工具总花费，包括失败尝试。
- 直到出现可接受结果的总耗时。
- 审阅者检查与修正所用的分钟数。
- 任何权限、兼容性或范围违规。
用全部试运行花费除以被接受任务数，得到每个被接受任务的成本。分子要包含失败运行，否则失败代价高的模型会显得更便宜。
运行对比前，先决定什么样的改进会改变你的选择。审阅瓶颈明显的团队，可能更看重更少的修正轮次；处理高成本故障的团队，可能愿意为更快的诊断多付模型费用。在看到谁赢之前，先把这个权衡说清楚。
把失败运行和被拒绝的补丁留在记录里。通过测试但未经批准改变公共行为的模型，仍然算失败。同样，没有复现的漂亮解释，只是不完整的调试证据。接受任何结果前，先看实际 diff，并在干净检出上重跑测试。
不要把模型升级和新工具、更大权限、重写的任务说明混在一起。这些变化可能改善结果，但会让你无法判断究竟是哪项改动带来的。
在 HiFox 里保持工作流稳定
HiFox 官网介绍了共享 Agent、任务指派、已连接执行环境，以及进度和审阅的可见性。比较配置时，用这层工作记录保存任务说明、基线发现和验收证据。
在任务的评估笔记里记录所选模型和 effort，把结果、测试输出和审阅决定放在一起。这是推荐的评估流程，不意味着 HiFox 会自动做基准打分或自动路由模型。
配置背景可以读我们在 HiFox 中运行 Opus 5.5 Agent 的指南。模型访问和计费仍取决于你配置的编程工具与账户。
不必每一轮都切换的替代方案
你可以让 Opus 做主模型，只在困难决策点咨询更强的顾问。Anthropic 的 advisor 文档描述了 Claude Code 中用于这种模式的实验性工具，并附有平台和计费要求。启用前先核对。
另一种做法是拆任务：先要调查或迁移计划，审阅后再授权实现。这样可以在两个模型都大量写代码之前，先暴露缺失的需求。
下一步
挑一个最近让 Opus 卡住的任务，再挑一个它顺利完成的任务。在受控条件下用 Fable 重放，记录被接受的产出和审阅投入，保留在你实测结果更好的配置。改变团队默认模型前，先把这次对比放进共享任务。
常见问题
Fable 5.2 在编码上总是更好吗？
Anthropic 在引用的编码评测上报告了更高分数，但这不能证明它在每个仓库或任务上结果都更好。
Opus 5.5 还应该做默认模型吗？
Anthropic 建议大多数工作负载从它开始。如果你的评估显示质量和成本可接受，就继续用它。
Fable 每个任务的成本是两倍吗？
它标称的标准输入和输出 Token 费率是 Opus 的两倍。任务成本取决于完成工作需要多少 Token 和尝试。
长任务就一定要用 Fable 吗？
时长本身是弱信号。只有规划、推理或集成失败阻碍了可接受的进展时，才升级。
这些是独立基准结果吗？
不是。上面的数值对比来自 Anthropic。本文提出的本地评估并未实际执行。
延伸阅读
评估方法可以读 Fable 与 Mythos 的系统卡，以及上面链接的公告和模型概览。任何用于采购或路由决策的分数，都要把方法和配置一起保留。
HiFox
