OpenAI launches Agents API: cloud agents, subagents, hosted sandboxes, and the Codex harness
Updated: Sep 15
OpenAI has launched the Agents API in public beta, giving developers access to the orchestration infrastructure used behind Codex and extending it beyond coding into broader long-running agent workflows.
The API is designed for tasks that may continue for minutes, hours, or even days, where a single model response is not enough and the system must preserve context, execute tools, manage files, recover from interruptions, coordinate parallel work, and keep operating across multiple stages.
Instead of requiring developers to build all of that infrastructure themselves, the Agents API exposes a managed Codex harness that combines model calls with context management, tool execution, sandbox access, subagent coordination, and long-running session control.
Agents can execute code, work with files, connect to MCP servers, call external tools, create artifacts, compress older context when needed, and divide a complex job among several parallel subagents with separate working contexts.
During the public beta, OpenAI is not charging a separate fee for the Agents API itself, which means developers pay primarily for the models and paid tools consumed during execution, while sandbox and infrastructure costs depend on the environment they choose to run.
··········
THE AGENTS API PUTS THE CODEX HARNESS BEHIND A SINGLE API.
Developers define the task, model, tools, and execution environment, while the harness manages the workflow required to keep the agent operating over time.
A normal model API call is usually built around a relatively simple interaction: the application sends a request, the model generates a response, and the application decides what happens next.
A production agent is considerably more complex because it must repeatedly decide which tools to use, preserve useful state, handle context-window limits, execute code safely, process tool results, recover from failed operations, and decide whether work should continue, stop, or be delegated elsewhere.
The Agents API moves much of that orchestration layer into infrastructure maintained by OpenAI, allowing developers to create a session, select a model such as GPT-6 Astra, attach tools and execution resources, and then let the harness manage the sequence of model calls and actions required to complete the task.
The model remains responsible for reasoning and generation, while the harness determines how that reasoning is connected to tools, files, memory, execution environments, and other agents.
This separation becomes especially important in long-running workflows because the quality of an agent depends not only on the underlying model, but also on how reliably the surrounding system can preserve context, manage failures, control tools, and keep the work moving without manual intervention.
........
What the Agents API manages compared with a basic model call.
Layer | Basic model API | Agents API |
|---|---|---|
Model inference | Yes | Yes |
Persistent agent session | Application-managed | Managed by agent infrastructure |
Context compaction | Application-managed | Automatic |
Tool discovery | Application-managed | Built into harness |
Parallel tool execution | Custom implementation | Supported |
MCP tools | Requires integration logic | Native support |
Subagents | Custom orchestration | Native multi-agent support |
Code execution environment | Separate infrastructure | OpenAI-hosted, self-hosted, or partner sandbox |
File workspace | Separate implementation | Available inside sandbox |
Long-running execution | Application-managed | Designed for extended sessions |
Harness maintenance | Developer | OpenAI |
Separate Agents API fee | — | No additional fee during public beta |
........
For teams that already maintain custom agent loops, the practical consequence is that part of the engineering effort moves away from application code and into a managed runtime whose main purpose is to keep a model productive across long and stateful workflows.
··········
DEVELOPERS CAN CHOOSE WHERE AGENT CODE AND FILES ACTUALLY RUN.
The orchestration layer is separated from the execution environment, so companies can use OpenAI-hosted sandboxes, external providers, or infrastructure they control themselves.
The Agents API does not require every workload to run inside an OpenAI-owned environment, which gives developers more flexibility over where code executes and where files, credentials, and network access are managed.
OpenAI supports its own hosted sandbox while also allowing developers to use self-managed infrastructure or supported sandbox providers, including Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel.
The choice of environment affects several operational areas at once because the sandbox determines where files are stored, which packages are available, how secrets are handled, what network resources the agent can access, and how CPU, memory, or GPU resources are provisioned.
For companies with stricter security or compliance requirements, external or VPC-based environments can provide more control over data movement and internal systems, although that control comes with additional infrastructure responsibility.
The OpenAI-hosted option is designed to reduce that operational burden by providing an execution environment connected directly to the same class of systems already used for Codex and ChatGPT workflows.
Inside the sandbox, an agent can inspect and modify files, install or use packages, execute code, preserve intermediate outputs, and return finished artifacts rather than limiting the result to text generated by the model.
From an architecture perspective, this separates the system into three distinct layers: model intelligence, agent orchestration, and execution infrastructure, which can be combined differently depending on performance, security, cost, and deployment requirements.
A fully hosted setup reduces the amount of infrastructure a developer must operate, while a self-managed or VPC-based environment gives the organization greater control over networking, secrets, compute allocation, and data residency.
··········
SUBAGENTS, CONTEXT COMPACTION, AND TOOL SEARCH TARGET LONG-RUNNING WORK.
[[ADPLUS_300x250_1]]
The Codex harness is designed to keep an agent effective even after the workflow grows beyond the size and complexity that can comfortably fit inside a single context window.
Long-running agents can accumulate context very quickly because each file inspection, tool response, intermediate result, planning step, and model output adds information that may need to be considered later in the workflow.
Without active context management, the session can become increasingly expensive and eventually exceed the model's context limits, forcing developers to build their own summarization or state-reduction systems.
The Agents API addresses this by automatically compacting earlier context as the session approaches its limit, retaining information considered useful while reducing the amount of historical material that must be passed forward.
Tool handling follows a similar approach because the API can use tool search to load relevant tool definitions only when they are needed instead of placing every possible tool into context from the beginning.
Programmatic tool calling can then execute operations in parallel, chain multiple calls, filter large results, and return only the information that the model needs for the next step.
The system supports MCP servers, custom functions, and OpenAI built-in tools such as web search, which makes it possible to combine internal company tools, external services, and OpenAI-provided capabilities inside the same agent workflow.
Multi-agent execution extends the architecture further by allowing a parent agent to divide a job into separate branches and send them to subagents that operate simultaneously with their own contexts.
The parent agent remains responsible for coordination and synthesis, but independent work can proceed in parallel rather than waiting for each branch to finish sequentially.
........
Data Studios calculation: effect of three-way subagent parallelism on an independent workflow.
Example workflow | Sequential execution | 3 parallel subagents |
|---|---|---|
Independent tasks | 3 | 3 |
Time per task | 10 min | 10 min |
Branch-processing time | 30 min | ~10 min |
Idealized reduction | — | ~66.7% |
Idealized speedup | 1× | Up to 3× |
........
This calculation assumes three tasks of equal duration with no dependencies between them, so it represents an upper-bound scheduling scenario rather than a performance guarantee.
In real deployments, coordination overhead, unequal task duration, rate limits, tool latency, shared resources, and model response time all reduce the maximum theoretical gain.
Even with those limitations, the calculation illustrates why native parallelism can materially change the latency profile of long-running agents, since three independent ten-minute investigations require roughly thirty minutes when executed sequentially but can approach ten minutes when they are processed at the same time.
OpenAI also cites an early customer that reported a 4× reduction in latency after moving subagent orchestration to the new API, although that figure reflects a specific implementation and should not be interpreted as a general benchmark for all workloads.
The main engineering benefit is that developers no longer need to construct the scheduling, context isolation, and coordination layer from scratch whenever they want several agents to work on different parts of the same task.
··········
THE COST OF AN AGENT DEPENDS ON THE WORK IT PERFORMS, NOT ON A SEPARATE ORCHESTRATION FEE.
OpenAI is not charging an additional Agents API fee during the public beta, but long-running workflows can still generate substantial model, tool, and infrastructure consumption.
The absence of a separate API surcharge means that the orchestration layer itself does not introduce another fixed billing category during the beta, while model tokens, paid tools, searches, and execution infrastructure remain the main cost drivers.
A session that runs for several hours can produce many model calls, process large amounts of context, launch subagents, invoke external services, perform web searches, and consume compute inside one or more sandboxes, so the total cost still depends heavily on how the workflow is designed.
Parallel subagents provide a good example because they can reduce elapsed time without necessarily reducing total inference consumption.
If three agents work simultaneously, the workflow may finish faster, but all three contexts still consume tokens and tools, which means latency can improve while total usage remains unchanged or even increases.
For that reason, the more useful production metric is the cost of completing the workflow successfully rather than the presence or absence of a separate Agents API line item.
A managed harness can still reduce total operating cost if it lowers failure rates, reduces engineering maintenance, improves tool reliability, or allows tasks to finish with fewer retries and less custom infrastructure.
OpenAI cites one early customer that reported a 60% reduction in cost per case after moving a case-review workflow to the Agents API, while another reported an 86% reduction in failed agent responses after separating its orchestration harness from the sandbox environment.
Those figures describe individual deployments and should not be generalized, but they show the type of operational gains OpenAI is targeting with the service.
The API is also built around the open-source Codex harness, which gives developers visibility into the orchestration foundation while still allowing them to use OpenAI's managed implementation for production workloads.
This combination lets teams inspect the underlying architecture, choose where execution takes place, connect their own MCP servers and tools, and avoid maintaining every part of the session-management stack themselves.
For long-running production agents, the model is only one component of the system, while reliability increasingly depends on how well context, execution, tools, parallel work, and failure recovery are coordinated around it.
··········
FOLLOW US FOR MORE.
·····
DATA STUDIOS
·····
datastudios.org
