OpenAI Agents API: Cloud-Hosted Agents Explained

• Launched 10 September 2026 in public beta, available to all API developers with no separate opt-in fee.
• Managed Codex harness: OpenAI runs orchestration, durable sessions, streaming events and context compaction; you supply the agent definition, tools and environment.
• Flexible execution: an OpenAI-hosted sandbox provisioned automatically, a self-hosted environment you control, or a named third-party sandbox provider (Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, Vercel).
• Tool support spans programmatic custom tool calls, built-in web search, and Model Context Protocol (MCP) servers over HTTP.
• Multi-agent delegation: a coordinator agent can hand independent subtasks to concurrent subagents, with a developer-set concurrency limit.
• No extra Agents API fee. Billing runs through standard model tokens, built-in tool usage and sandbox container rates.
• Reported early-user results include a 60% cost-per-case reduction, an 86% drop in failed agent responses, and a 4x latency improvement on subagent workflows — figures OpenAI supplied via named customer case studies, not independently reproduced here.
• "Cloud Agents" is not OpenAI's own product name for this launch; it is informal shorthand used in hands-on coverage, distinct from OpenAI's actually-named ChatGPT agent and workspace agents products.
• DevDay 2026 is confirmed for 29 September at Fort Mason, San Francisco, with unconfirmed reports (from mined app code, not an OpenAI statement) pointing to a further "Managed Agents" layer on top of this API.

OpenAI's own developer documentation describes the Agents API in blunt infrastructure terms: it gives applications "access to the Codex harness through an OpenAI-managed API." Codex, OpenAI's coding agent, was already built on a harness that handles the mechanics of long-running, tool-using work — deciding when to call a tool, tracking multi-step progress, recovering from a dropped connection. Until 10 September 2026, that harness was baked into Codex itself. The Agents API pulls it out and makes it available, as a general-purpose primitive, to any developer building agents for tasks that have nothing to do with writing code.

The pitch, as OpenAI frames it, is to "go from idea to a working agent faster" by removing the need to assemble runtime, session management and infrastructure separately. OpenAI's launch materials put it as a straightforward division of labour: the developer defines the task, model, tools and environment; OpenAI provisions and manages the orchestration, long-running sessions and context handling around it. Industry analysts covering the launch made the same point more pointedly. Amit Kumar Jena of Kanerika summarised the problem this way in comments on the release: "A long-running agent built by hand needs a job queue, a state database, a sandbox fleet, a compaction routine and a retry policy." The Agents API is OpenAI's offer to own all five of those pieces on your behalf.

Crucially, this is a developer product accessed via API call and SDKs (OpenAI's documentation shows examples in JavaScript, Python, Go, Java, Ruby and bash), not a consumer feature inside the ChatGPT app. It sits alongside, and is built from the same underlying harness as, OpenAI's separate ChatGPT-facing agent products, a distinction covered in more depth below.

The core unit of the Agents API is the session: a durable, stateful instance of an agent working on a task. OpenAI's documentation lays out a four-step lifecycle that maps directly onto the architecture diagram it publishes for the product.

Reading the diagram left to right: your application starts a session and displays whatever output comes back — that is the entire scope of what you have to build yourself. The session request crosses into the Agents API itself, described on the diagram as the "managed Codex harness," which is where OpenAI takes over: deciding what the agent does next, issuing tool calls, and streaming events and output back to your application. Those tool calls cross a second boundary into a sandbox, where actual commands run and files get read, written or executed, with results flowing back through the harness. OpenAI's diagram draws a dashed line around both the harness and the sandbox labelled "Provisioned and managed by OpenAI" — the explicit claim being that everything inside that boundary is infrastructure you no longer have to operate.

The documented lifecycle for using this is four steps: create a session with a configured agent and environment; submit a task to begin work; monitor progress via streaming events or webhooks; and continue or steer the session with new instructions once it is running. Sessions retain state across turns, which OpenAI positions as eliminating the need to rebuild context on every interaction — a session started in the morning can be checked on, redirected or extended in the afternoon without the calling application having to reconstruct what already happened. A screenshot of an early internal build of the agent-creation UI, published by TestingCatalog ahead of launch, shows the underlying REST call taking the shape POST https://api.openai.com/v1/agents with an OpenAI-Beta: agents=v1 header, alongside fields for the model, instructions, reasoning effort and text-output verbosity — consistent with a product still explicitly labelled beta.

Sandboxes and compute environments

Every session that needs to execute code or touch files runs inside a sandbox, and OpenAI gives developers three routes to one. The simplest is an OpenAI-hosted sandbox, which provisions automatically the moment a session is created — no infrastructure setup on the developer's side at all. The second is a fully self-hosted environment, where the developer controls CPU, GPU and memory allocation directly, useful for workloads with specific compute or data-residency requirements the managed option cannot meet. The third is a set of named, first-class third-party sandbox integrations: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle Cloud, Runloop and Vercel all appear in OpenAI's own list of supported providers. Inside any of these, the agent can execute commands, edit files, connect to MCP servers, and produce artifacts as output.

Tool use and MCP

The API supports several distinct ways for an agent to act on the world. Programmatic tool calling lets a developer register custom functions the agent can invoke directly. Web search is available as a built-in OpenAI tool, billed at the same standard rate as elsewhere in OpenAI's API. Most significantly for interoperability, the Agents API supports Model Context Protocol (MCP) servers over HTTP transport, meaning agents built on this API can plug into the same growing ecosystem of MCP tool servers that other agent frameworks, including Anthropic's, already use. OpenAI's documentation also describes a tool search capability with on-demand loading, so an agent with access to a large tool catalogue does not have to hold every tool definition in context at once.

Subagents and multi-agent delegation

A session can be configured to run as a coordinator that breaks a task into independent pieces and hands them to subagents running concurrently. OpenAI's own published quickstart example builds this concretely: an incident-investigation agent that delegates deployment analysis, error analysis and dependency analysis to three subagents running in parallel, then aggregates their findings into a shared output directory, all from a single session-creation call. Concurrency is developer-controlled through a setting such as max_concurrent_subagents inside a multi_agent configuration block; OpenAI's own documentation and its published examples use different default and example values in different places, so the concurrency ceiling for your workload is worth setting explicitly rather than assuming a specific default.

Context compaction and recovery

Long-running agent sessions eventually accumulate more conversational and tool-output history than fits in a model's context window. OpenAI's harness handles this automatically by "summarising previous work to manage its context window," rather than requiring the developer to build their own compaction logic or truncate history manually. The same managed layer is responsible for session recovery, meaning a session that hits a transient failure does not necessarily need to be restarted from scratch by the calling application.

OpenAI is explicit that there is no additional charge for using the Agents API itself. Developers pay for exactly two things: the underlying model and tool usage, at standard published API rates, and, if they choose an OpenAI-hosted sandbox, container compute at standard container pricing rather than model-token pricing. OpenAI's own announcement includes a direct caution alongside this: developers spinning up hosted sandboxes should "calculate the costs first," a reminder that a session running for hours inside a hosted container accrues compute charges independently of, and on top of, whatever tokens the model itself consumes.

This structure has a practical implication that is easy to miss: a workload that looks cheap on a per-token basis can still be expensive in aggregate once sandbox container time and subagent fan-out are added in, particularly for sessions designed to run unattended for long stretches. Choosing a self-hosted or third-party sandbox instead of OpenAI's own hosted option is one direct way to control that cost variable independently of model choice.

OpenAI's launch was accompanied by named customer case studies, reported in detail by AI-focused coverage of the release. Three figures stand out, and it is worth being precise about their source: these are OpenAI-supplied, customer-attributed numbers relayed through third-party reporting, not benchmarks AI Tools Review has independently reproduced.

Taken together, the three cases point at different parts of the same underlying pitch: cost efficiency from not maintaining custom infrastructure (SafetyKit), reliability from a harness that is properly separated from execution (Hypha), and raw performance from OpenAI's own subagent coordination outperforming a bespoke implementation (Ciridae). None of these figures come with published methodology, sample sizes or an independent audit, so they should be read as directional evidence of what the API can do for a well-matched workload, not as guaranteed outcomes for any given migration.

The Agents API is best understood as the latest step in Codex's steady expansion from a code-completion assistant into a general agentic platform. Codex began as a tool for writing and editing code inside a terminal or IDE session. Over 2026 it grew a cloud execution mode, longer-running sessions, and—as our coverage of Codex's August 2026 changelog detailed—a stream of incremental infrastructure changes that quietly pushed it further from "autocomplete for code" toward "a system that plans, acts, tests and delivers work with limited supervision." OpenAI's reported ambitions for Codex's Persistent Mode, which keeps an agent working until explicitly told to stop, sit on the same trajectory.

The Agents API is the point where that harness stops being exclusive to Codex. By exposing the orchestration engine as a general-purpose API, OpenAI is betting that the infrastructure it built to make Codex reliable at long-horizon coding tasks generalises to long-horizon agent tasks of any kind — customer support triage, incident investigation, research synthesis, compliance case review. The SafetyKit, Hypha and Ciridae case studies above are early evidence for that bet, in domains that have nothing to do with writing code.

It is worth being precise here, because the terminology around OpenAI's agent products has become genuinely confusing. "Cloud Agents" is not a name OpenAI itself uses for the Agents API, or for any single, specifically named product as of this launch. It appears in this context primarily as the framing used by hands-on reviewers — including the title of Bart Slodyczka's video embedded above, "I Tested OpenAI's New Cloud Agents... What You Need To Know" — to describe, in plain language, what the Agents API practically lets you build: agents that run continuously in OpenAI's cloud infrastructure rather than inside a local terminal or a single chat session.

OpenAI's own naming in this space is more fragmented, and worth laying out precisely to avoid conflating separate products:

• Agents API — the developer-facing product this article covers, accessed by API call and SDK, launched 10 September 2026.
• ChatGPT agent — a consumer-facing agentic ChatGPT mode that combines multi-step research with a remote browser environment and a limited-network terminal tool, aimed at end users inside the ChatGPT app rather than developers building their own products.
• Workspace agents in ChatGPT — Codex-powered agents that run inside ChatGPT for business teams, described by OpenAI as an evolution of GPTs, aimed at automating workflows like report preparation within an organisation's existing ChatGPT deployment.

All three share DNA with the same underlying Codex harness, which is precisely why the naming gets muddled in casual coverage. But they are distinct products with distinct audiences, and "Cloud Agents" describes none of them as an official title — it is a useful, accurate description of the Agents API's practical effect, not a product you can look up in OpenAI's own documentation.

OpenAI's DevDay 2026 is confirmed for Tuesday 29 September 2026 at Fort Mason in San Francisco, with in-person applications now closed but the keynote livestreamed free to anyone. Our earlier DevDay 2026 coverage, published when only the date and city had been announced, flagged that no product agenda had been confirmed at that point; the Agents API launch on 10 September is itself a concrete, pre-DevDay signal of the direction OpenAI is building in, even though OpenAI has not tied it to the conference explicitly.

Separately, reporting based on unreleased code found inside OpenAI's own platform points to a further capability, tentatively described as "Managed Agents," that reviewers expect to surface around DevDay. TestingCatalog, which mines shipped-but-hidden app code for upcoming features, published screenshots of an in-progress agent-creation interface that goes beyond the current Agents API's pure-code workflow with a graphical UI for defining an agent, choosing a runtime, and creating a session.

Per that reporting, the unreleased functionality would let users create separate agents and environments, manage them, and turn on specific skills and plugins, with support for self-hosted environments and a proposed "OpenAI Developers" plugin to create managed agents from the start — a shape that would sit as a graphical, more business- and consumer-friendly layer directly on top of the Agents API's raw infrastructure, echoing what Anthropic already ships as its own managed-agents offering. None of this has been confirmed by OpenAI, and mined pre-release code routinely differs from, or never ships as, a shipped feature. It belongs in this article as a clearly labelled expectation for DevDay 2026, not as a fact about the current Agents API beta.

• No Zero Data Retention (ZDR) support at launch, per analyst commentary on the release, which limits adoption in regulated sectors like healthcare and financial services until that changes.
• Vendor lock-in is a real, named concern. Pareekh Jain of Pareekh Consulting put it directly: "Lock-in is the biggest concern. If OpenAI provides the model, context management, tools, orchestration, and execution environment, moving becomes harder." A team whose entire agent loop lives inside OpenAI's managed harness has more to unwind than one using a portable, open-source framework.
• Sandbox costs are separate from model costs and can accumulate quickly on long-running or highly concurrent sessions; OpenAI's own guidance to "calculate the costs first" is a signal worth taking seriously.
• Still explicitly a public beta (the API's own request header identifies it as agents=v1), so interfaces, defaults and limits documented today may change before general availability.
• Case-study figures are vendor-supplied, not independently audited, and come from a small number of named early adopters rather than a broad sample.
• DevDay-adjacent "Managed Agents" coverage is speculative, based on mined app code rather than an OpenAI announcement, and should be treated as an expectation rather than a confirmed roadmap item.

Coverage of the launch places the Agents API in a competitive set that already includes Anthropic's own managed agent offering, AWS Bedrock AgentCore, Microsoft Foundry Agent Service, and open-source multi-agent frameworks like LangGraph. The shape of the trade-off is broadly consistent across that set: a managed, vendor-hosted harness reduces the amount of infrastructure a team has to build and operate, at the cost of tying the agent loop itself to one vendor's implementation and roadmap. Analysts covering the OpenAI launch framed this as suiting teams whose competitive edge is "the tools, data, and workflows rather than the agent loop itself" far better than it suits platforms that need to stay model- or vendor-agnostic by design.

Against building on the underlying open-source Codex harness directly, or assembling an agent loop from a framework like LangGraph, the Agents API trades flexibility for speed and reliability: OpenAI's pitch is that it "versions against model releases so improvements ship automatically rather than requiring manual rewiring," which is a real advantage for teams that would otherwise spend engineering time keeping a hand-rolled harness current with every new model release. Whether that advantage outweighs the lock-in risk is, per the analyst commentary above, a genuinely workload-dependent judgement rather than a settled answer either way.

Against OpenAI's own GPT-6 Astra, which represents the model-capability side of OpenAI's frontier push, the Agents API is a complementary rather than competing release: Astra (and other OpenAI models) are what an Agents API session actually calls to do its reasoning, while the Agents API itself is the infrastructure layer around that call. TestingCatalog's leaked screenshot of the unreleased agent-creation UI, for what it is worth, shows gpt-6-astra as the default model in its example configuration, suggesting the two releases are intended to be used together.

Worth adopting now if you are already building or planning a long-running, tool-using agent on top of OpenAI models and would otherwise be writing your own session management, compaction and retry logic from scratch. Teams whose value lies in domain-specific tools, data and workflows — rather than in a bespoke agent-orchestration engine — are the clearest fit, and the SafetyKit, Hypha and Ciridae case studies suggest real gains are achievable for workloads that match this profile.

Worth waiting on, or architecting carefully around, if you operate in a regulated industry that requires Zero Data Retention, if vendor portability is a hard requirement for your platform, or if your workload's cost profile is sensitive to sandbox container time rather than just token usage. Given the beta label, it is also sensible to build with the expectation that interfaces and default limits may shift before general availability.

The Agents API is a genuinely significant infrastructure move rather than a headline model release: OpenAI is betting that the harness it spent 2025 and 2026 hardening for Codex generalises well beyond coding, and is willing to sell that harness as a managed service with no markup beyond standard usage. The early case studies are encouraging but vendor-supplied, the lock-in trade-off is real and openly acknowledged by the analysts covering the launch, and "Cloud Agents" remains a description of what this product does rather than a name OpenAI has actually given it.

The more interesting test comes later this month. If the "Managed Agents" capability reportedly mined from OpenAI's own app code does surface at DevDay 2026 on 29 September, the Agents API launched here will look less like a standalone product and more like the first, developer-only layer of a much broader push to make cloud-hosted, always-on agents a default way of using OpenAI's models — for consumers and businesses, not just API developers. Until OpenAI confirms that itself, it stays a documented expectation rather than a fact.

OpenAI's own Agents API documentation is the primary source for the technical details in this article.