Fable 5.2、5.1 和 Opus 5.5 怎么选？价格、任务成本与迁移比较

对于现有 Fable 5.1 工作流，Fable 5.2 是单价更低的升级候选；但对许多新任务，Opus 5.5 仍是费用更低的起点。选择的关键是：更贵的模型能否用更低总成本交付通过验收的结果，或者满足便宜模型无法满足的要求。

本文是基于文档的功能与费用比较，核查日期为 2026 年 11 月 10 日，并提供可复算示例。它不是速度测试，也没有给出实测任务成功率。Ofox 发布本文，并通过 API 目录提供这些模型；这一关系不能证明某个模型最适合你的工作负载。

三个模型到底有哪些差异

来源为官方 Fable 5.2、Fable 5.1模型表及定价参考。这几个上限相同，因此“我需要更大的上下文窗口”不能作为区分三者的依据。

带日期的 Ofox 目录中，anthropic/claude-fable-5.2、anthropic/claude-fable-5.1 和 anthropic/claude-opus-5.5 对应字段的费率均与上表所列官方标准费率一致。这是牌价比较，不是供应商价格比较，也不是账单。供应商类型和功能可用性可能不同，因此除模型名外还应记录路由。

Fable 5.2 的普通输入和输出单价比 5.1 低 20%；每个未缓存输入或输出 token 的价格为 Opus 5.5 的两倍，但二者缓存读取费率相同。这些都不能直接决定一个 Agent 完成任务的费用，因为输出长度、缓存行为、尝试次数和工具操作可能不同。

三个可以自行复算的费用场景

以下是合成 token 预算，不是实测输出。全部采用标准同步请求费率，币种为美元，不含批量折扣、快速模式或单独收费的工具。输出指全部计费输出，包括需要计费的推理。缓存读取场景未计入此前写缓存的请求，不能当成整段会话账单。

最后一行说明，不能笼统地说“Fable 一定贵两倍”。在缓存主导的请求中，5.2 与 Opus 5.5 的缓存部分都为 $0.02，只有剩余输入和输出采用更高的 Fable 费率，因此请求费用比约为 1.23，而不是 2。

第二行可以用以下代码计算：

from decimal import Decimal as D

rates = {
    "fable52": (D("8"), D("40"), D("0.20")),
    "fable51": (D("10"), D("50"), D("0.25")),
    "opus55": (D("4"), D("20"), D("0.20")),
}
for name, (input_rate, output_rate, read_rate) in rates.items():
    cost = (1000 * input_rate + 4000 * output_rate
            + 19000 * read_rate) / D("1000000")
    print(name, cost)

缓存创建有独立费用。三者公布的 5 分钟写入费率分别为每百万 tokens $10、$12.50、$5；1 小时写入费率为 $16、$20、$8。会话估算要计入相应缓存写入、真实未命中及过期行为。不能仅因为代码含缓存指令，就把每轮都按命中计费。

多输出多少，会抵消相对 5.1 的降价

假设 5.1 任务使用第一行的 20,000 个未缓存输入和 4,000 个输出 tokens，计算费用为 $0.40。5.2 使用相同输入时，输入花费 $0.16，距离同样总价还剩 $0.24。按每百万输出 tokens $40 计算，这部分可以支付 6,000 个输出 tokens。

在这些特定假设下，5.2 比 5.1 示例多输出 50%，总价仍可持平。如果输入和输出按相同比例一起增加，20% 的费率下降则允许 token 总量增加 25% 后才达到收支平衡。两个百分比回答的是不同问题，都不是对真实模型行为的预测。

因此迁移后的第一项测量应记录同一任务的各类 token。新模型做更多工作、重试或使用额外工具时，单价更低与账单更高完全可能同时发生。API 指南说明应保留哪些响应字段。

按任务和验收条件选择

这些是选择规则，不是我们组织模型竞赛后的性能发现。例如，发票抽取结果若缺发票 ID 或总额错误，即使文字流畅也应拒收。代码仓库修复要通过相关测试且避免无关改动。调研报告应为重要论断附上可访问来源，并保留未解决的证据冲突。

官方模型选择建议建议多数工作负载从 Opus 开始，评估仍未达到要求时再升级。Fable 档位的价值在于能通过验收的工作，而不是更大的版本号本身。

比较每个合格任务的成本，而非单次调用费

对一批可比任务，记录 API 与工具总花费，再除以通过验收的交付物数量。被拒收、未完成和人工修复的任务也要纳入核算。排除失败会让较弱模型显得虚假地便宜。

举例，假设每次 Opus 尝试 $0.16、Fable 尝试 $0.32，与第一行合成预算一致。如果验收通过率分别为 50% 和 90%，简化后的每次合格结果费用分别为 $0.32 和约 $0.356。更高通过率并不自动抵消价差。这些通过率是为计算而假设的，不是实测模型结果。

这个简化模型假设每次尝试可比且独立，排除了人工修复、排队时间和外部工具。真实工作流可能更偏好重试较少的模型，因为每次失败都消耗昂贵的审核时间。应以明确的时薪假设单列这笔成本，不要混进 token 性能结论。

分阶段路由要测完整路径：Opus 尝试、验证、升级、Fable 尝试和最终验证。如果几乎所有任务都要升级，先用便宜模型也不是免费的。比较路由时，绝不能重复发送同一个非幂等副作用操作。

迁移流量前，计入迁移成本

Fable 5.2 会检查所有账户的会话前缀。旧客户端若会重写 system prompt 或工具，即使 5.1 曾接受请求，也可能需要修复。其默认 effort 也不同于 Opus 5.5：不显式设置，就从 medium 变成 high。应明确设置并披露配置。

迁移指南还列出数据保留、computer 工具、advisor 和思考兼容性差异。特别是旧版 computer-use 工具存在 Amazon Bedrock 例外，不能将某个平台的不兼容推广到全部 Ofox 路由。400 排查文章提供修复分支。

从 5.2 退到旧模型时，请求成功不一定保留 5.2 推理。应另行保存已验证的任务事实和工具结果。Agent 检查点指南说明接收模型完成工作需要哪些内容。

用小到能逐项检查的比较开始

选择固定、具有代表性的任务，并保留一部分留出集。查看结果前先固定提示词、输入文件、工具和验收条件。每个模型记录精确 ID、路由、effort、token 上限、SDK 版本、时间戳、输入／输出／缓存用量、工具费用、完成状态及验收结论。

先使用各候选模型正常的生产设置；需要优化费用或质量时，再明确比较 effort。相同 effort 标签只是配置控制，不证明内部计算量相等。还要保留超时、重试、拒绝和无输出记录，不要悄悄用成功重跑替换这些案例。

只有 5.2 达到质量线，并改善明确目标——如每个合格任务成本、困难案例完成度或审核投入——才升级。5.1 仅保留到经过测试的回滚方案不再需要为止，并区分模型回滚与签名会话状态恢复。

相关文档：Ofox 模型目录、用量追踪、原生 Messages。若比较运行在调用工具后失败，先解决工具结果配对错误，再把结果用于判断推理质量。