Anthropic 昨天，也就是 2026 年 9 月 1 日，发布了 Claude Fable 5.1。我没有只读发布信息，而是花了一晚在自己的技术栈上运行它。简而言之：价格与 Fable 5 相同，缓存读取成本降低 75%，误拒绝更少，而且在连续三小时处理乏味的基础设施工作时，模型始终保持连贯。
Fable 5 是我用过的最佳模型，同时也是人们抱怨最多的模型。我曾写过它在 发布当天重建一个旧版 CRM→ 的经历，也写过 出口管制暂停及其回归→。小版本更新是 Anthropic 对这些抱怨的回应。因此，5.1 的问题很明确：那些令人不满的地方修好了吗？价格有变化吗？
Claude Fable 5.1 有哪些变化
根据 Anthropic 的公告，每 token 的价格保持不变：每百万输入 token 10 美元，每百万输出 token 50 美元。变化在于缓存读取：每百万次 0.25 美元，降低了 75%。Anthropic 估计，这会让典型工作负载的成本降低约 25%，高度 agentic 的工作负载最多可降低约 45%，因为 agent 循环会在每一轮重新发送相同的上下文。
第二个杠杆是 effort。Anthropic 表示，低或中等 effort 下的 Fable 5.1，其表现可以匹敌甚至超过 Fable 5，但成本低得多。对运营人员来说，这才是更大的变化。agent 一天中完成的大多数工作都很常规，而为常规工作支付 `xhigh` 级别的价格，是 Fable 5 账单失控的主要原因。
安全防护也发生了变化。网络安全防护每个会话拦截的误报减少了 60%；生物学防护在面对良性生物学和医学问题时的触发频率降低了 85%；Fable 5.1 现在还可以为防御性工作识别软件漏洞，但不会编写漏洞利用程序。Mythos 5.1 是安全防护更少的同一模型，目前仅限一组美国机构使用：Life Sciences Verification Program 围绕它构建，而 Cyber Verification Program 仍运行 Opus 和 Sonnet 级别的模型，并计划“在不久的将来”加入 Mythos 级别的模型。
我最关注的是行为方面的说明。Anthropic 声称，5.1 会避免那些导致工作质量下降的捷径，在根因分析方面表现更好，并能在长期、多步骤任务中保持连贯性。他们给出的旗舰案例是 Millennium：一个大约每百万次运行中出现一次、且多年未能解释的崩溃。Fable 5.1 拆解了一个供应商库，将其与核心转储进行比对，并将 bug 追溯到了该库中。
现在即可使用：API 中的 `claude-fable-5-1`、claude.ai、Amazon Bedrock、Google Cloud 的 Agent Platform，以及 Microsoft Foundry。
Fable 5.1 与 Fable 5、Opus 5 和 GPT-5.6 Sol 的基准测试对比
以下是 Anthropic 自己的表格。由于数据由厂商报告，在独立排行榜跟进之前，应将这些差距视为方向性指标。
| 基准测试 | Fable 5.1 | Fable 5 | Opus 5 | GPT-5.6 Sol |
|---|---|---|---|---|
| --- | --- | --- | --- | --- |
| Terminal-Bench 4.0（agentic coding） | 55.8% | 42.0% | 52.3% | 37.3% |
| Terminal-Bench-Science 0.1 | 52.6% | 24.7% | 29.0% | 22.4% |
| AutomationBench（业务工作流） | 31.4% | 17.1% | 26.9% | 19.6% |
| CursorBench 3.2.0 | 73.4% | 70.5% | 70.0% | 67.2% |
| GDPval-AA v2（知识工作） | 1853 | 1723 | 1824 | 1711 |
| Humanity's Last Exam（无工具） | 60.9% | 57.8% | 56.6% | – |
| OSWorld 2.0（严格模式） | 41.7% | 36.1% | 39.6% | – |
有两点很突出。Terminal-Bench-Science、Terminal-Bench 4.0 和 AutomationBench 是长期 agent 测试，提升幅度也最大：科学基准测试从 24.7% 增至 52.6%，超过翻倍；另外两项各提升了约 14 个百分点。而 Opus 5——当 Fable 5 变贵或变得固执时，许多人会退回使用它——现在在相同任务上明显落后。Cognition 表示，他们会在发布当天将 Devin 的 Opus 5 流量迁移到 Fable 5.1，并指出缓存定价是 Fable 级别模型如今对他们变得可负担的原因。
来自另一方的一个注意事项：在 OpenAI 的 Agents' Last Exam 上，GPT-5.6 Sol→ 以 13.1 个百分点击败了 Fable 5；在中等推理设置下，它仍以 11.4 个百分点领先，而预估成本约为四分之一。Anthropic 没有公布 5.1 在该基准测试上的成绩。Sol 的每 token 价格仍只有一半：输入 5 美元，输出 30 美元。因此，5.1 的价格优势依赖于缓存读取和低 effort，而不是目录价格。
5.1 针对的问题清单
Fable 5 的反弹有着一致的模式。网页应用五小时的使用上限；安全分类器会悄悄将你的对话交给 Opus 4.8；token 消耗很高，有一份广泛传播的报告称一天烧掉了 110 美元；长任务进行到后期会偷懒、回答冗长、运行中途变慢，以及处理困难提示词时首 token 延迟超过一分钟。“一辆被限速到 30 英里/小时的 Ferrari”成了最令人印象深刻的说法。Opus 5 也有自己的抱怨，而 Anthropic Claude Code 团队成员 Thariq 在 X 上表示同意，称它“确实是一个波动很大的模型”，修复它“对我们来说是重中之重”。
在 8 月最后一周的灰度发布期间，获得新检查点的测试者报告称，长链推理更好，不再在任务进行到一半时忘记前置条件，工具使用和步骤规划也有所改善。一些测试者估计，法律工作中的结果提升了 10% 到 20%。它变得更严格的一个地方是：拒绝生成涉及受版权保护材料的图像。
这与官方表述一致：误拒绝更少，偷懒更少，完成任务的成本更低。消费者应用的使用上限，是我尚未看到得到解决的问题。
构建者需要做哪些改变
如果你直接调用 API，根据 Anthropic 的迁移指南，Fable 5.1 有几个 Fable 5 没有的棘手变化：
这些变化在 Claude Code 中都没有影响到我，因为它会替你处理。对于那些手写 agent 循环并强制调用工具的人来说，它们会带来问题。
在我自己的技术栈上运行 Fable 5.1 的一晚
基准测试衡量的是模型处理别人问题的能力。而我昨晚遇到的是运营人员夜晚常见的工作：一个损坏的工具、两次数据库迁移、两次部署，以及一个从未连接到 Spotify 的 widget。Claude Code 中的 Fable 5.1 全部完成了这些工作，我则一路进行审查。
损坏的工具。 我的网站 MCP server 有一个 `search_console` 工具，几周来一直返回 Unauthorized。原因藏在两层配置之后。负责处理工具调用的进程，并不是仓库 MCP 配置中定义的那个；Claude Desktop 通过一个 shell script 启动了第二个进程，而该脚本从未收到正确的 key。生产环境仍在运行旧的 auth 规则，因为包含新规则的 48 个文件的工作树从未提交。进程表显示 key 应在的位置是一个未展开的占位符，模型拒绝猜测。它通过在工具调用期间采样到我域名的 TCP 连接，找到了处理我的调用的进程；随后将 Node 的 inspector 附加到仓库配置启动的进程上，并确认占位符确实存在。修复方法是在两个文件中各加入一个 Node flag。
迁移。 Supabase MCP connector 返回了 DDL 的 permission denied。Supabase CLI 无法处理我的 `.env.local`。Vercel env pull 返回的是 `[SENSITIVE]` 占位符，而不是连接字符串；模型一度将这些占位符写入我的 env 文件，随后发现问题并回滚。通过符号链接目录运行的 linked-project 找不到 project ref。四条路都走不通，但它仍然完成了迁移。我曾看过早期模型在第一条失败路径上循环；这一次它不断改变方法。
部署。 70 个文件、两次迁移、三个新的 Vercel 变量、一次构建、一次推送、一次生产部署，以及对部署状态和受影响 endpoint 的验证，包括负面案例：旧 key 现在会在仅限 owner 的路由上正确返回 401。
widget。 代码树中存在一个 Spotify 正在播放的页脚 widget，但 OAuth 步骤从未运行；Spotify dashboard 中甚至没有注册 redirect URI。Fable 5.1 引导我完成 OAuth 设置，在本地测试了路由，然后对该功能进行了 18-agent 的对抗式审查：三名采用不同视角的审查者，每条发现都交给一个独立 agent，由它负责反驳该发现。最终提交了 15 条发现，其中 5 条经受住了检验。幸存的确实是真问题：艺术家文字与 4.5:1 要求相比只有 2.04:1 的对比度；物理 padding 破坏了我的阿拉伯语路由上的 pill；缺少 fetch 超时；未捕获的上游错误会以未缓存的 500 暴露；以及一个 refresh token 会在六个月后过期并静默消失。它修复了全部五项，在浏览器中测量了对比度和 RTL padding，然后完成部署。我故意没有将 refresh token 放入生产环境，因此 widget 在那里仍保持隐藏。询问它时，它记录了状态，让下一次会话知道当前哪些内容已上线。审查耗时九分钟，18 个 agent 总计约 165 万 tokens。
现在说说它的问题。那天晚上它两次将 secret 打印到工具输出中：一次是我的 Spotify client secret，一次是短期 access token，原因是在检查变量是否设置时发生了 shell expansion 错误。它发现了这两次问题，告诉了我，并建议轮换 secret。它还花了将近一小时确认究竟哪个进程处理我的 MCP 调用，最后才找到一个两行修复方案。那一小时里，模型拒绝接受与自身矛盾的证据——这是我希望看到的行为，但它仍然耗费了一小时。
应该拿哪个模型与它比较
先与 Fable 5 比较。小版本更新就是修复，因此测试重点是修复是否真正落地。那天晚上：会话后期没有偷懒，并且在三小时、两次部署和一次 18-agent 审查中保持了上下文连贯。我没有统计拒绝次数，一晚也不能算样本。我同样没有测量成本下降；这取决于 Anthropic 的缓存价格和 effort 设置，而我没有跟踪这两项。
第二个比较对象是 GPT-5.6 Sol。Sol 的目录价格只有一半，而且在 OpenAI 自己的基准测试中仍然拥有长期 agent 任务的领先成绩。如果你的工作负载量很大且容错较高，Sol 仍然是更便宜的选择。如果你的工作属于一次错误捷径就可能让你损失一天的那种工作，我会把任务交给 Fable 5.1。
暂时不要拿它与 Gemini 比较。Google 的旗舰产品仍然是 Gemini 3.1 Pro，目前没有新的数据。还要关注传闻将在 9 月上半月发布的 OpenAI Astra。如果它发布，这篇文章会更新。
按照本博客的惯例进行披露：Fable 5.1 在描述的同一会话中，根据当天的来源和自己的工具日志起草了这篇文章。我审查了每一条声明和每一个数字。