OpenAI Agents API — The Codex Harness You Rent but Never Own

OpenAI opened the Agents API in public beta on September 10, 2026 — no waitlist, no special tier, just an API key. It exposes the same managed harness that powers Codex and ChatGPT to any developer through a single API call: session orchestration, automatic context compaction, subagent coordination, crash recovery, sandboxed execution. The pitch is compelling. The compliance footnote buried in the docs is not: data residency is US-only, and Zero Data Retention is explicitly unsupported.

TL;DR

• What: OpenAI’s Agents API hit public beta, exposing the full Codex infrastructure harness to all developers
• Lock-in: You outsource session management, context compaction, and subagent orchestration — code you never write and cannot migrate
• Compliance blocker: US-only data residency, ZDR unsupported — unlike Chat Completions and Responses API where ZDR is available on request
• Action: Evaluate the harness for non-regulated workloads; do not commit regulated agent architectures until ZDR parity ships

OpenAI Agents API — What Happened

This is not the Agents SDK getting a point release. OpenAI is renting out the entire Codex infrastructure layer as a managed service. The announcement frames it plainly: the API brings the same harness and infrastructure that powers Codex to developers. That harness handles session orchestration across multi-turn interactions, compacts context automatically when conversations exceed model windows, coordinates subagents within a session, and recovers from crashes without you writing a single line of state management.

The sandbox story is broad from day one. OpenAI offers its own hosted sandboxes — the same infrastructure running Codex and ChatGPT — plus nine named partner environments: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. You can also bring your own sandbox and connect MCP servers directly. The pricing model sounds generous: no additional fees for the API itself. You pay model tokens, tool usage rates, and container compute for OpenAI-hosted sandboxes.

All of which makes this the easiest on-ramp to production-grade agent orchestration that has ever existed. And that is precisely the problem.

Why This Matters

The lock-in surface is the feature list

Every capability OpenAI manages for you is a capability you do not build, do not understand, and cannot replicate when you leave. Session orchestration? That is OpenAI’s state management, not yours. Context compaction? Their algorithm decides what your agent remembers and what it forgets across long-running tasks. Subagent coordination? Their scheduler, their recovery logic, their failure modes.

This is architecturally different from calling the Chat Completions API, where you own the conversation loop and can swap providers by changing a URL. The Agents API creates a dependency on runtime behavior — the kind of dependency that compounds every sprint your team builds on top of it. Migrating off means rebuilding infrastructure you never wrote, debugged, or even fully understood, because OpenAI abstracts it away behind “we handle orchestration.”

Compare this to the pattern we have seen from Anthropic’s Managed Agents and AWS AgentCore: all three vendors are racing to become the managed runtime for AI agents, and all three are betting that once you hand over the orchestration layer, switching costs make the relationship permanent. OpenAI’s version is the most aggressive because it bundles the most — session state, compaction, subagent scheduling, crash recovery — in a single opaque call.

The ZDR gap is a blocker, not a caveat

Here is where the “no additional fee” pitch falls apart for the enterprises OpenAI wants most. Zero Data Retention is available — subject to approval — for Chat Completions, the Responses API, image generation, embeddings, audio, moderations, and realtime endpoints. The Agents API is not on that list. It is explicitly excluded.

This is not a “coming soon” situation. The documentation states it plainly: data stays US-only, and ZDR is unsupported. For any team operating under HIPAA, SOC 2 Type II with data minimization requirements, GDPR with US adequacy concerns, or financial services regulations that mandate data retention controls — the Agents API is off the table. Not “needs workarounds.” Off the table.

Zero Data Retention is unsupported for the Agents API endpoint. If your compliance framework requires ZDR, you cannot use this API — even if you qualify for ZDR on Chat Completions and the Responses API. Check the OpenAI data controls documentation for current eligible endpoints.

The irony is thick. The enterprises with the most complex agent orchestration needs — financial services firms modeling risk scenarios, healthcare platforms coordinating multi-step patient workflows, legal tech companies processing privileged documents — are exactly the customers who cannot use the API that would save them the most engineering time. OpenAI built the most capable managed agent runtime and then excluded its highest-value customers from using it.

The pricing trap is time, not money

“No additional fees” is technically true and practically misleading. You pay tokens, tool calls, and sandbox compute. But the real cost is architectural commitment. After six months of building on the Agents API, your team has internalized its session model, designed around its compaction behavior, and structured subagent hierarchies to fit its coordination patterns. The switching cost is not the API bill — it is the engineering months required to rebuild everything the harness was doing silently.

Before committing agent architecture to this harness, benchmark total session costs against AWS AgentCore and Anthropic Managed Agents. More importantly, map which orchestration primitives each vendor exposes versus hides. The one that lets you inspect and override compaction and scheduling decisions is the one you can actually leave.

The partner sandbox ecosystem — nine providers at launch — is genuinely useful and partially mitigates compute lock-in. You can run execution on Cloudflare or Vercel or E2B and maintain portability at the sandbox layer. But the orchestration layer above those sandboxes? That is OpenAI’s, and they are not sharing the source.

The Take

I would call this the most elegant lock-in play of 2026. OpenAI solved the hardest problem in agent infrastructure — reliable multi-turn orchestration with crash recovery — and made it free to adopt. The engineering quality is real. The developer experience will be excellent. Teams that adopt it for non-regulated workloads will ship agent features faster than teams building their own orchestration, and many of those teams will never need to leave.

But the ZDR exclusion is not an oversight. It is either a technical limitation they have not solved yet or a deliberate segmentation choice — and neither explanation makes it safe to bet regulated workloads on “they will probably fix it.” The OpenAI Agents SDK lock-in dynamics we flagged earlier this year are now fully realized in API form: you get reliability in exchange for portability, and the compliance gap ensures that the customers who need the most help are the ones who cannot get it.

My recommendation: use the Agents API for internal tools, prototypes, and non-regulated customer-facing agents where US data residency is acceptable. Do not architect regulated workloads around it until ZDR reaches parity with Chat Completions. And regardless of regulatory status, keep a written record of every orchestration behavior you depend on — session lifecycle, compaction triggers, subagent failure modes — because the day you need to migrate, that documentation is all you will have.