OpenAI’s Agents API Is a Managed Control Plane—Adopt It Only If Retention, Lock-In, and Cost Pass Your Pilot

Facts, pricing, and availability verified September 13, 2026.

OpenAI’s Agents API is not merely a more convenient model endpoint. It is a managed agent control plane: OpenAI operates the Codex harness that runs the model-and-tool loop, maintains durable sessions, compacts context, coordinates subagents, and supports recovery. Applications still choose tools and an execution environment, but they surrender more orchestration and state ownership than they would with the Agents SDK or Responses API. (OpenAI launch announcement) (Agents API overview)

OpenAI launched the Agents API in public beta on September 10, 2026, with access for all developers. Requests use the beta namespace and require the OpenAI-Beta: agents=v1 header; current OpenAI SDKs add it automatically, while cURL callers must supply it explicitly. OpenAI’s announcement says there is no additional Agents API platform fee during the beta, but model, tool, container, and third-party charges still apply. (Launch announcement) (Agents API quickstart)

The defensible adoption rule is therefore conditional: use the Agents API when durable orchestration solves a measured operational problem, the managed data boundary is acceptable, and a matched pilot demonstrates better economics and recovery. Otherwise, retain the loop in application-controlled infrastructure with the Agents SDK or build directly on the Responses API.

Key Takeaways

The product boundary is orchestration, not just sandbox location. A self-hosted sandbox moves command execution and working files into customer infrastructure, but OpenAI still operates the harness and managed session. (Architecture)

Data governance should gate the prototype. The current Agents API supports only US data residency, is not Zero Data Retention eligible, and retains /v1/agents application state until deletion. Self-hosting the environment does not change those controls. (Agents API overview) (Data controls)

“No additional fee” is not a total-cost claim. Root agents, subagents, paid tools, hosted containers, retries, and external MCP or sandbox services can all contribute to the bill. (Launch announcement) (API pricing)

Pilot observability is substantial but incomplete. The API exposes events, saved items, turns, tool history, subagent attribution, and best-effort token usage, while supported trace retrieval/export and command-truncation indicators are absent from the public beta API. (Observability and usage)

OpenAI Has Productized the Agent Control Plane

OpenAI documents three architectural components:

Harness: the OpenAI-hosted Codex instance that runs the model and tool loop and maintains the session.
Environment: the optional execution plane where commands run, code executes, and files change.
Application server: customer code that submits tasks, receives events, handles function tools, and manages the lifecycle of a customer-provided environment. (Architecture)

An agent can run without an environment, in an OpenAI-hosted sandbox, or with a self-hosted environment. In self-hosted mode, customer code starts an executor that performs commands requested by the OpenAI-hosted harness. The customer owns provisioning, reconnection, shutdown, and file preservation; OpenAI continues to own orchestration and the durable session. (Architecture) (Sandbox lifecycle)

The managed harness can summarize prior work to manage the context window, resume sessions, accept steering, access MCP servers, and delegate independent work to subagents with separate contexts. These are documented capabilities—not proof that a particular workload will become faster, cheaper, or more accurate. Compaction should also not be treated as an audit record: OpenAI describes it as contextual summarization for continued work, so applications requiring complete evidence should preserve their own event and tool records. (Agents API overview) (Launch announcement)

Diagram of the Responses API orchestrating model and shell execution in an agent loop — Figure 1: OpenAI agent loop diagram: the Responses API orchestrates model calls and shell execution inside a persistent computer environment. Image: OpenAI engineering article

Agents API vs. Agents SDK vs. Responses API

OpenAI’s runtime guidance distinguishes the products primarily by where orchestration runs and who manages state. The following table combines documented boundaries with clearly identified editorial fit guidance. (Agent runtime comparison) (Agents SDK overview)

Runtime	Documented ownership and execution boundary	State and observability	Governance and portability considerations	Best fit
Agents API	OpenAI runs the managed Codex harness. Execution can use no sandbox, an OpenAI-hosted sandbox, or a self-hosted environment. Application code handles function tools and manages customer-provided compute.	OpenAI saves session configuration, turns, and items. Events, saved history, turns, tool calls, subagent attribution, dashboard traces, and best-effort usage are available.	Current beta is US-residency-only and not ZDR eligible. Dependence is highest for orchestration behavior and managed session state, even when compute is self-hosted.	Durable, long-running work where managed compaction, coordination, and recovery solve a demonstrated operational burden.
Agents SDK	The SDK runner operates inside the application and handles the loop and handoffs. The application controls deployment, tools, storage, approvals, and runtime integration. Sandbox-agent features are separately documented as beta.	State can remain in application-owned storage, an SDK session, or selected OpenAI continuation services. Built-in tracing and application hooks are available.	Greater control over policy, storage, telemetry, and migration; OpenAI-specific models, hosted tools, or server-managed state can still create dependencies.	Custom workflows requiring application-owned approvals, storage, deployment, or runtime behavior.
Responses API	The application works directly with model responses and owns the integration, with optional hosted tools and continuation mechanisms.	State can use manual history, response chaining, or Conversations; observability depends largely on application instrumentation and selected platform features.	Greatest control over the loop, but OpenAI-specific model behavior and hosted tools remain migration dimensions. Endpoint and feature retention rules must be reviewed individually.	Bounded calls, deliberately minimal agent loops, or systems where explicit application control matters more than managed durability.

Tool callbacks and approval boundaries

Function tools and MCP connections do not share the same control path. For function tools, the application receives the call, executes it, and returns the result; if the handler is unavailable, the session can remain waiting. By contrast, Agents API MCP calls can originate from OpenAI’s service or from the session environment, and the application does not need to handle each call. (Architecture) (MCP connections)

Editorial analysis: approval policy must therefore be enforced at the actual credentialed boundary, not only through natural-language instructions. For irreversible actions, use narrowly scoped credentials, explicit tool allowlists, isolated environments, and—where appropriate—a trusted proxy or credential broker. OpenAI’s security guidance warns that agent-generated code can access the files, credentials, and network exposed to its environment. (Sandbox security)

Residency and Retention Come Before the Prototype

As of September 13, 2026, the Agents API supports data residency only in the United States, does not support Zero Data Retention, and retains managed session state so work can continue across turns. Choosing a self-hosted sandbox does not make the service ZDR eligible because the harness and session remain OpenAI-managed. (Agents API overview)

OpenAI’s endpoint table lists /v1/agents with up to 30 days of abuse-monitoring retention, application-state retention until deletion, and no ZDR eligibility. These are separate retention categories. Under the standard API policy, abuse-monitoring logs may contain prompts, responses, or derived metadata and are retained for up to 30 days unless longer retention is legally required or reasonably necessary to protect OpenAI’s services or third parties. (Data controls)

API data is not used to train or improve OpenAI models unless the customer explicitly opts in. That non-training default does not eliminate abuse-monitoring logs or state created by an API feature. (Data controls)

Deleting a session removes it from the public API, but OpenAI states that physical cleanup may continue asynchronously. For self-hosted environments, session deletion neither stops provider compute nor emits a deletion webhook; applications must stop the environment separately. (Manage sessions) (Sandbox lifecycle)

The practical gate is binary: if the workload requires non-US residency or ZDR, do not send that workload to the current Agents API beta. A private VPC or self-hosted filesystem cannot compensate for a control-plane retention mismatch.

The Invoice Has Multiple Layers

OpenAI says there is no separate Agents API fee during the public beta. Customers still pay for the selected model, OpenAI tools, hosted containers, and any third-party services used by the workflow. (Launch announcement) (Agents API overview)

Model usage across root agents and subagents. As one current reference point—not a required Agents API model—OpenAI listed GPT-6 Astra on the Standard tier with short-context prices of $10 input, $1 cached input, $12.50 cache writes, and $50 output per 1 million tokens. Long-context rates were $20, $2, $25, and $75, respectively. Reasoning tokens are billed as output tokens. Prices can change, so production estimates should reference the current pricing page rather than hard-code these figures. (API pricing) (Observability and usage)
Tools and retrieved content. The September 13 pricing page lists web search at $10 per 1,000 calls, plus search-content tokens billed at the selected model’s rates. File Search storage is listed at $0.10 per GB per day after the first free GB, with Responses API tool calls at $2.50 per 1,000 calls. Tool-generated or retrieved content can also increase model input. (API pricing)
Hosted containers. Listed 20-minute container prices are $0.03 for 1 GB, $0.12 for 4 GB, $0.48 for 16 GB, and $1.92 for 64 GB per container. The same pricing page notes that eligible sessions are billed by the minute with a five-minute minimum. “GB” on that page denotes a binary gigabyte, or 2^30 bytes. (API pricing)
External infrastructure. Partner sandboxes, remote MCP services, databases, observability platforms, and customer-operated compute have their own pricing and retention terms. OpenAI usage fields are not a substitute for those invoices. (Data controls) (Observability and usage)

The correct denominator is total provider and internal cost per policy-compliant successful task—not cost per API call or session. Compare alternatives with the same model snapshot, task corpus, tools, retry ceiling, approval policy, and success rubric.

Request lifecycle diagram showing skill discovery before agent execution — Figure 2: OpenAI request lifecycle diagram: skill discovery and loading happen before the agent starts the task. Image: OpenAI engineering article

Sandboxing Narrows Risk; It Does Not Transfer All Security Ownership

OpenAI-hosted sandboxes support outbound networking in enabled, disabled, or restricted mode. Restricted mode accepts 1–100 exact host names; wildcards, protocols, paths, and ports are not allowed, while subdomains and redirect destinations require separate entries. Hosted stdio MCP servers currently require enabled network access. (OpenAI-hosted sandboxes)

Connected hosted sandboxes receive keep-alives. If activity and keep-alives stop for one hour, the sandbox may be deleted; the timeout is not configurable. Closing an event stream does not cancel the task, so applications need an explicit cancellation path and must retrieve saved state after a disconnection. (OpenAI-hosted sandboxes) (Events and items)

For OpenAI-hosted environments, documented limits are:

50 files in a session-creation request
5 MiB per inline file before base64 encoding
10 MiB total inline data per creation request
50 MiB per file copied from the Files API
200 MiB per published artifact
500 MiB total output published together. (Files and artifacts)

Files under /workspace/outputs are published from OpenAI-hosted environments as immutable artifacts when a turn completes. Published artifacts survive environment expiration but should be downloaded before session deletion. Deleting an artifact does not delete the live environment file. Files from self-hosted environments are retrieved through customer or provider infrastructure and are not published through the Agents API Artifacts API. (Files and artifacts)

Observability Is Useful for a Pilot, Not Yet a Complete Audit Plane

The Agents API exposes real-time events, saved session items, turns, tool calls, and root-versus-subagent attribution. The Platform dashboard provides session logs and detailed traces. However, trace retrieval and external trace exporters are not part of the public beta API, and detailed dashboard trace endpoints are not a supported customer API accessible through an ordinary project key. (Observability and usage)

Usage reporting is explicitly best-effort: it can be null, can change as accounting arrives, and is not the final invoice. The usage object includes input, cached-input, output, and reasoning-token categories, but it does not expose a separate cache-write count where cache-write pricing applies. The customer API also does not indicate whether command output was truncated. (Observability and usage)

A production audit design should therefore retain application-visible events, tool inputs and outputs, approval decisions, artifact hashes or manifests, environment telemetry, and provider invoices. Streams do not replay missed events; OpenAI’s recovery guidance is to reconnect, retrieve saved items, restore local state by item ID, and then apply buffered updates. (Events and items)

Lock-In and Failure Modes: Editorial Analysis

Lock-in should be separated into four dimensions:

Model lock-in: model identifiers, pricing, and provider-specific model behavior.
Orchestration lock-in: compaction, recovery, subagent coordination, and run semantics.
Session-state lock-in: how saved turns and items can be reconstructed in another runtime.
Sandbox lock-in: files, lifecycle controls, snapshots, and provider interfaces.

The Agents API improves sandbox choice, but that primarily addresses the execution-plane dimension. OpenAI’s public Codex codebase provides visibility into the harness foundation, yet the service still owns the live managed session. Resource-retrieval APIs should not be assumed to constitute a vendor-neutral migration contract. (Launch announcement) (Manage sessions)

The documentation establishes several operational failure conditions worth testing: an unavailable function handler can leave a session waiting; a self-hosted mid-turn disconnect can fail a tool without automatically restarting the command; a closed stream can miss intermediate events; and deleting a session does not terminate self-hosted compute. (Architecture) (Sandbox lifecycle) (Events and items)

A reversible implementation should maintain an application-owned task record, canonical tool schemas, idempotency keys, artifact manifests, and enough event history to reconstruct accepted results independently of the managed session.

Decision Rule for Platform Teams

Adopt the Agents API only when all four gates pass:

The workload genuinely requires durable, multi-step execution rather than a bounded Responses call.
Session orchestration, recovery, compaction, or state operations are measured engineering bottlenecks.
US-only, non-ZDR managed session state is acceptable for the exact data classification.
A matched pilot improves cost per policy-compliant successful task, transient-failure recovery, or engineering burden without unacceptable quality or governance regressions.

Tech Trend Insight Editorial Verdict

The Agents API is a credible option for long-running or bursty workflows whose teams already pay a significant operational tax for resumable state, compaction, coordination, and recovery. It is not the default choice for ordinary model calls, workloads requiring ZDR or non-US residency, or systems whose approval and audit semantics must remain fully application-controlled.

Public-beta status, incomplete programmatic trace export, managed session retention, and the remaining customer responsibilities around tools and sandbox lifecycle justify a reversible pilot—not a broad platform mandate. OpenAI’s launch materials reviewed on September 13, 2026, describe work toward general availability but do not publish an Agents API-specific GA date.

Multi-turn Codex agent loop diagram showing state carried across turns — Figure 3: OpenAI multi-turn agent loop diagram: state and tool results are carried across turns instead of being treated as one-off requests. Image: OpenAI engineering article

Proposed Validation — Not Yet Executed

The following experiment is proposed. It has not been run, and no performance result or winner is claimed.

Compare four implementations:

Agents API with an OpenAI-hosted sandbox
Agents API with a self-hosted sandbox
Agents SDK on customer-managed compute
Responses API with a minimal application-owned loop

Use 60 representative tasks: 20 repository investigations, 20 document-analysis workflows producing artifacts, and 20 incident-triage simulations using read-only observability tools. Run each task three times on each implementation for 720 total runs: 60 tasks × 3 repetitions × 4 implementations.

Hold constant the model snapshot, reasoning setting, system instructions, tools and schemas, network policy, repository or data snapshot, warm-start condition, approval policy, and retry ceiling. Randomize run order.

Measure:

Policy-compliant completion and rubric-scored correctness
Unauthorized or unintended side effects
p50 and p95 completion time, in seconds
Root-agent and subagent model usage
Tool calls, retries, and container runtime
Provider cost per successful task
Operator intervention, in minutes
Engineering maintenance effort, in hours
Recovery from injected transient failures
Artifact completeness and integrity
Availability of required audit evidence

Inject controlled failures: a stream disconnect, temporary tool outage, malformed tool response, context-heavy task, and self-hosted executor interruption. Use read-only or synthetic systems, require approval before irreversible actions, and provide no production write credentials.

Proposed acceptance criteria are: zero unauthorized side effects; at least 95% policy-compliant completion for the selected production task class; no statistically material quality regression; recovery from at least 95% of injected transient failures; complete audit evidence for every accepted result; and either lower median cost per successful task or at least 30% fewer measured orchestration-maintenance hours. Report confidence intervals and do not declare a numeric winner unless matched conditions support it.

Conclusion

OpenAI’s Agents API can remove genuine orchestration work, but it does so by relocating control-plane responsibility and durable state. The architecture decision should begin with residency and retention, continue through approval and migration design, and end with matched task-level economics.

The service is most compelling where managed durability replaces a proven operational burden. Where that burden is absent—or where the data boundary is unacceptable—the Agents SDK or Responses API remains the more defensible choice.

FAQ

1. Does a self-hosted sandbox keep Agents API session data outside OpenAI-managed infrastructure?

No. It keeps command execution and environment files in customer-controlled compute, but OpenAI still runs the harness and retains the managed session. The current beta remains US-residency-only and is not ZDR eligible. (Architecture) (Agents API overview)

2. When should a team choose Agents API instead of Agents SDK or Responses API?

Choose the Agents API when work is genuinely durable, managed orchestration removes a measured burden, its retention boundary is permissible, and a matched pilot demonstrates better outcomes. Choose the Agents SDK when application-owned storage, approvals, or runtime behavior are priorities; choose Responses for bounded calls or a deliberately minimal custom loop. (Agent runtime comparison)

3. How should teams calculate the real cost of an Agents API workload?

Add every root-agent and subagent model call, including cached input, output, reasoning, retry, and applicable cache-write charges. Then add paid tools, retrieved-content tokens, container usage, external MCP or sandbox services, operator intervention, and engineering maintenance. Divide the total by policy-compliant successful tasks—not attempts or sessions. (API pricing) (Observability and usage)

Tech Trend Insight