OpenAI Opens the Agents API, Selling the Harness Behind Codex

OpenAI spent the past two years selling developers model calls, and more recently a framework for wiring agents together. On September 10, 2026, it started selling something different: the machinery in between. The company opened its Agents API in public beta, giving any developer access to the managed "Codex harness" (the agent loop and infrastructure behind Codex) through a single API call.

Related reading: ServiceNow's Stock Fell 27% as AI Fears Came for the Software Trade · Cloudflare Acquires Deno to Make Workers Self-Hosting.

The pitch is deliberately narrow and, for teams that have built long-running agents, immediately recognizable. You describe the task, the model, the tools and the execution environment. OpenAI runs everything else. That includes the parts most teams underestimate until they are months into a build: keeping a session alive, managing a context window that overflows, retrying failed steps, and coordinating work that has to survive longer than a single request-response cycle.

It is a productizing move as much as a technical one. OpenAI is no longer just the supplier of the intelligence an agent uses; it now wants to be the runtime the agent lives in.

The part OpenAI is actually selling

OpenAI already offers building blocks in this space. The Responses API lets developers combine models with built-in capabilities such as web search, file search and computer use, and the Agents SDK helps define and orchestrate agent workflows. What those tools leave to you is the infrastructure around the model, the runtime, session handling, retries, sandbox lifecycle and state.

The Agents API absorbs that layer into a managed service. As InfoWorld's Anirban Ghoshal reports, the service packages orchestration, context management and execution infrastructure into one API, with OpenAI hosting and maintaining the harness. The value proposition analysts keep returning to is a reduction in engineering complexity: no queue, no state database, no sandbox fleet, no compaction routine and no retry policy for a team to own and page for.

According to the API documentation, the managed harness supports:

• Running commands and code in a sandbox.
• Applying relevant skills and instructions.
• Connecting to external data through tools or MCP servers.
• Steering the agent while it works.
• Summarizing previous work to manage its context window.
• Breaking work into subtasks and delegating to subagents.
• Resuming a session where it left off.

Applications still supply the tools and choose where the work runs. Everything above that line is now OpenAI's problem.

The distinction between a framework and a managed service is the crux. The Agents SDK, available since March 2025, gives developers a set of libraries to run themselves. The Agents API is the hosted counterpart: a service where the vendor operates the loop. Frameworks trade flexibility for control; managed runtimes trade control for less code to own. What OpenAI is explicit about is that this is the same harness it uses internally (not a developer-only reimplementation), which is a meaningful claim about battle-testing, even if the beta constraints below mean it is not yet a like-for-like substitute for every workload.

Sessions that persist, context that compacts itself

The API is organized around four concepts, per the docs: the agent (model, instructions, tools and MCP servers), the environment (an optional sandbox for files, commands and skills), the session (a durable agent instance that responds to new input), and events and items (the inputs sent and outputs produced).

Durability is the headline. A session can run for minutes, hours or days, with OpenAI retaining state so developers can continue work across turns without rebuilding conversation context. Context compaction is automatic: as a session approaches its limit, earlier content is condensed without the developer writing 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.

Subagent coordination follows the same managed pattern. The root agent can spawn subagents, hand them bounded tasks, wait for results and synthesize a final answer, with Simon Carter's write-up noting a default max_concurrent_subagents of three as a recommended starting point. A session can also be resumed after a failure, deleted when no longer needed, or steered mid-turn while it works, the last of which matters for anything that touches production systems.

The quickstart makes the shape concrete: a coding assistant that writes tree.py, runs it and reports a directory tree, with OpenAI managing the agent, its conversation and the sandbox. The first working example is a single SDK call.

Operationally, applications follow a session by streaming output or subscribing to webhooks, so they learn when an agent finishes or needs input rather than polling blindly. The docs warn that a completed turn does not guarantee every tool succeeded (events ending in turn.failed, turn.cancelled or session.failed indicate failure or cancellation) and that a disconnected stream should be recovered by retrieving the session's saved items before retrying. That guidance is a reminder that managing a long-running agent is as much about failure handling as it is about model quality, which is precisely the work OpenAI is now offering to absorb.

Three places to run the work

Execution environment is one of the few decisions the API does leave to the developer, and there are three options:

1. An OpenAI-hosted sandbox, the same sandboxing infrastructure behind Codex, configurable with files, packages, skills and plugins, and billed at standard container rates.
2. A self-hosted sandbox, run codex exec-server inside your own environment. It registers with a restricted key and connects outbound over WebSocket, so no inbound port has to be opened.
3. Partner sandboxes, Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel are all supported, letting enterprises keep compute inside their own VPC and pick their own approach to files, secrets and configuration.

The harness itself is additionally open-source through the Codex repository, according to Carter's report, so teams can inspect how it works regardless of which runtime they choose.

The economics: no fee for the harness

Pricing is unusually simple, and it is the part most likely to drive adoption decisions. OpenAI charges no additional fee for the Agents API itself. Model usage is billed at the selected model's standard API rates, OpenAI tools use their standard rates, and OpenAI-hosted sandboxes are billed at standard container rates. Compute you run yourself, or hand to a partner provider, is billed by whoever operates it.

For teams weighing build-versus-buy, that removes a common source of hesitation: there is no separate harness tax that would otherwise have to be justified against the cost of engineering the runtime internally. The trade is that once the managed pieces are in place, replacing them is a heavier lift than swapping a model endpoint.

The limits that matter: US-only residency and no ZDR

The beta constraints are not footnotes. During the public beta, data residency is US-only, and the service does not support Zero Data Retention (ZDR), a limitation that applies even when a team supplies its own self-hosted sandbox. OpenAI has given no public timeline for expanding residency.

That combination is a genuine blocker for a large slice of the market. Healthcare, financial services, legal and European workloads frequently hinge on keeping data in a particular jurisdiction and on contractual guarantees that prompts and outputs are not retained. InfoWorld quotes analysts making exactly this point, with one noting the ZDR gap could limit adoption in regulated sectors and another observing that EU-based teams have a hard constraint to check before planning any migration. Startups, SaaS companies and enterprises already standardized on OpenAI are, by contrast, the most likely early adopters.

Competition and the lock-in question

The managed agent runtime is already a crowded category, which matters because it changes the framing from "can OpenAI do this?" to "why choose OpenAI's version?"

• Anthropic's Claude Managed Agents has been in public beta since April 2026.
• AWS's Amazon Bedrock AgentCore reached general availability for its managed harness in June 2026 and performs the same category of work (the loop, tool execution, context, state and recovery), while letting customers use any model and switch providers mid-session without losing context.
• Microsoft's Foundry Agent Service and LangGraph sit in the same neighborhood, per InfoWorld.

The competitive difference is portability. A managed harness that is friendly to multiple models lowers the cost of switching; one that is tied to a single vendor's models, context management, tools, orchestration and execution environment raises it. Analysts quoted by InfoWorld name lock-in as the biggest concern, and note that deeper dependency can weaken an enterprise's negotiating position on pricing and terms. Enterprises pursuing multi-model strategies may prefer an independent harness or a hybrid split.

Access, and a migration clock

Access is open to any developer. Creating an application API key requires api.agents.read and api.agents.write for session operations, plus api.responses.write for model inference. Requests carry the header OpenAI-Beta: agents=v1; the official SDKs add it automatically for those using a client library rather than cURL.

There is also a deadline attached to the broader shift. OpenAI is retiring Agent Builder and Evals on November 30, 2026, pointing code-based workflows toward the Agents SDK and the Agents API. Teams using either tool have a finite window to plan a migration, and the arrival of the managed API gives them a target to move toward, or a reason to reconsider the approach entirely.

What to watch

• Residency and retention. Whether OpenAI adds regional data residency or a ZDR pathway is the single constraint most likely to determine enterprise adoption. No timeline has been given, so watch for it in the API's data-controls documentation.
• Real-world cost at scale. "No harness fee" is clean on a pricing page. The meaningful number is total cost once long-running sessions, sandbox container hours and token consumption are added up, especially against self-hosted and partner runtimes.
• Model portability. Whether the Agents API supports models beyond OpenAI's (or makes mid-session provider switching possible the way Bedrock AgentCore advertises) will decide how much lock-in teams are actually accepting.
• The November 30 retirement. Watch how quickly Agent Builder and Evals users are funneled into the Agents SDK and Agents API, and whether the migration paths hold up.
• Competitive pressure. With Anthropic and AWS already shipping comparable managed runtimes, watch whether OpenAI competes on features, price or openness, and whether the "no extra fee" stance survives general availability.

Cover image: developers working on laptops during a coding event. Photo by Matthew (WMF), via Wikimedia Commons, CC BY-SA 3.0.