OpenAI Agents API vs Claude Managed Agents

OpenAI released the Agents API in public beta on 10 September 2026, and the changelog sentence is the whole product: "Build agents with a managed Codex harness while OpenAI handles session orchestration, context compaction, and recovery." You bring the tools and pick where code runs. OpenAI runs the loop.

If that description sounds familiar, it should. Anthropic shipped the same shape five months earlier. Every request to Claude Managed Agents carries the beta header managed-agents-2026-04-01, which dates the launch in the header string itself, and Anthropic describes it as a "pre-built, configurable agent harness that runs in managed infrastructure."

Two frontier labs, two managed agent runtimes, and a set of design decisions that match each other almost line for line. This is a comparison of what each one actually gives you today, read off the two vendors' own documentation rather than their launch posts, plus the one limitation that both of them share and neither markets.

What OpenAI actually shipped

The Agents API is application access to the harness behind Codex. OpenAI's phrasing is that it manages "sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment." Inside a session the agent can "execute code, edit files, connect to MCP servers, and produce artifacts."

It is built on four objects. An Agent is the model, instructions, tools and MCP servers. An Environment is the optional sandbox or computer where files live and commands run. A Session is a durable agent instance working on tasks. Events and Items are the inputs and the saved outputs.

Concrete details worth having before you scope anything against it:

• The code samples run gpt-6-astra, and ship in JavaScript, Python, Go, Java, Ruby and curl.
• MCP connections use HTTP transport. OpenAI's own documentation MCP server appears in the examples.
• The documented examples cap parallel delegation at four, via max_concurrent_subagents: 4.
• Sandbox configuration uses a workspace_directory of /workspace and a capability_directories entry pointing at /workspace/capabilities/skills.
• Billing has three parts: "Model usage is billed at the selected model's API rates. OpenAI tools use their standard rates, and OpenAI-hosted sandboxes use standard container rates."

The session model is asynchronous and steerable rather than request and response. "A message sent to an idle session starts a new turn. A message sent during an active turn steers that turn." You track completion by watching for agent.session.turn.completed, agent.session.turn.failed or agent.session.turn.cancelled, over a stream or through webhooks. Cancelling an active turn keeps the session and the work already done.

Two labs, four primitives, three identical names

Put the two documentation sets side by side and the convergence is hard to unsee. OpenAI builds on Agent, Environment, Session, and Events and Items. Anthropic builds on Agent, Environment, Session, and Events. Four primitives each. Three of the four share a name exactly.

The definitions track too. OpenAI's Agent is "the model, instructions, tools, and MCP servers." Anthropic's is "the model, system prompt, tools, MCP servers, and skills." OpenAI's Environment is a sandbox you can host or hand to OpenAI. Anthropic's is "an Anthropic-managed cloud sandbox, or a self-hosted sandbox on your own infrastructure."

Even the defaults collide. Both runtimes put the agent's working directory at /workspace: OpenAI as an explicit workspace_directory setting, Anthropic as what its worker CLI reference calls "the system default working directory." Both surface skills as a directory the harness loads. Both stream events and offer webhooks. Both let you steer a running agent mid-turn instead of waiting for it to finish.

That is not imitation so much as two teams hitting the same constraints and arriving at the same answer. Long-running agents need durable session state, a filesystem, compaction when context fills, and a way to interrupt. Once you accept those four requirements, the object model mostly writes itself. The practical consequence for anyone building: porting between the two is a smaller job than it looks, and the choice is less lock-in than it feels.

OpenAI Agents API vs Claude Managed Agents

Everything in this table comes from the two vendors' documentation, not from launch coverage.

Two rows deserve a note rather than a shrug. Anthropic publishing hard rate limits and OpenAI not publishing them in the overview does not mean OpenAI has none. It means you cannot capacity-plan against OpenAI's numbers from the docs on day one of a public beta. Same for the billing row: OpenAI names three billable components, and Anthropic's overview and reference pages name none, so budget for a runtime charge on either platform and confirm it against your first invoice.

Which OpenAI runtime you actually want

OpenAI now offers three ways to build an agent, and it publishes a runtime comparison that is unusually blunt about the tradeoff.

The honest reading of that table is that the Agents API is the low-effort option and you pay for it in control. If your agent finishes in one turn, you do not need any of this. The Responses API is cheaper to reason about and cheaper to run. The Agents API earns its keep when a job runs for tens of minutes or hours, needs a filesystem that survives between turns, and would otherwise force you to build session storage, compaction and crash recovery yourself.

Neither one can give you Zero Data Retention

This is the row most launch coverage skipped, and it is the row most likely to end a procurement conversation.

OpenAI states that the Agents API "currently supports data residency only in the United States and does not support Zero Data Retention (ZDR)," and then closes the obvious escape hatch: "Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible." Anthropic reaches the same place and explains why. Managed Agents "is stateful by design: sessions are long-running, resume cleanly after pauses, and store conversation history, sandbox state, and outputs server-side. Because of this, Managed Agents is not currently eligible for Zero Data Retention (ZDR) or HIPAA Business Associate Agreement (BAA) coverage."

Read those together and the constraint is structural, not a policy either vendor is choosing to be difficult about. A managed harness has to persist the session to resume it. Persisting the session is what disqualifies it from ZDR. You cannot buy your way out with a self-hosted sandbox, because the sandbox is not where the session log lives.

Both vendors do give you deletion. OpenAI lets you delete sessions when they are no longer needed; Anthropic lets you delete sessions and separately delete uploaded files through the API at any time. Deletion after the fact is a real control, and it is a different control from never retaining. If your compliance posture requires the second one, the answer on both platforms today is to run the loop yourself, with the self-hosted route covering only the execution half of the problem. This is the same wall teams hit with self-hosted cloud coding agents: moving execution onto your infrastructure does not automatically move the orchestration record with it.

Where Anthropic is still ahead

Five months of head start shows up as features that are documented on one side and absent on the other. None of them are exotic; several are the difference between a demo and a production system.

Scheduled deployments. Anthropic runs agents on a cron schedule. If your use case is a nightly job rather than a user-triggered one, that is the entire integration on Anthropic's side and a piece of infrastructure you still own on OpenAI's.

Memory across sessions. Memory stores carry their own beta header, agent-memory-2026-07-22, mounted into the sandbox at a path. OpenAI's Agents API retains state within a session; it does not document a cross-session memory primitive.

A richer multiagent model. OpenAI delegates to subagents. Anthropic runs threads with a coordinator, and the event stream reflects it: agent.thread_message_sent and agent.thread_message_received let you watch agents talk to each other, and child-thread status transitions are cross-posted to the primary stream. If you have built anything like multi-machine coding agents, that observability is the part you miss when it is not there.

Permission policies and web allowlists. Anthropic's tool-use events carry an evaluated_permission field, and its web tools accept a domain allowlist or blocklist. A user.tool_confirmation event lets a human approve or deny an individual tool call. That is a human-in-the-loop story with named event types behind it.

Operational polish. Managed Agents runs on Claude Platform on AWS. Its self-hosted worker exposes real knobs, including a --max-idle that defaults to 60s and an --unrestricted-paths flag with a candid warning that the workdir check "is a guardrail for the file tools only, not a sandbox; it does not constrain bash."

Anthropic also publishes branding rules for partners, which tells you something about maturity on its own: you may ship "Claude Agent" or "Powered by Claude," and you may not call your product "Claude Code." Nobody writes that page before they have partners shipping.

What to do this week

If you are already on OpenAI models and building something long-running, the Agents API is worth a spike now, because the migration cost from a hand-rolled loop only grows. Start with one job that currently needs your own queue, your own session store and your own retry logic, and see how much of that you delete.

If you are on Claude, there is nothing here that should move you. The equivalent has been available since April and is ahead on scheduling, memory and permissions.

If you have not committed to either, the convergence is your friend. Four primitives, three shared names, and a shared working directory mean a thin adapter over both is realistic, and that is the position worth holding while both products are still in beta. Write your agent definition, your tool list and your session bookkeeping as your own types, and keep the vendor call at the edge.

And if you handle data that cannot be retained server-side, neither product is available to you yet. That is not a gap either vendor is racing to close, because closing it means giving up the durability that makes a managed harness worth renting.

Frequently asked questions

Is the OpenAI Agents API generally available?

No. OpenAI's changelog entry for 10 September 2026 says it was "released the Agents API in public beta." Public beta means anyone can call it, not that the interface is frozen. Claude Managed Agents is also in beta, gated behind the managed-agents-2026-04-01 header.

How much does the OpenAI Agents API cost?

There are three charges. Model usage bills at the selected model's normal API rates, OpenAI's built-in tools bill at their standard rates, and OpenAI-hosted sandboxes bill at standard container rates. If you run a self-hosted sandbox you avoid the third charge and pay for your own compute instead.

What is the difference between the Agents API and the Agents SDK?

The Agents API runs inside OpenAI's managed Codex harness and saves your session configuration, turns and items for you, at what OpenAI rates as low integration effort. The Agents SDK runs the loop inside your own application, at medium effort, and leaves deployment, storage and state to you. Use the API for long-running work, the SDK when you need control of the runtime.

Can I use my own sandbox with the OpenAI Agents API?

Yes. The Agents API supports a self_hosted environment type alongside OpenAI-hosted sandboxes, so tool execution can happen on infrastructure you control. Be clear about what that does and does not buy you: OpenAI states explicitly that choosing a self-hosted sandbox does not make the Agents API eligible for Zero Data Retention, because the session record still lives on OpenAI's side.

How many subagents can an OpenAI agent session run at once?

The documented examples set max_concurrent_subagents to 4. Treat that as the value OpenAI documents rather than a proven hard ceiling, and confirm against the API before you design a fan-out wider than four.

Does either platform support Zero Data Retention?

Neither does. OpenAI says the Agents API does not support ZDR and that a self-hosted sandbox does not change that. Anthropic says Managed Agents is not eligible for ZDR or a HIPAA BAA, because sessions store conversation history, sandbox state and outputs server-side in order to resume. Both let you delete sessions after the fact, which is a different guarantee.

Which one should I pick for a nightly automated job?

Claude Managed Agents, on the documentation as it stands. It ships scheduled deployments that run agents on a cron schedule. The OpenAI Agents API does not document a scheduler, so you would supply the trigger yourself from your own infrastructure.