Fable 5.1 打破两个 Operator 假设：`tool_choice` 强制调用和 Thinking Block 复用

Claude Fable 5.1 于 9 月 1 日发布，发布说明中有两处变更很容易被略过。一个是立即打破强制调用工具模式的 400 错误。另一个是对 Thinking Block 的约束，会静默降低多轮 Agent 会话质量——对于 8 月 31 日之后创建的账户，这也变成了硬性 400 错误。两者都没有宽限期，都在今天生效。

tool_choice 移除：什么会中断，以及 Anthropic 为何做出这个取舍

Fable 5.1 和 Mythos 5.1 不支持 any 或 tool 类型的 tool_choice。发送任一类型将返回 400 错误。auto 和 none 保持不变。

any 类型告诉 Claude 本轮必须至少调用一个工具。tool 类型强制指定命名工具。两者都被需要 Agent 步骤结构化输出的 Operator 广泛使用——例如期望工具调用 JSON 而非散文输出的分类管道，或每轮都必须返回带类型 Schema 的数据提取 Agent。

在 Fable 5.1 上，两者都不再可用。Anthropic 给出的实际原因是：该特性的功能——保证 Schema 合规的工具输入——现在由两个独立机制更好地提供：严格工具使用（在工具定义上设置 strict: true，使用语法约束采样）和结构化输出（顶层 output_schema 参数，直接返回 JSON 对象）。两者都比 tool_choice: tool 提供更硬的 Schema 保证，因为它们在 Token 采样层面强制执行，而不是生成后检查。

如果您使用 tool_choice: tool 来保证单个命名工具的结构化返回值，请迁移到结构化输出。在消息请求上直接定义 output_schema，而不是定义工具并强制模型调用它。您将从响应体中直接获取匹配 Schema 的 JSON 对象，而不是在 tool_use 块内部。

如果您使用 tool_choice: any 来确保模型在应该采取行动时不返回散文，请迁移到严格工具使用。在每个相关工具定义上添加 "strict": true。模型仍然选择调用哪个工具，但当它调用工具时，输入将始终匹配您的 JSON Schema——无类型强制转换，无遗漏必填字段。

跨提供商上下文很重要。OpenAI 的 tool_choice: required（类似 any）和 tool_choice: {"type": "function"}（类似 tool）在其最新模型上仍然可用。Google Gemini 也有等效的 tool_config.function_calling_config.mode: ANY。运行跨提供商路由层的 Operator 需要让 Fable 5.1 分支走结构化输出或严格工具使用路径，而不是翻译成强制调用参数。

Thinking Block 版本门控：模型绑定和对话绑定

第二个变更更为微妙，有两层独立的强制执行。

第一层：模型绑定。 Fable 5.1 或 Mythos 5.1 产生的 Thinking Block 只能被这两个模型或更新模型读取。如果您的会话回退到旧模型——例如，分类器拒绝触发回退到 Claude Sonnet 5——旧模型无法读取来自 Fable 5.1 轮次的 Thinking Block。API 会在请求到达模型之前将其删除。

没有 thinking-binding-controls-2026-08-01 Beta Header 时，这种删除是静默的。API 不通知您发生了什么。有了 Beta Header，响应包含 input_transformations 字段，将每个被删除的 Block 报告为 model_binding_mismatch。

反向不适用：Fable 5.1 可以读取旧模型列表上每个模型产生的 Thinking Block（Claude Opus 5、Fable 5、Mythos 5 及更早版本）。将对话切换到 Fable 5.1 保留先前的推理。切换到任何旧模型会丢失那次请求的 Fable 5.1 推理。

第二层：对话绑定（前缀不匹配强制执行）。 Fable 5.1 Thinking Block 的 signature 涵盖 system 提示、tools 列表以及之前的每条消息。如果在后续轮次中重放该 Block 之前，上述任何内容发生变化，该 Block 在该对话中不再有效。

对于2026 年 8 月 31 日或之后创建的账户，API 立即强制执行：在前缀更改后重放 Thinking Block 返回 400 错误。

对于较旧账户，检查目前仅记录在 signature 中但不强制执行——除非请求设置了 thinking.block_binding.prefix_mismatch_behavior。Anthropic 明确表示，对较旧账户的强制执行将在未来模型上生效。现在就是在被强制执行之前修复应用程序的窗口期。

打破此检查的模式正是以前看似无害的那些：在轮次之间编辑 system 提示（在向每轮注入每用户上下文的多租户系统中很常见）、在会话中删除或添加工具，或为管理上下文长度而进行的任何历史记录截断或消息编辑。

修复路径：

• 仅追加对话历史。 永不编辑先前消息。将新上下文作为新消息注入，而不是修改 system 提示。这与保持提示缓存热的模式相同。
• 轮次范围系统消息（通过 mid-conversation-system-clear-at-2026-08-21 Beta Header）。在中间对话 role: system 消息上设置 clear_at: "next_user_message"，在不触及顶层 system 提示的情况下注入每轮上下文。该消息仅对该轮有效，之后以零 Token 成本保留在历史记录中。
• 现在就针对强制执行进行测试，发送 thinking.block_binding.prefix_mismatch_behavior: "error" 加 Beta Header。较旧账户会收到与新账户相同的 400 错误，在测试环境中暴露不兼容模式。

在将生产流量路由到 Fable 5.1 之前需要更改的内容

两个破坏性变更相互影响。从 Fable 5 迁移到 Fable 5.1 的 Operator 可能同时在请求形状上遭遇 tool_choice 错误，并在 Thinking Block 处理中积累前缀不匹配违规。分别运行两个检查会遗漏修复方案属于同一迁移的不同部分这一事实。

审计清单：

1. 在代码库中搜索 type: "any" 或 type: "tool" 的 tool_choice。 每一个命中在 Fable 5.1 上都会立即失败。按调用点决定结构化输出还是严格工具使用是正确的替换——它们是具有不同人机交互的不同接口。
2. 在指向 Fable 5.1 的测试环境中启用 thinking-binding-controls-2026-08-01。在 input_transformations 中观察 model_binding_mismatch 删除。如果回退路径中出现任何删除，请添加显式 Block 过滤或重新设计回退以仅保留消息。
3. 在预发布环境中设置 prefix_mismatch_behavior: "error" 以在转变为生产 400 错误之前暴露对话历史编辑模式。通过将突变转换为追加来修复。
4. 检查在轮次之间向 system 字段注入每用户上下文的多租户会话模式。这些在没有任何代码更改的情况下打破前缀绑定——由配置驱动，因租户而异。轮次范围系统消息是最简洁的修复方案。

来自同一版本的缓存重新定价角度——Fable 5.1 缓存读取为 $0.25/MTok，即基础输入价格的 0.025 倍，而其他所有模型为 0.1 倍——是一个独立的故事。但值得注意的是，前缀绑定强制执行和仅追加缓存规范是同一规范：正确实施迁移以修复 Thinking Block 约束的 Operator，同时也会在 Fable 5.1 上获得更好的缓存命中率和更低的输入成本。约束和激励是一致的。