Claude Fable 5.1 详解：Claude API 降低缓存成本，却收紧迁移规则

对于需要长时间运行的智能体任务，Claude Fable 5.1 值得纳入测试，但它并不是所有 Claude 集成的即插即用升级。Anthropic 于 2026 年 9 月 1 日发布该模型，将缓存读取价降至每 1M token $0.25；与此同时，更严格的 Claude API 规则可能让强制工具调用和修改过的对话历史失效。

Claude API 中的 Fable 5.1 到底是什么

Fable 5.1 面向那些需要持续推进的工作：让编码智能体跨服务追查故障，让研究智能体沿着多个来源梳理证据，或让文档智能体把一大批文件整理成最终交付物。它的 API 模型 ID 是 claude-fable-5-1，所有 Claude API 客户均可使用，Amazon Bedrock、Claude Platform on AWS、Google Cloud 和 Microsoft Foundry 也已提供该模型。

这里最关键的词是模型。它不是一款新应用，也不会取代整个 Claude 产品。Anthropic 依然建议大多数 API 开发者先从 Claude Opus 5 开始；只有在高难度推理或长周期任务仍无法通过自己的 Opus 评测时，才需要升级到 Fable 5.1。Claude Mythos 5.1 使用相同的底层模型，但安全防护不同，并且仅向获批的 Project Glasswing 客户开放。Anthropic 当前的模型指南明确说明了这一区别。

默认上下文窗口为 1M token，输出上限为 128k token。上下文窗口就是模型处理当前请求时的工作记忆，其中包括指令、消息、文件、工具、工具结果、思考过程和正在生成的答案。1M token 的容量很大，但并不代表每个 token 都能发挥作用。Anthropic 自己的上下文指南也警告了“上下文腐化”问题：无关内容不断堆积时，模型的召回率和准确度可能下降。

自适应思考始终开启。你可以用 5 个 effort 级别控制模型投入的计算量：low、medium、high、xhigh 和 max。建议从 API 默认的 high 开始，只有评测证明降档后效果依然达标时才调低，因为即使推理文本不可见，thinking token 仍按输出计费。

本文写给 Claude API 开发者。如果你只在聊天界面使用 Claude，模型可能会改善你交给它的任务，但你无需执行任何迁移。

Claude 价格变化：看似有限，实际影响更大

Fable 5.1 并非所有项目都降价。它的基础输入和输出单价与 Fable 5 相同，两者也依旧是 Opus 5 的 2 倍。真正大幅下降的是重复上下文的成本。

提示缓存会保存已经处理过的前缀，例如系统指令、工具定义、代码仓库结构图或文档集。只要下一次请求以完全相同的前缀开头，Claude 就能直接读取缓存结果，不必再按完整输入价格重新处理。

以一个 1M-token 前缀被读取 10 次为例。Fable 5 的这些缓存读取费用为 $10，Fable 5.1 则是 $2.50。同一份重复上下文可节省 $7.50，也就是 75%；这里还没有计入新增输入或输出。Anthropic 根据其 2026 年 8 月 4 周的使用数据估算，典型按 token 计费工作负载的总成本可降低约 25%，高度智能体化的工作负载最高约可降低 45%。这些是厂商估算，但背后的单位价格很明确。当前价目表列出了每一种缓存操作。

不过，写入缓存本身也有成本：5 分钟缓存每 1M token 收费 $12.50，1 小时缓存则为 $20；默认缓存有效期是 5 分钟。前缀必须至少包含 512 token 且完全一致，同时首个响应必须已经开始，后续并行请求才能命中缓存。Anthropic 表示，5 分钟方案读取 1 次即可回本，1 小时方案则需要读取 2 次。不要想当然地认为缓存生效了，应实际检查 cache_creation_input_tokens、cache_read_input_tokens 和 input_tokens。

如果提示很短且只运行 1 次、前缀频繁变化，或智能体的大部分成本来自输出，这次调整几乎没有意义。输出价格仍是每 1M token $50，不必要的思考和冗长回答依然可能成为主要开销。

发布时的基准测试释放了积极信号，却不足以替你作出采购决定。Anthropic 报告称，Fable 5.1 在 Terminal-Bench 4.0 上得分 55.8%，Fable 5 为 42.0%；在 AutomationBench 上则分别为 31.4% 和 17.1%。这些测试采用 Anthropic 的生产环境安全防护，也来自厂商自身。它们可以成为开展真实任务评测的理由，却不能证明每种工作负载都会改善。发布报告给出了测试说明和对比结果。

谁适合使用，又该怎么用

只有一项棘手代码仓库任务的独立创业者

不必把所有编码任务都迁到 Fable 5.1。常规修改继续交给已经达标的模型，只把难啃的工作路由给 Fable，例如跨服务迁移、根因调查，或必须串联大型代码库中多项决策的审查。把稳定的代码仓库指令和工具定义放入缓存。这样既能提高高成本任务的成功概率，也无需为每个小改动支付 Fable 的费率。

正在上线工具循环的智能体平台工程师

换模型只完成了一半。还要审计智能体运行器是否强制指定工具、改写顶层系统提示、变更工具数组、删除旧消息，或在保留后续思考块的同时换入客户端摘要。这些模式都可能让原本正常的会话变成 400 错误。真正的收益不是做出更漂亮的演示，而是确保上线后多轮对话仍能稳定运行。

需要处理大型文件集的研究负责人

只有任务确实需要从长篇记录中建立关联时，才使用 Fable 5.1，而不是看到 1M 这个数字就启用它。先以 high effort 运行，对照已知结论给答案评分，再逐步下调至 medium。Anthropic 表示，medium 能以更低成本大致达到 Fable 5 的水平，但这项取舍是否成立，仍要由你自己的检索和引用检查来决定。

企业安全或数据负责人

先看政策，再看能力。Fable 5.1 属于 Covered Model，要求保留数据 30 天；除非 Anthropic 明确授权，否则零数据保留政策下不可使用。它也不支持 Priority Tier。如果其中任一条件不可妥协，就应在这里终止评估，并继续使用符合要求的模型路由。

Claude API 安全迁移 Fable 5.1 的方法

最简调用并不难。要迁移生产环境，则需要完成 4 项检查。

1. 1

   用一项真实任务建立基线

   在当前模型上运行同一项有代表性的任务，记录任务成功率、耗时、输入、缓存创建、缓存读取、输出以及任何拒绝。应选择真正值得支付 Fable 更高费率的工作，而不是玩具提示。

2. 2

   以 high effort 调用固定版本模型

   设置 API key，安装当前版本的 Python SDK，并将下面的 Python 代码块保存为 test_fable.py。

   python3 -m venv .venv
   source .venv/bin/activate
   pip install anthropic
   export ANTHROPIC_API_KEY="your-api-key-here"

   import anthropic
   
   client = anthropic.Anthropic()
   
   message = client.messages.create(
       model="claude-fable-5-1",
       max_tokens=4096,
       output_config={"effort": "high"},
       messages=[
           {
               "role": "user",
               "content": "Map the risks in moving this service from SQLite to PostgreSQL.",
           }
       ],
   )
   
   for block in message.content:
       if block.type == "text":
           print(block.text)
   
   print(message.usage.model_dump_json())

   使用 python test_fable.py 运行。以上写法符合 Anthropic 当前 SDK 和 effort 参数的语法；在生产环境中，应换成你的评测任务。

3. 3

   移除两类会导致报错的模式

   检查请求中是否把 tool_choice 设为 any 或某个指定的 tool，这两种写法现在都会返回 HTTP 400。将其保留为 auto；需要有效参数时，在工具 schema 上设置 strict: true，并在提示中告诉模型本轮必须使用哪个工具。

   随后把对话历史改成只能追加。assistant 回合必须按照返回内容原样传回，包括思考块。新的指令应作为对话中途的 system 消息添加。需要缩减上下文时，应使用服务端压缩或上下文编辑，不要重写之前的回合。

4. 4

   在接入流量前开启诊断

   使用 beta header thinking-binding-controls-2026-08-01 和 prefix_mismatch_behavior: "drop_block" 运行一次正常的多轮会话，并记录 input_transformations。出现 prefix_binding_mismatch，说明集成修改了对话历史；路由到旧模型后出现 model_binding_mismatch 则属于预期行为。

   确认历史稳定后，在包含至少 512 token 可复用前缀的请求中加入顶层 cache_control: {"type": "ephemeral"}。然后确认后续请求报告的 cache_read_input_tokens 大于 0。

必须坦诚的一点：上下文更便宜，状态规则却更严格

Fable 5.1 会将每个思考块与它之前的系统提示、工具和消息绑定。对于在 2026 年 8 月 31 日当天或之后创建的账户，只要修改此前的前缀再重放该思考块，请求就会失败，并返回 The block is bound to a different conversation。较早创建的账户现在也可以选择启用同一项检查；Anthropic 表示，未来的模型将更广泛地强制执行它。

即使不抛出错误，模型的行为也有所变化。在隐含的智能体循环中，Fable 5 可能一次并行调用多个工具，Fable 5.1 却可能只调用 1 个。它给出的进度更新更少，在 low effort 下搜索次数更少，文风可能更密集，也可能为了一个小改动重写整个文件。即使缓存费率下降，这些变化依然会增加回合数、延迟和输出量。Anthropic 针对每种行为都给出了提示词调整方法，但你仍需要通过评测来衡量自己真正关心的行为。

128k 输出这一说法背后还藏着另一项上限：max_tokens 超过 21,333 时，SDK 要求使用流式传输。思考过程与可见答案共享输出预算，因此高 effort 请求可能在可见答案开始前就消耗很大一部分。面对真正困难的工作，应给出充足上限，但不要把一个很高的上限误当成目标。

Claude Code 用户需要处理的集成工作少一些。版本 2.1.257 已于 2026 年 9 月 1 日将 Fable 5.1 设为默认 Fable 模型。你仍需关注用量、审查 diff，并把该模型留给产出足以覆盖其费率的工作。Claude Code 更新日志记录了这次模型切换。

现在应该怎么做

如果你已经在运行长周期 Fable 5 智能体，会反复发送稳定上下文，也能接受数据保留条款，就应在本周采取行动。先把一小部分流量切到 Fable 5.1，运行历史诊断，替换强制工具配置，再比较 medium 和 high effort 下每项成功任务的成本。

如果 Opus 5 或当前模型已经能通过工作负载，大多数调用都是一次性的，或你还没有代表性评测，那就先等待。Fable 的基础输入和输出价格依然是 Opus 5 的 2 倍。缓存这一项更便宜，并不能弥补错误的路由决策。

如果你只使用 Claude 聊天，不控制 API 集成，这次变化与你无关。让产品自行选择模型，再根据结果判断即可。要求常规零数据保留或 Priority Tier 的企业团队也应继续使用符合要求的路由，除非 Anthropic 给出书面授权。

如果你希望把下一次发布转化为可执行的开发决策，欢迎订阅邮件通讯。