OpenAI Agents API Beta: Codex's Harness, Now an API

What Shipped

OpenAI added the Agents API to its public API in beta, listed under September 10 in the official OpenAI API changelog. In OpenAI's own description, "the Agents API gives your application access to the Codex harness through an OpenAI-managed API." That framing matters: this is not a new model. It is a managed service that runs the same orchestration layer that already powers Codex, made available for developers to call directly.

The pitch is a division of labor. OpenAI manages sessions, orchestration, context compaction, and recovery. The developer's application supplies the tools and picks where the code actually executes. For teams that have been hand-rolling agent loops -- retry logic, context trimming, task state -- this moves that plumbing out of their own codebase and into OpenAI's infrastructure.

Four Core Concepts

The Agents API is built around four concepts. An Agent bundles a model, instructions, tools, and any connected MCP servers. An Environment is the optional sandbox or compute target the agent runs in. A Session is a durable instance that works on a task over time and responds to input as it arrives, rather than a single request-response call. Events and items are the inputs sent to a session and the outputs it produces along the way.

A session's lifecycle follows a consistent pattern: create a session, give it a task, follow its progress by streaming output or listening for webhooks, then continue the task or steer it as needed.

Under that structure, the managed harness handles a specific set of jobs: running commands and code inside a sandbox; applying skills and instructions; connecting to external data through tools or MCP; letting a developer steer the agent mid-task; summarizing earlier work to keep the context window under control; splitting work into subtasks and delegating pieces to subagents; and resuming a session from where it left off after a pause or disconnect.

That subagent piece is exposed directly in the API through a multi_agent configuration block, with an enabled flag and a max_concurrent_subagents setting -- the documentation's own example sets it to 4. Combined with session durability and context compaction, the API is explicitly built for tasks that run longer than a single model call, not just one-shot completions.

Building Against It

In practice, a developer starts a session with a call like client.beta.agents.sessions.create(...), configuring an agent.model (the docs example uses gpt-6-astra), agent.instructions, and agent.tools -- which can include programmatic_tool_calling, mcp, or web_search. The request also sets environment.type to pick where execution happens.

Three environment types are available. openai_hosted provisions a Linux workspace with Python, Node.js, and CLI tools, with a working directory at /workspace; it accepts configuration for packages, setup commands, files, environment variables, skills, plugins, capability directories, and an environment template ID, and network access can be toggled on or off. self_hosted lets a developer run codex exec-server from the @openai/codex@alpha package on their own laptop, container, or remote sandbox; it registers with an environment ID and a restricted executor key, then connects outbound over WebSocket to OpenAI's coordination endpoint, reconnecting automatically if the connection drops. none skips a sandboxed environment entirely.

Authentication requires the application's API key to carry the api.agents.read and api.agents.write scopes, plus api.responses.write for the underlying model inference. Every request also needs an OpenAI-Beta: agents=v1 header; the official SDKs add it automatically, but anyone calling the API with cURL has to set it by hand -- a small but concrete reminder that this is a beta surface, not a stable one.

On pricing, there is no separate fee layered on top of the Agents API itself. Model usage bills at the selected model's standard API rates, OpenAI tools bill at their standard rates, and OpenAI-hosted sandboxes bill at standard container rates.

One constraint is worth flagging before any enterprise evaluation. OpenAI's documentation states that the Agents API currently supports data residency only in the United States and does not support Zero Data Retention, and that choosing a self-hosted sandbox does not make the API ZDR-eligible. Session state is retained so work can continue across turns, though sessions and published artifacts can be deleted.

Pros and Cons

The clearest benefit is that context compaction, failure recovery, and session durability move off the developer's plate and onto OpenAI's managed service -- infrastructure that is genuinely hard to build well. Native subagent fan-out through multi_agent is also a capability most teams would otherwise build themselves. The self_hosted environment is a real escape hatch: code can run on a developer's own hardware even while OpenAI continues to manage the orchestration.

The trade-off is equally real. Building on the beta.agents namespace with a required agents=v1 header ties an application to a beta contract that can still change. And because orchestration always stays with OpenAI regardless of environment choice, adopting the API means depending on OpenAI's harness for how work gets scheduled and steered, not just for model inference. The data-handling terms compound that: US-only data residency and no ZDR support are hard blockers for some regulated teams, and the self_hosted option does not lift them.

Outlook

The official showcase applications listed in OpenAI's documentation -- an incident response agent, a Slack bot, a read-only SQL data analyst, a GitHub issue investigator, and a document reviewer -- point at long-running, tool-using workflows rather than chat interfaces. Those are the kinds of tasks that benefit most from durable sessions and mid-task steering, and they suggest where OpenAI expects early adoption to concentrate. Because the API is in beta, its interface and pricing model may still change before a general release.

Conclusion

The Agents API packages infrastructure OpenAI was already running for Codex and offers it directly to developers who need long-running, steerable, tool-using sessions. It suits teams building incident-response, code-investigation, or data-analysis agents that would otherwise need custom orchestration code. Teams wary of beta APIs or deeper OpenAI lock-in should watch how the interface settles before committing production workloads to it.

Editor's Verdict

OpenAI Agents API Beta: Codex's Harness, Now an API earns a solid recommendation within the GPT space.

The strongest case for paying attention: moves context compaction, failure recovery, and session durability off the developer's codebase and into a managed service. That alone raises the bar for what readers should expect in this space. Reinforcing that, native multi_agent subagent fan-out is available as a direct API parameter — practical value rather than just headline appeal. The broader signal worth registering is straightforward: the API productizes Codex's own orchestration layer rather than shipping a new model, separating 'who manages the agent loop' from 'what model or tools it uses'. On the other side of the ledger, one constraint is real rather than a marketing footnote: orchestration remains dependent on OpenAI's harness regardless of which environment type is chosen. It should factor into any serious decision. Layered on top of that, beta-stage API surface (beta.agents namespace, required agents=v1 header) may still change before general availability — which narrows the set of teams for whom this is an obvious yes.

For ChatGPT power users, OpenAI API customers, and enterprise teams already running on the OpenAI stack, this is a serious evaluation candidate, not just a curiosity to bookmark. For everyone else, the safer posture is to monitor coverage and revisit once the use cases that matter to your team are demonstrated in the wild.