NEW DELHI, September 11, 2026, 5:35 p.m. IST — OpenAI has launched the Agents API in public beta, giving developers a managed version of the agent harness behind Codex for workloads that can run across long sessions, use tools and delegate work to subagents.
The release moves a consequential part of production agent infrastructure from application code into OpenAI’s control plane. Instead of assembling context compaction, tool discovery, multi-agent coordination and sandbox lifecycle independently, teams can now request an agent session with a model, tools and execution environment through one API.
For platform and DevOps teams, that convenience comes with a new set of architectural decisions. OpenAI’s documentation says the API currently supports data residency only in the United States and is not eligible for Zero Data Retention, even when a customer runs the execution sandbox on its own infrastructure. The product is also a public beta, so operational behavior and interfaces may change before general availability.
What OpenAI confirmed
OpenAI said the Agents API is available to all developers and carries no separate orchestration fee. Customers pay for the selected model, tools and compute resources they use. An OpenAI-hosted sandbox is billed at the company’s standard container rates, while model use is billed separately.
A session can run in an OpenAI-hosted Linux sandbox, on infrastructure operated by the customer, or through an integrated sandbox provider. Launch partners named by OpenAI include Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel. Partner options span managed environments, VPC deployments and different compute, storage and secret-handling models.
The managed harness includes automatic context compaction for work that exceeds a single model context window. Tool search can load definitions only when they are relevant, while programmatic tool calling can run operations in parallel and filter results before returning them to the model. The service supports MCP servers, custom functions and built-in tools such as web search.
Multi-agent mode lets a coordinating agent divide work among isolated subagents with separate contexts. OpenAI presents customer-reported improvements in evaluation scores, latency, cost and failure rates, but those figures are early adopter reports rather than independent benchmarks and should not be treated as guarantees for other workloads.
The operational boundary matters more than the demo
The API separates the agent harness from its execution environment. That is useful for organizations that want OpenAI to manage sessions and context while code runs in a customer-controlled network. It does not, however, make a self-hosted sandbox equivalent to a fully self-contained agent deployment: session state still passes through the Agents API, and OpenAI explicitly says self-hosting does not make the service eligible for Zero Data Retention.
OpenAI-hosted sandboxes also allow outbound network access by default unless a template policy says otherwise. Teams can disable networking or restrict it to an allowlist of exact hostnames. Redirect targets and subdomains require separate entries, and the current documentation notes that hosted standard-input/output MCP servers require unrestricted outbound access.
That default deserves deliberate review before connecting an agent to source repositories, incident systems or cloud credentials. A safer production baseline is to deny network access unless a workload needs it, grant narrowly scoped service identities, inject short-lived secrets, separate read and write tools, and place approval gates before deployment, credential, billing or customer-data actions.
What changes for developer and platform teams
The service may reduce the amount of custom orchestration code required for long-running agents, but it does not remove the need for reliability engineering. OpenAI’s hosted-sandbox guide says a completed turn does not guarantee that every tool succeeded. Applications still need to inspect session events and artifacts, define success conditions, handle partial completion and make retries idempotent.
Sandbox lifecycle also affects workflow design. Files persist between turns while an OpenAI-hosted sandbox exists, but an inactive sandbox can be deleted after one hour without keep-alives. Files placed in the designated outputs directory are published as immutable artifacts after a turn completes. Teams should export required results, delete finished sessions and avoid treating a live workspace as durable storage.
Observability should follow the unit of work rather than only the model request. Useful production signals include total tool calls, denied egress attempts, approval waits, retry counts, subagent fan-out, artifact completeness, task-level cost and verified outcome rate. That approach aligns with the broader discipline of LLMOps, where model quality is only one part of a dependable system.
Before migrating an existing workflow, teams should replay a representative evaluation set through both the current harness and the new service. Measure end-to-end success, not just whether the API returned a completed status. Long-running tasks should also have explicit time, token, tool-call and spend budgets to prevent loops from becoming unbounded bills.
A managed harness creates a new dependency
OpenAI has open-sourced the underlying Codex harness, which gives developers visibility into the coordination logic and an escape route for some use cases. The hosted Agents API nevertheless creates a provider dependency at the orchestration layer, above the model itself. Version changes can affect context selection, tool behavior and delegation even when an application keeps the same model identifier.
Platform teams should therefore pin supported SDK and API versions where possible, store portable task inputs and outputs, and maintain a small conformance suite for critical workflows. A self-hosted fallback is most valuable when it is tested before an outage or policy constraint makes it necessary.
The launch is a meaningful step toward agents as managed cloud workloads rather than collections of prompts and tool loops. Its practical value will depend on whether OpenAI can stabilize the beta while giving enterprises the residency, retention, audit and network controls required for sensitive production systems.
Sources
OpenAI’s Agents API announcement, the Agents API technical overview, the hosted sandbox guide, and the API pricing reference. For broader independent context on agent deployment transparency and operational controls, see the MIT AI Agent Index.
