Claude Fable 5 初体验：一位运营者的视角

目录

2026 年 6 月更新。

TL;DR： Fable 5 是 Anthropic 能力最强的模型，在高难度、长周期的智能体任务上表现尤其突出——但它并不是默认的升级选择。它每 token 的价格更高，使用了一种新的分词器，会让你的 token 数膨胀约 30%，运行着无法关闭的常驻 thinking，还可能在分类器层面拒绝请求。对于大多数工作负载，Opus 4.8 仍然是正确的选择。只有当任务真正困难时，才动用 Fable 5。

【运营者视角】 我在一个咨询品牌和一家匹克球场馆里运维着 30 多个生产级智能体，所以一个新的旗舰模型对我来说不是一个跑分——它是一笔开销，也是一次迁移。下面就讲讲我真正把 Fable 5 接入其中几个智能体时发生了什么变化，以及哪些地方我仍然保留着 Opus 4.8。

Fable 5 到底是什么

Claude Fable 5 是 Anthropic 大范围发布过的能力最强的模型。它瞄准的是难度光谱中最苛刻的那一端：深度推理和长周期智能体任务——也就是那些需要智能体在数十次工具调用之间始终守住整个计划、不让思路断线的运行。

它的 API 接口与 Opus 4.7/4.8 几乎完全一致，这让测试变得很容易。默认提供 100 万 token 的上下文窗口，每次请求最多可输出 128K token。如果你在近期的 Opus 系列上构建过任何东西，这种请求结构会让你倍感熟悉。差异藏在细节里，而细节正是钱和意外所在的地方。

提一个命名上的注意点，免得你搞混：Mythos 5 是同一个模型——同样的能力、同样的定价、同样的行为——只是仅通过 Anthropic 的 Project Glasswing 项目提供。如果你不在那个项目里，你想要的模型就是 claude-fable-5。下面所有内容对两者都适用。

它真正变强的地方

我先把自己最难的智能体任务抛给了它：一个多步骤的研究与综合任务，要读一堆来源、交叉核对论断，并写出一份带引用的简报。这正是那种弱模型会漂移的活儿——大约十次工具调用之后，它们就记不清哪条论断来自哪个来源了。

Fable 5 守住了思路。综合更紧凑，引用始终牢牢挂在正确的论断上，而且它还抓出了两处来源之间的矛盾，这些是我那个 Opus 4.8 版本一直在悄悄”和稀泥”略过的。在长链条、结构化的推理上，它是实打实的进步——不是边际性的跑分提升。

这就是支持它的诚实理由。如果你的智能体的失败模式是”在最难的那 10% 上崩盘”，那么 Fable 5 能缩小那道差距。如果你的智能体只是在总结新闻邮件或起草社媒帖子，你根本感受不到差别——而且你还会为自己用不上的能力买单。

没人提醒你的成本陷阱

这是一个如果你只是草草扫过发布说明就会被咬一口的点。Fable 5 搭载了一个全新的分词器，同样的内容分词后大约比 Opus 系列多出 30% 的 token。

再读一遍，因为它会和价格叠加放大。Fable 5 本来定价就在 Opus 这一档之上（每百万输入 token 10 美元，每百万输出 token 50 美元）。现在再在每条 prompt 和每次补全上叠加约 30% 的 token 膨胀。一个原封不动的工作负载——同样的 prompt、同样的输出——在迁移后可能花费明显更多，而你对智能体所做的事情还一个字都没改。

所以千万不要沿用你的旧数字。你的 max_tokens 设置、你的上下文窗口预算、你的每次运行成本估算——它们全都是在另一个分词器上测出来的。好消息是：当你传入 model: "claude-fable-5" 时，token 计数端点会返回两种分词器下的计数，所以你可以在动任何东西之前，先在你真实的 prompt 上测出这个差值。

# Measure the tokenizer delta on YOUR prompt before migrating.
# The response includes input_tokens (new) AND input_tokens_prior_tokenizer (old).
curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{ "model": "claude-fable-5", "messages": [{"role":"user","content":"<your real prompt>"}] }'

我先在自己最重的那些 prompt 上跑了这个。差值并不均匀——它会因内容而异——但”预留约 30% 的额外量，再加上价格溢价”是正确的心智模型。

thinking 始终开启——而且你无法关闭它

在 Fable 5 上，自适应 thinking 始终在运行。相对于 Opus 系列唯一一个新的破坏性变更是：如果你发送一个显式的 thinking: {type: "disabled"}，你会收到一个 400。修复很简单——直接整个省略 thinking 参数即可——但如果你之前有为了便宜、快速的调用而显式禁用 thinking 的代码，那段代码现在会报错。

你也拿不回原始的思维链。Fable 5 会保护它：你会收到正常的 thinking 块，并且可以用 display: "summarized" 请求一份可读的摘要，但未经过滤的推理过程永远不会暴露出来。对大多数应用来说这无关紧要——需要可见性的话读摘要就行。真正要紧的地方是多轮智能体：当你在同一个模型上续接一段对话时，你必须把 thinking 块原封不动地传回去。丢掉它们或编辑它们，这一轮就会出错。如果你在构建智能体循环，请把 thinking 块当作你需要逐字向前携带的不透明 token。

拒绝现在成了一个控制流问题

这是对你围绕模型编写代码的方式影响最大的变化。Fable 5 会对传入的请求运行安全分类器，主要针对研究型生物学和大部分网络安全相关内容。当一个请求被拒绝时，你会收到一个成功的 HTTP 200，带有 stop_reason: "refusal"——不是错误，也不是异常。content 数组可能为空。

如果你的代码在没有先检查 stop_reason 的情况下执行 response.content[0].text，那么在某个请求被拒绝的那一天，它就会崩溃。而且无害的相邻工作——合法的安全工具、生命科学任务——偶尔也会触发误报，所以这并不只是那些做可疑事情的人才会遇到的问题。

规则是：基于 stop_reason 来分支，绝不要基于 stop_details。

const res = await client.messages.create({
  model: "claude-fable-5",
  max_tokens: 1024,
  messages,
});

if (res.stop_reason === "refusal") {
  // classifiers declined — content is empty or partial. Don't read content[0].
  await handleRefusal(res);
} else {
  console.log(res.content[0].text);
}

在生产环境中，有一条更干净的路径：一个服务端的 fallbacks 参数（处于 beta 阶段），它会在同一次往返中自动把被拒绝的请求重试到 claude-opus-4-8 上，并应用类似抵扣额度的重新计价。如果你在无人值守地运行智能体，把它接上，这样一次误报式的拒绝就不会把整个运行带进死胡同。这正是我反复重新学到的关于智能体在生产环境中不断失败的同一个教训：模型变聪明并不会消除你处理它边缘情况的需要——它只是把边缘情况挪了个位置。

另外两个迁移细节

还有几件较小的事，它们花掉了我的时间，所以别让它们再花掉你的：

• 没有 assistant 预填充。 如果你之前是通过预填充最后一轮 assistant 回合来引导输出的，那种模式没了。改用结构化输出（output_config.format）或系统提示词指令。
• 必须接受 30 天数据保留。 Fable 5 在零数据保留下不可用。如果你出于合规原因处于 ZDR 状态，那么 Fable 5 就无从谈起，Opus 4.8 仍是你的上限。请在你规划迁移之前核实这一点，而不是之后。

你到底该不该切换？

下面是我和它共处一段时间之后的运营者判断。**Fable 5 并不是默认的”升级到最新模型”目标——Opus 4.8 才是。**这让人意外，但这才是正确的框架。Opus 4.8 相对于 4.7 只是一次模型 ID 的替换，没有新的破坏性变更，它更便宜，而且对于绝大多数智能体工作，它在输出质量上根本无法与之区分。

Fable 5 凭借真正困难的任务赢得自己的位置：必须在多个步骤之间保持连贯的长周期智能体、深度多来源推理，以及那些你想要消灭的失败本身很微妙的运行。对于这些，它的能力是实打实的，值这个溢价。而对于其他一切——内容起草、分类、路由、总结——你是在用更高的价格、更多的 token，去换你根本感知不到的质量。

我最后两个都在用。我的研究与综合智能体迁到了 Fable 5。其余一切都留在 Opus 4.8 上。这种分流正是关键所在：按任务挑模型，而不是按潮流。如果你运维着一支智能体舰队，我在我的 2026 运营者技术栈中写过的同一套纪律同样适用——把困难的活儿路由给昂贵的模型，别再为简单的活儿多花冤枉钱。

运营者的结论

在你动其他任何东西之前，先在你那个唯一最难的任务上测试 Fable 5——那里才是它见效的地方，而且如果它在那里都没能拨动指针，那它在别处也不会。拿 token 计数器去跑你真实的 prompt，这样约 30% 的分词器膨胀和价格溢价就不会在账单上给你来个措手不及。在 Fable 5 触及生产的每一处，加上一个 stop_reason: "refusal" 检查（或服务端回退到 Opus 4.8）。然后有意识地路由：困难的那 10% 交给 Fable 5，其余交给 Opus 4.8。最好的模型不是能力最强的那个——而是与任务最匹配的那个。