Claude Fable 5 服务端 Fallback API：无需重试循环即可处理拒绝

如果你的 Fable 5 API key 可用，但 claude-fable-5 返回拒绝，最短路径是：在请求里声明 fallback 模型，固定启用 fallback beta header，并读取 usage.iterations 判断最终是 Fable 5 还是备用模型完成了响应。

6 月 9 日，Anthropic 发布 Claude Fable 5 时，媒体关注的是基准测试成绩。而运营层面的关键变化截然不同：Fable 5 是第一个能够以 stop_reason: "refusal" 拒绝请求的 Claude 模型——一个 HTTP 200 响应，携带零输出，表示分类器拒绝回答。发布三天后，Anthropic 推出了处理该信号的配套工具，无需再手写重试逻辑：Claude Fable 5 服务端 Fallback API。

服务端 Fallback API 的作用

此前，处理 Fable 5 的拒绝意味着：在应用层检查 stop_reason，捕获 "refusal" 分支，再向另一个模型重新发起请求——通常是 Claude Opus 4.8 或其他正式可用模型。这套方案可行，但会增加一次往返时延、在两个模型间重复产生 prompt cache 费用，并且每个使用 Fable 5 的团队都必须独立构建这套应用层逻辑。

server-side-fallback-2026-06-01 beta 将上述流程压缩为单次调用：

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "anthropic-beta: server-side-fallback-2026-06-01" \
  -H "content-type: application/json" \
  -d '{
    "model": "claude-fable-5",
    "max_tokens": 1024,
    "fallbacks": [{"model": "claude-opus-4-8"}],
    "messages": [{"role": "user", "content": "你的提示词"}]
  }'

若 Fable 5 正常回答，返回 model: "claude-fable-5" 的普通响应；若其拒绝且指定了 fallback，API 会在同一调用内自动重试 claude-opus-4-8，最终返回 model: "claude-opus-4-8" 的响应。应用层只看到一次响应、一次计费事件，响应中的 usage.iterations 数组记录了实际走过的路径。

fallbacks 数组最多可以指定三个备用模型，形成链式结构。API 依次尝试每个模型，直到有模型给出答案，或全部拒绝后返回最后一次拒绝响应。

Fallback 信用令牌：避免 Prompt Cache 成本重复

计费机制和路由机制同样关键。Prompt cache 是按模型隔离的。如果之前手动构建重试循环，且被拒绝的请求包含一段经过昂贵缓存的长系统提示，切换到第二个模型时需要全量重写该缓存，按 cache write 费率计费。

Anthropic 的解决方案是 fallback_credit_token——一个不透明令牌，当你在请求中带上 fallback-credit-2026-06-01 beta 头时，该令牌会出现在拒绝响应的 stop_details 字段中。在重试请求体中将其作为 fallback_credit_token 传入，重试模型就会按"对话一开始就在该模型上发起"的方式计费：cache write 成本被吸收，你只需支付 cache read 费率。

服务端 fallback 和 TypeScript/Python/Go/Java/C# SDK 中间件会自动处理信用令牌。只有在使用原始 HTTP、Ruby、PHP 或需要自定义重试逻辑时，才需要手动管理令牌。

拒绝类别与 Fallback 适用场景

并非所有拒绝都一样。Fable 5 通过 stop_details.category 暴露四种类别：

对于 "frontier_llm" 和 "reasoning_extraction"，fallback 模型通常也会拒绝，或以不符合原始意图的方式回答。建议将这两类拒绝路由到人工审核队列，而非静默重试。

对 AI 工程团队的路由影响

Claude Fable 5 服务端 Fallback API 在三个维度上改变了在生产环境中路由 Fable 5 的风险模型：

1. 拒绝不再是需要网关层处理的故障模式。 此前需要中间件层捕获 stop_reason: "refusal" 并重路由的团队，现在可以将这一逻辑内置于 API 调用本身。这对通过代理或 AI 网关运行 Fable 5 的团队尤为重要：fallback 可以在请求级别声明，而无需在基础设施层面处理。

2. 缓存密集型工作负载的成本核算发生变化。 如果系统提示较长且已缓存于 Fable 5，同时拒绝率不可忽视，fallback_credit_token 机制值得做基准测试。在重试时支付大量 cache write 成本的团队，在 fallback 场景下可以收回一部分开销。

3. 仅在 Claude API 和 Claude Platform on AWS 上可用，Bedrock、Vertex 和 Foundry 暂不支持。 fallbacks 参数在 Message Batches API 上会被拒绝，且在当前 beta 阶段不适用于 Amazon Bedrock、Vertex AI 和 Microsoft Foundry。跨这些平台路由的团队应改用 SDK 中间件进行客户端 fallback 处理，该方式覆盖所有平台。

后续关注点

Anthropic 将此功能标注为 beta（需要 server-side-fallback-2026-06-01 头）。根据 beta 命名惯例，稳定版本预计今年晚些时候发布。在此之前，建议团队：

• 固定 beta 头版本，不要假设未来的稳定 API 与当前完全相同；
• 通过 usage.iterations 记录每次响应由哪个 fallback 模型处理——这是按工作负载审计拒绝率和 fallback 模型表现的有效数据；
• 在生产运行数周后回顾拒绝类别分布；Anthropic 已指出 "cyber" 类别在无害安全和 DevOps 场景中存在已知误报问题。

对于已经使用手动重试逻辑运行 Fable 5 的团队：服务端 Fallback API 是一次干净的升级。对于因拒绝处理复杂度而尚未迁移到 Fable 5 的团队：这次更新消除了集成阻力最大的一个障碍。

参考资源

完整参考文档见 Anthropic 文档中的 Refusals and fallback。Fallback and billing cookbook 提供了包含流式拒绝和 token 计费的完整端到端示例。

在通过 TheRouter 路由 Fable 5 请求的场景下，路由层可以将 fallback 声明原样透传给上游 API；对于服务端参数不可用的平台（Bedrock、Vertex、Foundry），也可以在 AI 网关层统一处理 fallback 逻辑。