OpenAI Just Gave Away the Agent Loop. The Session Is the Part You Rent

A diagram splitting an agent stack into three bands — the loop, which OpenAI now runs for free and which is open source in the Codex repository; the session, which is durable, retained, US-only and not eligible for Zero Data Retention; and the tools, data and domain logic, which remain the founder's own — with the middle band marked as the layer that is rented rather than owned, and a note that durability and retention are the same property described by engineering and by legal — The loop is free and open. The state is neither. The switching cost moved from the code you wrote to the transcripts you did not.

For about eighteen months, the hardest engineering in an agent product was not the model call. It was everything around it. On 10 September 2026 OpenAI shipped all of that as a managed service, at no markup, and published a limitations page that most coverage skipped.

Both halves matter. The second one more.

1. What actually shipped

The Agents API entered public beta, exposing the same harness that runs Codex. The documentation reduces it to four primitives:

The Agents API, as documented

Four concepts, one of which is doing the real work

Agent — the model, instructions, tools, and MCP servers available to it.
Environment — an optional sandbox where the agent reads files and runs commands.
Session — "a durable instance of an agent that works on tasks."
Events and items — the inputs sent in and the output produced.

Behind those, OpenAI runs the loop: it "handles session orchestration, context compaction, and recovery." Sessions summarise earlier work as the window fills, split tasks across subagents under a concurrency ceiling (max_concurrent_subagents is 4 in the published example), load tool definitions on demand rather than paying for all of them every turn, and survive failures without you writing the retry.

Sandboxes come three ways: OpenAI-hosted, self-hosted via codex exec-server over an outbound WebSocket, or through a partner — Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel were named at launch.

And the pricing is the headline nobody quite believed: there is no fee for the Agents API itself. You pay model tokens at standard rates, standard rates for OpenAI-provided tools, and container time if you use a hosted sandbox. The orchestration is free.

2. The harness stopped being where the work is

I have written about the harness twice this summer, both times as a thing you choose between. Prime Agent and Muse Code made opposite bets on open versus hosted, and DeepSeek open-sourced one where even the loop is a plugin. The shared premise of that whole argument was that the harness is a real piece of engineering with real design choices, and that picking one is a strategic act.

That premise just weakened considerably — at least for the parts everybody was building identically.

Nobody was differentiating on their retry logic. They were just all writing it.

Go through the list of what the managed harness now does and ask, honestly, which of them your team was doing better than a competent default. Context compaction when the window fills. Parallel tool calls. A subagent that gets its own context and returns a result. Resuming after a crash without replaying from turn one. Loading tool schemas lazily so a hundred tools do not cost a hundred schemas per turn.

Those are the exact items on every agent team's internal infrastructure backlog, and they are not where anyone's product wins. If a competitor ships them for free and they work, keeping your own version is a decision you now have to justify rather than one that justifies itself.

The genuine efficiency argument

Lazy tool definitions and automatic compaction attack the residency problem directly — every file an agent reads stays resident and is re-billed every turn, and a managed compactor that runs correctly will beat a hand-rolled one that runs when someone remembers. This is a real saving, not a marketing one.

3. The paragraph to read before you take the deal

Here is the line, from OpenAI's own Agents API documentation:

From the Agents API limitations

The Agents API currently supports data residency only in the United States and does not support Zero Data Retention. Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible.

Read that last sentence twice, because it closes the escape hatch a founder would reach for first.

The intuition goes: fine, our code is sensitive, so we will run the sandbox in our own VPC. You can. The compute moves. The files stay on your infrastructure. And you are still not ZDR-eligible, because the sandbox was never the thing being retained.

4. Durability and retention are one property

This is the part I would want a founder to actually internalise, because it is not a policy gap that a later release fixes.

What makes a durable session valuable is that it remembers. You can hand a task back to it tomorrow and it knows what it read, what it tried, what failed and what it concluded, without you rebuilding any of it. OpenAI's docs put it plainly: the API "retains session state so you can continue work across turns without rebuilding the conversation context."

Now describe the same mechanism to a security reviewer. A third party holds a persistent, replayable record of everything your agent touched — file contents, tool outputs, intermediate reasoning, customer data that passed through — on infrastructure you do not control, in a jurisdiction you did not choose.

Durability is retention with the marketing on. They are one property, described by engineering and by legal.

There is no version of this where the session survives a restart and nothing is kept. Zero Data Retention and a durable session are mutually exclusive by construction, and the honest reading of that limitations page is not "not yet" but "not while the feature works this way."

That reframes the decision. This is not a checkbox that unblocks in Q1. It is a structural trade: you are exchanging the ability to promise a buyer that nothing is retained for the ability to stop maintaining an agent loop. For plenty of products that trade is obviously correct. For some it is disqualifying on day one, and the useful thing is knowing which you are before you build eight months on top of it.

5. What is portable and what is not

The open-source framing has confused people, so it is worth separating cleanly.

The harness logic

Portable

The Codex harness is open. You can read how compaction, tool dispatch and subagent coordination work, run it yourself, and fork it. This is genuinely more than most managed agent offerings give you, and it means the behaviour of your agent is inspectable rather than a black box. Credit where it is due.

The sandbox

Portable

Nine named providers plus your own codex exec-server means the execution environment is a real choice, with real CPU, GPU, memory and VPC options. If your concern is where code executes and where files live, that concern is addressable today.

The session state

Captive

The accumulated context of every long-running agent instance lives on OpenAI's infrastructure, in the US, retained. There is no export-and-resume-elsewhere story, because the compacted state is an artefact of their compactor. This is the lock-in, and it is the one nobody lists when they list lock-in.

The model coupling

Captive

The examples run gpt-6-astra. A harness that manages context, chooses when to compact and coordinates subagents is co-designed with the model it was tuned against. Even with open harness code, "swap in another provider" is a rewrite of the tuning, not a config change.

The switching cost moved. It used to be the orchestration code you wrote, which was annoying but yours. It is now the transcripts you did not write, which are not.

6. Taking the deal without taking the lock-in

If you want the free loop — and most teams should at least price it — the architecture that keeps your options open is the same one that makes your agent debuggable, which is a pleasant coincidence.

Make the session derived, not primary

One

Your own store holds the task, its inputs, the decisions made and the artefacts produced. The vendor session holds working context that accelerates the next turn. If a session vanished tonight, you should lose speed, not truth. Teams that skip this end up with their actual product history living in someone else's summarisation format.

Checkpoint at your boundaries, not theirs

Two

Every time the agent completes a meaningful unit, write the result to your system in a shape you defined. That is your audit trail, your resume point and your migration path in one. It is also what you hand an enterprise buyer who asks what the agent did, which a compacted vendor session cannot answer on your behalf.

Know what crosses the boundary

Three

Decide deliberately which data an agent session may ever see, and enforce it before the call rather than in a policy document. Redaction, scoped credentials and synthetic fixtures at the boundary are cheap now and enormously expensive to retrofit once the retained transcripts already contain the thing you wish they did not.

Do these and the Agents API becomes an accelerator you can leave. Skip them and it becomes the place your product's memory lives.

7. Reading the design-partner numbers

The launch carried customer results, and they are worth stating accurately and discounting appropriately: one design partner reported an evaluation score moving from 0.71 to 0.85 with a roughly 4x latency reduction, another a 60% cost reduction per case, a third 86% fewer failed responses.

These are real teams reporting real deltas. They are also vendor-selected, self-reported, un-audited, and measured against whatever those teams had before — which, for a company that agreed to be a launch partner for managed orchestration, was plausibly a hand-rolled loop that needed replacing.

What the numbers do and do not establish

They establish that a competent managed harness beats a neglected in-house one, which was never in doubt. They do not establish that it beats a maintained in-house one, and no published comparison does. Treat them as evidence the thing works, not as your projected improvement.

8. Where I would land

A straight answer by situation

The retention line decides most of this before anything else does

Selling into EU, healthcare, finance or public sector. Do not build on it yet. US-only residency and no ZDR will end your first serious security review, and discovering that after eight months of integration is the expensive version.
Pre-product-market-fit, consumer or SMB, no regulated data. Take it. Every week spent on compaction logic is a week not spent on the thing customers judge you by, and the loop is now free.
You already have a working harness in production. Do not rip it out on a launch post. Run one real workload both ways, compare token cost and failure rate, and keep whichever wins — you have the rarest asset here, which is a baseline.
Long-running autonomous work over days. This is the strongest fit. Durable sessions with managed recovery are exactly the hard part, and rebuilding that yourself is months.
Your differentiation is the agent loop itself. Then your moat just got commoditised by a free alternative, and that is worth knowing this week rather than next year.

9. What I would not over-read

Public beta is public beta. Residency, ZDR and model support can all change, and a limitation that is structural today for the durable-session design may be answered by a different session mode later. Build for what is documented, not for what is plausible.

"No fee" is not "no cost." Container time is billed, hosted tools are billed, and a harness that transparently compacts and spawns subagents makes token consumption harder to predict, not easier. Instrument spend per completed task from the first day, not per call.

Free orchestration is a strategy, not generosity. Giving away the layer above to sell the tokens below is the oldest move in infrastructure, and it works precisely because the free layer is genuinely good. That is an argument for using it clear-eyed, not for refusing it.

The honest summary

The agent harness stopped being a differentiator on 10 September 2026. Context compaction, subagent coordination, lazy tool loading and crash recovery are now a managed service at no markup, and the case for maintaining your own version of those has to be made rather than assumed.

What replaced it as the strategic question is the session. A durable agent session is the most useful primitive in the release and the one you cannot self-host, cannot get retention guarantees on, and cannot take with you. Durability and retention are the same property, which means this is a trade rather than a temporary gap.

Rent the loop. Own the state. The teams that get this wrong will not notice for a year, and will notice all at once.

Sources: OpenAI, "Introducing the Agents API" · OpenAI API documentation, Agents API overview · OpenAI API changelog, 10 September 2026 · MarkTechPost, "OpenAI Launches the Agents API in Public Beta, Putting the Codex Harness Behind One API Call" · Primitives, the limitations text and all pricing components are quoted from OpenAI's documentation; the design-partner figures are vendor-reported. The reading of durability and retention as one property, and every architectural recommendation, is mine. For how the harness debate looked when it was still a choice between vendors, see the two harnesses that shipped in 48 hours making opposite bets.

Two Agent Harnesses Shipped in 48 Hours — and They Make Opposite BetsAugust 7, 2026

DeepSeek's Harness Makes Even the Agent Loop Swappable — and Charges You 10x the Tokens for ItAugust 18, 2026

One Refactor Cost $14.29. Every File the Agent Read Stayed on the BillSeptember 2, 2026

IdeaToMVP Academy

Want to build with AI — not just read about it?

4-week live cohort for founders. Learn to ship AI agents, scope MVPs, and automate your business — taught by the same team that writes these guides.

Explore the Academy →