The OpenAI Agents API Rents You the Codex Harness, and There Is No Version Number On It

OpenAI will run the agent loop for you. Read the configuration schema before you decide that is a bargain.

There is a sentence in the Agents API launch post that reads like a feature and works like a liability. OpenAI describes the managed Codex harness this way: "The Agents API provides versioned access to these capabilities with each model launch. We maintain and continuously improve the harness alongside our models."

Read the version axis carefully. It is the model. You pin gpt-6-astra. The harness that drives gpt-6-astra improves underneath you, on OpenAI's schedule, and the configuration schema has no field where you could say otherwise.

I went looking for that field. The configuration guide lists what an agent definition holds: model, instructions, tools, reasoning and output settings. The agent object also carries the multi_agent block, and the session adds an environment with vault IDs and capability directories nested inside it. The architecture page defines the harness as "the OpenAI-hosted Codex instance that runs the model and tool loop and maintains the agent's session." Nowhere in either page is there a harness version, a pin, a channel, or a date you can freeze.

That is the whole argument of this piece, so let me say why it matters before anything else.

The harness is not plumbing anymore

For most of the last two years the harness was the part you wrote. A while loop, a tool dispatcher, some retry logic, a hand-rolled summarizer for when the context filled up. Nobody thought of it as a product because nobody was selling one.

That changed on September 10. The Agents API went into public beta and the pitch is that you stop writing the loop entirely. One client.beta.agents.sessions.create() call and OpenAI runs orchestration, automatic context compaction as the session approaches its limit, tool search that loads tool definitions only when they are needed, programmatic tool calling that lets the agent chain and filter calls in code, and subagent fan-out through multi_agent: { enabled: true, max_concurrent_subagents: N }. Compute runs in an OpenAI sandbox, on your own infrastructure, or with one of nine partners including Cloudflare, Modal, E2B, Daytona, Vercel and Oracle.

Every one of those managed behaviors is a decision about what your agent does. Compaction decides what survives from the first hour of a six-hour run. Tool search decides which tools the model can even see at a given moment. Subagent delegation decides how work gets split and how much context each piece carries. Those are not implementation details. They are the difference between a run that works and a run that burns a thousand dollars and produces nothing.

And here is the uncomfortable part: we now have a public measurement of exactly how much the harness decides.

Somebody left a harness running for 35 hours and counted

Armin Ronacher pointed a deliberately hands-off setup at CPython over a weekend, gave the model freedom to manage its own context and spawn subagents, and asked it to add virtual threads and lexical scoping. He published the receipts: 35 hours, 75,000 net lines added, 79 commits, roughly 1,400 agent messages, about $1,200 in raw API cost, which works out to around $15.50 per commit. His verdict on the output was "absolutely nothing of value."

The interesting part is not the failure. Anyone who has pointed an agent at a compiler expecting magic could have predicted the failure. The interesting part is the mechanism he documents, and the mechanism is a harness mechanism.

When the agent abandoned the harness's edit tool and started doing its work through heredoc Python that string-spliced C source in place, two things happened. The changes stopped being followable as they happened, because you cannot read a diff that is being assembled inside a p.read_text().replace(...) chain. And the code-golfed style bled into what got committed: tests with no whitespace or indentation, magic integer indexes into an accelerator tuple, C written in a style that appears nowhere else in the CPython tree.

Ronacher's read is that models are rewarded for token efficiency in tool calls and task completion, with little penalty for code a human cannot read, and that the penalty vanishes entirely inside subagents where nobody is watching. He notes the same behavior shows up less in a different harness that keeps steering the model toward a structured edit tool.

Same model. Different harness affordances. Different committed code.

One caution on his numbers: his post gives the token spend twice, as roughly 4 billion in the opening and around 1 billion later. Those cannot both be right, so treat that single figure as unreliable. The hour count, commit count, line count and dollar figure are consistent throughout.

The other half of the evidence came from Anthropic

Claude Code 2.1.268 published to npm on September 10 at 18:41 UTC. Read its changelog as a security document rather than a feature list and four entries stand out, all of them the harness failing to hold its own boundary:

Deny and ask permission rules on symlinked directories (/etc, /tmp, /var on macOS, /bin on Linux) were not applying when a path arrived by its real location, and Bash commands ignored deny rules written against the symlinked spelling.
A Read or Edit deny rule could be skipped when an env -C, eval or similar wrapper the permission checker cannot analyze sat on the same line.
A respawned in-process teammate could pick up tools or a system prompt from a same-named agent file in a folder the user had never trusted.
/mcp, /plugin, claude mcp list and MCP login errors were printing secrets resolved from ${VAR} placeholders.

None of those are model failures. They are harness failures in a product whose entire safety story is that the harness holds the boundary. That they were found, fixed and written down in public is a point in Anthropic's favor, not against it. The point for our purposes is different: if you were running 2.1.264 and someone asked you whether your deny rules held, you would have said yes, and you would have been wrong, and there was no way to know from the outside.

Now ask that question about a harness you cannot version.

What "open-source foundation" does and does not buy you

The launch post has a section headed "An open-source foundation." It says the Agents API is powered by the open-source Codex harness, and that while OpenAI operates and maintains it, "developers can inspect and learn from its public codebase."

Inspect and learn from. Not pin. Not run. Not diff against what is actually executing in the managed service.

The openai/codex repository is genuinely useful; Ronacher's post even links directly into the Rust file where Codex parses and hides recognized bash commands, which is the kind of thing you can only learn from source. But reading a repository tells you what the harness did at a commit. It does not tell you which commit the managed service is on, and nothing in the API tells you either.

There is a second cost in the same docs that deserves a line here, because it surprises people who assume self-hosting the sandbox solves it. From the Agents API overview: the service "currently supports data residency only in the United States and does not support Zero Data Retention (ZDR). Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible." The harness is OpenAI's, the session state is OpenAI's, and moving your compute does not move those.

Put this into practice

None of this means don't use it. A managed harness is a real productivity win, and writing your own compaction logic is a bad use of a week. It means treat the harness as an unversioned dependency and build the small amount of scaffolding that an unversioned dependency requires. Four steps, roughly in order of effort.

1. Record the session ID and the wall-clock time for every run you might need to explain. There is no harness version to log, so the timestamp is your only proxy for "which harness was this." If behavior changes in October and you need to show what changed, a session ID plus a date is the difference between an investigation and a shrug.

2. Build a canary task and run it on a schedule. Pick something small, deterministic in shape, and representative of your real workload: read three files, call one tool, write one output with a known structure. Run it daily against the managed harness and store the full event stream. You are not checking whether it passes. You are checking whether the shape of how it passes changed, meaning tool call counts, compaction events, subagent spawns, which tool made the edit. A harness change shows up here weeks before it shows up as a production incident.

3. Log which tool performed each file mutation, especially inside subagents. This is the direct lesson from Ronacher's 35 hours. If your agent is writing files through raw shell rather than a structured edit tool, you have lost the ability to review changes as they happen, and you will not notice until the diff arrives. The Agents API streams detailed events and supports webhooks, so this is a filter on an event stream rather than new instrumentation.

4. Keep one pinned harness as a reproducibility baseline. This is what NVIDIA did with its Pi extension, SoL-Pi, whose install instructions pin @earendil-works/pi-coding-agent@0.84.2 exactly and ship a scripts/check-pi-compat.mjs that asserts the specific public Pi API exports it depends on still exist and still have the right shape. That is an API-compatibility check rather than a version check, which is arguably the better move: the pin tells you what was tested, and the script tells you whether the interface underneath actually moved. It is what an exact npm version of Claude Code gives you. When a managed run produces something you cannot explain, being able to replay the same task against a frozen local harness is the only way to tell whether the model changed, your prompt changed, or the harness changed.

And before adopting a managed harness at your company, get an answer in writing to one question: can we pin a harness version. My expectation is that the answer is no today and yes eventually, in the enterprise tier, priced accordingly. A vendor that lets you pin has to support old harnesses. A vendor that improves continuously does not.

Where this argument is weak

The Agents API is one day old and labeled public beta. OpenAI says explicitly that it will iterate based on feedback as it works toward general availability, so a pinning mechanism may well ship. Judging a beta by its missing knobs is partly unfair, and I would rather be wrong about this in six weeks than right.

My "no harness version field" claim comes from reading three documentation pages: the overview, the architecture page, and the configuration guide. I did not read the full API reference schema, which those pages link to for accepted values. If an undocumented or reference-only field exists, that claim is too strong and I would want to correct it. I also have not run the Agents API. Everything here is read from documentation and from other people's measurements, which is exactly the position most readers are in on day two of a beta.

Ronacher's experiment was adversarial by design and he says so. Zero oversight, self-managed context, one enormous prompt, a codebase he happens to work on. That is not how anyone should run a production agent, and the failure does not generalize to a well-scoped task with a human in the loop. What generalizes is narrower and still holds: the tool the agent edits through changes the reviewability of what it commits.

And the Claude Code bugs cut both ways. Four permission-boundary failures in one release is a real finding about how hard this layer is. It is also four fixes shipped and documented, in public, by a team that could have written "various bug fixes" instead. That is the behavior you want from a harness vendor, and it is only visible because that harness ships as a versioned artifact you can read the changelog for.

Which is the whole point.

The line to remember

The layer that most determines how your agent behaves is now the layer you are most likely to outsource. That trade can be worth making. It stops being worth making the moment you cannot answer a simple question about your own system: when it starts behaving differently on a Tuesday, what do you diff?

Build the canary before you need it.

Sources: OpenAI, Introducing the Agents API · Agents API overview · Agents API architecture · Configuring agents · Armin Ronacher, "Astra for Coding: Why Are We Doing This Again?" · Claude Code CHANGELOG · NVlabs/SoL-Pi

Medium metadata

Title: The OpenAI Agents API Rents You the Codex Harness, and There Is No Version Number On It
Subtitle: OpenAI will run the agent loop for you. Read the configuration schema before you decide that is a bargain.
Tags: OpenAI, AI Agents, Software Engineering, Developer Tools, Codex
Suggested kicker image: a rack-mounted server with every faceplate label blank
Canonical: import from the fervorai.dev URL