目录

迁移到 Claude Fable 5.1，并不是把模型ID换掉就完事。官方明确写着“其中3项是破坏性变更”（What's new in Claude Fable 5.1）。而且其中2项，报错的位置和原因离得很远——属于不容易察觉的那一类。

⚠️ ③会在2026年8月31日及以后创建的账户上强制生效。在此之前创建的账户，API只是把不一致记录下来，只有我们明确指定时才会反映到行为上。

也就是说，“我们这边跑得好好的，所以没事”取决于账户的创建时间。新建的验证环境会失败，而生产环境不会，这样的矛盾是可能出现的。

1. 先说定位——这不是旗舰的换代

这里搞错了，就会误判迁移本身的决策。Fable 5.1 是 Fable 5 的后继，而不是用来取代 Opus 5 的。

官方文档的写法很明确——“大多数工作负载都应从 Claude Opus 5 开始”。用 Fable 5.1 的场景是“要求苛刻的推理和长时间的智能体作业”，或者“把 Opus 5 调到高 effort 评测之后仍然不够用的时候”。

　 Claude Fable 5.1 Claude Opus 5
定位 要求苛刻的推理、长时间的智能体作业 先从这里开始（复杂的智能体式编码与企业应用）
价格（每100万token） 输入 $10 / 输出 $50 输入 $5 / 输出 $25
缓存读取 $0.25（基础输入的0.025倍） 基础输入的0.1倍
知识截止 2026年6月 2026年5月
上下文 / 最大输出 1M / 128k 1M / 128k
停止提供不会早于 2027年9月1日 2027年7月24日

Fable 5 并没有消失。在官方的模型列表里，它作为 legacy（继续提供）保留着。迁移目前并没有被强制——不过如后文所述，成本会下降。

Mythos 5.1 性能相同，只有安全装置不一样。提供范围仅限 Project Glasswing 的参与者。

📌 订阅这一侧的事：发布当天用量被重置了。官方的 @ClaudeDevs 宣布，配合 5.1 的上线，已重置所有用户的5小时窗口和每周窗口。这说的不是 API 计费，而是 Claude Code 等订阅的用量额度，而且它不是永久规格，只是配合重大发布的临时措施。这类重置过去发生过多少次、哪些已确认、哪些仍未证实，可参见核查每周限额提前重置的那篇文章。另外，每周限额本身将在2026年9月14日修订，如果你要按额度来做计划，也请一并确认。

2. 破坏性变更①——强制工具调用会返回400

这一项会立刻报错，所以最容易发现。

tool_choice: type "tool" and "any" are not supported for this model.

给 tool_choice 指定 {"type": "any"} 或 {"type": "tool", "name": "..."}，就会返回 400 invalid_request_error。默认的 {"type": "auto"} 和 {"type": "none"} 没有变化。同样的校验也作用于统计token数的端点。

💡 官方给出的理由是说得通的。这个模型的思考是常开的，一旦强制调用工具，那部分思考就会被跳过。模型会把本该想清楚的内容写进工具参数里，于是参数质量下降——所以就把这条路堵上了。

那么该怎么替代

想让它守住 schema 的话

保持 tool_choice: auto 不变，改为设置 strict: true（strict tool use），或者转向 structured outputs

必须让它用工具的话

在提示词里写清楚什么时候用（“天气问题请用 get_weather 工具回答”）。官方称“Fable 5.1 会可靠地遵循明确的工具指令”

3. 破坏性变更②——思考块与模型绑定

从这里开始就麻烦了。思考块现在会记录它是由哪个模型生成的，而且能被保留的方向变成了单向。

✅ 能保住的方向

从上一代（Opus 5、Fable 5 及更早）迁到 Fable 5.1 的对话，可以带着推理继续跑下去

❌ 会丢掉的方向

从 Fable 5.1 退回上一代时，在那里跑过的那几轮推理就没了。上一代读不了 Fable 5.1 的思考块

⚠️ 最危险的一点是，默认情况下它会悄无声息地失败。当一个请求里混进了读不了的块，API会在交给模型之前就把那些块丢掉。被丢掉的部分不计入 input_tokens，也不计费——也就是说，账单上同样看不到。

会被这一点扎到的，是在对话中途切换模型的做法。路由器、降级回退、为压低成本而做的动态模型选择。它们都可能落到“看上去在正常工作，只有推理悄悄没了”的状态。

想让它变得可见，就加上 thinking-binding-controls-2026-08-01 beta 请求头。这样丢弃就会被报告在顶层的 input_transformations 数组里。不加就完全没有报告。

4. 破坏性变更③——编辑过去的轮次就会坏掉

3项当中，对现有代码影响面最广的就是这一项。只要改动了位于 Fable 5.1 思考块之前的东西——system 提示词、tools、更早的那些消息——下一次请求就会报错。

The block is bound to a different conversation

会让后续思考块全部失效的模式

  • 编辑、重排或删除过去的轮次，同时保留它后面的轮次
  • 把每次请求专用的文本插进过去的轮次，再在下一次请求里删掉（提醒语或状态行）
  • 在同一个对话里重新构建 system 提示词或 tools 数组
  • 图片或文档的URL在后续请求中返回了不同的字节（被检查的是字节而不是URL，所以只要是同一个文件，签名URL在轮换也没问题）

反过来，做了也不会坏的事

  • 从思考块的最前面连续地往后移除（按从旧到新的顺序）
  • 用服务端的压缩或上下文编辑来削减历史
  • 移动 cache_control 标记
  • 在请求之间改变 effort

要注意的是，只要从最前面以外的位置抽掉一个思考块，之后的就会全部失效。

⚠️ 是否适用，会随账户的创建时间而变。这项检查在2026年8月31日及以后创建的账户上强制生效。在此之前创建的账户，API只是把不一致记录下来，只有设置了 thinking.block_binding.prefix_mismatch_behavior 时才会反映到行为上。

新建的验证环境会失败，生产环境却不会，这样的矛盾是可能出现的。反过来也一样。

怎么查自己的代码是否中招

官方给出了具体步骤。指定 prefix_mismatch_behavior: "drop_block" 跑一个会话，把 input_transformations 打到日志里。如果确实在编辑历史，那里就会出现 reason: "prefix_binding_mismatch"。

另外，Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDK 在设计上就不会破坏这个前缀部分。受影响的只有自己动手组装 messages 数组的代码。

5. 缓存读取降到四分之一——实际能省多少

输入和输出都没有涨价。变的只有缓存读取。

项目 每100万token
基础输入 $10
缓存写入（5分钟） $12.50
缓存写入（1小时） $20
缓存读取 $0.25
输出 $50
批处理 输入 $5 / 输出 $25

效果有多大，取决于“被缓存的前缀会被反复读多少次”。在其他Claude模型上，缓存读取是基础输入的0.1倍，而在 Fable 5.1 和 Mythos 5.1 上是0.025倍。越是反复读同一段前缀的长时间智能体运行，差距就越大。

官方给出的效果是典型工作负载约降低25%，智能体色彩浓的作业最多约降低45%。缓存写入，以及512个token的最小可缓存长度，都没有变化。

6. 不改代码也会变的7个行为

这里最容易在迁移时被漏掉。API规格没变，但出来的东西变了。官方列了7项。

并行工具调用变少

在 Fable 5 会一次性发出去的场合，可能变成一轮只调用一次。回答质量不会下降，但token、往返次数和实际耗时都会增加

进度播报变少

在高 effort 下尤其明显。如果界面依赖实时播报，看上去就像没有反应

low effort 下倾向凭记忆作答

调用搜索、检索类工具的频率下降。需要新信息的轮次要把 effort 调高

行文变密

句子可能变长，段落之间的断开变少

排版变少

比以前更少用粗体、标题和项目符号。为旧模型写的“不要排版”指令现在会用力过猛

摘要里不标明引用

在概括文档时，更容易把原文的段落原样复现出来，却看不出那是引用

小改动也会重写全文

结果一样，却要多花输出token和时间

每一项官方都准备了提示词层面的对策。并行调用就加上一句“互相独立的读取请一起发出”，需要进度就明确要求开头、中途和收尾各说一次，诸如此类。

7. 新增的功能

官方一共列了5项新增。其中1项是缓存读取降价，因为影响很大，已经单独放到第5章。这里看剩下的4项。

对话中途改变 effort（beta）

可以不破坏提示词缓存地上下调节效率。难的工序调高，套路化的调低

只在本轮生效的系统消息（beta）

clear_at: "next_user_message"。这是为了安全地替换③里“插进去再删掉”的做法而做的功能，不会改写历史

以文本形式接收进度（beta）

display: "updates"。推理依然隐藏，只把工具调用之间的进度作为正文接收

内容来源标识

在生成文本里加统计式水印。既不增加token也不增加隐藏字符，不携带用户或组织的信息。图片和视频则用 C2PA

请留意第2项。针对破坏性变更③所禁止的“插入提醒再删掉”这种写法，官方同时准备了达成同一目的的替代方案。迁移的形式不是“别这么干”，而是“搬到这边来”。

8. 迁移步骤——5项确认

在把模型ID换掉之后，官方列了以下5点。

model = "claude-fable-5"    # Before
model = "claude-fable-5-1"  # After
　 要确认的事
1 去掉 tool_choice 里的 any 和 tool。schema强制改用 strict tool use 或 structured outputs
2 原样返回思考块，历史只做追加。原先插进去再删掉的东西，改用只在本轮生效的系统消息；system 和 tools 的变更，改用对话中途变更的功能
3 把 effort 从默认值（high）重新调一遍。也可以考虑在对话中途改
4 看看智能体的循环里是不是变成了一轮只调用一次
5 把评测重跑一遍。拒绝的处理、降级回退、token计数都没有变化

拒绝相关的部分没有变。stop_reason: "refusal" 仍然会返回，被认可为 Fable 5.1 降级目标的是 Opus 4.8 和 Opus 5。在产出输出之前到来的拒绝不计费，切换模型所产生的提示词缓存费用会以降级抵扣额度返还。

📌 数据保留期为30天，原则上不能使用零数据保留（Anthropic明确批准的情况除外）。它和 Fable 5、Mythos 5 一样属于 Covered Model。这一点根据合规要求，可能直接左右能不能采用。

总结

  • 这不是旗舰的换代。官方明确写着“大多数用途都从 Opus 5 开始”，Fable 5.1 面向的是要求苛刻的推理和长时间的智能体作业
  • 破坏性变更有3项。强制工具调用返回400 / 思考块与模型绑定 / 编辑过去轮次导致失效
  • 第2项会悄无声息地失败。读不了的块会被丢掉，账单上也看不到。想察觉就得加beta请求头
  • 第3项按账户的创建时间决定是否适用（2026年8月31日之后为强制）。验证环境和生产环境的行为可能对不上
  • 没有涨价，只有缓存读取降到四分之一（基础输入的0.025倍）。效果取决于同一段前缀要读多少次
  • 不改代码也有7个行为会变。尤其是并行工具调用变少这一点，直接关系到成本和时间

FAQ

Q1. 应该马上迁移吗？

没有人在催。Fable 5 作为 legacy 仍在提供，官方也表态停止提供不会早于2027年9月1日。迁移的动机是成本——缓存读取降到四分之一，所以越是反复读同一段前缀的长时间运行，越划算。反过来，如果主要是短小的一次性调用，差别就不大。

Q2. 只是在用 Claude Code 的话，会受破坏性变更影响吗？

③不受影响。官方明确写着Claude Code、claude.ai、Claude Managed Agents、Claude Agent SDK 在设计上就不会破坏前缀部分。受影响的是自己动手组装 messages 数组的代码。

Q3. 我们有动态切换模型的机制。要改什么？

这里正是②的主战场。从 Fable 5.1 切回上一代时，那一轮的推理会丢失。而且默认情况下是被悄悄丢掉的，账单上也不会出现。先加上 thinking-binding-controls-2026-08-01 beta 请求头，把 input_transformations 打到日志里，先测出实际有没有发生丢弃，这才是第一步。

Q4. Opus 5 和 Fable 5.1，该选哪个？

照搬官方的说法是妥当的——先用 Opus 5 试，“连高 effort 都不够用的时候”再上 Fable 5.1。价格在输入和输出上都是 Opus 5 的两倍，唯独缓存读取反而更便宜。区分使用的细节，在选型指南里讲。

Q5. 我想删掉思考块来节省上下文

删的方式是有条件的。从最前面按由旧到新连续移除没有问题，但从中间抽掉一个，之后的思考块就会全部失效。如果用服务端的上下文编辑或压缩，就不算编辑。

Q6. 说是会加水印，那会影响输出吗？

官方称不会影响——不改变含义、质量和可读性，既不增加token也不增加隐藏字符，也不包含用户或组织的信息。请求和响应都不需要改动。图片和视频会通过 Files API 带上 C2PA 的 Content Credentials。

Q7. Mythos 5.1 能用吗？

性能和 Fable 5.1 相同，但提供范围仅限 Project Glasswing 的参与者。差别在安全装置，比如在 Terminal-Bench 4.0 上，Fable 5.1 是55.8%，而 Mythos 5.1 是60.9%——官方解释说，这是同一个模型只有安全装置不同所带来的差距。

相关文章