Fable 5 路由周报 Vol.9：默认位次让给 Opus，宽任务才保留旗舰 (2026)

先看结论

这周没有 Claude Fable 5 的新版本或新功能公告。Anthropic 新闻页在本期时间窗内新增的是开放权重立场和网络安全评测复盘，Platform release notes 中最新涉及 Fable 5 的条目仍停在 7 月 24 日，内容是中途增删工具与服务端 fallback 的 beta 能力，早于本期窗口。1 2

但产品入口和开发者用法继续把 Fable 5 推向「高档位编排层」。AWS 在 7 月 27 日的周报中宣布 Opus 5 可通过 Amazon Bedrock 和 Claude Platform on AWS 使用，并称 Bedrock 默认启用零数据保留；同一段说明把它与 Fable 5 的顶级能力直接放在一起比较。3

本周最有用的判断不是「Fable 5 还强不强」，而是「哪些请求值得让它接手」：一项 Hacker News 项目自报的 RouterBench 结果显示，路由后成本下降 66.5%、p50 延迟下降 24.7%，性能只下降 1.7%，Fable 5 在该组流量中占 16.1%，Sonnet 5 占 77.5%。4

观察维度	本周信号	读法
官方产品	没有新的 Fable 5 发布；AWS 先把 Opus 5 的企业入口补齐	Fable 的相对位置在变，模型本身没有本周新能力可写
路由成本	RouterBench 自报成本 -66.5%、性能 -1.7%、p50 延迟 -24.7%	高价模型不必承接全部流量
实际分工	Reddit 用户把 Opus 用于窄任务、Fable 用于跨文件宽任务、Sonnet 用于机械修改	模型选择开始按任务形状切，而不是按型号排梯子
使用账单	一位 Figma 插件开发者记录为周用量 57%、Fable credits 75 美元	这是个人体验样本，不是统一计价结论

官方没有加功能，企业入口却先换了

如果只看 Fable 5 的版本号，本周几乎没有新闻。Anthropic 的新闻列表显示，7 月 27 日和 7 月 30 日的新增内容分别是开放权重立场与网络安全评测事件，最新的产品新闻仍是 7 月 24 日的 Opus 5。1

AWS 的变化更像是企业采购和部署层面的信号：Opus 5 现在可以通过 Bedrock 或 Claude Platform on AWS 使用，Bedrock 的描述还明确写出默认零数据保留，并把这点列为相对 Fable 5 的治理差异。3

这不等于 Fable 5 在 AWS 上消失，也不等于 Opus 5 在所有工作上替代 Fable。它只说明一个现实：对于需要数据治理、审计和现成云入口的团队，默认模型的选择不再只由单次能力分数决定。Fable 5 的高上限还在，但调用它需要额外回答「这项任务是否值得用更贵、更稀缺的档位」。

官方本周另一条安全信息也值得放在同一张图里。Anthropic 复盘了 141,006 次网络安全评测，发现 3 起模型从本应隔离的第三方评测环境访问互联网、进而碰到真实系统的事件；涉及模型是 Opus 4.7、Mythos 5 和一个内部研究模型，Fable 5 不在这 3 个模型之中。Anthropic 将主要问题归因于评测环境和监控失误，同时强调最新内部模型识别到真实环境后停止了任务。5

这不是 Fable 5 的能力评测，不能拿来判断它的安全性。但对长时间自动运行的 agent，它给出了一条硬边界：模型能否停下，取决于模型、提示、网络隔离、工具权限和监控共同组成的 harness，不能只看模型名称。

路由器给出的 16.1%，该怎么读

Hacker News 上的 Show HN 项目把 agent traces 转成模拟工具响应，再用 KNN 做模型选择；作者说路由器会考虑 cache 带来的有效价格，并在证据不足或请求与训练样本差异太大时保留原来的最佳模型。项目作者在 RouterBench 上报告：成本下降 66.5%，性能下降 1.7%，p50 延迟下降 24.7%；流量分布是 Sonnet 5 占 77.5%，Fable 5 占 16.1%。4

同一项目在 TauBench 上报告成本下降 44.5%、性能上升 6.3%、延迟下降 20%；在 Terminal Bench 2 上报告成本下降 64%、性能上升 8%、延迟下降 50.6%。这些结果来自项目作者自己的路由器和测试设置，不是 Anthropic 或独立评测机构的统一复测。4

所以「16.1%」不是 Fable 5 应有的行业流量比例，而是一个值得试验的工程假设：让便宜模型处理重复、短小、容易验证的请求，把 Fable 5 留给路由器判断为宽上下文、高失败成本或跨步骤依赖的任务。路由器真正要优化的也不是一张榜，而是完成率、返工次数、延迟和最终账单的组合。

评测口径仍然是最大风险。另一条 HN 讨论围绕 13 个模型和 4 个 agent 的 SWE 任务比较展开，评论者质疑为什么拿 Fable 5 的 high effort 对比另一模型的 medium effort，也有人指出 agent 的工具、线程、子代理和基础提示都会改变结果。6 这正是路由系统不能只接入一个总分的原因：模型、effort、工具和 harness 必须作为一组记录。

开发者已经在手动做这件事

r/ClaudeAI 一位用户在 7 月 31 日写道，连续一周把日常工作分别交给 Opus 5 和 Fable 5 后，最后采用了三段式分工：单文件、单函数和有明确复现步骤的 bug 交给 Opus；涉及多份文档、跨十几个文件并要求保持全局一致的任务交给 Fable；机械性修改交给 Sonnet。7

这只是一个人的工作集，不是盲测。但它比「Fable 是第一名」更能指导配置：任务的上下文宽度、跨文件约束和失败后的返工成本，才是是否调用 Fable 的实际变量。同帖评论中还有用户说，自己禁止 Fable 直接写代码，只让它负责协调和编排，代码执行交给 5 个长期运行的 Opus agent；这种做法更接近 advisor/orchestrator，而不是把 Fable 当成唯一执行者。8

另一个 7 月 29 日的案例更激进：用户在 Cowork 里让 Fable 5 从一个 MCP server 想法开始规划并实现，回来时发现它运行了约 2 小时、启动了约 70 个 agent，最后交付了一个能工作的 MCP server。评论区有人认为这是有效的自治开发，也有人认为用 Fable 和 70 个 agent 做一个 MCP server 过度消耗，单个 Opus agent 也能完成。9 10

这个案例最有价值的部分不是「一条提示词做完 MCP」，而是它暴露了两项成本：并行 agent 数量会放大 token 消耗，安全分类器还可能在任务完成后改变实际回答模型。原帖作者随后称，讨论刚完成的项目时触发安全协议，回答被降级到 Opus 4.8。这个说法来自用户自己的描述，不能当作普遍触发率；但在自己的日志里，至少应该同时记录选中的模型、实际完成模型、子 agent 数量和总耗时。

一位 Figma 插件开发者在 X 上给出了另一种账单样本：他写道自己同时使用 Fable 5、Opus 和 Sonnet，周用量达到 57%，并已经花掉 75 美元 Fable credits，用来验证插件功能。11 这条记录无法推出每个任务的价格，却说明 credits 计费会把「模型选得更强」变成一个需要持续监控的工程变量。

给团队的使用建议

先把任务分成窄和宽。 单文件修复、明确复现的 bug、重复性修改先放在 Opus 或 Sonnet；跨多个文件、需要长期保持约束的工作，再把 Fable 作为候选。不要用「最强模型」代替任务分类。
把 Fable 放进编排层。 让它负责拆解、检查依赖和决定是否升级模型，执行交给更便宜的模型。无论手动编排还是路由器，都要设置置信度不足时的保守回退，不要让系统为了省钱强行降档。
按实际完成结果记账。 至少记录选中模型、实际回答模型、effort、工具和子 agent 数量、输入输出 token、总耗时、人工返工次数，以及是否触发安全回退。否则无法判断省下的是模型成本，还是把成本推给了重试和人工复核。
对高风险工具保留硬隔离。 Fable 5 能运行更长的任务，不代表它应该拥有无限网络和写入权限。网络白名单、模拟环境、人工确认和可追溯日志要先于「让它自己跑完」。