Claude Fable 5.1 发布：Containment Escape 默认拦截云凭证获取

Claude Code 2.1.257 一次推了两件事，两件事放在一起比任何一件单独出现都更值得注意。

第一件是把 Claude Fable 5.1 提为默认 Fable 模型。第二件是给 auto 模式加了一条 Containment Escape 规则，从此云元数据凭证获取、出口规避、跨租户访问默认不再自动放行。如果你的 agent 流水线运行在 AWS、GCP、Azure 或任何 169.254.169.254 可达的环境里，下次部署前必须先读这篇。

Fable 5.1 带来了什么

新模型 ID 是 claude-fable-5-1，接替上一代成为默认 Fable 档，上下文窗口 100 万 token。

定价是 输入 $10 / 输出 $50（每百万 token），缓存读取 $0.25 / 百万 token。这个价位坐落在 Opus 5（$15/$75）和 Sonnet 5（$3/$15）之间。对于在乎指令跟随质量、但又不想在每次调用上付 Opus 5 价格的 agentic 工作负载，Fable 5.1 是最自然的中间档。

一个值得注意的细节是缓存读取定价。Fable 5.1 的缓存读取是 $0.25/Mtok，比 Sonnet 5 的 $0.30/Mtok 略低。如果你的流水线针对大上下文（长系统提示 + 大型代码库）做了激进的 prompt caching，Fable 5.1 在高缓存命中率下会比 Sonnet 5 省一些实际成本。

如果你有 claude-fable-5-0 硬编码在 routing 配置里，请注意 TheRouter 并未定义通用别名 fable——模型 ID 按精确匹配路由，所以配置会一直指向 claude-fable-5-0，直到你手动把固定字符串改成 claude-fable-5-1。

Containment Escape 实际做了什么

Containment Escape 规则针对的是一种具体攻击路径。agent 在云 VM 或容器内运行时访问实例元数据服务（IMDS，地址 169.254.169.254），拿到短期凭证后横向移动，或者访问到不属于当前会话的租户资源。

在 2.1.257 里，下面三类操作在 auto 模式下不再自动放行。

• 云元数据凭证获取，包含任何发往 169.254.169.254（或 Azure/GCP 平台等效地址）的 HTTP 请求
• 出口规避，即运行时识别为尝试绕过沙箱出口管控的网络行为
• 跨租户访问，即针对当前会话预期范围之外的主体、资源或存储的操作

以前这些操作在 auto 模式下会静默通过，无需任何确认。2.1.257 起，除非环境明确声明了这些行为是预期行为，否则都会在这里停下来等确认。

怎么声明"这是预期行为"。 如果你的工作负载确实需要访问 IMDS（比如 agent 通过查询实例角色 token 来轮换短期凭证），可以通过 .claude/settings.json 或 managed-settings 策略，在 permissions.containmentEscapeExpected 下加入对应的操作类别，这样就能解除阻断。不做这个声明的话，哪怕是完全自动化的流水线，只要碰到 IMDS 请求就会暂停等待确认。

跑无人值守 agent 任务且流水线触达 IMDS 的运营者，现在面临两个选择，要么显式声明预期行为，要么把凭证获取逻辑从 agent 的操作范围里剥离出去。

CLAUDE_CODE_SUBAGENT_MODEL_FORCE 与多模型治理

2.1.257 之前，主 agent 的模型选择不会传递给它衍生的 subagent，除非每次衍生时明确设置。agent 定义可以覆盖模型，单次衍生配置可以再覆盖一遍。结果就是，团队在主 agent 上设了符合策略的模型，但无法保证 subagent 会跟着走。

新环境变量 CLAUDE_CODE_SUBAGENT_MODEL_FORCE 改变了这一点。设置之后，它会把 CLAUDE_CODE_SUBAGENT_MODEL（或主模型，如果那个变量没设）应用到所有衍生 subagent，无视单次衍生覆盖和 agent 定义里的模型字段。

对需要管控成本或合规性的运营者，这是第一个能用单个环境变量锁定整个 agent 树模型选择的机制。如果治理策略要求生产环境所有 agent 必须使用特定模型或档位，CLAUDE_CODE_SUBAGENT_MODEL_FORCE 能在不修改各个 agent 定义的前提下做到这一点。

认证头泄露修复

2.1.257 里有两处相关修复，即使听起来像是常规清理，运营者也值得专门看一眼。

第一处是 gateway 的头部泄露。Claude apps gateway 在向 Foundry、Vertex、Bedrock 上游发请求时，附带了多余的 Authorization 或 profile 头。具体表现取决于配置，可能意味着 Anthropic 来源的凭证泄露进了发给企业 provider 的请求里，混入了不属于该认证链的内容，在审计追踪上也会有问题。

第二处是双凭证问题。在 Foundry 的 API-key 模式下，多余的 Anthropic API key 或 auth token 随着 Foundry 订阅密钥一起发出去了。一个请求里带了两套凭证，而目标端只应该看到其中一套。

这两个问题在大多数配置下没有立即触发认证失败，这恰恰是它们值得排查的原因。如果你的日志里近几周出现了形状不对的 Authorization 头，这两个修复就是答案。

另一个相关修复涉及 Bedrock、Mantle、Vertex 和 WIF 上自定义 Authorization 头被重复列出并覆盖了已配置凭证的问题。还有 Vertex 设置向导会从 ~/.config/anthropic 拾取遗留的 Anthropic profile，在多 provider 配置下静默混用 profile。

路由决策参考

Fable 5.1 入列后，agentic 工作负载的模型选择大致有三个档位可以参考。

对于通过 OpenAI-compatible gateway 路由的 TheRouter 用户，模型 ID claude-fable-5-1 可以直接通过 Anthropic 上游使用。如果你的 gateway 配置用的是通用别名 fable 并且需要明确锁定到 5.1，改成版本字符串固定。

部署前五个检查点

检查点一，排查 agent 流水线里的 IMDS 访问。 在过去 30 天的 agent 输出日志里搜 169.254.169.254。出现了就决定是在 settings 里声明预期行为，还是把凭证获取逻辑从 agent 操作范围里剥离。

检查点二，Foundry 和 Vertex 的认证头形状。 检查上游请求日志里有没有不符合预期的 Authorization 或 profile 头。如果你在 Foundry Entra ID 模式下设置了 ANTHROPIC_FOUNDRY_API_KEY，确认修复已生效。上个版本里 Entra ID 上游无法启动。

检查点三，CLAUDE_CODE_SUBAGENT_MODEL_FORCE 落地。 如果治理策略要求所有 agent 使用特定模型，现在就在环境配置里设置这个变量，而不是继续依赖 agent 定义里的默认值。

检查点四，模型 ID 固定字符串。 如果有 claude-fable-5-0 硬编码，决定是留在 5.0 还是更新到 claude-fable-5-1。TheRouter 并未定义通用别名 fable——固定的模型 ID 字符串需要手动更新。

检查点五，缓存成本基准更新。 如果 Fable 档模型在你的 prompt-cache 密集型流水线里占比高，把成本模型里的缓存读取更新为 $0.25/Mtok。

Claude Code 2.1.257 已正式发布。Containment Escape 规则从这个版本起在 auto 模式里默认生效。

来源 Anthropic Claude Code releases