OpenAI opens the Agents API in public beta: giving every developer the same managed harness that powers Codex

From 10 September 2026, OpenAI’s Agents API is in public beta, open to all developers. It gives you access to the same managed orchestration infrastructure that runs Codex and ChatGPT for Work, session management, context compaction, subagent coordination, and hosted sandboxes, through a single API call. You pay only standard token and tool rates. There are no additional fees for the harness itself.

What the Agents API actually is

If you have built anything with long-running agents before, you know where the time goes. It is not the model calls. It is everything around them: keeping context alive across a session that runs for hours, writing retry logic, routing tool calls, managing subagent lifecycles, and making sure the whole thing does not fall over between steps. Most teams end up writing a substantial amount of plumbing before they ship a single feature.

The Agents API is OpenAI’s answer to that problem. Rather than giving you a framework to run yourself (that is the Agents SDK, which has been available since March 2025), the Agents API is a managed service. OpenAI runs the harness. You describe the task, the model, the tools, and the environment, and OpenAI handles everything else.

The API is built around four concepts:

Agent: the model, instructions, tools, and any MCP servers the agent can use.
Environment: an optional sandbox where the agent can access files, run commands, and load skills.
Session: a durable agent instance that persists across steps and responds to new input.
Events and items: the inputs sent to the agent and the outputs it produces.

Context compaction and subagent coordination, handled for you

Two things tend to break long-running agents in practice: running out of context window, and losing track of parallel work. The Agents API addresses both without asking you to implement anything yourself.

Context compaction is automatic. As a session approaches its context limit, the API compacts earlier content without you writing a single line of compaction logic. When multi-agent mode is enabled, compaction is applied independently to the root agent and each subagent, so their contexts do not interfere with each other.

Subagent coordination works the same way. The root agent can spawn subagents, send them bounded tasks, wait for results, and synthesise a final answer. Your application does not need to implement any orchestration to make this happen. The default max_concurrent_subagents is set to 3, which OpenAI recommends as a sensible starting point.

Tool search loads relevant tool definitions as needed rather than stuffing everything into context upfront, which keeps token usage and cost down while preserving the model’s cache. Agents can also run tool calls in parallel and filter or combine results in code before bringing anything back into context.

Sandbox options

You have three choices for where the agent actually runs its work:

OpenAI-hosted sandbox: the same sandboxing infrastructure behind Codex and ChatGPT, configurable with files, packages, skills, and plugins.
Your own infrastructure: run codex exec-server inside your environment. It registers with a restricted key and connects over WebSocket. All connections are outbound from your side.
Partner sandboxes: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel are all supported.

The underlying harness is also open-source via the Codex repository, so you can inspect how it works regardless of which option you choose.

What this means for you

The practical effect depends on where you are right now.

If you are building long-running agents for the first time, the Agents API removes a significant amount of foundational work. You do not need to design a context management strategy, build a subagent orchestration layer, or maintain sandbox lifecycle code. You get a production-grade harness from the first call.

If you already have agents running in production on top of something like LangGraph or CrewAI, the question is whether to migrate. Early users report meaningful improvements. Ciridae saw their evaluation score rise from 0.71 to 0.85 with a 4x reduction in latency on subagent flows. SafetyKit reported a 60% reduction in cost per case after migrating their case review workflow. Hypha saw an 86% drop in failed agent responses after separating the harness from the sandbox. Those are not incremental numbers.

If you are in a regulated industry or based in Europe, there is a hard constraint to know about before you plan anything. During the public beta, data residency is US-only, and Zero Data Retention is not supported. That is a genuine blocker for many healthcare, financial services, and legal workloads, regardless of whether you use an OpenAI-hosted sandbox or a partner provider. OpenAI has not given a timeline for expanding residency options.

Pricing and what is going away

Pricing is straightforward. Model usage is billed at the selected model’s standard API rates. OpenAI tools use their standard rates. OpenAI-hosted sandboxes use standard container rates. The managed harness itself carries no additional charge.

One housekeeping note: OpenAI is retiring Agent Builder and Evals on 30 November 2026, pointing code-based workflows towards the Agents SDK and Agents API. If you are using either of those tools, it is worth planning your migration now rather than in November.

The honest picture

The Agents API is a meaningful shift in how much infrastructure you need to own when building agents that run for minutes, hours, or days. The “no extra fees” pricing removes a concern that would otherwise complicate build-versus-buy decisions. The beta limitations around data residency are real and worth checking against your requirements before you commit to a migration path.

For most developers building with OpenAI’s models, it is worth at least running the API against a real task and comparing the results against what you have now. The official documentation is a reasonable starting point.