Every team that has tried to ship an AI agent has ended up building the same boring software twice. First they build the thing the agent is supposed to do. Then they build the plumbing that keeps it running: tracking what happened in the last step, trimming a conversation that has grown too long for the model’s context window, restarting cleanly after a crash, and coordinating smaller sub-agents that split up a big task. On September 10, OpenAI opened public beta access to something it says removes that second job entirely. It calls it the Agents API, and the pitch is simple. The exact harness that runs Codex, OpenAI’s own coding agent, is now available behind a single API call, for the price of the tokens you use and nothing else.
Quick facts
- Public beta opened September 10, 2026, no fee beyond standard API usage
- Exposes the Codex harness: session state, context compaction, crash recovery, subagent coordination
- Runs in an OpenAI managed sandbox, a customer’s own infrastructure, or a partner sandbox
- Launch partners include Cloudflare, DigitalOcean, Modal, Oracle, Vercel, E2B, Daytona, Runloop and Blaxel
- Early testers report 4x lower latency, 60% lower cost per task and 86% fewer failed responses
- The orchestration layer is OpenAI’s own implementation, which is also the main criticism of it
The part every agent team keeps rebuilding
Ask any engineer who has shipped an autonomous coding or research agent what took the longest, and the answer is rarely the model. It is the harness around it. Something has to remember what tools were already called and what they returned. Something has to decide when the running transcript is getting too large for the model to see all of it, and compress the older parts without losing what matters. Something has to notice when a long task dies partway through and pick it back up rather than starting over. And once a task is big enough to split across several cooperating sub-agents, something has to manage handoffs between them.
OpenAI has been solving exactly that problem internally to keep Codex working reliably on tasks that run for hours or, in some cases, days. The Agents API is that same internal system, opened up so outside developers can call it directly instead of rebuilding a rougher version of it from scratch. According to OpenAI, the harness “handles what developers usually build themselves: session state, context compaction, crash recovery, and subagent coordination,” and keeps an agent running reliably across multi-day tasks rather than the single-turn exchanges most chat-style APIs were designed around.
The Agents API exposes the same session, context and recovery logic that already keeps Codex running on long tasks. Photo by Juanjo Jaramillo via Unsplash.
Three ways to run the same agent
OpenAI is not forcing every workload onto its own servers. Developers choose where the agent’s compute actually executes, and that choice is meant to matter for cost, compliance and how much control a team wants to keep.
| Deployment option | Who manages the sandbox | Best fit |
|---|---|---|
| OpenAI managed sandbox | OpenAI | Fastest way to ship, least setup work |
| Customer infrastructure | The development team | Strict data residency or existing compute contracts |
| Partner sandbox | Cloudflare, DigitalOcean, Modal, Oracle, Vercel, E2B, Daytona, Runloop, Blaxel | Teams already built on one of those platforms |
The numbers OpenAI is leading with
OpenAI is framing this less as a new model and more as an efficiency upgrade for agents that already exist. The company’s early access figures compare teams running the same workload before and after switching to the shared harness.
Reported change for early testers
Figures reported by OpenAI from early access partners. No independent benchmark has yet reproduced them.
As with most numbers a company publishes about its own product, these are worth reading as a directional claim rather than an audited result. What they do line up with is a real, well documented pain point: agent frameworks fail most often not because the underlying model reasons badly, but because the surrounding orchestration mishandles a dropped connection, a stale context window, or a sub-agent that never reports back. If OpenAI’s own infrastructure genuinely handles that better than most in-house implementations, an 86% drop in failed responses is plausible even without independent verification.
The trade-off nobody puts on the launch slide
The catch is baked into the pitch itself. Adopting the Agents API means handing the orchestration layer, the part of an agent stack that decides how a task gets planned, retried and split up, to OpenAI’s own implementation. For a team whose product is genuinely the tools, data and workflow built on top, that is a reasonable trade of a few percentage points of independence for a large amount of saved engineering time. For a team whose differentiation was the orchestration logic itself, or which wanted the option to swap in a different model provider later, it is a much bigger commitment than a normal API integration.
That tension showed up earlier this year in a smaller but related controversy. Developers using Codex noticed OpenAI quietly reduced the default context window configuration for GPT-5.6 from 372,000 tokens to 272,000, triggering context compaction sooner on long coding sessions. The change was reversible with a setting, but it was a reminder that when the harness lives on the vendor’s side, the vendor also controls the defaults that shape how an agent behaves day to day. Anyone building on the new Agents API is accepting the same arrangement at a larger scale.
Where this fits in the wider agent race
The Agents API arrives less than a week after OpenAI said its research organization had already reached an internal milestone it calls an automated research intern, running 3.1 agent workdays of effort for every human workday. The two announcements read like two ends of the same strategy: prove internally that agents running on this harness can do meaningful multi-day work, then open the same harness to every outside developer building something similar. The company’s broader model lineup has been moving the same direction, with GPT-6 Astra’s rollout prioritizing exactly the kind of long, tool-heavy sessions this harness is built to support.
It also puts pressure on the layer of independent tooling that has grown up around agent orchestration over the past two years, from open-source frameworks to commercial products built specifically to solve session state and retries for whichever model a team happens to be using. OpenAI is not the first lab to make this move. Anthropic has taken a more restrictive approach with third-party agents built on Claude, while startups like Cursor built entire products, including its own agentic coding tools, around solving orchestration problems a foundation lab’s own API might now absorb.
None of that means the Agents API will win every workload. It means the calculation for any team building an agent right now has changed. The question is no longer only which model performs best on a benchmark. It is increasingly whether it is worth building and maintaining the orchestration layer yourself at all, when the lab that trains the model is now willing to rent you its own.
