OpenAI's Agents API opens up the Codex harness
The beta keeps sessions, context compaction and recovery on OpenAI's side; your app supplies tools and the environment. US data residency only.
In short
The Agents API exposes the Codex harness as a hosted service, with OpenAI running the session loop, orchestration, context compaction and recovery while your application picks the model, the tools and where code actually executes.
At a glance
- Calls go to POST /v1/agents/sessions with the header OpenAI-Beta: agents=v1; in the SDK, client.beta.agents.sessions.create().
- Four objects: agent, environment, session, plus events and items.
- Tool types in the examples: programmatic_tool_calling, mcp, web_search; parallelism via max_concurrent_subagents: 4.
- The docs state data residency in the United States only, with no Zero Data Retention support.
- Billing: the model at its own API rates, OpenAI-hosted sandboxes at standard container rates.
The agent loop itself is now a product. OpenAI's Agents API hands you the Codex harness as a managed service: the platform keeps the session, the orchestration, the context compaction and the recovery logic, and your code supplies the model choice, the tools and the machine where commands run.
Most hand-rolled agents spend their code budget on plumbing rather than on product. Collecting tool results, trimming transcripts before the context window fills, picking a crashed run back up — that layer is what this API takes over.
The documented harness covers running commands and code in a sandbox, applying skills and instructions, reaching external data through tools or MCP, steering the agent mid-task, summarizing earlier work to manage the context window, splitting work across subagents, and resuming a session where it left off.
The flow described is short: create a session with an agent config, send a task, let the environment provision. You then stream output or register webhooks that fire when the agent finishes or needs input, and because session state is retained, later turns do not rebuild context from scratch.
Over REST it is POST /v1/agents/sessions with the OpenAI-Beta: agents=v1 header; the SDK equivalent is client.beta.agents.sessions.create().
The examples name gpt-6-astra as the model. Tool entries shown are programmatic_tool_calling, mcp and web_search, and fan-out is configured by a multi_agent block with enabled and max_concurrent_subagents, set to 4 in the example. Environments appear as self_hosted, with OpenAI-hosted sandboxes as the other route.
Model usage bills at the selected model's API rates, OpenAI's own tools at standard rates, and OpenAI-hosted sandboxes at standard container rates. No dollar figures appear on the overview page.
Two limits are spelled out plainly: data residency is currently United States only, and Zero Data Retention is not supported. For anyone whose compliance review starts with where bytes land, that decides the question before any cost modeling does.
There are no rate limits, no quotas, no general-availability date and no stated retention period for session state. This story rests on that single overview page, so anything beyond it would be guesswork rather than reporting.
FAQ
How does the Agents API differ from writing my own agent loop?
The loop is hosted. OpenAI handles session state, orchestration, context compaction and recovery, so your code defines the agent, its tools and the execution environment instead of the control flow.
Which endpoint and header does the Agents API use?
POST /v1/agents/sessions with the header OpenAI-Beta: agents=v1, or client.beta.agents.sessions.create() in the SDK. The documented example model is gpt-6-astra.
Does the Agents API support Zero Data Retention?
No. The documentation states it does not support Zero Data Retention and that data residency is currently limited to the United States, with no other regions listed.
