2026 年 11 月 9 日，Anthropic 发布了 Claude Fable 5.2。官方将其定位于高难度推理和长周期智能体任务，重点面向复杂编程、多步骤研究，以及需要持续推进才能交付结果的技术工作。

对开发者来说，真正值得关注的不是“又出了一个新模型”，而是三个问题：

• 已经在用 Fable 5.1，有没有必要升级？
• Opus 5.5 已经很强，为什么还需要 Fable 5.2？
• 接入 API 时，是不是改一下模型名称就够了？

下面从规格、评测、价格和工程接入四个角度展开。

一、先理清定位：Fable 5.2 不是“版本号更小的 Opus”

首先要避免一个误区：不能跨产品线，单纯根据 5.2 和 5.5 的数字判断模型强弱。

Fable 5.1 是 Fable 5.2 的同系列前代；Opus 5.5 则是另一条产品线的主力模型。Anthropic 的建议是：多数日常编程和知识工作先用 Opus 5.5，遇到更复杂、开放性更强的技术任务，再考虑 Fable 5.2。

这里的“长周期智能体任务”，可以理解为：模型不仅回答一个问题，还要在工具环境中反复执行“分析—操作—检查—修正”，逐步完成整个任务。

因此，理解 Fable 5.2 的重点，不是看它能不能写出一段更漂亮的回答，而是看它在复杂任务里能否更有效地推进工作。

二、基础规格对比：上下文没变，价格和默认配置有区别

先把三款模型放在同一张表里，输入价格指基础输入价格，缓存读取单独列出。

这张表说明了两件事：

第一，Fable 5.2 并不是靠扩大上下文窗口来体现升级，三款模型在这项规格上相同。

第二，Fable 5.2 相比 Fable 5.1 的基础输入、输出及缓存读取单价均下降了 20%；但与 Opus 5.5 相比，其基础输入和输出单价仍是两倍，缓存读取单价则相同。

这里必须区分“每 token 单价”和“完成一次任务的总成本”。模型用了多少思考 tokens、调用多少次工具、是否需要重试，都会影响最终账单。

三、相比 Fable 5.1，能力提升主要体现在哪里？

1. 编程、研究和图表理解，是值得关注的方向

以下为 Anthropic 发布公告中的部分评测成绩，不是本文的独立测试结果。

评测项目	Fable 5.2	Fable 5.1	Opus 5.5
FrontierCode 2.0：智能体编程	49.1%（xhigh）	32.4%（xhigh）	45.5%
FrontierSWE v2：软件工程任务	69.9%	56.3%	62.3%
Terminal-Bench-Science 0.1：智能体科研任务	74.6%	52.6%	58.7%
WANDR：智能体搜索，relaxed score	82.1%	68.7%	72.3%
Humanity’s Last Exam：使用工具	74.2%	65.6%	67.7%
Chartography：不使用工具的图表识别	73.4%	44.8%	64.4%

官方说明：除特别标注外，成绩采用各模型最高可用 effort；上述三款模型的成绩默认开启安全防护。这里也没有把公告中单独标注为 Mythos 的成绩算到 Fable 头上。

以 FrontierSWE v2 为例，Fable 5.2 相比 Fable 5.1 提高了 13.6 个百分点。这是该评测上的分数变化，不能直接解释为“所有项目开发效率提高 13.6%”。

对实际选型而言，我更建议用以下任务验证这些提升是否有价值：

• 跨多个模块定位问题，而不只是修改单个函数；
• 完成功能开发后，继续补测试、检查回归；
• 综合代码、日志和文档中的信息；
• 对研究任务进行多轮查证，而不是输出一份看似完整的总结。

这些是建议的验证方向，不是对模型成功率的保证。

2. 不能据此得出“所有场景全面领先”

即使只看官方公告，也并非每一项指标都是 Fable 5.2 更高。

例如，AA-Briefcase v1.1 的 Elo 指标中，Fable 5.2 为 1785，Opus 5.5 为 1800；同一评测的 rubric 指标则是 Fable 5.2 更高。

这提醒我们：不同指标衡量的是不同侧面。“某些高难度任务更强”，不等于“所有回答都更好”。

四、价格下降、输出更快，但别误读成“任务必然更省更快”

1. 单价下降，不代表每次任务固定省 20%

Fable 5.2 相比 Fable 5.1 的标准输入、输出单价下降了 20%，这是可以直接核对的变化。

但官方迁移文档也指出：在某些智能体编程环境中，Fable 5.2 在较高 effort 下会启动子智能体检查自己的工作，而子智能体可能占据会话成本的较大部分。

因此，评估成本时最好同时记录：

• 输入、缓存写入和缓存读取 tokens；
• 输出及思考 tokens；
• 工具调用和重试次数；
• 最终任务是否通过验收。

只比较单次请求价格，很容易忽略返工成本。

2. “最多快 30%”说的是输出生成速度

Anthropic 表示，Fable 5.2 相比 Fable 5.1 的输出生成速度最多提高 30%；另外提供可选 Fast mode，token 生成速度最多可达到标准模式的 2.5 倍，价格为输入 16、输出80／百万 tokens。这里的关键词是“输出生成速度”。

完整任务耗时还包括思考、工具执行、文件读取、网络等待和多轮检查，因此不能把这一数字改写成“所有任务都能快 30%”。

Fast mode 也不是免费提速，需要单独评估延迟收益是否值得额外成本。

五、Fable 5.2 和 Opus 5.5，实际应该怎么选？

官方给出的选型原则比较明确：多数任务先从 Opus 开始；如果提高 effort 后仍无法满足要求，再考虑 Fable 5.2。

结合这个原则，可以采用以下验证顺序：

任务类型	建议的起点
日常问答、文档整理、常规开发	先测试 Opus 5.5
已有工作流效果稳定、成本敏感	保留现有方案，做小规模对照测试
多次尝试仍难以解决的工程问题	将 Fable 5.2 加入对照
长时间、多步骤、需要反复验证的任务	重点评估 Fable 5.2 的完成率与总成本
大量重复、规则明确的简单任务	不必直接选择最高档模型

这张表是选型建议，不是性能承诺。

对于已经使用 Fable 5.1 的项目，升级评估的理由更直接：新版本单位价格更低，官方公布的多项评测更好，而且 Fable 5.1 已被官方标为 Legacy，文档建议考虑迁移到 Fable 5.2。

但“值得评估升级”，仍不等于“可以不做回归测试直接替换”。

六、开发者注意：迁移不只是改一个模型名

Fable 5.2 的原生 API 模型标识为：

claude-fable-5-2

这不仅仅是官方模型标识，大多数第三方中转也是如此，比如myapi-ai

myapi-ai.com

官方价格的0.6倍，很适合想体验的朋友去试试，注册送免费额度，另外还有无门槛的每日签到，简单测试绝对够用

1. 思考始终开启，使用 effort 调整深度

Fable 5.2 支持 low、medium、high、xhigh、max 五档 effort，API 默认是 high。官方建议从 high 开始验证，在确有收益时提高到 xhigh，而不是所有请求都直接使用 max。

以下是原生 Messages API 请求体示意，并非实测结果：

{
  "model": "claude-fable-5-2",
  "max_tokens": 16384,
  "thinking": {
    "type": "adaptive"
  },
  "output_config": {
    "effort": "high"
  },
  "messages": [
    {
      "role": "user",
      "content": "请分析以下代码的并发风险，给出修改方案和测试用例：<代码>"
    }
  ]
}

这类请求应省略 temperature、top_p、top_k；max_tokens 则需要为思考和最终回答共同预留空间。不能再用 thinking: disabled 关闭思考，也不能使用旧式 budget_tokens 手动思考配置。

注意，这些思考限制在 Fable 5.1 中已经存在，并非全部都是 5.2 新增的变化。

2. 从 Fable 5.1 升级，重点检查四类兼容性变化

检查项	需要注意的变化
会话前缀校验	5.2 对所有账号执行校验；修改此前的系统提示、工具或历史消息后，再回传受影响的 thinking blocks，默认可能触发 400 错误
跨模型切换	Fable 5.1、Opus 5.5 等模型不能读取 Fable 5.2 生成的 thinking blocks
Computer use	除 Amazon Bedrock 外，旧版 computer_20251124 工具会报错，需要迁移到新工具集
Advisor 配对	Fable 5.2 作为执行模型时，Advisor 必须使用 Fable 5.2 或 Mythos 5.2

这些是官方列出的主要破坏性变更，尤其值得自建 Agent、会话存储和模型路由系统检查。

另一个容易忽略的细节是：thinking blocks 还与生成它们的账号绑定。由其他未关联账号回传时，API 会丢弃这些块，即使请求本身仍然成功。

所以，HTTP 请求成功，不一定意味着完整的会话推理状态被保留下来。

3. 企业接入还要确认数据保留要求

Fable 5.2 默认要求 30 天数据保留；除非获得 Anthropic 明确授权，否则不适用于零数据保留安排。

涉及企业源码、客户资料或敏感业务数据时，这项要求应在接入之前确认，不能只比较模型效果和价格。

七、为什么同一个模型，在不同工具里用起来还不一样？

模型名称一致，只能说明比较的起点相同，不能单独证明最终体验完全一致。

一个直接的例子是默认配置：官方 API 文档列出的 Fable 5.2 默认 effort 为 high，而发布公告说明 Claude 应用和 Claude Code 的默认 effort 为 medium。

如果不统一这些条件，比较响应速度、回答深度和成本，就可能得出错误结论。

评估不同客户端或 API 接入方式时，建议至少检查：

1. 模型与参数：实际使用的模型版本、effort 是否明确；
2. 工具调用：工具定义和返回结果是否完整；
3. 会话状态：历史消息及 thinking blocks 是否被正确保留；
4. 缓存计费：是否区分缓存写入、读取和普通输入；
5. 长任务表现：是否存在超时、中断或重试后重复执行。

与其只看一个价格倍率，或者问模型一道题，更有价值的做法是：用同一组真实任务，比较完成质量、总成本和稳定性。

总结

Fable 5.2 相比 Fable 5.1 的主要变化，可以概括为：多项复杂任务评测提升、标准 token 单价下降，以及输出生成速度提升；但它并没有因此取代 Opus 5.5 的日常主力定位。

如果已经在使用 Fable 5.1，值得安排一次完整的升级回归；如果目前使用 Opus 5.5 且效果稳定，则更适合先把 Fable 5.2 用在那些确实难以解决的任务上。

选模型的最终标准，不是版本号，也不是单项跑分，而是在你的工作流中，能否以可接受的成本，稳定交付可验证的结果。