On September 10, 2026, OpenAI released the Agents API in public beta for all developers, designed for long-running AI agents. This is not simply another endpoint for querying a model. OpenAI has extracted the control layer it has been using for Codex—session management, context compaction, recovery from failures, and coordination across multiple agents—and turned it into an API that OpenAI itself operates. Developers hand over that control while still being able to choose the execution environment where their code and files live. To gauge how useful this actually is, you need to separate what OpenAI takes on from what remains on the user's side in terms of cost and data management.
OpenAI Takes Over Agent Operational Control
What the Agents API externalizes isn't the model itself, but rather the machinery that connects a model to a task and keeps it running. OpenAI describes this as the same Codex harness that powers Codex. The harness invokes the model, lets it select tools, maintains working state, and can resume even after a mid-task failure. Work that application developers previously had to piece together themselves is now handled by the service.
Official documentation distinguishes OpenAI's three development options by who manages them.
| Option | Primary Use Case | Who Primarily Manages the Loop and State |
|---|---|---|
| Agents API | Advancing long-running tasks while persisting progress | OpenAI runs the Codex harness |
| Agents SDK | Embedding reusable agents, tools, and handoffs into an app | The developer's application |
| Responses API | Calling model responses directly, or building an agent from scratch | The developer's application |
The deciding factor isn't which model you use—it's who manages the loop and the state. If you want your application to control fine-grained branching and responses, the SDK or Responses API fits better. If your work spans hours or days and you want to offload the burden of maintaining resumption and context management, the Agents API becomes a candidate. It doesn't replace the existing two approaches; rather, it's a difference in how much operational responsibility you delegate.
The Agents API has four core resources. An Agent is a configuration defining the model, instructions, tools, and MCP connections; an Environment is the place where files and commands are handled. A Session is the unit that carries work across turns, and Events and items record inputs, outputs, and progress. By separating configuration, execution location, continuation state, and logging into distinct resources, mid-task instructions, webhooks, and resumption can all be handled on the same operational surface.
A Design That Decouples the Harness from the Execution Environment
Even though OpenAI runs the harness, that doesn't mean generated code always executes on OpenAI's own computers. The official architecture separates the controlling harness, the execution environment that handles code and files, and the application server that submits tasks and receives events. The execution environment can be set to none if unnecessary, or you can choose OpenAI-hosted infrastructure, your own infrastructure, or a partner provider's environment.
Choosing the OpenAI-hosted sandbox gives you a Linux environment equipped with Python, Node.js, and CLI tools. The working directory is /workspace, where you can configure packages, initialization commands, input files, environment variables, skills, and plugins. Each session has its own independent workspace, and files persist across turns for as long as the sandbox exists. Artifacts placed in /workspace/outputs are published as immutable outputs when a turn completes, and remain retrievable even after the sandbox expires.
An official tutorial published by Cloudflare demonstrates this separation concretely. A Cloudflare Worker receives signed OpenAI webhooks and connects to a Container managed per-session via a Durable Object. Inside the Container, codex exec-server and the generated code run, while the workspace stays on the Cloudflare account side. In this setup, OpenAI controls how the work proceeds, while Cloudflare holds the location where the code actually executes.
This separation means organizations don't need to maintain the harness from scratch, and can place file and code storage wherever their requirements dictate. However, placing the workspace on your own infrastructure or with a partner is a separate matter from where the session state held by the Agents API is stored. Choosing an execution environment alone doesn't satisfy data residency or storage-prohibition requirements.
Context Management and Parallel Execution That Support Long-Running Tasks
For long-running tasks, what determines the outcome isn't the model's one-shot performance but whether progress can continue without losing intermediate results. The Agents API holds sessions as a persistent resource, allowing work to continue even if a streaming connection drops. Closing an event stream is not a cancellation. An application can return to the same session later, read its progress, and send additional instructions.
As the context limit approaches, context compaction summarizes past work and carries it forward into the next context window. Tool search, meanwhile, doesn't load the definitions of every registered tool each time—it retrieves only the ones needed. With programmatic tool calling, multiple calls can be parallelized or chained in code, with results narrowed down before the relevant portions are returned to the model. This is a design that suppresses context bloat—which tends to grow with longer sessions—from three directions: history, tool definitions, and tool outputs.
When multi-agent mode is enabled, the primary agent can split work among sub-agents that hold independent context. The default concurrency limit is six, excluding the primary agent. Creating sub-agents doesn't spin up new execution environments—everyone shares the same file system. While this makes it easier to parallelize research and inspection tasks, dividing the work and preventing conflicts over shared files remains the user's design responsibility.
Progress can be tracked through session logs and events, and you can also check token usage for both the primary agent and sub-agents. However, in the public beta, there is no dedicated API for retrieving traces, nor is there an external exporter. OpenAI-hosted sandboxes also don't persist indefinitely—they can be deleted if activity and keep-alive signals stop for one hour. This one-hour figure is fixed, but it does not represent the maximum lifespan of the session itself.
There's no guarantee that automatic compaction always preserves critical information, nor that sub-agents will always improve speed or quality. Therefore, what needs to be measured in long-running operations extends beyond task success or failure, to include instruction retention across compaction events, consistency after resumption, and the increased usage that comes from parallelization.
What "No Additional Fee" Doesn't Erase: Three Layers of Cost
In its announcement, OpenAI stated that there is no additional service fee for the Agents API itself. This means there's no markup for using the API—it does not mean the entire execution cost is limited to token fees alone. While there's no additional service fee for the Agents API, actual billing adds up separately across model tokens, OpenAI-provided tools, and container fees for OpenAI-hosted sandboxes.
| Billing Layer | Subject | Treatment in Official Documentation |
|---|---|---|
| Model | Input/output or cached tokens | API pricing for the selected model |
| OpenAI Tools | Web search, etc. | Standard pricing per tool |
| Hosted Sandbox | Containers for Shell, Code Interpreter | Standard container pricing based on capacity and runtime |
According to the official pricing page checked on September 11, 2026, hosted Shell and Code Interpreter container fees, per 20-minute session-container, are $0.03 for 1GB, $0.12 for 4GB, $0.48 for 16GB, and $1.92 for 64GB. Applicable sessions are billed by the minute, with a note indicating a 5-minute minimum. Web search costs $10 per 1,000 queries, with model fees added on top for the tokens involved in the search content.
In other words, total cost varies depending on the model chosen, the tools invoked, container capacity, and runtime. Even if long sessions or sub-agents raise the success rate, the bill can rise as processing volume increases. Conversely, if narrowing down tool results or dividing labor appropriately reduces retries, total cost could drop. What should be compared isn't the per-token unit price, but the combined total of success rate, time to task completion, and model/tool/environment costs. When running in your own infrastructure or a partner's, separate fees for that environment apply as well.
Data Retention and Security Responsibilities That Remain Even When Self-Hosting
Session state for the Agents API is retained on the API side even if you place the execution environment on your own infrastructure. According to OpenAI's overview documentation, as of September 11, 2026, data residency is limited to the United States only, and Zero Data Retention (ZDR) is not supported. Users can delete sessions and published artifacts, but organizations in regulated regions or with storage-prohibition requirements cannot assume that self-hosting the execution environment alone satisfies those requirements.
Another boundary concerns the code that agents generate and execute. That code can access files placed in the execution environment, credentials, and any permitted network. In the OpenAI-hosted environment, if you don't inherit a template's policy, outbound network access starts as enabled. You can also choose disabled to fully block it, or restricted to allow between 1 and 100 exact-match hostnames—meaning a production design needs to limit permitted destinations in advance.
Credentials also need to be separated by purpose. OpenAI advises keeping the application's API key outside the execution environment, and separating out a restricted key used for environment connections. Third-party service credentials should be injected via a broker whenever possible. In Cloudflare's example too, an execution key that allows only model reads and environment connections is kept separate from the application key that reads session state.
Moving the harness to a managed service reduces the burden of maintaining session control and recovery. But the judgment calls about which files to hand over, where to let it communicate, and what permissions to grant don't disappear. Only by auditing execution location, API-side retention, network access, and credentials separately can you actually translate the division of responsibility into real-world operations.
Operational Conditions Worth Verifying During the Public Beta
Public materials don't confirm the timeline for general availability, formal service-level guarantees, recovery guarantees in the event of a failure, or the maximum lifespan of a session. When data residency outside the US or zero data retention will be offered also remains unannounced. Adoption decisions therefore need to separate conditions to confirm with the provider from performance metrics you can measure yourself against your own workload.
What you can measure in a trial run includes: the completion rate for long-running sessions, the rate at which conditions were preserved after compaction, and the rate of successful resumption after disconnection or tool failures. For multi-agent setups, it's worth recording latency, total tokens, tool usage, and the number of shared-file conflicts compared against handling the same task with a single agent. While OpenAI's customer case studies mention improved evaluation scores and reduced latency, the comparison conditions and sample sizes aren't disclosed, so these figures cannot be applied directly to your own expectations.
On the other hand, formal SLAs, data residency regions, and deletion/audit conditions cannot be confirmed through experimentation. Organizations should first define their mandatory requirements, then identify which use cases fall outside what the public beta currently offers. For use cases that satisfy mandatory requirements—such as data residency or credential permission scope—measure the actual probability of task completion and the total cost incurred to reach that completion. Those figures are what will determine whether to adopt the operational control that has been refined through Codex.