Claude Code fallbackModel 支持三级 fallback 链，并收紧跨 session 安全边界

Claude Code 6 月 6 日发布的 v2.1.166 版本包含两项直接影响 operator 可靠性配置与多 agent 信任架构的变更。核心功能是对 fallbackModel 设置的升级——现在支持有序的最多三个 fallback 模型列表。与此同时，跨 session 安全性也得到显著加固：通过 SendMessage 从其他 Claude session 转发的消息不再携带用户权限，接收方 session 将拒绝转发来的权限请求。

这两项变更同时落地并非巧合——它们从相反方向解决同一个问题：在主要资源失败时保持长时运行的 agentic 工作流，同时确保 session 间的权限不会被静默转移。

Claude Code fallbackModel 三级 fallback 链的变化

v2.1.166 之前，fallbackModel 是单值配置——当主模型返回 529 超载错误或不可用时，Claude Code 只会尝试一个备用模型，再失败则直接暴露错误给用户。

新行为：

• fallbackModel 接受最多三个模型标识符组成的有序数组。
• Claude Code 依序尝试：primary → fallback[0] → fallback[1] → fallback[2]。
• --fallback-model CLI 参数现在作用于交互式 session，不再仅限于无头 claude -p 调用。这是一项实质性改变：此前交互式用户仍会遭遇硬性 529 错误。
• 另外，当 API 返回非预期的不可重试错误时，Claude Code 会在第一个可用的 fallback 模型上重试一次该轮次。认证错误、限流错误、请求体过大错误和传输错误被明确排除在外，仍然会立即暴露给用户。

典型的 settings 配置现在形如：

{
  "model": "claude-opus-4-8",
  "fallbackModel": ["claude-sonnet-4-6", "claude-haiku-4-5", "deepseek/deepseek-v4-flash"]
}

这给出了三层降级策略：Opus 4.8 作为主模型 → 超载时切换至 Sonnet 4.6 → 次级轻量 Haiku 4.5 → 最后兜底一个外部 OpenAI 兼容模型。

跨 session 安全加固

Claude Code 支持多 agent 模式，一个 Claude session 可以通过 SendMessage 向另一个 session 分发任务。此前，这种方式转发的消息会继承发起 session 的用户权限——这意味着转发的权限请求可以被接收 session 当成用户直接批准的请求来接受。

v2.1.166 关闭了这一通道：

• 通过 SendMessage 从其他 Claude session 转发的消息不再携带用户权限。
• 接收 session 将拒绝转发来的权限请求。
• Auto 模式下，会明确拦截原本会被自动批准的转发请求。

这对运行多 agent Claude Code 部署的团队而言是一项重要的架构澄清：信任边界现在位于 session 边缘，而非消息边缘。编排 session 无法通过转发子 session 的方式提升自身权限。

为什么这对 AI 工程团队重要

Operator 可靠性规划

三级 fallback 链改变了大规模运行 Claude Code 时的可靠性计算方式。此前，Anthropic API 持续超载时，要么静默降级到单个备用模型，要么直接失败。现在可以明确编排分层降级策略：

• 第一层（primary）： Opus 4.8，用于高保真、推理密集型任务。
• 第二层（fallback[0]）： Sonnet 4.6，当 Opus 容量受限时——能力略低，速度更快，通常更便宜。
• 第三层（fallback[1]）： Haiku 4.5 或同等轻量模型，适用于成本敏感或延迟敏感的任务。
• 第四层（fallback[2]）： 异构 provider（例如路由网关后面的 OpenAI 兼容端点）作为最终保障。

这实际上是一条客户端侧的路由链——类似于 AI 网关在网络层所做的事，但以声明式方式写入 Claude Code 的 settings 文件，在工具层面生效。

与网关层 routing 的配合

如果你的团队通过 AI 网关路由 Claude Code（例如通过 ANTHROPIC_BASE_URL），客户端侧 fallbackModel 和网关层 routing 是互补关系，而非冗余。

网关负责 provider 层面的关注点：区域均衡、quota 聚合、Bedrock/Vertex/Foundry 多云分发、请求级重试、成本归因。客户端侧 fallbackModel 链负责模型级别的关注点：当前模型超载或不可用时，依序尝试哪个 Claude 模型或 OpenAI 兼容模型。两层可以同时激活，互不干扰。

使用 TheRouter AI routing 层 的团队，实践配置如下：

1. 将 ANTHROPIC_BASE_URL 指向你的网关端点。
2. 在 Claude Code settings 中配置三层 fallbackModel 链。
3. 在网关层为每个 provider 配置重试和延迟预算。

这样你就有两个独立的 fallback 机制：网关在同一模型的多个 provider 实例之间重试；Claude Code 在网关已耗尽主模型选项时升级到不同的模型层级。

多 agent 部署的安全影响

跨 session 权限变更对于运行 orchestrator/sub-agent 拓扑的团队，需要主动审查。

如果当前架构依赖编排 session 向子 session 转发权限请求——且子 session 因看到"用户权限"而自动批准——这一模式在 v2.1.166 中将不再有效。你需要：

1. 审计 SendMessage 流程，找出权限委托隐式发生的位置。
2. 显式预授权：在子 session 的 allow-list 中预批准它实际需要的特定工具，而非依赖运行时转发批准。
3. 在 settings 中使用 allowedTools，为子 session 赋予最小必要的权限集。
4. 将 session 边界视为信任边界：设计编排拓扑时，确保每个 session 在预定义的最小权限范围内运行。

这使 Claude Code 的安全模型与网关层 API key 作用域机制对齐：下游消费者获得的是有限作用域的 token，而非主凭证的委托。

Operator 决策框架：升级 fallbackModel

对于当前将 fallbackModel 用作单个字符串的团队，升级路径很直接：

第一步： 确定你的降级预算。第二层和第三层可接受的能力与成本权衡是什么？

第二步： 确认每层的模型可用性。如果通过网关路由，验证每个 fallback 模型在网关的 allowed-providers 列表中。

第三步： 将 fallbackModel 设为数组。第一个条目是首选 fallback，在第二个之前尝试，以此类推。

第四步： 如果团队以交互式（非无头）模式使用 Claude Code，验证新的 --fallback-model 交互式 session 行为，并相应更新操作手册。

第五步： 对于多 agent 拓扑，在将 v2.1.166 部署到生产编排工作流之前，先运行上述 SendMessage 审计。

值得关注的方向

当前 fallback 链解决的是模型身份——它不会根据成本、延迟或质量信号在运行时动态选择下一个模型。如果团队需要动态路由决策（例如"响应延迟超过 5 秒时使用 Haiku，而不仅仅是 Opus 529 超载时"），该逻辑仍然需要在网关层实现。

关注后续版本是否会在 OTEL trace 中暴露每轮次的 fallback 元数据，这将使网关层监控系统能够关联客户端侧 fallback 触发的时机和目标模型层级。

在安全方面，v2.1.166 中针对 auto-mode 和权限转发场景的 SendMessage 信任边界变更已完整落地。如果你的编排模式以其他方式依赖跨 session 能力传递（共享上下文、共享工具集），请验证这些模式仍按预期工作。

相关资源

• 为多 provider fallback 配置 routing 策略
• 模型 routing 与 fallback 模式
• Claude Code 接入指南