Anthropic fallbacks "default" 模式扩展至 Opus 5 —— Opus 4.7 的 speed: fast 现在直接返回 400

Anthropic 在 7 月 24 日的 API 更新中引入了两项变更，路由团队今天就应核查自己的配置是否受到影响。

第一项是已上线的破坏性变更：claude-opus-4-7 的 speed: "fast" 现在会直接返回硬性 400 错误，不再像 Opus 4.6 那样静默回退到标准速度。任何在生产中将 fast mode 硬编码到 Opus 4.7 的路径，已经悄无声息地在报错四天了。

第二项是路由原语的扩展：fallbacks: "default" —— Anthropic 按拒绝类别推荐的服务端 fallback 模式 —— 现已在 Claude Opus 5 和 Claude Opus 4.8 上可用，而这两个型号正是大多数团队在生产 agentic 任务上使用的主力模型。

已破坏的内容：Opus 4.7 fast mode 是硬性错误，不是优雅降级

Anthropic 在 Opus 系列上的 fast mode 行为并不一致，理解这一历史很重要：

对 operator 最直接的影响是：Opus 4.7 不会优雅降级。如果你的 gateway 配置在任何代码路径中将 speed: "fast" 与 claude-opus-4-7 绑定——无论是环境变量、模型配置文件还是路由策略表——你都在产生 400 错误而非正常返回响应。模型本身仍可以标准速度使用；被拒绝的仅是 speed 参数。

迁移路径：

# 之前（现在对 claude-opus-4-7 返回 400）
{
  "model": "claude-opus-4-7",
  "speed": "fast",
  ...
}

# 之后：升级到 Opus 5 或 Opus 4.8 以保留 fast mode
{
  "model": "claude-opus-5",
  "speed": "fast",
  ...
}
# 或者：去掉 speed 参数，以标准速度使用 Opus 4.7
{
  "model": "claude-opus-4-7"
  # 不传 speed 参数
}

如果你在 SDK 层使用了 anthropic SDK middleware，请检查 speed 字段是否在 SDK 层设置或来自环境配置——SDK 级别的默认值可能在模型升级后依然存在。

新增内容：fallbacks "default" 模式现已适用于 Opus 5 和 Opus 4.8

服务端 fallback API 允许你在请求本身中声明一个 fallback 模型。当主模型返回 stop_reason: "refusal" 时，API 在单次往返中完成重试，无需客户端逻辑接管。你收到的响应来自主模型或 fallback 模型，不会有额外的重试延迟。

"default" 模式——由 Anthropic 按拒绝类别选择推荐 fallback 模型——此前仅在 Fable 5 和 Mythos 5 上可用。自 7 月 24 日起，它也在 Opus 4.8 和 Opus 5 上可用：

response = client.beta.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "..."}],
    fallbacks="default",
    betas=["server-side-fallback-2026-07-01"],
)
# response.model 告诉你实际由哪个模型处理了响应
print(response.model)

curl、TypeScript、Go、Java、PHP 和 Ruby 均支持相同模式——beta header server-side-fallback-2026-07-01 是开关，fallbacks: "default" 是模式。

"default" 实际做了什么： Anthropic 按拒绝类别将被拒绝的请求路由到其推荐的 fallback。没有推荐 fallback 的类别会原样返回拒绝响应。你不控制由哪个模型处理重试——这是零客户端复杂度的代价。如果你需要指定确切的 fallback 模型，显式形式（fallbacks: [{model: "claude-sonnet-5"}]）仍然可用。

路由架构的启示

这两项变更指向相反方向，却传递了同一个 operator 教训。

Opus 4.7 fast mode 事件展示了过时模型配置的代价：上周还能工作的参数值，现在悄悄产生错误。修复只需一行配置，但损失（4 天以上的 400 错误）已经发生，因为没有人发现。

Opus 5 上的 fallbacks: "default" 则展示了前向路径处理的样子：一个参数告知 API 当主模型拒绝时该怎么做，无需维护自己的重试逻辑，也无需硬编码将来同样需要轮换的 fallback 模型名称。

这两者合在一起，是对路由策略中明确处理模型生命周期的有力论据——而不是假设今天有效的参数在下次 API 更新后仍然有效。

今天需要检查的路由配置

1. 审计 fast mode 设置： 在代码库和配置文件中搜索 speed.*fast 或 "fast-mode"。如果有任何路径指向 claude-opus-4-7，请删除 speed 参数或将模型升级至 Opus 4.8 或 Opus 5。

2. 验证 400 错误处理： 如果你的 gateway 将所有 400 视为硬性失败而不检查错误体，你可能在悄悄丢弃请求而非路由到 fallback。请为 speed 参数错误添加显式处理。

3. 评估 Opus 5 工作负载上的 fallbacks: "default"： 如果你在 Opus 5 上运行涉及内容分类器的 agent 任务（文档分析、摘要、agentic 浏览），"default" fallback 模式现在无需额外的模型管理开销即可使用。

4. 检查日志中的 response.model： 服务端 fallback 激活时，响应中的模型字段将与请求中的不同。请确保你的计费对账和可观测性 pipeline 读取 response.model，而非假设请求模型与响应模型相同。

关于服务端 fallback 的完整配置，包括主模型被拒绝时 prompt cache 命中的计费积分行为，请参阅 TheRouter 早期分析文章 及 Anthropic 拒绝与 fallback 文档。