OpenAI opens the Agents API, and the agent runtime becomes something you rent
OpenAI put its Codex harness behind a public-beta API on September 10, letting developers rent context management, tool routing, and subagent coordination instead of building them. The tradeoff is US-only, no-retention limits that rule out regulated workloads.
OpenAI opened its Agents API to every developer in public beta on September 10, and the interesting part is not another model. It is the runtime. The API exposes the managed Codex harness, the same orchestration layer that sits behind Codex and ChatGPT, behind a single call. A harness is the scaffolding around a model that decides what context to keep, which tools to load, and how to break a job into steps. For years that layer was something teams built themselves or stitched together from open-source frameworks. OpenAI now appears to be betting that, for many agent workloads, developers would rather rent it than run it.
What the managed harness actually does
The harness takes over four chores that anyone who has shipped an agent will recognize. As a session nears its context limit, it automatically compacts earlier turns rather than failing or forcing you to prune history by hand, and OpenAI says it does this in a way that cuts token usage while protecting the prompt cache. Tool definitions load only when the model needs them, so a large tool catalog does not sit in every prompt burning tokens, and programmatic tool calling lets an agent run calls in parallel and chain them. With multi-agent delegation enabled, a main agent can split a task into independent pieces, hand each to a subagent that keeps its own context, then combine the results.
For a working developer, the practical shift is that the operational parts of an agent, the parts that decide whether it stays cheap and stable over a long task, are now managed rather than hand-rolled. The throughline is that OpenAI is packaging the machinery of running an agent, not just the model that reasons inside it.
Where the agent runs is now a menu
Execution is decoupled from orchestration. You can run the agent in an
OpenAI-hosted sandbox, configurable with your files, packages, and skills. You
can self-host it, running codex exec-server over a WebSocket with restricted
keys so the code executes inside your own network. Or you can point it at a
partner sandbox, with nine providers named at launch: Blaxel, Cloudflare,
Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel.
That menu matters more than it looks. It means a team can keep code execution inside its own environment, close to private code and data, while still using OpenAI’s runtime to plan and coordinate the work. The reasoning question and the where-does-it-run question no longer have to share an answer.
The real decision is build versus rent
OpenAI now offers three ways to build agents, and they trade control for effort. The Agents API runs the harness on OpenAI’s side with saved session configuration and low integration effort. The Agents SDK runs the same patterns inside your own application, with more control and more code to own. The older Responses API leaves state and history management to you entirely. Cost on the Agents API is model tokens plus any paid tools and container time, with no separate API fee, so you are mostly paying for work you were going to pay for anyway.
The honest framing is a tradeoff, not a free win. The pitch is less orchestration code to write and operate. The cost is that the runtime, including how context gets compacted and how subagents are coordinated, lives inside a vendor you do not control and cannot fully inspect. The early gains OpenAI and its coverage cite, a reported latency drop at one customer and a large reduction in failed responses at another, are vendor-supplied and worth treating as directional rather than as benchmarks. For a team, the question is whether the agent runtime is somewhere you want to build differentiation, or plumbing you are happy to outsource to the model vendor.
The constraints that decide eligibility
Two limits set the boundary at launch, and neither is about capability. Data residency is US-only, and there is no zero-data-retention option, the arrangement where a provider agrees not to persist your inputs and outputs. That combination rules out a lot of regulated work, including health, finance, and teams with EU data-residency obligations, no matter how good the harness is. It is also public beta, so interfaces and limits can still move. The harness is compelling, but the gate on who can actually use it today is drawn by policy and geography rather than by the technology.
What to watch
The signals worth tracking over the next quarter are whether independent evaluations reproduce the latency and reliability gains outside OpenAI’s own customer list, whether the residency and retention limits lift enough to reach regulated teams, and whether renting the runtime creates the kind of lock-in the framework layer was meant to avoid, since an agent shaped around OpenAI’s compaction and delegation behavior is not trivially portable to another vendor. Stackmaven’s follow-up will revisit around December 10.