Budget Code Interpreter Containers by Memory and Session

Last reviewed: 2026-10-20

Direct answer

Budget Code Interpreter container costs separately from model tokens. Set an approved memory tier, count the containers and billable sessions created for each business task, and limit replacement containers after failures. A short script or a small final answer can still require a separately priced execution environment.

The current OpenAI pricing page lists container rates by memory tier and a 20-minute session unit. It also says eligible container sessions will be billed by the minute with a five-minute minimum. Verify which treatment applies to your account before converting runtime into dollars.

Container reuse is another control. OpenAI’s Code Interpreter guide says automatic mode can reuse an active container referenced by an earlier tool-call item in the model’s context. Record the returned container_id; an application conversation ID alone does not establish reuse.

Who this is for

This guide is for platform engineers and cost owners running file analysis, spreadsheet processing, chart generation, or other workflows through OpenAI’s hosted Code Interpreter. It covers direct OpenAI API terms checked on October 20, 2026. A gateway, cloud platform, or negotiated agreement needs its own applicable rate evidence.

The proposed controls are application policies and test procedures. No authenticated API call, account billing check, or measured savings experiment was performed for this article.

Key takeaways

• Keep model tokens and container charges on separate budget lines.
• Choose memory before creating a container; the selected tier applies for its lifetime.
• Track actual container IDs across follow-up responses and retries.
• Separate the billing session from the inactivity timer that expires container data.
• Budget replacement environments and recovery work, including unsuccessful tasks.

Sources checked

Three current official references support this workflow:

• OpenAI Pricing supplies the container price table, the eligible-session minute-billing qualification, and the separate model-token treatment.
• OpenAI Code Interpreter explains automatic and explicit creation, reuse through model context, memory tiers, returned container IDs, and expiration behavior.
• OpenAI Create container reference defines memory_limit, the optional expires_after policy, and returned lifecycle fields such as created_at, last_active_at, and status.

All three pages were fetched for this review. These are maintained technical references rather than a dated product announcement; they support an evergreen budgeting procedure. Recheck the pricing and lifecycle terms before approving a new workload or changing its container policy.

Contract details to verify

Price the selected memory tier

The published container table covers Hosted Shell and Code Interpreter. These are the listed rates, with a deliberately narrow planning example:

The example assumes exactly 1,000 billable 20-minute sessions at the listed rate. It excludes model tokens and other services. The same pricing page says eligible sessions will be billed by the minute with a five-minute minimum, without defining eligibility in that passage. Confirm the applicable meter before using a shorter-runtime estimate.

The price follows the chosen tier, so an estimate based only on average memory consumption misses the configuration decision. OpenAI documents 1g as the default and supports 4g, 16g, and 64g. Its pricing page defines GB here as binary gigabytes, or 2^30 bytes.

Memory and container count can compound. Under the table’s assumptions, 1,000 reports using one 1 GB session each produce $30 in container charges. Four fresh 1 GB sessions per report produce $120; four fresh 4 GB sessions produce $480. These are arithmetic scenarios, not observed bills or guaranteed savings from reuse.

Keep billing and expiration clocks separate

The Code Interpreter guide says a container expires after 20 minutes without use. An expired container cannot be reactivated, and its data is discarded. Save required outputs while it is active and retain the approved inputs needed to rebuild the task.

That inactivity rule does not establish how many billing units a long-running or repeatedly used container incurs. Likewise, a local timeout does not establish the end of its billable session. Match account usage to the applicable pricing terms instead of deriving a charge solely from expiration.

Activity is broader than useful computation. The guide says container operations, including retrieval and adding or deleting files, refresh last_active_at. A frequent inventory poll can therefore keep moving the inactivity anchor. Use application task events to identify useful work rather than treating that timestamp as a business-activity counter.

The Create container reference also exposes an optional expires_after object anchored to last_active_at, with an interval expressed in minutes. Record any configured policy and the returned value. Treat expiration settings as lifecycle controls; they do not independently prove a billing discount.

Make reuse explicit in the cost record

For automatic creation, this is a settings excerpt from a Responses request, not a complete request:

{
  "tools": [
    {
      "type": "code_interpreter",
      "container": {
        "type": "auto",
        "memory_limit": "1g"
      }
    }
  ]
}

Automatic mode may create a container or reuse an active one from an earlier code_interpreter_call in context. Inspect that output item’s container_id to distinguish the two. For explicit mode, create a container through /v1/containers and pass its returned ID as the tool’s container value.

Choose a reuse boundary that matches the application’s data isolation requirements. Reuse within one approved task can avoid unnecessary creation, but pooling unrelated tenants is not an acceptable shortcut to a lower container count. Do not assume reuse eliminates additional billing sessions while the environment remains active.

Run one bounded workload trial

1. Define the task budget. Name the owner, expected input size, approved memory tier, maximum newly created containers per task, and replacement allowance. Keep a separate token and model-call budget using the agent turn-limit workflow .
2. Qualify the smallest suitable tier. Use representative non-sensitive files and confirm that processing completes correctly. Raise memory only through an explicit workload policy; an example’s 4 GB setting is not evidence that your job requires it.
3. Check follow-up behavior. Run an initial analysis and a follow-up that should continue in the same active environment. Preserve the required context or explicit ID, then compare returned container IDs. Also test a deliberately fresh context to reveal accidental creation paths.
4. Export required results. Save generated files before the container becomes unavailable. Record a durable output reference and whether recovery can rebuild from retained inputs; a container citation alone is not a permanent artifact store.
5. Exercise replacement limits. Test a controlled expired-container case and a local failure path. Confirm the application checks its remaining allowance before creating another environment and preserves earlier attempts in the task’s counters.
6. Reconcile the trial. Compare container identities, memory tiers, task outcomes, model-token usage, and available billing evidence. Keep unresolved session quantities or rates marked unknown and require cost-owner approval before scaling.

For retained retrieval indexes, use the separate vector-store expiration guide . A vector store’s storage meter and a Code Interpreter container’s session meter need distinct records.

Failure modes

Every follow-up starts fresh. A client drops relevant context or always creates an explicit container. Detect this through rising unique container IDs per task, then repair the intended reuse path.

Memory escalation becomes the default retry. A failed job is rerun at successively larger tiers without an approved ceiling. Preserve the original attempt, investigate the failure, and allow another tier only when the remaining task budget permits it.

A timeout resets the creation allowance. The application loses a response and restarts with new counters. Keep the task identity and any known container ID; classify the earlier outcome as unresolved until checked. Do not treat a transport failure as evidence of zero cost.

Polling defeats inactivity expiry. Repeated container reads refresh the activity anchor. Reduce unnecessary container operations and keep a separate record of when useful task work ended.

Recovery has no usable inputs. Expiration discards state that the workflow expected to retain. Stop automatic replacements when required inputs are missing; another empty environment will not restore the old one.

The cost denominator excludes failures. Report container and token cost per successful business output while retaining failed-attempt costs in the numerator. Otherwise, cheaper successful runs can hide an increasingly expensive recovery path.

FAQ

Is one tool call the same as one container charge?

No. The guide allows an active container to be reused across tool activity, while pricing distinguishes container sessions from model tokens. Observe container identities and reconcile the actual session meter rather than multiplying tool calls by a container rate.

Does lowering an output-token limit reduce container charges?

It controls a different cost dimension. Keep it as a token guardrail, then manage memory tier, creation count, replacement policy, and applicable session duration separately.

Does an active container mean only one session will be billed?

An active lifecycle state is not sufficient evidence of that. Verify the billing terms and usage records, including whether the eligible minute-billing rule applies. The inactivity timer describes when the environment becomes unavailable.

Can an expired container be restored?

The guide says it cannot be reactivated. Create a new environment and upload the required files again, with a replacement allowance that also covers renewed model work. In-memory objects from the old container are lost.

Reader next step

Take one file-analysis workflow and add three controls before increasing traffic: an explicit memory tier, a maximum number of new containers per task, and a bounded replacement allowance. Record container IDs, creation or reuse decisions, lifecycle timestamps, output references, and task outcomes without logging file contents or credentials.

Run the initial-analysis, follow-up, and expired-container cases. Use their evidence to approve the creation policy, then reconcile the first available bill against the correct session meter and separate token ledger. Change the budget from observed task behavior rather than assuming every short script has the same cost.