OpenAI Agents API: the Codex harness as a managed service, and when it locks you in

On September 10, OpenAI put the Agents API into public beta, and the honest description is their own: it exposes the Codex harness as a fully managed cloud-agent service. Long-running sessions, orchestration, context compaction, recovery, subagents, sandboxed execution, file editing, MCP connectors and artifact generation, all behind one API. You bring tools and a runtime; they run the loop. Self-hosted sandboxes are supported through workspace and capability directories, and there is no surcharge beyond tokens and tool usage.

I spent much of this year documenting what makes Codex robust from the outside, in Codex sandbox internals and Codex cloud delegation. The interesting part of the Agents API is that the pieces I was reverse-engineering are now the product.

What you are actually buying

Strip the feature list to the parts that are hard to build well and you get three things.

• Context compaction. Summarizing old turns so a session runs for hours without blowing the window, without losing the fact that matters on turn 200. Almost nobody builds this well.
• Recovery. A session that dies mid-task and resumes with its state intact.
• Sandboxed execution with file editing. An environment the agent can break without breaking you, with edits flowing back as artifacts.

Subagents and orchestration sit on top, and MCP connectors are the standard door for your own tools. The build-versus-buy question is really: do you want to own compaction and recovery, or only the tools and the domain logic.

The harness was never the product. The harness was the tax you paid to ship the product, and OpenAI just offered to collect it.

Build, buy, or keep your own stack

• Buy it if your team is small, your value is in the tools and the domain, and you are already on OpenAI models. Time-to-value drops because orchestration is somebody else's problem, and the pricing means the harness costs nothing extra to try.
• Build it if you need control over which model handles which step, if you run open-weight models for cost or residency reasons, or if session state is itself sensitive and must live in your infrastructure. A managed harness that only drives one lab's models is a routing decision made for you.
• Keep your LangGraph or MCP stack if you already have compaction and recovery working. The API does not make that code worse; it makes it a maintenance line you can now compare against a price of zero. Where that stack stands is in LangChain in 2026.

The self-hosted sandbox option muddies the middle case in a useful way. You keep execution on your machines, with your secrets, while the harness runs in OpenAI's cloud. That is a real answer to the residency objection, and it is also the shape of the lock-in.

Where it locks you in

• Session state. Compacted context and recovery snapshots live in their service, with no stated export format. The day you move a long-running agent elsewhere, its memory does not come with it.
• Sandbox conventions. Workspace and capability directories are OpenAI's contract. Tools written against them are portable in spirit, not in practice.
• Model coupling. The harness orchestrates OpenAI models. If your routing depends on sending cheap steps to a cheap model from another vendor, the harness is not where you do that.

The trap is adopting the harness for a free prototype and finding that the prototype became the product with its memory in someone else's store.

What I would do this week

Take one existing agent workflow with a real compaction problem, run it on the Agents API with self-hosted sandboxes, and measure three things: cost per completed task against your own stack, recovery behaviour when you kill it mid-run, and how much of your tool code had to change. If the third number is near zero, you have optionality. If not, you have a migration in both directions.

The honest limitation

This is a public beta announced two days ago, and everything above rests on OpenAI's description plus my reading of the earlier Codex internals. I have not run a production workload on it, the no-surcharge claim is the vendor's and may change at GA, and the portability concerns are inferences from the feature list rather than tested failures. Public beta means the contract can shift under you. Prototype accordingly.