Claude Code 2.1.247：/claude-api cost-optimize 命令改变了运营者审计 API 支出的方式

AI gateway 部署里的成本问题，大多数时候等账单到了才变得可见。一个团队可能跑了几周才发现缓存根本没开，或者所有子智能体都在用旗舰模型处理其实只需要一个小模型的任务。Claude Code 2.1.247 把这个反馈周期往前拉了一大截，内置了一个专门做性能分析的命令，同时修复了一个静默的 fallback 断裂问题。

这次发布了什么

2.1.247 里对运营者影响最大的有两件事。

/claude-api cost-optimize 是新增的内置命令，用来分析当前项目的 Claude API 支出，并按照顺序逐项给出可操作的调整建议。覆盖的范围包括缓存（cache hit rate、reads-per-write、TTL 配置），token 用量（上下文膨胀、compaction 阈值、对话长度），batch API 适用性，reasoning effort 调节，以及模型层级选择。每一项都会给出前后的测量对比，而不只是一句建议。

子智能体模型 404 fallback 链 是这次的另一个修复。子智能体发起第一次 API 调用，如果返回了 404（模型名称配置错误、模型已退役，或者 gateway 路由到了不包含该模型的 provider），之前版本会让子智能体直接在那里挂掉。报给上层 session 的错误信息里既没有 request id，也没有具体的模型名称，很难在日志里找到对应的 API 调用。2.1.247 之后，子智能体会走 session 配置好的模型 fallback 列表，fallback 成功了就继续执行；全部 fallback 都失败了，报给上层的错误里会包含 error type、HTTP status、request id 和模型名称。

这个版本还改了 Bedrock、Vertex 和 Foundry 上的 MCP server 连接错误报告方式，以及修复了云端 session 在容器重启后的状态恢复，后面会详细说。

为什么成本分析应该在客户端里做

想管住 AI 成本，第一反应通常是加一层 proxy，在 gateway 层面按模型和团队拦截请求，导出到数据仓库。这个思路对账单归因有效，对优化本身用处有限。proxy 能看到请求的形状，看不到 session 的上下文。它没法判断子智能体每次重试都在拉完整的 100K token 上下文是因为 compaction 配置有问题，也没法发现对某个特定工作流来说换成 medium reasoning effort 能省 40% 的费用，因为 proxy 对 session 结构一无所知。

/claude-api cost-optimize 在 session 内部运行，能观察到上下文大小的增长趋势、cache hit 率与实际 prompt 结构之间的关系，以及 reasoning effort 设置和任务复杂度之间的匹配度，针对的是这个具体项目，而不是所有团队的汇总数据。

对管理很多团队的运营者来说，这改变了支持工作的对话方式。原本要告诉某个团队"你们的费用偏高，检查一下缓存配置"，现在可以让他们跑 /claude-api cost-optimize，直接看到具体是哪个杠杆在出问题。最常见的两个发现，一个是 prompt cache TTL 配置不对，另一个是团队在原型阶段用旗舰模型起步，上生产之后路由策略一直没调整。

子智能体 404 fallback 的空白

2.1.247 之前，子智能体配置有误时，故障序列是这样的。

子智能体启动，用模型 A 发出第一个 API 调用。API 返回 404，模型在这个 provider 或 workspace 里不可用。子智能体挂掉，把一个通用错误报给上层 session，里面没有模型名称，也没有 request id。上层 session 不知道该用另一个模型重试，还是子智能体其实已经完成了部分工作。

Gateway fallback 链本来就是为了处理这种情况，模型 A 不可用就试 B，再试 C。但 fallback 链只对上层 session 的直接调用生效，对子智能体首次调用失败这种情况无效。

2.1.247 的修复让子智能体从第一次调用起就参与 session 的 fallback 链。对运营多 provider 路由的团队来说，效果很直接，一个子智能体配置了某个模型，而你的 workspace API key 在这个 provider 下没有访问权限，现在会走到 fallback 列表里的下一个模型，而不是静默退出。

结构化的错误格式也会正确落到 gateway 日志里。之前子智能体产生的 404 在上层 session 上下文里是一条不透明的错误，很难追溯到对应的 API 调用。

Bedrock、Vertex 和 Foundry 上的 MCP server 连接报错

在这几个托管 backend 上部署有一个安静的摩擦点，MCP server 连接失败是静默的。Claude 执行任务到某一步，需要一个连接失败的 MCP server 提供的工具，找不到工具列表，就得出这个工具不存在的结论，有时候尝试绕过，有时候用一个莫名其妙的错误停下来。真正的原因，连接拒绝、超时还是鉴权失败，在日志里能看到，但不会传给模型。

2.1.247 在 MCP server 连接失败时会向模型发送一条明确的提示。模型可以据此告诉用户，比如"code-search MCP server 连接失败了，这个服务是否正在运行？"，而不是静默出错。对运营者来说，这意味着"Claude 说它做不了 X，但工具应该是可用的"这类支持请求会少很多，因为失败现在在 session 里是可见的。

部署时应该检查什么

成本优化方面，先对花费最高的几个项目跑 /claude-api cost-optimize。最常见的发现是缓存配置，缓存没开，TTL 设置比对话长度短，或者子智能体没有和上层 session 共享缓存。第二常见的是模型层级，团队在原型阶段选了旗舰模型，生产路由策略一直没更新。

子智能体 fallback 这边要检查子智能体配置里的模型名称，在你的 fallback 链覆盖的所有 provider 上是否都可用。如果同时用 Anthropic 直连和 Bedrock 两套 provider，确保两边都有子智能体指定的那个模型，或者在 session config 里显式加一个 fallback 模型。2.1.247 处理的是运行时的失败，但根本的修法是把子智能体的模型列表和 provider 覆盖范围对齐。

MCP 连接失败的情况，如果你在 Bedrock 或 Vertex 上管理 MCP server，确认连接错误现在能在 session 输出里看到。如果看不到，检查 Claude Code 版本是否已经升到 2.1.247 或更高。

TheRouter 用户需要关注的地方

子智能体模型 fallback 行为和 gateway 路由策略之间有直接交互。如果你通过一个 gateway 路由 Claude Code，而这个 gateway 会改写模型名称或映射到 provider 特定的标识符，2.1.247 的 fallback 链会拿着改写后的名称打到 gateway，gateway 需要对各个 provider backend 统一处理 404 响应。如果 gateway 吞掉了 404 并返回了另一个错误码，fallback 链可能不会正确触发。

检查你的 gateway 对 Bedrock、Vertex 和 Anthropic 直连来的模型 404 响应的透传处理方式。路由配置文档里有 TheRouter 里 provider 特定错误处理的配置说明。