Stop rebuilding intermediate files every request: reuse the Code Execution container to carry pipeline state

The billing reality: execution-time charges and the "attached files" trap

Before talking about reuse, it helps to internalize that Code Execution is billed separately from tokens. When you pair it with web search or web fetch there is no extra charge, but used on its own it is billed by execution time (the container's running time). There are a few traps here that cost you if you don't know them.

That last row matters most. The moment you attach an input file, execution time accrues for loading it onto the container, even if Claude never runs any code. A habit of "let me attach the CSV every time just in case" keeps generating cost even on lightweight questions where no code runs.

This is where container reuse pays off. Instead of re-attaching a large input file on every request, mount it once, leave the intermediate results in the workspace, and pass the container ID afterward to skip the attachment. Given that the minimum charge is in 5-minute units, finishing a sequence in one container beats standing up a fresh container for each tiny step. Once I limited input attachment to the first call, the execution-time line in my aggregation job's bill dropped noticeably.

Running a multi-step pipeline in one container

Abstract talk is hard to hold onto, so let me run "extract -> clean -> aggregate -> output" through a single container. Each stage leaves its artifact as a file, and the next stage reads it.

import anthropic
 
client = anthropic.Anthropic()
TOOLS = [{"type": "code_execution_20250825", "name": "code_execution"}]
MODEL = "claude-opus-4-8"
 
 
def step(container_id, instruction):
    """Run one stage while reusing the same container; return the container ID."""
    kwargs = dict(model=MODEL, max_tokens=4096, tools=TOOLS,
                  messages=[{"role": "user", "content": instruction}])
    if container_id:
        kwargs["container"] = container_id
    resp = client.messages.create(**kwargs)
    return resp.container.id, resp
 
 
# Stage 1: load input, save the extracted result to an intermediate file (attach input only here)
cid, _ = step(None,
    "Load the raw sales data, extract only the needed columns, and save to '/tmp/extracted.parquet'")
 
# Stage 2: clean (read the previous intermediate file; do not re-attach the input)
cid, _ = step(cid,
    "Read '/tmp/extracted.parquet', impute missing values and fix types, save to '/tmp/clean.parquet'")
 
# Stage 3: aggregate
cid, _ = step(cid,
    "Aggregate '/tmp/clean.parquet' by month and save to '/tmp/summary.csv'")
 
# Stage 4: output (generate a chart)
cid, final = step(cid,
    "From '/tmp/summary.csv', build a monthly line chart and save it as 'report.png'")
 
print("pipeline container:", cid)

step() is a thin wrapper that takes a container_id and, if present, passes it into container=. From stage 2 on, no input data is attached, because extracted.parquet already lives inside the container. With this setup, each stage's instruction can focus only on "which file to read, which file to write," and Claude is less likely to get confused too.

The design tip is to always separate stage boundaries with files. If the intermediate result persists as a file, you can rebuild just one stage from its input file when you need to. Cram everything into a single request and you tend to restart from scratch whenever you hit the 90-second cell limit (more on that below).

Don't swallow container_expired

Reuse is convenient, but containers don't live forever. Containers expire 30 days after creation. Specify an expired container and the tool result returns the container_expired error code. For jobs left idle for a while, or batches you resume the following week, you have to plan for this.

What you must not do is swallow container_expired and proceed as if it "succeeded." Continue aggregating in a container that has no intermediate files, and an empty report quietly takes shape. In an unattended pipeline, the pattern I fear most is exactly this: no error raised, yet the wrong result emerges.

The defensive baseline is to never treat the container ID as an absolute precondition. Treat intermediate files as a cache, and make sure you can rebuild from source (the original input) if they have expired.

import anthropic
 
client = anthropic.Anthropic()
TOOLS = [{"type": "code_execution_20250825", "name": "code_execution"}]
MODEL = "claude-opus-4-8"
 
 
def has_container_expired(resp):
    """Check whether the response contains a container_expired error."""
    for block in resp.content:
        content = getattr(block, "content", None)
        err = getattr(content, "error_code", None)
        if err == "container_expired":
            return True
    return False
 
 
def run_summary(container_id, source_instruction, summary_instruction):
    # First, try to continue on the existing container
    if container_id:
        resp = client.messages.create(
            container=container_id, model=MODEL, max_tokens=4096, tools=TOOLS,
            messages=[{"role": "user", "content": summary_instruction}],
        )
        if not has_container_expired(resp):
            return resp.container.id, resp
        # If expired, don't swallow it; fall through to a rebuild
        print("Detected container_expired. Rebuilding from source.")
 
    # No container, or it expired: rebuild from the original input
    resp = client.messages.create(
        model=MODEL, max_tokens=4096, tools=TOOLS,
        messages=[{"role": "user", "content": source_instruction}],
    )
    return resp.container.id, resp

With this shape, expiry becomes a "cache miss" rather than an error. Thirty days sounds generous, but month-crossing operations and jobs that only run occasionally hit it routinely. The small effort of explicitly catching container_expired and branching is what prevents silent degradation.

Combine the 90-second cell limit with reuse

One more thing worth knowing: each cell has a 90-second wall-clock limit (exceeding it returns a detection_timeout-style result). Pack heavy work into one cell and you get cut off here.

Container reuse pairs nicely with this limit. Split heavy work into "fits in 90 seconds" units, write each step's result to a file, and keep going in the same container. For aggregating a large number of records, for example, you can save per-chunk partial aggregates as /tmp/partial_0001.parquet and merge them at the end. That kind of split works precisely because state persists as files inside the container.

# Conceptual example: split heavy aggregation into 90-second-safe units in the same container
cid, _ = step(None,
    "Split a huge log into chunks of 500k rows, partially aggregate each chunk, and save to "
    "'/tmp/partial_<seq>.parquet'. You may proceed one chunk at a time")
 
cid, _ = step(cid,
    "Load all of '/tmp/partial_*.parquet', merge them, and save the final result to '/tmp/final.parquet'")

Because the split partial aggregates remain inside the container, if one chunk stalls midway you can resume from the remaining partial_*.parquet. Not forcing everything into one request is, in the end, what makes the whole thing robust.

To try this, pick one job where you currently attach the input file on every request, and switch it to mount once and pass container.id thereafter. The surest check is the billing number: see how much the execution-time line changes. For me, the confidence of running an unattended pipeline shifted a notch once I added reuse and expiry handling. I hope it helps anyone automating multi-stage processing the same way.