Claude 高阶模型升级的成本与迁移取舍

Fable 5.2 的单 token 价格是 Opus 5.5 的两倍，值得换吗？原文给出的答案是：多数任务先用 Opus，只有更强模型能减少失败、返工或执行轮次时，涨价才可能划算。程序员该比较的是「完成一件合格任务花多少钱」。

但这篇材料也有缺口：它转述了 Anthropic 的发布信息，却没有附上提到的基准表，实测部分还留着编辑占位符。下面涉及模型能力、价格和 API 的说法，都按原文说明，不能当作已独立核验的产品事实。

两倍单价，为什么未必是两倍任务成本

按原文，Anthropic 在 11 月 9 日发布 Claude Fable 5.2，定位是高难度推理和长时间运行的智能体任务。后者指模型需要连续规划、调用工具、处理反馈，经过多轮操作才能交付结果。

相较 Fable 5.1，官方宣称它在编码、推理和视觉基准上得分更高，输出速度最多提升 30%，安全机制拦截约减少 55%，还能协调大量子智能体。这里的比较对象是 Fable 5.1，不能直接套到 Opus 5.5 身上。拦截减少也不等于答对得更多。

原文还提到 Claude Mythos 5.2：底层模型相同，但没有网络安全与生物领域的安全限制，仅面向验证计划内的组织。对普通开发者来说，它不是可直接替换的选项。

价格方面，两款模型的 Batch 请求都优惠 50%；Fable 的 fast mode 标价为 $16 / $80，官方称最多快 2.5 倍。原文还列出 Fable 5.1 过去的 $10 / $50，并称 Fable 5.2 比它便宜，但没有给出当前标准模式的完整价目和计价单位，不能据此直接编预算。

单 token 价格适合看报价，每个成功任务的成本才适合做选型。

如果 Fable 能一次完成 Opus 需要反复修改的任务，较高单价可能被更少的调用抵消。反过来，两者都能稳定通过验收时，Opus 更适合作为默认选择。这是合理的成本逻辑，原文没有提供实测数字证明它已经发生。

先对齐 effort，再谈模型谁更强

原文最有用的提醒，是两款模型的默认思考强度不同：Fable 5.2 默认 high，Opus 5.5 默认 medium。两者都始终启用自适应思考，通过 effort 控制投入程度。

直接替换模型 ID 跑同一条提示词，比较的其实包含两项变化：模型变了，思考预算也变了。

下面这段代码解决的是测试条件不一致的问题，同时记录 token 用量：

import Anthropic from '@anthropic-ai/sdk';

const client = new Anthropic();

async function ask(model: 'claude-fable-5-2' | 'claude-opus-5-5', prompt: string) {
  const msg = await client.messages.create({
    model,
    max_tokens: 32000,
    output_config: { effort: 'high' },
    messages: [{ role: 'user', content: prompt }],
  });
  console.log(model, msg.usage.input_tokens, msg.usage.output_tokens);
  return msg;
}

await ask('claude-fable-5-2', 'Refactor this function...');
await ask('claude-opus-5-5', 'Refactor this function...');

重点看 output_config: { effort: 'high' }：两次调用显式使用相同档位。原文称代码通过了 @anthropic-ai/sdk 1.8.0 的类型检查，这不代表已经完成线上调用验证。

另一个关键是 max_tokens: 32000。按原文，它同时覆盖思考和最终答案，预算不足可能截断长回复。合法档位包括 low、medium、high、xhigh、max；官方建议 Fable 从 high 起步，最难的长期任务在测出收益后尝试 xhigh，max 留给能力上限测试。

相同 effort 能消除一个明显干扰因素，但不保证两款模型消耗相同 token。最终仍要记录完整任务中的调用、重试和验收结果。

迁移 API，不能只替换模型 ID

原文列出的兼容性变化，会直接影响现有 Node 调用封装：

• 强制工具调用不兼容，tool_choice 设为 any 或指定工具会返回 400，需要让模型自行选择工具。
• 应省略 temperature、top_p 和 top_k，其中部分取值会返回 400。
• 不能通过 thinking: { type: "disabled" } 关闭思考，需要用 effort 调整速度和成本。
• Fable 5.2 默认要求保留数据 30 天，依赖零数据保留的团队需要先确认适用条件。

前两项尤其容易藏在公共 SDK 包装层里。业务代码可能只传了模型名称，底层却统一注入采样参数，切换后就可能报错。

工具调用还有行为层面的影响。如果现有流程依赖「下一步必须调用某个工具」，改成模型自由选择，就要重新验证流程能否正常推进。请求成功返回，不代表业务步骤一定完成。

我的判断

我认同「Opus 默认，Fable 按评测升级」的取舍。相比全量切换，把昂贵模型用于普通模型反复失败的复杂任务，更容易判断额外支出买到了什么。

但原文的证据不足以支持明确的能力排名。它说基准来自官方、使用各模型最高 effort、开启 Fable 安全机制，还提到 Opus 在 AA-Briefcase Elo 一项领先，却没有展示表格或分数，读者无法判断差距大小。

所谓「我们试过」也没有形成有效实测：提示词、双方 effort 和观察结果都还是编辑占位符。作者自己承认单条提示词不能算评测，但这里连完整的一次演示都没交付。

因此，减少重试能抵消两倍单价，目前是待验证的假设。网络安全和生物请求还可能因安全机制被路由到能力较弱的模型，这类团队更不能只参考通用编码表现。

能拿来做什么

• 从日常工作里选 10 到 20 个真实任务，例如函数重构、缺陷修复和跨文件修改，先明确测试通过、行为正确等验收条件，再比较两款模型。
• 在 Node 调用层显式设置相同 effort，记录每次调用的输入与输出 token，并把失败和重试开销一起计入每个成功任务的成本。
• 切换前检查公共封装里的 tool_choice、采样参数和 thinking 配置；对于必须执行工具的流程，单独验证实际执行结果。
• 保留 Opus 5.5 作为默认候选，只在它提高 effort 后仍不达标的任务上评估 Fable 5.2，并将评测任务留作后续模型升级的回归样本。