OpenAI places the Codex engine behind a single API

The Agents API gives developers access to Codex’s agentic engine, featuring persistent sessions, tools, sub-agents, and managed or self-hosted execution environments.

An agent receives an assignment, opens files, runs code, queries external services, delegates several research tasks, and resumes its work after an interruption. Until now, assembling this kind of system required developers to build much of the infrastructure around the model themselves. OpenAI is now offering that infrastructure as a service.

The Agents API is entering public beta for all developers. It exposes the same agent harness used by Codex, through an interface that manages sessions, tools, context, compute environments, subagents, and recovery after a disruption.

This release is not a new model. Developers choose the model that will perform the task, with GPT-6 Astra appearing in OpenAI’s examples. The new component is the harness, the software layer that organizes work around the model and gives it the ability to act beyond producing a text response.

A single call can specify the model, instructions, available tools, vault IDs, number of subagents, and execution environment. It can also include the initial assignment. The API then creates a durable session and returns the events produced during its execution.

The distinction from a standard model request matters. A conventional response begins with an input and ends with an output. An agent session retains state, makes multiple model calls, waits for tool results, handles files, and can request additional information before continuing.

The client application can monitor progress through a stream or wait for webhook notifications. It can send a new instruction to a completed session or intervene during an active task to redirect the agent. Closing the event stream does not automatically cancel the work in progress.

This persistence is designed for assignments that take several hours or even several days. OpenAI cites incident analysis, document review, software repository investigation, and database queries. The agent can return to files created during earlier turns without requiring the application to reconstruct its entire history for every request.

The model’s context does not become unlimited. As a session approaches its maximum capacity, the Agents API automatically compacts its oldest exchanges. It retains a summary so the work can continue in a new context window.

This operation saves developers from writing their own summarization and transfer system across multiple windows. It also means part of the history is no longer shown to the model in its original form. For a long-running project, information that must remain exact is better stored in files, a database, or another structured state than entrusted solely to the conversation.

The agent can use functions defined by the application, MCP servers, and built-in tools such as web search. Skills and plugins can supplement its instructions with specialized procedures. The system therefore resembles a configurable workstation more than a simple catalog of tools called on demand.

A tool-search feature avoids loading every tool definition into each request. The model discovers the tools it needs as the task progresses. OpenAI aims to reduce the space occupied by technical descriptions and preserve the cache at the beginning of the conversation, although each search can add more calls and results for the model to process.

Programmatic tool calling gives the model a code environment for organizing multiple calls. It can run them simultaneously, chain them together, and filter their results before returning only the useful information to its context. The benefit becomes more noticeable when a task must query many services or process large volumes of data.

Subagents extend this approach across several separate work contexts. The primary agent divides the assignment, gives each part to a different instance, waits for the results, and then prepares a combined response. A research task could, for example, distribute several documents among different subagents instead of having one agent read them sequentially.

Each subagent maintains its own context. This separation limits interference between independent assignments and reduces the amount of information each one must carry. When an execution environment is used, however, they share the same file system. Paths and access rights must therefore be organized carefully if several tasks might modify the same resources.

The multi-agent documentation sets the default concurrency at six subagents, excluding the coordinator. Developers can choose a different limit when creating the session. Subagents inherit MCP connections, associated credentials, web search, and command-line tools, but they do not yet support application-defined functions.

Parallel execution does not always guarantee faster completion. An assignment must be divisible into genuinely independent parts that can be combined without creating more coordination work than useful work. Multiple subagents also generate additional model calls and may each reread part of the context. Lower latency may therefore come with higher consumption.

OpenAI includes a testimonial from Ciridae, which says the system improved its evaluation score from 0.71 to 0.85 and reduced latency by a factor of four compared with its previous setup, thanks to subagents. This result comes from a customer featured in the announcement. The evaluation protocol, tasks, model, and total cost are not disclosed, so the result cannot be generalized to other applications.

Execution can take place in a sandbox hosted by OpenAI. Each session then receives a separate Linux workspace with Python, Node.js, and command-line tools. Files, packages, environment variables, setup commands, skills, and plugins can be added when the session is created.

Files remain available between turns for as long as the environment exists. Anything saved in `/workspace/outputs` becomes an immutable artifact that can be downloaded after a turn ends. These copies remain available after the sandbox expires.

The compute environment itself is not permanent.