OpenAI’s Agents API Puts the Codex Harness in Developers’ Hands

OpenAI has released its Agents API to all developers in public beta, putting the managed harness behind Codex behind a new API for building long-running agents. Launched on September 10, the service handles the model-and-tool loop, session state, context management, recovery and subagent coordination that development teams previously had to assemble themselves.

The practical change is significant. Developers can now submit a task, select a model and tools, and choose where the agent will run code and manipulate files. OpenAI can provision the entire environment in one of its hosted Linux sandboxes, or developers can connect infrastructure they control through a self-hosted or partner environment.

That moves OpenAI beyond supplying models and agent-building libraries. It is now offering a managed agent control plane: OpenAI operates the reasoning loop and durable session while the customer defines the agent’s capabilities, data connections and execution boundary.

What OpenAI actually launched

The Agents API is built around four resources: an agent configuration, an optional execution environment, a durable session and the events generated as work progresses. A developer can create a session with an initial task and then stream its activity, receive webhooks, send follow-up instructions or steer an active turn.

OpenAI describes the service as the same harness and infrastructure used by Codex. In this context, the harness is the software surrounding the underlying model: it decides when to call the model again, how to present tools, how to preserve useful context, how to recover from interruptions and when to delegate work.

This distinction matters because the Agents API is not simply a renamed model endpoint or an update to the existing Agents SDK. The Responses API provides model and tool primitives, while the SDK helps developers implement agent workflows in their own applications. The new API operates the central loop as a hosted service and preserves work across multiple turns.

OpenAI says an agent can be created with one API call. That can dramatically shorten setup, but it should not be confused with deploying a complete production system in one call. Applications still need authentication, authorization, evaluations, error handling, spend controls, user approvals and policies governing what an agent may change.

Why the Codex harness is the important part

Models receive most of the attention in AI launches, but the surrounding harness can determine whether an agent completes a task reliably or stalls after a few steps. It also becomes increasingly difficult to maintain as jobs stretch from minutes into hours and involve large numbers of tools.

Durable sessions and automatic context management

The Agents API retains session state so developers can continue work without reconstructing an entire conversation for every request. When a session nears a model’s context limit, the harness can compact earlier work while attempting to preserve the information needed for later steps.

That opens the door to workflows extending across multiple context windows, such as investigating an incident, reviewing a repository, comparing a collection of documents or producing a report through several rounds of analysis.

The session can also continue even if a client disconnects. Developers can return to its saved state, retrieve events and resume interaction. This is a different operating model from keeping a single request open and hoping a long job finishes before a connection or worker fails.

Tool discovery and programmatic calls

The service supports custom functions, Model Context Protocol connections and built-in tools including web search. OpenAI’s tool-search system can load definitions when they become relevant instead of placing every available tool in the model’s context from the start.

Programmatic tool calling allows the agent to coordinate calls through generated code, including parallel requests and operations that filter or combine large results before returning the most useful material to the model. That can reduce context pressure when an agent is working across extensive tool catalogs or high-volume data sources.

Parallel subagents

Developers can also enable a coordinator agent to create subagents for independent pieces of work. Each subagent receives its own context, while the coordinator waits for results and assembles them into a final response.

The default maximum is six concurrent subagents when delegation is enabled, excluding the coordinator, although developers can set a different positive limit. Subagents operating with a sandbox share the session’s filesystem rather than receiving separate environments, so workflows that edit the same files still need careful coordination.

Parallelism may improve completion time for separable tasks, but it can also multiply model calls. OpenAI’s documentation tells developers to account for coordinator work, subagent calls, retries, tools and sandbox compute when estimating the true cost of a task.

Developers get three choices for agent compute

The managed harness does not require every workload to run inside OpenAI’s cloud. The execution environment is a separate architectural choice.

OpenAI-hosted sandboxes provide a Linux workspace with Python, Node.js and command-line tools. Developers can preload files, install packages, run setup commands and publish completed files from a designated output directory as downloadable artifacts.

Files persist between turns while the sandbox remains available. If activity and keep-alives stop for one hour, OpenAI may delete the sandbox, and that timeout cannot currently be changed. Published output artifacts can remain downloadable after the underlying sandbox expires.

For self-hosted execution, the developer runs OpenAI’s executor inside the chosen environment. It initiates an outbound WebSocket connection to the Agents API and receives commands from the OpenAI-operated harness. That keeps processes, files and network access within infrastructure the developer controls, but it is not full self-hosting: session orchestration and model decisions still occur on OpenAI’s service, and command results travel back to the harness.

OpenAI is also offering integrations with Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel. Those options could help teams choose different CPU, GPU, memory, storage, cold-start and VPC configurations without writing a separate adapter for every provider.

Security remains a deployment responsibility

Managed infrastructure removes operational work, but it does not remove the security consequences of allowing generated code to access files, services and credentials.

One setting deserves particular attention: outbound network access in an OpenAI-hosted sandbox is enabled by default unless a saved template imposes another policy. Developers can disable networking or restrict it to an allowlist of approved domains. Security-sensitive workloads should make that choice explicitly rather than relying on the default.

OpenAI warns that agent-generated code can access the files, credentials and network available inside its environment. Its guidance recommends isolating workloads, separating environments that must not share data, limiting outbound destinations and keeping the primary application API key outside the sandbox.

For self-hosted environments, OpenAI provides a restricted environment key that can connect the executor but cannot authorize other API operations. Long-lived third-party secrets should remain in an external secrets manager or credential broker where possible. Simply injecting a secret as an environment variable can still expose it to code the agent creates.

The API also includes vaults for authenticated remote MCP connections. A vault can supply a bearer token or OAuth grant without returning the underlying secret value to the agent, although teams still need to scope tool permissions and determine which actions require human approval.

Pricing is simple at the top level, less simple per task

OpenAI is not charging an additional fee for access to the Agents API during the beta. Customers pay for the model tokens, built-in tools and hosted compute their agents consume.

The per-task bill can still be difficult to predict. An agent may make several model calls, revisit a long history, launch subagents, retry failed operations and invoke paid external services. The API exposes recorded usage for root agents and subagents, but OpenAI describes those figures as best-effort rather than a final bill.

For production testing, teams will need to measure the cost of completing an entire task at the required quality and latency, not just the price of one model response. A cheaper model call is not necessarily a cheaper workflow if it causes more loops, retries or human review.

The public beta has important data and observability limits

The Agents API currently supports data residency only in the United States and is not eligible for Zero Data Retention. Choosing a self-hosted sandbox does not change that limitation because OpenAI still maintains the session and operates the harness.

Developers can delete sessions and published artifacts, but organizations with regional residency requirements or strict retention policies will need to evaluate whether the beta is suitable before moving sensitive workloads onto it.

OpenAI provides session events, saved history, dashboard logs and traces of model responses, tool calls and subagent activity. Tracing is enabled by default for new sessions. However, the public beta does not expose trace configuration, supported API retrieval for detailed traces or external trace exporters.

That is likely to matter to larger engineering teams that already send distributed traces into their own observability and incident-response systems. The dashboard is useful for debugging, but it is not yet a substitute for a fully integrated audit and telemetry pipeline.

OpenAI is entering an emerging managed-agent market

OpenAI is not the first major AI lab to package an agent runtime as a managed service. Anthropic already offers Claude Managed Agents with persistent sessions and both managed and self-hosted sandboxes.

The similarity suggests that agent infrastructure is becoming a distinct layer of the AI stack. Model providers increasingly want to operate not only inference, but also the state, tool coordination and recovery logic surrounding long-running work.

OpenAI’s pitch centers on its Codex harness, built-in subagent orchestration, its expanding tool system and the option to inspect the open-source foundation behind the managed service. For developers, the competitive question will be whether that package produces better reliability and lower total engineering cost than an in-house loop or another provider’s runtime.

Who should test the Agents API now

• Small teams building agent-heavy products: The API can remove substantial work around session persistence, streaming, recovery and sandbox orchestration.
• Existing Codex users: Teams can bring familiar harness behavior into custom applications rather than limiting it to OpenAI’s own interfaces.
• Developers running document, coding or research workflows: Persistent files, artifacts and parallel subagents are a natural fit for tasks with multiple independent steps.
• Platform teams comparing sandbox providers: The separation between harness and environment makes it possible to test different execution backends without replacing the entire agent layer.

Highly regulated organizations, teams requiring non-U.S. data residency and developers that need external trace export may be better served by controlled experiments until OpenAI expands the beta’s governance and observability options.

What to watch next

The most important milestones will be general availability, service-level commitments, additional data-residency regions, Zero Data Retention support and stronger trace-export capabilities. Developers should also watch how OpenAI versions the Codex harness and whether applications can pin behavior tightly enough to avoid unexpected changes during model upgrades.

Another key test will be economics. Hosted orchestration is attractive when it prevents teams from maintaining fragile loops and sandbox fleets, but long sessions and parallel agents can consume tokens quickly. Real production results will depend on whether the managed harness completes tasks with fewer failures and less human intervention.

For now, the Agents API changes the build-versus-buy calculation. Developers no longer have to create every part of a durable agent runtime themselves. They can rent OpenAI’s Codex harness, choose where the work executes and concentrate on the tools and workflows that distinguish their product. The beta does not eliminate the hard problems of permissions, evaluation and cost control, but it moves a large portion of the underlying plumbing into a single managed service.