OpenAI adds container pools to the Responses API for faster hosted shell and code interpreter
Original: Agent workflows got even faster. You can spin up containers for skills, shell and code interpreter about 10x faster. We added a container pool to the Responses API, so requests can reuse warm infrastructure instead of creating a full container creation each session. developers.openai.com/api/docs/guide… View original →
What OpenAI announced on X
On March 21, 2026, OpenAI Developers said agent workflows got faster because containers for skills, hosted shell, and code interpreter could start roughly 10x faster. The key change was a container pool added to the Responses API, letting requests reuse warm infrastructure instead of creating a fresh environment every session.
What the updated hosted shell docs clarify
The linked OpenAI documentation frames this inside the hosted shell guide. It shows that a request can ask OpenAI to provision a container automatically with container_auto, then reuse an active environment later with a container_reference. The docs also say hosted shell runs inside OpenAI-hosted containers and shares the same lifecycle model as Code Interpreter.
- Containers are explicitly ephemeral, so persistent data still needs to live in external systems.
- Files created in the container remain available while the container is active, which makes iterative multi-step workflows practical.
- OpenAI says a hosted shell container expires after 20 minutes of inactivity, after which the data cannot be recovered.
Why this matters
The improvement matters because container startup overhead is often one of the most visible latency sources in agent systems that need shell access or temporary execution environments. If the platform can reuse warm containers, the agent spends less time waiting for infrastructure and more time actually reading files, running commands, or iterating on tools.
It also shows OpenAI tightening the link between model calls and execution environments. The Responses API is no longer just returning text or tool calls; it is increasingly acting as the control plane for short-lived developer runtimes. That makes the OpenAI stack more attractive for teams building agents that need code execution, but it also reinforces a constraint the docs make clear: hosted containers are convenient, not durable, so production workflows still need explicit state and artifact handling outside the container lifecycle.
Sources: OpenAI Developers X post · OpenAI hosted shell guide
Related Articles
OpenAI Developers published a March 11, 2026 engineering write-up explaining how the Responses API uses a hosted computer environment for long-running agent workflows. The post centers on shell execution, hosted containers, controlled network access, reusable skills, and native compaction for context management.
Perplexity said on March 11, 2026 that its new Agent API combines search, tool execution, and multi-model orchestration behind one managed runtime. The launch positions Perplexity less as a single-answer interface and more as infrastructure for production agent workflows.
On March 11, 2026, OpenAI published new guidance on designing AI agents to resist prompt injection, framing untrusted emails, web pages, and other inputs as a core security boundary. The company says robust agents separate data from instructions, minimize privileges, and require monitoring and user confirmation before taking consequential actions.
Comments (0)
No comments yet. Be the first to comment!