Claude 代码执行工具新增 90 秒单格预算：Operator 必须调整的智能体流水线策略

Anthropic 在 6 月 11 日的平台更新中发布了 code_execution_20260521，这是代码执行工具的第三个版本。变更精准而直接：在 code_execution_20260120 引入的沙箱运行时基础上，将 90 秒每格墙钟限制加入工具自身的描述中。这一改动影响 Claude 对格设计的推理方式，也影响 Operator 需要在流水线架构层面做出的应对。

发生了什么变化

三个工具版本共享同一底层沙箱——隔离容器内的 Python 和 Bash，以及在 _20260120 中新增的 REPL 状态持久化和沙箱内编程式工具调用。code_execution_20260521 的新增内容是：90 秒上限现在被写入 Claude 所看到的工具定义中。

此前，90 秒限制由基础设施层静默执行。Claude 在不知晓此约束的情况下编写格代码，超时后收到 detection_timeout 错误只能被动处理。现在 Claude 在写第一行代码前就知道这个限制存在。

{
  "tools": [{
    "type": "code_execution_20260521",
    "name": "code_execution"
  }]
}

无需 beta 请求头。

detection_timeout 的表现形式

当单个格的墙钟执行时间超过 90 秒时，API 在工具输出块中返回 detection_timeout 而非 stdout/stderr。这与之前的行为一致——code_execution_20260521 并未改变错误格式——但模型现在会在写代码前预见这个约束，并相应设计格的结构。

{
  "type": "tool_result",
  "content": [{
    "type": "text",
    "text": "detection_timeout"
  }]
}

流水线应显式处理 detection_timeout。若不处理，Claude 可能重复尝试相同的格设计，或在没有有效结果的情况下结束轮次。

模型兼容性

code_execution_20260521 适用于以下模型：

Haiku 4.5 和已废弃的 Opus 4.1 继续使用 code_execution_20250825，该版本不含 REPL 持久化和格预算披露。如果你将低优先级任务路由至 Haiku 4.5，模型不会看到 90 秒约束，也不会据此规划格。

平台可用性

代码执行工具仅在以下平台提供：

• Claude API（Anthropic 直连）
• Claude Platform on AWS
• Microsoft Foundry

Amazon Bedrock 和 Vertex AI 不支持代码执行工具。如果路由层将 Bedrock 或 Vertex 作为备选执行目标，代码执行调用将在这些端点失败，与工具版本无关。

价格说明

当同一请求包含 web_search_20260209 或更新版本，或 web_fetch_20260209 或更新版本时，代码执行调用免费。不包含 web 工具时，按标准代码执行费率计费。

Operator 的应对措施

1. 升级工具版本字符串

将 code_execution_20260120 或 code_execution_20250825 替换为 code_execution_20260521，是在支持的模型上启用模型侧格预算所需的最小改动。运行时行为完全一致。

tools = [{"type": "code_execution_20260521", "name": "code_execution"}]

2. 在流水线中显式处理 detection_timeout

当工具结果中出现 detection_timeout 时，流水线应：

1. 记录失败信息，包括格内容和轮次 ID，供后续排查
2. 决定是否拆分格重试，或将问题上报给用户
3. 不要静默忽略错误继续执行——Claude 在看到无法处理的超时时会产生降级输出

Python 简单示例：

def handle_tool_result(result):
    content = result.get("content", [{}])
    text = content[0].get("text", "") if content else ""
    if text == "detection_timeout":
        raise CellTimeoutError("代码格超过 90 秒墙钟限制")
    return text

3. 在提示词中指导格拆分

Claude 现在知晓 90 秒限制，但并不总会主动拆分，尤其是在没有明确指示的情况下。对于已知耗时较长的数据任务——大文件解析、迭代 ML 循环、多阶段 ETL——建议在系统提示词中加入明确指示：

处理大型数据集或运行迭代循环时，请将工作拆分为每格
执行时间不超过 60 秒的多个格。不要将可能耗时超过一分钟的
任务放在单个格中执行。

60 秒目标为 detection_timeout 保留 30 秒缓冲。对于运行时间可预测的任务，也可指示 Claude 在格内加入超时守护（如 Python 的 signal.alarm）。

4. 检查 Haiku 4.5 路由路径

如果你出于成本原因将较低优先级的智能体任务路由至 Claude Haiku 4.5，需注意这些调用仍使用 code_execution_20250825，模型不会看到 90 秒约束。可接受由外部层完全处理超时，或在系统提示词中显式说明该限制——后者为近似效果，因为模型没有工具描述作为参照锚点。

5. 与 response_inclusion 结合降低成本

code_execution_20260521 与同日发布的 web_search_20260318 和 web_fetch_20260318 的 response_inclusion 参数配合使用效果显著。当 Claude 在同一轮次中先通过网络搜索收集数据、再通过代码执行处理数据时，在 web 工具上设置 response_inclusion: "excluded" 可从 API 响应中删除已消费的搜索结果块，降低多步数据流水线轮次的输出 token 费用。

路由层面的影响

code_execution_20260521 的实际效果是让格失败变得更可预测、更易恢复。知晓 90 秒限制的模型会主动编写更短的格，标记需要多格处理的任务，避免之前在生产日志中出现的、上下文不明的静默 detection_timeout。

对于运行 Notebook 式智能体流水线的 Operator——数据分析、报告生成、多步计算——迁移路径是修改一行工具版本字符串，加上流水线层的显式超时处理。两者都值得在下一次命中慢速数据集之前完成。