Claude Managed Agents vs OpenAI Agents API in 2026: Which Hosted Runtime Should You Build On?

By Camellia · Updated Nov 3, 2026

If you lead engineering or product, you've probably already priced out building your own agent loop: the retry logic, the sandbox, the context compaction, the session store, the tracing. Both Anthropic and OpenAI now sell that whole layer as a hosted service. Anthropic's version is Claude Managed Agents. OpenAI's version is the Agents API, which runs the Codex harness as a managed service. The pitch is nearly identical, and the structure underneath is not.

This is a runtime decision, not a model decision. We're not ranking the models that sit inside each one, because that comparison changes every few months and says little about what you'll live with operationally: who holds session state, where code executes, how the meter runs, what you can export, and what you give up on data retention. Those are the choices that are expensive to reverse, so that's what this article compares, using only what each vendor publishes in its own documentation.

TL;DR

Key Facts

• Claude Managed Agents is billed on two dimensions, tokens and session runtime, and the runtime rate is $0.08 USD per session-hour measured only while the session status is running.
• Claude Managed Agents is in beta and requires the managed-agents-2026-04-01 beta header on every request.
• Anthropic states that Managed Agents is not currently eligible for Zero Data Retention or HIPAA BAA coverage, because sessions are stateful and transcripts persist until you delete them.
• OpenAI states that the Agents API does not support Zero Data Retention, and that choosing a self-hosted sandbox does not change that.
• OpenAI prices web search at $10.00 per 1k calls plus search content tokens at model rates, the same headline figure Anthropic prints as $10 per 1,000 searches.
• OpenAI prices code containers per 20-minute session per container, from $0.03 for 1 GB to $1.92 for 64 GB.

What You're Actually Choosing Between

There are really three layers in play, and vendors blur them in their marketing. The first is the model API (Anthropic's Messages API, OpenAI's Responses API), where you write the loop yourself. The second is an SDK that gives you a loop to run in your own process. The third is a hosted runtime, where the vendor runs the loop, keeps the session, and gives the agent a place to execute code. This article compares the third layer on both sides.

Anthropic describes its two options plainly: the Messages API is for "custom agent loops and fine-grained control," while Managed Agents is "best for long-running tasks and asynchronous work," per its overview. OpenAI's agents guide lays out the same ladder with different names: the Responses API for building from scratch, the Agents SDK where code runs inside your application, and the Agents API where OpenAI manages the agent and saves its progress. OpenAI rates the integration effort as low for the Agents API, medium for the Agents SDK and high for the Responses API.

If your team is still deciding whether it needs a hosted runtime at all, the frameworks roundup covers the in-process options, and Best AI Agent Platforms in 2026 covers the wider field including no-code platforms. For the multi-agent angle specifically, see best multi-agent frameworks in 2026.

Decision by Business Goal

Before the feature detail, here's the decision through the lenses a CTO, a VP of Engineering and a CFO actually use.

How Each Runtime Is Built

Both services share a mental model: you define an agent once, point it at an environment, and start durable sessions that you talk to through events. The vocabulary differs, so a quick map helps.

Anthropic's flow is five steps: create an agent, create an environment, start a session, send events and stream responses over server-sent events, then steer or interrupt while it runs. Event history is persisted server-side and can be fetched in full. OpenAI's architecture splits into three components: the harness (which OpenAI runs and which executes the model-and-tool loop), the environment (where commands run and files live), and your application server (which submits tasks, receives events and handles function tools).

One structural difference matters for how you design around it. In Claude Managed Agents the agent definition is separate from the environment, so you can keep the same agent and swap a cloud sandbox for a self-hosted one. Anthropic says this directly: "The agent definition is the same whichever you choose." OpenAI's environment is optional by design. With the type set to none, the harness calls the model and remote MCP tools directly and your code runs the function tools, but the built-in Bash, apply-patch and workspace files are unavailable, per OpenAI's architecture page.

Where Your Code Actually Runs

This is the section your security team will read first. Both vendors offer a managed sandbox and a self-hosted option, but what "self-hosted" keeps on your side is narrower than the name suggests.

For Claude Managed Agents, a cloud environment gives each session "its own fresh Linux container on Anthropic-managed infrastructure, with common languages, databases, and utilities already installed," and you choose the network rules and extra packages. With a self-hosted sandbox, you run a worker on your own hosts that carries out the agent's bash and file tool calls and returns each result. Claude still runs on Anthropic's side and decides which tool to call next. Anthropic is explicit about what doesn't change: conversation history and tool results still go to the Managed Agents service in either mode, and the web search and web fetch tools run on Anthropic's side, not in your sandbox. See choosing an environment for the full comparison.

For the OpenAI Agents API, the environment type is one of three. With openai_hosted, OpenAI creates and manages the sandbox and you configure packages, files and network access. With self_hosted, your infrastructure runs the environment and your code starts it and connects an executor that runs the commands the harness requests. OpenAI's architecture page says that environment can be a remote sandbox, your laptop, a Docker container or an AWS Lambda function. With none, there's no sandbox at all.

That last row is worth a procurement conversation. Anthropic itemizes the features you lose by self-hosting. OpenAI's docs describe the mechanics but don't give a comparable loss list in the public docs, so ask for one before you commit.

Tools, MCP and Extension

An agent runtime is only as useful as the tools it can reach. Here the two vendors take similar but not identical routes.

Claude Managed Agents ships a built-in toolset, enabled by default when you include it: bash, read, write, edit, glob, grep, web_fetch and web_search, per its tools page. You can disable individual tools, or switch the default off and enable only what you need. Each tool takes a permission policy that controls whether calls run without confirmation, need confirmation, or are evaluated by the server. Custom tools work like client-executed tools in the Messages API: Claude emits a structured request, your code runs it and returns the result to the session. MCP servers are declared on the agent (up to 20 per agent) and authenticated at session creation through vaults, which keeps secrets out of reusable agent definitions. The MCP toolset defaults to the always_ask permission policy, so each tool call needs approval until you change it, per the MCP connector docs.

OpenAI's Agents API describes three tool forms: service-connected tools, application function handlers, and the optional sandbox. The overview page's examples show programmatic tool calling, MCP servers over HTTP transport, and web search, with subagents available behind a concurrency limit. The Responses API underneath lists tool types such as web_search, file_search and mcp, plus shell, computer use, image generation and skills, per its tools guide. Whether every Responses API tool is available inside an Agents API session isn't stated in the public docs, so confirm the exact tool list for your use case.

If human approval before consequential actions is a hard requirement, the approval model deserves a dedicated test. Our guide to human-in-the-loop AI agents covers the patterns that apply to either vendor.

Sessions, State and Long-Running Work

Both products exist because agent tasks outlive a single request. The question is what each one remembers and for how long.

Anthropic says Managed Agents is "stateful by design": sessions are long-running, resume cleanly after pauses, and store conversation history, sandbox state and outputs server-side. It also supports memory stores, which a cloud environment mounts at /mnt/memory/. Two features inside the beta, MCP tunnels and dreaming, are in a more limited research preview and need an access request.

OpenAI says the runtime saves session configuration, turns and items, and that sessions can be resumed where they left off. Progress arrives through streaming events or through webhooks that deliver state changes without an open stream. One operational warning from OpenAI is worth repeating to your engineers: if a function tool handler is unavailable, the agent can wait indefinitely for a result. That's a design choice, not a bug, but it means your handler's uptime becomes part of your agent's reliability.

Neither vendor prints a maximum session lifetime in the public docs. If your workload runs for many hours, ask each vendor for the hard limit in writing before you design around it.

Billing: Where the Two Models Really Diverge

This is the section where the two services stop looking alike, and it's the one your finance partner will care about.

Anthropic bills Managed Agents on two dimensions, per its pricing page. First, tokens: everything a session consumes is billed at the standard model rates, and prompt caching multipliers apply identically. Second, session runtime: $0.08 USD per session-hour, metered on running status duration, to the millisecond. Time the session spends idle (waiting for your next message or a tool confirmation), rescheduling or terminated doesn't count. That's a meaningful detail for agents that wait on humans. Runtime also replaces the code execution container-hour model, so you aren't billed for container hours on top. Web search inside a session is still $10 per 1,000 searches. The Batch API discount does not apply either, because there is no batch mode. If you pin inference_geo to us, tokens are billed at 1.1x.

OpenAI's Agents API doesn't print a runtime SKU in the public docs. Its overview says model usage is billed at the selected model's API rates, built-in tools use their standard rates, and OpenAI-hosted sandboxes use standard container rates. The observability page adds that you should estimate cost across all calls a task needs, including subagent work and retries, and that the usage fields are best-effort and "not a final bill." The tool and container rates live on OpenAI's pricing page.

Notice the shape of the difference. Anthropic gives you one extra number to model (hours of running time). OpenAI gives you a sandbox sized by memory and sliced into 20-minute sessions, plus per-call tool rates. Neither is cheaper in the abstract. It depends on whether your agents spend their time thinking, waiting, or calling tools. For a fuller treatment of modeling these meters before you commit, see AI agent cost optimization.

A Worked Example for the Runtime Line

Take an illustrative fleet of 1,000 one-hour agent runs a month where the agent spends the whole hour in running status.

The point of the exercise is the order of magnitude. At these rates the sandbox or runtime line is small next to what a busy agent spends on tokens, so don't pick a vendor on runtime cents. Pick on the model-and-token bill, on tool metering, and on what the runtime lets you control. The runtime line only becomes the story if your sessions run for many hours, hold large containers, or sit idle on one side and not the other.

Observability and Debugging

Hosted runtimes hide the loop, so what you can see and export decides how fast you debug in production.

OpenAI documents tracing for the Agents API: you can inspect a completed turn and its agent activity in the Platform dashboard's Agents tab, and export session traces as OTLP JSON through the public API with a project API key. Saved session items show work already done, and a subagent_id on each turn identifies delegated work. One caveat from OpenAI's own page: the customer API doesn't report whether command output was truncated.

Anthropic's Managed Agents gives you the full event history over the API, plus typed events such as session.error carrying the affected MCP server name and a retry status when a server is unreachable or rejects a credential. Session creation doesn't validate MCP connectivity, so a broken credential shows up as an event during the run, not as a failure at launch. The public docs don't describe a dashboard trace view or a standard trace export format, so if you already run an observability stack, ask Anthropic how to ship events into it.

If you need evaluation, tracing and cost attribution that sit outside either vendor, the observability tools roundup compares the independent options.

Risk, Governance and Data Handling

This is where C-level and IT concerns concentrate, and the two vendors land in a surprisingly similar place.

Anthropic is direct: Managed Agents is not currently eligible for Zero Data Retention or HIPAA BAA coverage, because it's stateful and transcripts persist until you delete them. That applies to all sub-features, including self-hosted sandboxes. You can delete sessions and any files you uploaded at any time through the API. The service is also offered on Claude Platform on AWS and Claude Models on Google Cloud (Anthropic managed), both in beta, with some feature differences. On AWS, for example, memory stores don't carry over to a self-hosted sandbox and MCP tunnels aren't available.

OpenAI is equally direct: the Agents API does not support ZDR, and choosing a self-hosted sandbox does not make it ZDR-eligible. OpenAI also states that data residency is currently available only in the United States. The public docs don't say whether HIPAA BAA coverage applies, so treat that as unconfirmed and ask.

Both being in beta (or beta-shaped) is itself a risk to price in. Anthropic notes that behaviors "may be refined between releases." Build a thin adapter layer around session creation and event handling, so a change in the beta doesn't ripple through your product.

Implementation Effort and Time to Value

Both services are aimed at teams that want a working agent in days, not a quarter spent on infrastructure.

When Claude Managed Agents Is the Right Call

• You want a single, printed runtime rate (a session-hour) and you'd rather model hours of active work than container sizes.
• Your agents spend meaningful time idle, waiting on people, and you want that waiting time to cost nothing on the runtime line.
• You value a clean separation between the agent definition and where it runs, so you can start in Anthropic's cloud and move to a self-hosted sandbox later without redefining the agent.
• You need fine-grained approval controls, with per-tool permission policies and an MCP toolset that defaults to asking before it acts.
• You want the option to consume the same service through your existing AWS or Google Cloud relationship.
• Your agent is built around file work, shell commands and web research, which is exactly what the built-in toolset covers.

When OpenAI's Stack Is the Right Call

• Your engineers already build on the Responses API, and you want the Agents API's managed harness without changing vendors or billing relationships.
• You want billing to follow model tokens and each tool's own rate, with no separate runtime line, and you're comfortable estimating sandbox compute from container pricing.
• You need dashboard tracing and OTLP trace export from day one.
• You want the freedom to run with no sandbox at all, calling the model and remote MCP tools directly while your own code executes function tools.
• You want a ladder of options on one platform: the Responses API for control, the Agents SDK in your own process, and the Agents API when you'd rather not run the loop.
• You plan to use file search over your own documents, which OpenAI meters with a separate storage and per-call rate.

If Neither Fits

A hosted runtime is the right answer for a lot of teams, but not all. If your compliance team requires Zero Data Retention or a BAA, both of these are out for now by the vendors' own statements. If you want to avoid committing to a single model vendor, an in-process framework gives you more room to switch, and the developer frameworks roundup is the place to start. And if you're still sorting out which class of tool you need before you pick a vendor, choosing an AI agent platform walks through the no-code, managed and framework paths. For fully autonomous setups, best autonomous AI agents covers that class.

Decision Framework

What to Do Next

1. Pick one real task, not a demo. Choose a workflow that takes your team an hour or more today and has a checkable result, such as triaging a backlog of tickets or producing a research brief.
2. Run it on both runtimes for two weeks with the same person reviewing every output, and record tokens, tool calls and, for Claude, running hours.
3. Compare the bill to your estimate. Use the worked example above as a template, and note where your real usage broke the assumption (idle time, container size, search volume).
4. Ask each vendor three questions in writing: the maximum session length, the exact tool list available inside the hosted runtime, and the current release status and deprecation policy for the beta.
5. Put an adapter between your product and the runtime. Both services are young, and a thin wrapper around session creation and event handling is cheap insurance.