OpenAI Container Sessions Per-Minute Billing: 5-Minute Minimum Cost Model for Hosted Shell and Code Interpreter

OpenAI container sessions now use per-minute billing with a 5-minute minimum for Hosted Shell and Code Interpreter. This routing cost model explains when to reuse container_reference, avoid fresh container_auto sessions, and right-size memory tiers.

Published via OpenAI

Archive item produced with AI assistance from the cited source and published without individual review. Editor of record: Joe Werner.

Abstract editorial illustration of a billing meter and branching agent routing paths on a neutral background

OpenAI quietly changed how eligible container sessions are billed on June 2, 2026. Instead of charging the full 20-minute session rate regardless of actual usage, the platform now charges by the minute, with a 5-minute minimum per session. The per-minute rate itself is unchanged.

This is not a price cut. It is a billing granularity change — and for teams that route agent workloads through OpenAI's Hosted Shell or Code Interpreter, the implications for cost modeling are significant.

What Changed and Where It Applies

Container sessions cover two built-in tools available through the Responses API:

  • Hosted Shell (container_auto or container_reference) — a full Debian 12 terminal environment with Python, Node.js, Go, Java, Ruby, and PHP preinstalled.
  • Code Interpreter — the sandboxed execution environment for data analysis, file processing, and computation.

Previous billing model: every eligible session was charged at the 20-minute block rate regardless of duration. A 90-second data-processing task cost the same as a 19-minute debugging session.

New billing model (effective June 2): sessions are billed per minute actually elapsed, with a floor of 5 minutes. A 90-second task now costs 5 minutes. A 7-minute task costs 7 minutes. A 22-minute session still costs 22 minutes.

Current pricing (unchanged per minute): 1 GB RAM costs $0.03 per 20 minutes → $0.0015/min; 4 GB $0.006/min; 16 GB $0.024/min; 64 GB $0.096/min.

The Routing Cost Model Implications

For teams routing OpenAI container sessions per-minute billing, the 5-minute minimum creates a new cost floor that reshapes three common routing decisions.

Decision 1: Micro-Task Routing

Short tasks (under 5 minutes of actual container time) now have a fixed minimum cost. If your agent pattern spawns a fresh container for every small tool call — converting a CSV, running a quick calculation — you are paying for 5 minutes regardless.

Routing implication: For predictable micro-tasks that run in under 2 minutes, evaluate whether a local shell runtime (self-hosted) or a function call without a container is more cost-efficient. The hosted shell guide explicitly supports a local execution path for teams that want to avoid container overhead.

Decision 2: Session Reuse vs. Fresh Containers

The Containers API allows creating a persistent container and referencing it across multiple Responses API calls via container_reference. With per-minute billing, reusing a long-lived container across a multi-step agent session is now clearly more efficient than spawning a new container per step.

Previously, the flat 20-minute rate made short-lived containers relatively cheap compared to keeping one alive. Now, each new container session carries a 5-minute minimum, so batching multi-step work into a single container session lowers your effective cost per task.

Routing implication: If your router dispatches sequential tool calls to hosted shell, pass container_reference rather than container_auto for each call. Design container lifecycle to match your agent session lifecycle, not individual tool calls.

Decision 3: Memory Tier Selection in Routing Policy

The minimum bill applies per container at whatever memory tier you provisioned. A 64 GB container that runs a 45-second task now costs $0.48 (5 minutes × $0.096/min) instead of $1.92 (full 20 minutes). That is a genuine reduction for over-provisioned containers.

Routing implication: Check whether your routing policy defaults to a higher memory tier than tasks actually need. With per-minute billing, right-sizing the memory tier now has a more direct impact on short-session cost than it did under the flat rate.

What Operators Need to Check Now

Review these three areas if you use OpenAI container sessions in your routing layer:

  1. Cost attribution per task type — segment container session costs by task duration. Identify which task categories consistently run under 5 minutes and evaluate local shell or function-call alternatives.
  2. Container lifecycle in your agent orchestration — confirm your orchestration layer passes container_id across multi-step tool calls within the same agent turn. Each container_auto call creates a fresh session and a fresh 5-minute minimum.
  3. Memory tier defaults in routing config — audit the memory_limit setting you pass to the Containers API. If you default to 4 GB or 16 GB for all tasks, evaluate whether task-type-based tier routing makes sense now that per-minute costs are transparent.

The Routing Decision Checklist

Use this decision framework when routing tasks that may involve OpenAI container sessions with per-minute billing:

  • Task runtime < 2 min and predictable? → Consider local shell or pure function call
  • Task runtime 2–5 min? → Hosted container is justified; reuse via container_reference within the agent session
  • Task runtime > 5 min or file-heavy? → Hosted container is the right call; right-size memory tier
  • Multi-step sequential shell work? → Create one container, pass container_reference across all steps; do not spawn fresh containers per call

Source and Verification

The billing change is documented in the OpenAI API changelog (June 2, 2026 entry) and reflected in the built-in tools pricing page: "Eligible container sessions will be billed by the minute, with a 5-minute minimum per session."

For routing architecture context, see the TheRouter documentation and the related story on OpenAI's legacy model deprecation wave for broader API lifecycle planning.

Help & contact