Fable 5 生物分类器修复：你的 API 账单从未警告过的静默换模问题

8 月 7 日，Anthropic 更新了 Fable 5 内部的生物安全分类器，将生物相关请求的回退率降低了约 85%。官方公告的重点是医疗用户此前遇到的不必要拒绝现在大幅减少。这个描述没错，但对 API 运营商来说，这次修复同时揭开了另一件事。自 Fable 5 上线以来，你们团队调用的模型和实际回答请求的模型，有时并不一样。

Anthropic 实际改了什么

Fable 5 上线时内置了一个覆盖范围很宽的生物分类器。分类器触发时，系统不会直接拒绝请求，而是在返回响应前把请求重新路由给 Opus 5。Anthropic 把这个过程叫做"fallback"。从 API 调用方的角度看，请求发出去，响应回来了，没有报错，没有错误码，标准 messages API 的响应体里也没有字段告诉你这次实际由哪个模型回答。

8 月 7 日的更新重新编写了分类器的规则体系和训练数据。按 Anthropic 的测试，这次改动把生物相关的 fallback 比例在各产品面上降低了约 85%。日常的健康问题，比如化验单解读、症状查询、生物学教育内容，现在能直接到达 Fable 5。而具有双重用途风险的研究方向，比如病毒学、毒理学、分子设计，仍然会触发 Opus 5 回退。

运营商普遍忽视的计费问题

对在 API 层跑生产流量的工程团队来说，这里有一个值得算清楚的问题。

Fable 5 和 Opus 5 的定价不同。按 Anthropic 现行价格，Opus 5 的 input token 价格高于 Fable 5。一个按 Fable 5 计费、实际由 Opus 5 服务的请求，意味着计费和实际服务模型之间存在偏差。更重要的是，Opus 5 不具备 Fable 5 在生物领域的前沿能力。那些专门因为 Fable 5 的生物性能而路由到该模型的生物技术、临床信息学或计算药物研发团队，实际上有相当比例的生物工作负载是由 Opus 5 回答的。两个模型在高级生物任务上的能力差距并不小。

这是提供商控制型 fallback 与网关层 fallback 在结构上的根本区别。当网关把一个失败的 Fable 5 请求路由到备用模型时，运营商配置了这个行为，日志里也看得到。提供商端的分类器 fallback 对网关来说是不透明的。请求到达 Anthropic API，被不同的模型处理，响应正常返回。网关的路由记录显示"Fable 5 成功"，没有告警触发。

85% 改善实际恢复了什么

Anthropic 给出的 85% 是跨所有产品面测量的，涵盖了消费端 Claude 应用。针对 API 的细分数据没有单独公布。生物类查询量大的团队，不应该假设修复前的误报率在自己的流量里可以忽略不计。

修复后的当前状态

• 日常生物类请求（化验单、症状、教育内容、普通生理学）→ Fable 5 直接处理。
• 双重用途生物类请求（病毒学、毒理学、分子设计、病原体相关研究）→ 仍然触发 Opus 5 回退。
• 这条边界由 Anthropic 的分类器决定，不受你传入 API 的参数控制。

没有任何 API 参数可以让运营商绕过生物分类器。service_tier、metadata 和模型名称都无法跳过它。目前 Anthropic 描述的唯一可信访问途径是运营商注册计划，不是生产环境中今天可用的 API flag。

横向对比：其他提供商怎么处理

其他主流 API 提供商没有以这种方式实现提供商端静默换模机制。向 deepseek-v4-pro 发送被阻止的请求时，响应里包含明确的拒绝内容。Google Vertex AI 的安全过滤器触发时，会返回带有 SAFETY finish reason 的无内容响应，而不是换个模型来回答。Azure AI Foundry 的内容过滤器同样返回明确的阻断代码。

Anthropic 的架构很特殊。分类器触发，静默换模，响应正常返回。这样设计的出发点是用户体验，避免请求走到死路，降级到一个有能力的模型继续回答。代价是运营商的可观测性。一个坐在 Anthropic API 前面的路由层，没办法从响应本身区分 Fable 5 的回答和 Opus 5 fallback 的回答，除非主动对响应内容做验证，或者针对已知生物查询跑 eval 对比。

运营商现在应该审计什么

1. 回顾 Fable 5 上线以来的 Anthropic 账单明细。 如果团队在此期间对 Fable 5 跑过生物相关的工作负载，检查响应质量和延迟是否稳定。Opus 5 和 Fable 5 的延迟分布不同，如果生物查询批次的 p50/p95 曲线出现异常，可能说明当时 fallback 比例不低。

2. 重新跑生物领域的 eval。 如果你在宽分类器上线期间为 Fable 5 建立了测试集或基准，这些结果可能不代表 Fable 5 的真实生物能力。病毒学邻近方向、生物信息学或临床肿瘤学问题，当时有相当比例是由 Opus 5 回答的。

3. 不要以为提供商端 fallback 在网关日志里可见。 被分类器重新路由的请求返回 HTTP 200，响应体完全合法。网关把这类请求记录为"Fable 5 成功"，这不是谎言，API 调用在技术上确实成功了。如果需要检测换模行为，必须在内容层做明确的校验或模型指纹探针，不能依赖日志。

4. 追踪双重用途的边界，而不只是那个 85% 的数字。 85% 的下降不代表所有生物查询现在都能到达 Fable 5。分子生物学、病毒学、毒理学查询仍然会触发 Opus 5。如果你的临床信息学用例涉及这些方向，需要把剩余的 fallback 范围纳入流量预期。

TheRouter 用户可以关注什么

TheRouter 路由到 Anthropic API 端点，把 Anthropic 的响应当作权威答案。在 Anthropic 公开哪个模型实际处理了分类器替换的请求之前，上游路由器无法自动感知这种换模行为。

一个可行的缓解方案是在 Anthropic 集成里加一个 canary 探针，选择一个 Fable 5 在生物领域有明显特征响应的查询，定期把响应特征与基线做对比。如果 canary 的响应质量下降，说明该查询类的分类器 fallback 可能再次激活。这是手动开销，但目前是 API 层唯一可观测的信号。

对跑高量生物技术或临床工作负载的团队，可以参考 /docs/guides/features/ 了解如何把特定查询类路由到独立的提供商路径。把双重用途生物查询明确路由到 Opus 5，能完全绕过静默 fallback 带来的不确定性。