The Harness Is an API Now. Here Is What You Still Own.
On September 10, OpenAI put the agent harness behind a URL. The Agents API, in public beta, takes a POST to /v1/agents/sessions with a model, a tool list, and an environment. From then on OpenAI's servers run the loop that Codex runs on your laptop: call the model, execute tools, summarize old context when the window fills, fan work out to subagents, pick up where it left off after a disconnect. The same morning, Baseten announced it had bought Blaxel, a company that builds sandboxes for agents. Read together, the two posts draw a new line through the agent stack. The loop is becoming something you rent from the model vendor. The computer the loop drives is becoming its own market.
What moved across the wire
A harness is everything around the model call. I have spent a lot of this blog on that layer, from why it is where the leverage is to how Codex treats compaction as an API primitive. Until now, even when the model lived on someone else's GPU, the harness lived in your process. Your code held the transcript, decided when to summarize, dispatched each tool call, retried the ones that failed, and kept going or died when your process did.
The Agents API moves that code to OpenAI. The overview page states the split in one sentence: "OpenAI manages sessions, orchestration, context compaction, and recovery while your application provides tools and chooses its execution environment." The harness it runs is the open-source Codex harness, so you can read the logic that coordinates model calls, tools, and context. You just do not run it.
The pricing makes the move cheap to try. OpenAI says there are no extra fees for the API itself. You pay the selected model's token rates, standard rates for OpenAI's built-in tools, and container rates if OpenAI hosts the sandbox.
Four nouns and a turn
The API has four concepts. An agent is the model, instructions, tools, and MCP servers. An environment is an optional computer where the agent runs commands and edits files. A session is a durable instance of an agent working on tasks. Events and items are what flows in and what gets saved: events stream live progress, items are the stored messages and tool calls you can list later.
The unit of work inside a session is a turn, and the sessions guide defines it by what your message lands on. A message sent to an idle session starts a new turn. A message sent while a turn is active steers that turn. Turns run asynchronously, so your application either holds a stream open or registers a webhook and gets told when the session changes state. To stop the agent without losing the conversation, you send an agent.session.input.cancel event.
Two capabilities that used to be weeks of your own code are now fields. Context compaction happens server side: the harness "automatically compacts earlier context as a session approaches its context limit," and you write no compaction logic. Subagents are a config block, multi_agent: { enabled: true, max_concurrent_subagents: 3 }, where each subagent keeps its own context and the main agent merges their results. Tool search loads tool definitions only when needed, and programmatic tool calling lets the agent run calls in parallel and filter results in code before they enter context.
Three places the tools can run
The environment field is where the new design gets interesting, because it separates two things every local harness fuses: the loop that decides what to do, and the machine that does it. The architecture page offers three values.
none. No computer at all. The harness calls remote MCP servers directly and sends function-tool calls to your application. The built-in Bash and apply-patch tools and workspace files are unavailable.openai_hosted. OpenAI provisions a sandbox per session from the same infrastructure behind Codex and ChatGPT for Work. You configure files, packages, skills, and network access.self_hosted. You bring the computer. It can be a laptop, a Docker container, a remote sandbox, or an AWS Lambda function.
The self-hosted path is the one with a new moving part. Inside your environment you run codex exec-server, which the docs call the executor. It registers with the API using an environment ID and a restricted key, then opens an outbound WebSocket to codex-cloud-environments.chatgpt.com and waits for commands. "All connections are outbound," the self-hosted guide says, and the executor reconnects if the connection drops. Nothing has to reach into your network. The harness in OpenAI's cloud decides to run npm test; the executor in your container runs it and sends back the output.
OpenAI lists nine sandbox partners with first-class integrations: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel. The partners compete on the things a harness does not care about, such as cold start, GPU shapes, VPC deployment, and how files persist. One customer quote in the launch post names the payoff of the split directly: Hypha says that separating the agent harness from the sandbox cut its failed agent responses by 86%. That is a vendor-selected testimonial, but the mechanism behind it is real. A harness that is not sharing a process with rm -rf and an out-of-memory test suite has fewer ways to die.
Put the pieces on one board and the question "what did I just outsource" gets a concrete answer.
Ten jobs every agent runtime does. Pick a setup to deal them into your column or the provider's, or tap a chip to move it yourself. The readout checks whether any shipping product actually offers the split you built.
your code0
OpenAI0
Assignments follow the Agents API architecture, self-hosted, lifecycle, and security docs as of September 12, 2026. "Your own loop" means your code calling the Responses API directly.
What a crash costs now
The strongest argument for renting the loop is durability. A local harness is exactly as alive as the process running it. Kill the process mid-turn and the in-flight model call is gone, the tool call it was waiting on is orphaned, and whatever transcript you had not written to disk goes with it. Every team that runs agents for hours ends up writing a checkpoint layer for this.
In the Agents API, the session is the durable object and your process is a viewer. OpenAI keeps the session's configuration, turns, and items. If your application restarts, the turn keeps running. There is one sharp edge: "Streams do not replay missed events." After a disconnect you retrieve the session and list its saved items to catch up, instead of reconnecting and expecting the backlog. And if the agent is waiting on one of your function tools when your process is down, it waits; the session sits in requires_action until something answers.
The environment is the part that is still mortal, and the lifecycle page is unusually candid about it. "An agent session can outlive its environment." A mid-turn disconnect "can fail a tool even if the turn completes." The disconnect does not restart a killed command. Later input can request a reconnection, and the API waits up to five minutes for the executor to come back before failing the submission. "Reusing the environment ID does not restore files in replacement compute." And deleting a session "neither stops its environment nor emits a deletion webhook," so the bill for a forgotten sandbox is yours to notice.
One turn of a coding agent, seven steps. Choose where the harness runs and what dies while step 3, a long npm test, is still executing. The ledger reports what survives, following the documented behavior.
runtime
what dies at step 3
Behavior for the Agents API rows comes from the sessions, lifecycle, and manage-sessions guides. For hosted sandboxes OpenAI manages recovery and does not publish a contract for sandbox loss, so the figure says so rather than guessing.
The sandbox key and the other keys
A remote harness driving a local executor needs a credential inside the box, and OpenAI's design for it is worth copying even if you never use the API. There are two keys. Your application's OPENAI_API_KEY gets api.agents.read, api.agents.write, and api.responses.write, and the docs say to keep it outside the sandbox. The executor gets a separate environment key, created on its own dashboard tab with every other permission set to None, passed in as CODEX_API_KEY.
The security page does not pretend that key is hidden. "Agent-generated code can read the environment key." Its defense is scope: "This key only permits connecting environments. It cannot authorize any other API action." Assume the agent can read everything in its box, then put nothing in the box worth stealing.
Third-party secrets follow the same rule. For OpenAI-hosted sandboxes, vaults store a credential outside the session, the sandbox code sees an environment variable holding a placeholder, and a network proxy swaps in the real secret only for approved hosts. MCP credentials in a vault are bound to one server URL and used by OpenAI's service, not by code in the sandbox. For self-hosted environments, the docs tell you to run that proxy yourself: "This is infrastructure you provide." That sentence is the part of the harness you still own, and it is the part that decides how bad a prompt injection gets. The same week, an eval sandbox holding real provider keys became the entry point for a campaign against about 30 AI companies, which I took apart in the eval sandbox essay.
Three secrets an Agents API deployment handles. Choose the environment, then choose where each secret lives. Each row reports whether code the agent writes can read it, and what a stolen copy can do.
Scopes and placement rules from the Agents API self-hosted, security, and vaults guides. "Your proxy" is infrastructure you run; the docs recommend it for self-hosted environments but do not ship one.
Same morning, different layer
Baseten sells inference. On the day OpenAI moved the harness into its own API, Baseten bought the layer underneath it. Blaxel built microVM sandboxes that, in Baseten's words, "suspend and resume in 25 milliseconds, up to 5x faster than other sandbox products," plus a distributed filesystem for artifacts it calls Agent Drive, with idle sandboxes running "at close to zero cost." The press release names Abridge, Clay, Cursor, Lovable, Mercor, and OpenEvidence as customers. Terms were not disclosed. Baseten's stated thesis is locality: agents should "act next to the models they're calling, not across a network boundary."
Those two moves point in opposite directions, and both make sense. OpenAI is betting that the loop is model-specific enough that the lab should own it; the launch post promises "versioned access" to harness improvements "with each model launch." Baseten is betting that the computer is where agents spend their wall-clock time, so it should sit next to the GPUs. The sandbox vendors in the middle are becoming interchangeable targets for a harness that dials out to them. E2B had already shipped templates on September 7 that run Cursor's self-hosted agent machines on E2B infrastructure. The executor pattern turns every sandbox into a place any harness can drive.
What you give up
Renting the loop has costs that do not show up in the quickstart.
- Data controls. The overview states that 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 change that, because the session state lives with the harness, not with the box. If your compliance story depends on ZDR, this API is out today.
- Behavior that moves under you. A harness that improves with each model launch is a harness whose compaction strategy, subagent policy, and tool loading can change without a deploy on your side. The compaction triggers are not published as tunable thresholds. Your evals now test a moving pair, model plus harness, and a regression can come from either.
- A new failure domain on the critical path. With a local harness, your agent depended on the model endpoint. Now it also depends on the session service and, for self-hosted work, on the WebSocket route between your executor and OpenAI. The docs' own warnings about idle events, five-minute connection waits, and pending input that "the API does not guarantee" to recover after a crash are the operational surface you are signing up for.
- Portability. The loop is open source, which helps. The session store, event schema, vaults, and environment registration are not. Moving off means rebuilding durability yourself, which was the reason to adopt it.
It is still a beta, and OpenAI says it will iterate quickly on feedback before general availability. Some of these will shrink. The data-residency one is structural, because a server-side harness has to hold the transcript somewhere.
When to rent the loop
The honest decision rule is about which failure you would rather own. If your agents run for hours, fan out to subagents, and die in ways you keep patching with checkpoints, the Agents API hands you a durable session and a compaction strategy that someone else maintains, and it lets you keep your own computer through the executor. If your agents are short, your data cannot leave your boundary, or you need to route between labs turn by turn, keep the loop in your process and treat this launch as a reference design.
Either way, copy three things from it. Split the loop from the machine it drives, and make the machine dial out. Give the machine a key that can do exactly one thing. Keep every other secret behind a proxy the agent's code cannot read. Those are good rules for a harness you run on your laptop, and now they are also the shape of a product.
Keep reading