Fable 5.2 vs Opus 5.5：编程案例、费用与模型选择
通过插件修复、玻璃泳池和冰之大教堂案例及对比视频，比较 Fable 5.2 与 Opus 5.5 的交付结果、High/Max 配置、缓存费用和适用任务。
EvoLink Team产品团队文章目录
对于通过 EvoLink 管理模型接入和费用的团队，真正需要决定的是：某一类工作应该交给哪个模型、采用什么推理强度。一次明确的代码修改、一项反复受阻的迁移，以及需要长时间调用工具的 Agent，可能适合不同配置。
这篇对比围绕这些选择展开：哪些差异会影响交付，什么情况下更高的单价仍可能值得，以及什么时候应该保留已有方案。
具体任务的对比结果，展示了不同的选择
真实案例能让比较更具体。下面前三组属于作者报告的单次对比，第四组来自 Anthropic 实验。它们没有经过 EvoLink 独立复现，也不能用于估算两个模型在日常工作中的平均表现。
案例一：给已有插件找 Bug，找到的问题相同，修复结果不同
开发者 Octavio Aranda 让两个模型检查自己使用的插件，找出真实 Bug、复现问题并提出修复。他表示，两者采用了相同指令和推理强度。针对目标插件，两个模型找到了相同的六个 Bug：
| 作者报告的结果 | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 用时 | 2.9 分钟 | 6.6 分钟 |
| 按 API 费率计算的费用 | 约 0.76 美元 | 约 2.78 美元 |
| 用另一模型的测试检查修复 | 全部通过 | 一项未通过 |
这个案例把“发现更多内容”和“完成要求的修复”区分开来。审查覆盖范围、得到验证的缺陷，以及最终代码能否通过检查，都会影响结果。
案例二：玻璃泳池场景，额外细节对应更大的账单
Mr Tactical 发布了一段玻璃泳池场景的双模型对比视频：
| 作者报告的结果 | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 用时 | 68 分钟 | 90 分钟 |
| 费用 | 14.39 美元 | 57.87 美元 |
对于视觉原型，需要判断额外细节是否影响这次交付。团队可能愿意为选中的场景继续投入，而在探索方向时，成本更低的草稿已经足够。
案例三：冰之大教堂，更高费用换来了更短等待
Tony（EnvolDev）报告，用相同的“冰之大教堂”提示词比较两个模型：
| 作者报告的结果 | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 用时 | 3 小时 11 分 26 秒 | 1 小时 56 分 52 秒 |
| 费用 | 45.97 美元 | 81.10 美元 |
案例四：大规模数学形式化，两个模型的完成情况拉开了差距
这是一个在高难度任务上完成情况不同的具体例子。它有专门的基础设施、起始材料和验证方式，需要与普通编码任务分别理解。
这些案例支持的选择各不相同：可验证的修复、偏好的视觉细节、更短的等待，以及完成一个原本停滞的项目，属于不同的交付目标。先确定工作最需要哪一项，再比较获得它的成本。
先看会影响选择的基本差异
两个模型的标准 API 规格相当接近：
| 标准 API 项目 | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 模型 ID | claude-opus-5-5 | claude-fable-5-2 |
| 上下文窗口 | 100 万 Token | 100 万 Token |
| 常规消息请求最大输出 | 128K Token | 128K Token |
| 输入与输出 | 文本、图片输入，文本输出 | 文本、图片输入，文本输出 |
| API 默认推理强度 | medium | high |
| 每百万普通输入 Token | 4 美元 | 8 美元 |
| 每百万输出 Token | 20 美元 | 40 美元 |
Fable 在这组比较中没有更大的上下文窗口。如果失败原因是应用遗漏了关键文件，或给出了相互矛盾的要求，更换模型后，这些问题依然存在。比较之前，应先确保两个候选都拿到了完成任务所需的信息。
默认推理强度也会影响结果。API 请求不指定 effort 时，Opus 使用 Medium，Fable 使用 High。这能够反映默认调用的表现，但如果团队准备替换一个已有配置，还应把实际使用的 Opus 设置与合理的 Fable 设置放在一起比较。
公开成绩显示了提升，也保留了值得注意的例外
Anthropic 在发布评测中报告了以下结果：
| 评测 | Opus 5.5 | Fable 5.2 |
|---|---|---|
| FrontierCode 2.0 | 45.5% | 49.1%，Xhigh |
| FrontierSWE v2 | 62.3% | 69.9% |
| AutomationBench | 42.5% | 51.4% |
| AA-Briefcase v1.1 评分标准得分 | 61.2% | 66.1% |
| AA-Briefcase v1.1 Elo | 1800 | 1785 |
这些成绩支持把 Fable 放入困难任务的评估范围，但验收仍要回到交付物。代码需要检查行为和测试，分析报告需要检查事实依据、计算，以及是否真正回答了问题。综合分数无法替团队决定哪一种错误最重要。
将 Fable High 与实际使用的 Opus 配置比较
更高的 Token 单价和更低的任务费用可以同时出现，因为两种配置实际消耗的 Token 和执行过程不同。这项结果对应特定评测，不能直接套用到 Opus Medium 已经能完成的普通编码任务。
如果团队已经需要把 Opus 开到 Max，才能尝试解决某类难题，那么 Fable High 是值得测试的候选。如果 Opus Medium 已经能够稳定交付，则应先明确升级要改善什么：完成率、人工修改量，还是拿到可用结果的时间。
这个区别能避免把一个有吸引力的评测结果，直接变成所有任务都增加预算的理由。
日常编码、复杂迁移和代码审查，可以采用不同选择
| 工作类型 | 建议起点 | 什么变化足以支持切换 |
|---|---|---|
| 需求明确、测试可靠的常规修改 | 保留已有 Opus 配置 | Fable 节省的时间或人工修改，足以覆盖增加的费用 |
| 反复受阻的迁移或重构 | 用 Fable High 对照当前 Opus 配置 | 保留要求的行为，并通过相同检查 |
| 需要权衡多个约束的架构决策 | 先比较方案，再进入实现 | 方案解决关键约束，并能落实为可工作的改动 |
| 重要改动的代码审查 | 评估 Fable 作为补充审查者 | 找到可验证的问题，同时控制误报和核查负担 |
这些是评估起点。最终要看模型变化是否改善了这类工作的交付。
例如，一项服务迁移反复破坏兼容性，可以把接口契约、实现、相关测试和已知失败交给两个候选，要求它们解释原因、提出方案，并完成最小可行修改。验收应覆盖兼容行为，包括可见失败测试之外的情况。
代码审查则需要另一套判断。每条问题都应给出位置、触发条件、具体影响和依据。记录最终成立的问题、漏掉的缺陷，以及人工排除误报所用的时间。审查意见很多，未必意味着维护者更容易完成工作。
单价是两倍，完整请求费用却不一定是两倍
下面使用相同的计费 Token 数，做两个假设计算：
| 假设请求 | Opus 5.5 | Fable 5.2 |
|---|---|---|
| 10 万普通输入＋1 万计费输出 | 0.60 美元 | 1.20 美元 |
| 80 万已有缓存读取＋10 万普通输入＋1 万计费输出 | 0.76 美元 | 1.36 美元 |
第二行假设缓存前缀已经存在，不含此前创建缓存的写入费用。两行均不含工具调用、重试和其他费用；它们是按标准费率计算的示例。
对于完整编码任务，还应把失败请求和后续尝试计入总费用。可以比较“全部工作流费用 ÷ 通过验收的任务数”，并单独记录人工审查时间。
一个方案即使总支出较高，如果能减少反复失败，仍可能降低每个合格结果的成本；如果只是探索更多，却没有提高验收表现，增加的费用就缺少实际回报。
缓存创建也要留在账单里。已有缓存的请求适合观察重复工作，但第一轮请求同样属于项目成本。
让 Fable 参与关键决策，Opus 继续执行
除了单独使用两个模型，还可以评估一种组合：Opus 完成明确的实现工作，Fable 参与困难方案的判断或结果审查。
在自己控制的应用中，也可以通过明确的任务文档交接：写清需求、计划、已作决定、未解决问题和测试结果。执行模型遇到与计划不一致的情况时，应报告冲突，而不是继续沿着错误假设推进。
比较这类组合时，应与“仅用 Opus”和“仅用 Fable”同时对照，把规划和审查费用也算进去。错误方案交给更便宜的执行者，仍可能保留最初的问题，因此交接过程需要允许质疑原有判断。
这里提到的原生 advisor 是 Anthropic 的 Claude Code 功能，其他 API 渠道是否支持需要单独核实。自行设计规划交接流程，并不要求网关已经实现同名工具。
持续对话切换模型，需要保留可交接的任务状态
对于会交替使用模型的工作流，需求、修改文件、检查结果和未解决问题，应当保存在下一步能读取的普通文档或任务记录中。随后，在实际应用里测试切换行为，包括它如何处理历史消息和摘要。
把对比落实为 EvoLink 上的模型选择
开始评估时，可以选择一项常规工作、一项 Opus 已经遇到困难的任务，以及一项需要较长工具调用链的工作。固定输入和验收要求，将当前 Opus 配置与 Fable High 对照，再根据结果调整推理强度。对于输出存在波动的任务，重复运行并保留实际通过数量。
在 Opus 仍能以合适成本交付的地方继续使用它；在 Fable 带来明确改善的地方，把收益落实为具体升级规则，例如某类任务，或某种 Fable 更擅长处理的重复失败。这样得到的模型策略，才便于团队解释和持续维护。
常见问题
Fable 5.2 的编程能力是否比 Opus 5.5 更强？
它在上文公布的编码评测中得分更高。能否改善实际工作流，还取决于任务、推理强度、工具和验收标准。
Fable 是否一定更贵？
普通输入和输出单价更高。完整任务费用还受 Token 消耗、缓存、重试和工具调用影响；官方 Fable High 与 Opus Max 的比较，说明需要观察完整配置。
公平比较是否应该把两个模型都开到 Max？
应优先比较团队实际可能部署的设置，并明确预算与质量要求。最高能力比较也有价值，但它回答的是另一个问题。
Fable 的上下文窗口是否更大？
两者均标注为 100 万 Token。需要检查模型是否正确使用了相关上下文，容量本身不代表理解质量。
能否让 Fable 做规划、Opus 写代码？
可以把它作为候选工作流，用明确的计划和可验证的结果交接。费用中应包含两个模型，以及纠正错误交接所用的成本。
什么时候应该继续使用 Opus？
当已有配置满足质量和时间要求，而候选没有带来值得采用的改善时，可以继续使用。新模型发布不会改变原有任务的验收标准。
