OpenAI Agents API public beta: what developers need to check

OpenAI Agents API public beta: the news, and the limit of the news

OpenAI announced the OpenAI Agents API public beta on 10 September 2026, describing it as an OpenAI-managed way to use the Codex harness for agent work that can continue over time. The launch is a developer-infrastructure announcement, not evidence that every agent task is now reliable or ready for unrestricted production use. OpenAI says the beta is available to all developers; the reviewed materials do not identify a separate launch in India, an India data region or a timetable for general availability.

The practical proposition is narrower and more useful. Rather than asking an application team to build the entire long-running-agent harness itself, the API packages a managed session layer around a model, instructions, tools and optionally an environment where code can run. Superpower Daily separately reported the 10 September public-beta launch and the same managed-harness boundary, but product behaviour and limits in this explainer are grounded primarily in OpenAI’s documentation.

The managed harness changes the plumbing, not the owner of the outcome

OpenAI’s terminology separates an agent from an environment and a session. An agent combines a model, instructions, tools and Model Context Protocol (MCP) servers. An environment is an optional sandbox or computer. A session is the durable instance through which the work proceeds. OpenAI says the service manages sessions, orchestration, context compaction and recovery; the application provides tools and chooses where execution happens.

That boundary is central. A managed harness can remove some application-level work in coordinating steps, storing working context and recovering a session. It does not decide whether an agent should have access to a customer system, whether a financial action needs human approval, which credentials are least privileged, or what output should count as correct. Those are developer and organisation decisions, even when the scheduling layer is managed.

In practical terms, OpenAI manages sessions, orchestration, compaction and recovery, and it provisions the Linux sandbox when the hosted option is selected. The developer still chooses the model, defines instructions and acceptable outputs, supplies tools and credentials, selects hosted or self-hosted execution, sets approval points, monitors use and decides what reaches production. Neither product boundary makes a deployment automatically secure or compliant.

Why durable sessions, compaction and recovery matter

A session gives an application a durable unit of work rather than a single isolated prompt-response exchange. According to OpenAI, an application can send more work to the same session, steer it while it runs and use streaming or webhooks to follow progress. The service retains session state, and sessions and published artifacts can be deleted when they are no longer needed. The reviewed documentation does not establish one universal deletion or retention duration for every session item, artifact and connected storage layer.

As a session approaches a model’s context limit, automatic context compaction summarizes earlier work so the agent can continue without the developer implementing that compaction loop. That is a context-management feature, not a guarantee that every prior detail remains available or that an agent has correctly understood a long task. Teams should test whether summaries preserve the facts their workflow needs, particularly for tasks with strict traceability or hand-off requirements.

Hosted versus self-hosted environments: where code runs

An OpenAI-hosted sandbox is a Linux workspace provisioned and connected by OpenAI. Its documentation lists Python, Node.js and command-line tools, alongside controls for packages, setup commands, files, environment variables, capabilities, plugins and outbound networking. Networking can be enabled, disabled or limited to named hosts. Each session has a separate workspace, and files persist between turns while that sandbox exists.

The hosted option also has lifecycle details that should not be collapsed into a simple claim of ephemeral execution. Files saved under /workspace/outputs are published as immutable artifacts after a turn and remain downloadable after sandbox expiry. A connected sandbox may be deleted after one hour without activity or keep-alives. Deleting or expiring an execution workspace is not documented as deletion of every related session record or published artifact.

A self-hosted environment can instead be a laptop, container or remote sandbox selected by the developer. OpenAI still operates the agent harness, while the developer runs codex exec-server in that environment. The executor performs commands, reads and writes files, and can use local MCP servers after it receives requests through an outbound WebSocket connection. OpenAI advises isolating self-hosted environments by user or workload because agents sharing one could access the same files, credentials and resources.

The useful framing is control plane versus execution plane. Self-hosting can offer a chosen image, a private-network path or compute controlled by the developer. It also puts dependency setup, executor lifecycle, isolation and execution-side security on that developer or provider. It does not turn the managed API into a wholly developer-hosted service.

Tools, MCP and subagents widen capability—and the permission surface

The Agents API supports custom functions, MCP servers, built-in capabilities such as web search, tool search and programmatic tool calling. MCP, short for Model Context Protocol, is a way to connect an agent with external tools or data services. These connections can make an agent useful beyond text generation, for example by retrieving information, operating an approved internal tool or working with files. OpenAI presents the tools as part of the agent configuration supplied by the application.

That design means a tool call is not merely a model feature; it is an access decision. An MCP server or custom function may expose data, invoke a business workflow or write to another system. Developers therefore still need to decide which operations are available, what credentials they use, whether scopes are limited, what must be logged, and where a human approval point belongs. A model’s ability to select a tool does not itself establish authority to take a consequential action.

There is no single Agents API price

OpenAI says there is no additional fee for the Agents API harness itself. That phrase is easily misread as a no-cost agent service. The same product materials say billing can arise from the chosen model’s token use, OpenAI tools at their standard rates and OpenAI-hosted sandbox or container use at standard container rates. A self-hosted environment or partner platform can add separate infrastructure charges that are not covered by OpenAI’s no-harness-fee statement.

The pricing page illustrates why teams should budget by component. At the time reviewed, web search was listed at $10 per 1,000 calls plus search-content tokens billed at model rates. Hosted Shell and Code Interpreter containers were listed at $0.03, $0.12, $0.48 and $1.92 per 20-minute session for 1 GB, 4 GB, 16 GB and 64 GB respectively; eligible container sessions are billed by the minute with a five-minute minimum. These are time-sensitive published prices, not a quotation for a particular deployment.

The prominent constraint: US-only residency and no ZDR

OpenAI’s current Agents API overview states that data residency for this API is supported only in the United States. It also states that the API does not support Zero Data Retention, commonly shortened to ZDR. This is a product-specific current constraint, not a statement about every OpenAI endpoint or every service a developer might connect to an agent.

The point is especially important because self-hosted execution can sound like a complete data-location solution. OpenAI explicitly says that selecting a self-hosted sandbox does not make Agents API use ZDR eligible. A developer may control the machine that runs the executor, but the managed harness and session layer remain part of the architecture. Self-hosting changes where execution happens; it does not change the stated Agents API residency or ZDR position.

OpenAI’s broader data-controls guide says abuse-monitoring logs are retained for up to 30 days by default, subject to stated exceptions, and identifies feature-specific application state separately. Its endpoint table lists /v1/agents as not ZDR eligible and application state as retained until deletion. These details should be read alongside the Agents API overview rather than used to assume one uniform lifecycle for inputs, session state, sandbox files, published artifacts, tool-provider records and application logs.

For an India-based team, the relevant question is architectural fit, not whether the public beta carries an India label. A team handling sensitive, customer, regulated or contractually restricted data should map every data path and seek its own internal privacy, security and legal review as appropriate. That is not legal advice and does not determine an outcome under any particular Indian law or contract. It is a prudent response to OpenAI’s documented US-only residency and non-ZDR limitation.

A practical way to evaluate the beta without mistaking it for a finished platform

Start with a bounded workflow and non-sensitive or synthetic data. Define the task, choose a model, supply only the tools it needs and decide what a correct result looks like before measuring the agent. Record not only completion rates, but also tool errors, inappropriate calls, human-review outcomes, retries, elapsed time and total component cost. The managed harness can reduce custom coordination work, but it does not substitute for a test plan.

Next, choose the environment for a specific reason. OpenAI-hosted sandboxes are the documented option for a provisioned Linux workspace with configurable outbound-network rules. Self-hosting may be appropriate when a workload needs a selected image, existing internal access or developer-controlled compute, provided the executor and workload isolation are operated carefully. Neither choice erases the documented data-residency and ZDR constraint.

What independent reporting confirms—and what it does not

Superpower Daily separately reported the public beta, managed-harness boundary and stated data-control limits. Wavect’s technical review treated the product as a managed harness rather than a replacement for business permissions or acceptance tests. These reports help confirm that the launch occurred, but they do not independently prove a deployment’s accuracy, latency, cost or security.

OpenAI’s launch post includes named customer accounts of results, including Ciridae’s reported evaluation and latency changes and SafetyKit’s reported cost reduction. Those outcomes are worth identifying as testimonials because they show the kinds of workflows OpenAI is highlighting. They should not be rephrased as a universal promise that subagents make every task faster, cheaper or more accurate.

What is still unknown or changing

The reviewed materials do not state a general-availability date, an India-specific availability programme, an India residency option, a universal session or artifact deletion service-level commitment, or a benchmark that applies across agent workloads. They also do not establish a single answer to whether an Agents API deployment is suitable for a particular regulated or contractual setting. These are gaps to verify with current documentation and an organisation’s own reviewers, not blanks to fill with launch-day assumptions.

Some implementation identifiers also signal the beta’s evolving state. OpenAI’s examples use a beta namespace and the OpenAI-Beta: agents=v1 header, while the self-hosted executor guide directs developers to @openai/codex@alpha. They are documented implementation details, not promises that every interface will remain unchanged through general availability.

The durable-session story is meaningful because it gives developers a managed building block for work that spans more than one turn. Its limits are equally meaningful: teams remain responsible for the model, tool permissions, execution choice, data map, quality checks and spend. The OpenAI Agents API public beta is therefore best evaluated as a managed infrastructure option with clear current constraints, rather than as a finished answer to deploying agents safely in every environment.