OpenAI Opened Its Agents API. Here's What Actually Changed.
The public beta ships the exact harness that runs Codex and enterprise ChatGPT — sessions, sandboxes, and subagents included. Here's what a developer actually gets access to now.
In this article 7 sections
Quick answer: OpenAI's Agents API went to public beta on September 10 — not a new model, but the actual harness that already runs Codex and enterprise ChatGPT, now callable as a managed endpoint. Sessions, sandboxing, tool routing, and subagent delegation move from "thing you build yourself" to "thing you call." The plumbing is the product here.
Every few months something ships labeled "developer platform" that turns out to be a wrapper around an existing chat endpoint with a new logo. This isn't quite that. Teams that have written their own retry logic and a half-working sandbox for agent side projects will recognize when a vendor hands over the internal tool instead of a demo version of it. Protocol Wire covers AI releases for what changes in practice.
What Shipped on September 10
The headline claim, straight from OpenAI's own announcement, is that developers now get "direct access to the framework underlying Codex and enterprise ChatGPT" rather than a simplified public version of it. That's a real distinction. The older Assistants API gave you a chat loop with some tool-calling bolted on; this one gives you the same session state, context compaction, and multi-step recovery logic OpenAI's own product team relies on. That matters most for long, multi-step tasks, where state and recovery logic decide whether a run finishes.
The Four Concepts You Actually Need
Strip away the marketing copy and the API is organized around four pieces. The Agent bundles the model, system instructions, and available tools into one reusable definition. The Session holds state across turns, so a task picks back up where it left off instead of re-explaining itself every call. The Sandbox is the actual execution environment — the part everyone building an agent from scratch ends up half-reinventing badly. And Tools cover both custom functions and native MCP server support, so you're not writing a bespoke adapter for every integration. None of these are new ideas individually. What's new is getting all four handled server-side instead of stitched together from three different open-source libraries and a prayer.
Where Does the Code Actually Run?
You choose, and that choice is the most consequential design decision in the beta. According to an AICybr breakdown of the launch, OpenAI runs the harness while developers can pick an OpenAI-hosted sandbox, their own infrastructure, or an integrated sandbox provider. The hosted option can be configured with files, packages, skills, and plugins. Self-managed execution is pitched for teams that care about network topology, credentials, data locality, or specialized hardware.
The same write-up lists Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel as integrated sandbox providers. That split matters because the harness and the execution environment are separate concerns. A team with strict network rules can keep code execution inside its own boundary and still use OpenAI's session handling, context compaction, and recovery.
What Does It Cost, and What Are the Limits?
There is no separate Agents API fee. AICybr reports that usage is billed through the models and tools each session uses, plus any sandbox or external service charges. AI Weekly's coverage describes billing as standard API rates plus container rates, and says the service is US data-residency only and does not support Zero Data Retention. That second claim comes from a single secondary source here, so check OpenAI's documentation before relying on it for a regulated workload.
The AICybr write-up also cautions that this is a public beta whose infrastructure can change quickly, so regression tests should cover the full workflow. It adds that context compaction does not replace application state, which means durable outputs and checkpoints still need to be stored separately. And because long sessions can generate many model turns and tool calls, cost should be measured per complete session rather than per request.
On the multi-agent side, RuntimeWire's report says the public beta manages context and subagents for developers building long-running agents. AICybr adds that each subagent gets its own context while the primary agent coordinates the work and combines results, and that concurrency should match independent tasks and respect external rate limits.
Why the Timing Matters
This isn't shipping into a vacuum. McKinsey's 2026 State of AI survey found that 32% of organizations have already decided against buying a piece of off-the-shelf software because an agentic coding tool could build the equivalent internally — and that number climbs to 41% in the tech sector specifically. A managed agent harness lowers the cost of exactly that decision. It doesn't fix the part that actually stalls most agent projects, though, which is everything downstream of "the code runs": governance, access control, and who's accountable when the agent does something in production nobody reviewed. Protocol Wire covered exactly that gap in a piece on why most enterprise AI agent pilots never reach production, and a better SDK doesn't touch any of it.
What I'd Actually Try First
Don't point this at anything customer-facing on day one of a public beta — that's not skepticism, it's just how betas work. Start with an internal, bounded task with a clear success condition, the kind of thing you'd hand to a junior engineer with a checklist. If you're choosing which underlying model to run behind the new harness, the benchmark gaps covered in this month's model release roundup still apply — the API doesn't change what the model underneath is actually good at. And if your organization is the type that greenlights an agent pilot and then can't get it past legal, read the argument in this piece on enterprise buyers not being ready for agentic AI before you get too excited about the SDK. The harness was never the hard part.
Conclusion
The Agents API is a genuine step — OpenAI handing over its own internal tooling instead of a stripped-down public version is rarer than the framing suggests. But it's infrastructure, not a strategy. Treat it like plumbing: useful, mildly exciting if you've been fixing your own leaks for a year, and not a reason to skip the actual planning work before you put an agent anywhere near production.
