OpenAI has opened the Agents API in public beta, offering developers a managed way to build cloud agents around the Codex execution layer. The launch brings sessions, tools, sandbox environments and multi-agent workflows behind one API, while leaving the model choice and much of the application design with the developer.[1]
What OpenAI has put into the beta
The Agents API is a platform for running agents rather than a new model announcement. OpenAI says developers can create a production-ready agent in a single API call by defining the task, model, tools and execution environment.[1] The public beta is available to all developers, with model usage, OpenAI tools and hosted sandboxes billed under their respective rates.[1][2]
The basic unit is a durable session. The developer sends input, receives events or webhook notifications, and can continue or steer the same session later.[1][2] That is a different operating model from a one-off request in which the application stores all state and reconstructs the agent’s context on every call.
OpenAI’s documentation describes four parts: an agent, an optional environment, a session, and the events and items exchanged during work.[2] The agent contains the model, instructions, tools and MCP servers. The environment supplies a place to access files, run commands and create artefacts. The session holds the continuing work.
The service is selling coordination as a product
The main change is the amount of application infrastructure OpenAI says it will operate. Its managed service includes session handling, context compaction, recovery, tool discovery, programmatic tool calls and delegation to sub-agents.[1][2] Developers can therefore spend less code on keeping a long-running process alive and more on the tools, permissions and data that define a particular application.
The multi-agent feature is explicit rather than implied. OpenAI says a complex task can be divided into independent pieces, sent to sub-agents in parallel and combined by a coordinating agent.[1][2] Each sub-agent keeps its own context. That may simplify parallel research or analysis, although the announcement does not establish how often the feature improves results outside the customer examples published by OpenAI.[1]
The same API also supports tool search and programmatic tool calling. The documentation says tool definitions can be loaded when needed, while code can run calls in parallel, chain operations and filter results before returning them to the model.[1][2] These features address the practical costs of large tool collections: context size, repeated calls and the amount of intermediate output an application must handle.
Developers still choose the execution boundary
OpenAI is not requiring every agent to run inside an OpenAI-owned environment. The announcement lists OpenAI-hosted sandboxes, developer infrastructure and integrations with sandbox partners including Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel.[1] The documentation groups the options around files, secrets, CPU, GPU, memory, cold-start time and cost.[2]
That choice separates the agent control plane from the place where code and files run. In an OpenAI-hosted sandbox, OpenAI provisions and manages the environment. With a self-hosted option, the application controls more of the compute boundary, but the Agents API still manages the session and its associated service behaviour.[1][2]
The distinction matters for incident response. A team may own the network, storage and runtime permissions while depending on OpenAI for session state, model calls, event delivery and the coordination logic. A failure or policy change in any of those layers can affect the same application, even when its compute runs elsewhere.
The beta has clear policy limits
As of 13 September 2026, the public documentation says that Agents API sessions retain state so work can continue without rebuilding context. It also says that the service currently supports data residency only in the United States and does not support Zero Data Retention. Choosing a self-hosted sandbox does not make the API eligible for ZDR.[2]
Those statements are operational requirements, not footnotes. A team handling regulated or geographically restricted data would need to examine what enters the session, how long it remains available, which tools can receive it and whether the selected environment changes any separate storage obligations. Tools, MCP servers, sandbox partners and application infrastructure may have their own data-handling and residency terms. The documentation points to data-control guidance, but it does not turn the beta into a general-purpose compliance guarantee.[2]
Cost is similarly more specific than the launch headline. OpenAI says there are no additional fees for using the Agents API, while its documentation says model usage, tools and OpenAI-hosted sandboxes are billed through their normal rates.[1][2] The relevant budget is therefore the combined cost of model calls, tool calls, sandbox time and the application’s own infrastructure, not a separate Agents API subscription alone.
What the announcement proves, and what it does not
OpenAI’s announcement and documentation establish that the Agents API is available in public beta and describe a service model built around persistent sessions, managed coordination, tool use and selectable environments.[1][2] OpenAI’s public Codex repository also describes the underlying project as an open-source coding agent and publishes it under the Apache-2.0 licence.[3]
It does not establish that the service is faster, cheaper or more reliable for a typical deployment. The announcement includes customer statements claiming lower latency, lower cost or fewer failed responses, but those figures may use different workloads, baselines, denominators and deployment conditions. They are not independent evaluations, and the page does not supply a common test set, baseline or measurement method.[1]
The practical question is therefore less whether an agent can be started with one request than where responsibility sits after it starts. Developers still need to define permissions, approve sensitive actions, monitor tools and events, limit data access and test failure recovery. The managed service removes some plumbing. It does not remove the need to decide what an agent may do.
read0nly 