Claude Code Execution: How the 90-Second Cell Budget Works (and What Operators Need to Fix)

Anthropic's June 11 platform update added code_execution_20260521, the third version of the code execution tool. The change is surgical: it takes the same sandboxed runtime introduced in code_execution_20260120 and adds the 90-second per-cell wall-clock limit to the tool's own description. That one addition changes how Claude reasons about cell design and changes what operators need to account for in pipeline architecture.

What changed

All three tool versions share the same underlying sandbox — Python and Bash in an isolated container, with REPL state persistence and programmatic tool calling from within the sandbox (features added in _20260120). What code_execution_20260521 adds is that the 90-second ceiling is now part of the tool definition Claude sees.

Previously, the 90-second limit was enforced silently at the infrastructure layer. Claude would write cells without knowledge of the constraint, and any cell exceeding the limit would return a detection_timeout error that the model had to reason about reactively. Now Claude knows the limit exists before writing the first line of code.

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

No beta header is required.

What detection_timeout looks like

When a cell exceeds 90 seconds of wall-clock time, the API returns a detection_timeout result in the tool output block instead of stdout/stderr. This is the same behavior as before — code_execution_20260521 does not change the error format — but the model now anticipates the constraint and structures cells to avoid triggering it.

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

Your pipeline should handle detection_timeout explicitly. Leaving it unhandled causes Claude to retry the same cell design or stop the turn without a useful result.

Model compatibility

code_execution_20260521 is available on:

Haiku 4.5 and the deprecated Opus 4.1 remain on code_execution_20250825, which predates both REPL persistence and cell budget disclosure. If you route cheaper tasks to Haiku 4.5, the model does not see the 90-second constraint and will not budget accordingly.

Platform availability

Code execution is only available on:

• Claude API (Anthropic direct)
• Claude Platform on AWS
• Microsoft Foundry

It is not available on Amazon Bedrock or Vertex AI. If your routing layer conditionally selects Bedrock or Vertex as execution targets, code execution calls will fail at those endpoints regardless of tool version.

Pricing note

Code execution calls are free when the same request includes web_search_20260209 or later, or web_fetch_20260209 or later. Standard code execution charges apply when neither web tool is present.

What this means for operators

1. Upgrade the tool version string

Swapping code_execution_20260120 or code_execution_20250825 to code_execution_20260521 is the minimum change required to enable model-side cell budgeting on supported models. The runtime behavior is otherwise identical.

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

2. Add detection_timeout handling to your pipeline

If detection_timeout appears in a tool result, the pipeline should:

1. Log the failure with cell content and turn ID for later inspection
2. Decide whether to retry with a split cell or escalate to the user
3. Not silently swallow the error and continue — Claude will produce degraded output if it sees a timeout it cannot act on

A simple handler in Python:

def handle_tool_result(result):
    content = result.get("content", [{}])
    text = content[0].get("text", "") if content else ""
    if text == "detection_timeout":
        raise CellTimeoutError("Code cell exceeded 90s wall-clock limit")
    return text

3. Prompt for cell-splitting on long-running tasks

Claude now knows the 90-second limit but does not always split proactively without guidance. For known long-running data tasks — large file parsing, iterative ML loops, multi-stage ETL — add an explicit instruction to your system prompt:

When processing large datasets or running iterative loops, split work into
cells that each complete in under 60 seconds. Do not rely on a single cell
for any task that may take more than a minute.

The 60-second target gives a 30-second buffer before detection_timeout. For tasks with predictable runtime, instructing Claude to add a timeout guard (e.g., Python's signal.alarm) inside the cell is also effective.

4. Review your Haiku 4.5 routing paths

If you route lower-priority agentic tasks to Claude Haiku 4.5 for cost reasons, be aware that those calls stay on code_execution_20250825 and the model does not see the 90-second constraint. Either accept that timeout handling must be fully external for those paths, or add a system prompt note stating the limit explicitly — the effect will be approximate since the model has no tool description anchor.

5. Combine with response_inclusion for cost control

code_execution_20260521 pairs well with the response_inclusion parameter on web_search_20260318 and web_fetch_20260318 (released the same day). When Claude uses web search to gather data and then processes it via code execution in the same turn, setting response_inclusion: "excluded" on the web tools drops consumed search result blocks from the API response, reducing output token charges on multi-step data pipeline turns.

Routing implications

The practical effect of code_execution_20260521 is that cell failures become more predictable and recoverable. A model that knows it has 90 seconds per cell will attempt to write shorter cells, flag tasks that need multi-cell treatment, and avoid the silent detection_timeout surprises that previously appeared in production logs without clear context.

For operators running notebook-style agentic pipelines — data analysis, report generation, multi-step computation — the upgrade path is a one-line tool version change plus explicit timeout handling in the pipeline layer. Both are worth doing before the next run that hits a slow dataset.