OpenAI Agents API: The Codex Harness Is Now for Rent

The OpenAI Agents API is a public-beta API, released September 10, 2026, that runs the Codex agent harness for you. You bring the task, the model, the tools, and a place for code to run. OpenAI runs the loop, keeps the session, compacts the context, and handles recovery. There is no separate line item for the harness itself. You pay for tokens, tools, and sandbox time.

In June we wrote that agent reliability is a harness problem, not just a model problem. Now all three major labs will run a harness for you. Anthropic and Google already had managed agent runtimes, and this is OpenAI's entry.

This post is also a deliberate update to our May comparison of hosted agents across Anthropic, Google, and OpenAI. In May, OpenAI's column was Assistants plus the Responses API, a toolbox you assembled yourself. The Assistants API shut down on August 26. OpenAI's column is now a managed loop, and the question has moved from "which lab hosts the tools" to "what is still ours when the loop is rented."

Our short answer: renting the harness moves the work. It does not remove it.

What does the managed harness actually do for you?

OpenAI's Agents API overview lists what the harness handles. In plain English, each one maps to something a small team used to build by hand.

• Summarizing previous work to manage the context window. This is compaction. It used to be a custom summarizer plus a lot of guessing about what to keep.
• Breaking work into subtasks and delegating to subagents. This is fan-out orchestration, the part that gets fragile fastest when you write it yourself.
• Resuming a session where it left off. Durable state across turns and crashes, which used to mean your own session store and replay logic.
• Running commands and code in a sandbox. Isolated execution, either OpenAI-hosted or an environment you run.
• Connecting to external data through tools or MCP. Your systems, exposed as tools the agent can call.
• Applying skills and instructions, and steering the agent while it works. A way to shape behavior mid-run instead of restarting.

For long-running work, compaction and resume are the two that matter most. We covered the tradeoff in long-running agents in production. Every summary is a lossy write, and the thing a summary tends to drop is the record of what already failed. A managed compactor does not change that. It just means the summarizing happens in code you did not write and cannot read.

When you owned the harness, a bad compaction was a bug you could find. When you rent it, it is behavior you have to detect from the outside.

What does it cost?

Three lines, per OpenAI's docs:

• Model usage at the selected model's API rates
• OpenAI tools at their standard rates
• OpenAI-hosted sandboxes at container rates

The pricing page lists hosted containers at $0.03 for 1 GB, $0.12 for 4 GB, $0.48 for 16 GB, and $1.92 for 64 GB, per 20-minute session per container.

Look at the unit. The price is quoted per 20-minute container session, not per second of code execution. An agent that opens a large sandbox and then spends most of its time thinking may be paying for container time it barely uses. Before you pick a memory size, check how your agent's idle time maps onto that unit.

The honest read on the harness fee being zero: the cost did not disappear, it moved into the other lines. Compaction spends tokens. Subagents spend tokens. Sandboxes spend container time. A loop that runs longer than it needs to is now billed across all three.

It is also not the same shape as Anthropic's. Claude Managed Agents bills session runtime at $0.08 per session-hour, and per Anthropic's pricing docs that clock only runs while the session is active, not while it sits idle. Two different meters. Run your own workload through both before you assume one is cheaper.

Who cannot use it yet?

This is the section that decides it for a lot of buyers, and it is one paragraph in the docs.

OpenAI says the Agents API currently supports data residency only in the United States and does not support Zero Data Retention. It adds that choosing a self-hosted sandbox does not make the Agents API ZDR-eligible. Bringing your own sandbox moves where code runs. It does not move where the session lives.

It is also a public beta, so expect the surface to change.

For a dental office, a law firm, or anyone whose customer contract fixes where data sits and how long it is kept, that is a "not yet," or at minimum a "read the terms twice." It is the same reason our clinical notes work for Smile PreVue runs on Google Cloud Vertex AI under the Google Cloud BAA. Compliance was the decisive constraint there, not a benchmark.

It is not only OpenAI. Anthropic's data retention docs list Claude Managed Agents as not eligible for ZDR or HIPAA-ready access, because sessions are stateful and transcripts persist until you delete them, and that applies to self-hosted sandboxes too. Stateful, rented loops and zero retention do not mix well by design.

If you built on Assistants, you are choosing a new home this month anyway. OpenAI's own migration path points to the Responses and Conversations APIs, so the Agents API is an option, not the required destination.

How does it compare with Anthropic and Google?

Here is what we could verify in each vendor's current docs. Where we could not verify a cell, we say so instead of guessing.

We are not crowning a winner. We build on Anthropic Claude, Google Vertex AI Gemini, and OpenAI GPT depending on the problem. Pick on residency, retention, and where the sandbox runs, not on the benchmark table.

What stays your job when the loop is rented

Four things. None of them come with the harness.

The tool boundary. Which systems the agent can read, which it can write, and with whose credentials. A managed loop will happily call every tool you hand it. Deciding what goes in that list is the most important security decision in the whole build, and no vendor makes it for you.

The evals. A managed loop knows when a task finished. It does not know whether the answer was right. That gap is where plausible-and-wrong output lives. We wrote about eval-driven agent development for exactly this reason: observability tells you what happened, evals tell you whether it was correct.

The list of what is not true yet. An agent reading your codebase reconstructs what exists. It cannot infer what has not shipped, what was promised to a customer, or what is off limits. Keep that list in a file the agent reads, and keep it current. A compactor will not preserve a constraint it never saw.

The human gate where a wrong answer is expensive. Refunds, customer messages, anything touching a regulated record. This is the core of our agent orchestration methodology: deterministic control flow around the steps that must happen, model judgment only where judgment is actually needed, and a person in the loop where a mistake costs real money or trust.

When we would use it, and when we would not

Where we would try it first: a long-running back-office agent that needs a sandbox, for a team with no ops capacity to run its own harness, on data that can live in the United States without zero retention. Think document processing or internal reporting, where the sandbox and the resume behavior save real engineering time.

We would ship a thin slice: one tool, one eval set, one human checkpoint. Read the transcripts before you widen it.

Where we would not: protected health information or any regulated record, anything that needs sub-second interactive latency, or a product whose value depends on moving between model providers. A rented loop is a real form of lock-in. The session format, the compaction behavior, and the subagent model all belong to the vendor.

Figure out what the agent should touch. Build the evals and the gate. Ship the smallest version that proves it. The harness is the part you can now rent. The rest was always the work.

FAQ

Is the OpenAI Agents API free? There is no separate charge for the harness. You pay model rates, standard tool rates, and container rates for OpenAI-hosted sandboxes.

Can I run it on my own servers? You can run the sandbox in your own environment. OpenAI still runs the loop, and a self-hosted sandbox does not make the Agents API ZDR-eligible.

Can I use it with patient data? Not as documented today for most regulated uses: it is US data residency only and does not support Zero Data Retention. Check OpenAI's current docs and your own obligations before sending protected data.

How is this different from the Agents SDK? The Agents SDK is code you run in your own application. The Agents API is a harness OpenAI runs for you.

If you are deciding whether to rent a loop or build your own, tell us what you are trying to ship. If you would rather learn to work with these tools yourself, that is what /learn is for.