OpenAI Put the Codex Harness Behind One API Call. Here's What That Actually Saves a Two-Person Dev Shop From Building.

Note: OpenAI shipped this on September 10, 2026 — one day old as of writing, well inside the freshness window. Public beta status matters here: this is new enough that the rough edges are still being found in public, not a mature, battle-tested product yet.

If you’ve ever built an AI agent that needs to do more than answer one question — run code, browse the web, edit files, hand pieces of a task off to sub-agents, and keep working reliably across a session that might run for hours — you already know the actual hard part isn’t calling a model. It’s everything around the model call: session state that survives a crash, context that doesn’t blow past the window on a long task, a sandbox the agent can safely run code in, and a way to split work across multiple agents without them stepping on each other. That plumbing is where small teams lose weeks. OpenAI’s Agents API, now in public beta, is a bet that most of that plumbing doesn’t need to be built twice.

What actually shipped

The Agents API exposes the same harness and infrastructure that powers OpenAI’s Codex coding agent, packaged as a general-purpose API any developer can call — not just for coding tasks, but for any agent workflow that needs durable sessions, tool use, and sandboxed execution. It went live for all developers in public beta on September 10, 2026, with no separate fee for the API itself: you pay for the tokens, the tools, and the compute time your agents actually use, the same usage-based model as OpenAI’s other APIs.

The design organizes around four concepts:

Inside a session, an agent built on this API can run code, edit files, search the web, apply predefined “skills,” produce artifacts, and split work across subagents up to a configurable concurrency limit — the example configuration OpenAI published shows max_concurrent_subagents: 3 as a typical setting.

The sandbox choice actually matters for a small shop

Where the code runs is a real decision, not a checkbox, and the Agents API gives three real options:

1. OpenAI-hosted sandboxes, running on the same Codex infrastructure OpenAI’s own product uses — the lowest-effort option, and the one most small teams will start with.
2. Self-hosted, running codex exec-server on your own infrastructure — for teams that need the agent’s code execution to happen inside their own network, their own compliance boundary, or their own existing servers rather than OpenAI’s.
3. Nine partner integrations at launch — Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop, and Vercel — which let you keep the managed convenience of a hosted sandbox while choosing a specific infrastructure provider, useful if your product already runs on one of those platforms and you want the agent’s execution environment to live in the same place as everything else. Worth noting for cost planning: the Agents API itself carries no extra fee, but the containers backing any of these sandbox options — hosted, self-hosted, or partner — run at standard compute rates on top of your token spend, so “which sandbox” is a cost decision, not just an infrastructure-location decision.

For a two-person shop building an internal tool or an early-stage product, the OpenAI-hosted option removes an entire category of infrastructure work: you’re not standing up your own container orchestration, you’re not writing the session-recovery logic for what happens when a long-running agent job gets interrupted, and you’re not building your own context-compaction system for keeping a multi-hour task inside the model’s context window. OpenAI’s own developer example cited an evaluation score improving from 0.71 to 0.85 and a reported 4x latency reduction after moving from a custom-built agent loop to the Agents API — numbers from a single self-reported case, not an independently verified benchmark, but directionally consistent with what “someone else already solved the hard infrastructure problem” should look like.

What this replaces, concretely

If you’ve been building agent products before now, you’ve likely written some version of all of the following yourself, or bolted together several open-source libraries to approximate it:

• Session persistence — keeping an agent’s state alive across a task that spans multiple tool calls, possibly multiple hours, possibly surviving a server restart.
• Context compaction — summarizing or trimming earlier parts of a long-running session so it doesn’t exceed the model’s context window, without losing information the agent still needs.
• Tool orchestration — routing the agent’s requests to the right tool, handling failures, and managing what happens when a tool call errors out mid-task.
• Sandboxed code execution — giving the agent somewhere safe to actually run code or shell commands without that execution touching your production systems directly.
• Multi-agent coordination — splitting a task across subagents and merging their results back into a single coherent output.

Each of those is a legitimate multi-week engineering project on its own if built from scratch and built well. The Agents API doesn’t eliminate the need to understand any of them — you still need to configure sandbox boundaries thoughtfully, you still need to think about what tools an agent should and shouldn’t have — but it collapses “build this infrastructure” into “configure this infrastructure,” which is a meaningfully different scope of work for a shop without a dedicated platform team.

Where it’s genuinely not a fit yet

Two specific limitations are worth knowing before you build a real product on this, not after:

US-only data residency, no Zero Data Retention option yet. OpenAI’s own documentation flags this directly: workloads that require data to stay outside the US, or that need OpenAI to guarantee it isn’t retaining request data at all, aren’t supported on the Agents API in this beta. If you’re building for a customer with data-residency requirements — EU-based clients, healthcare data, anything with a compliance obligation attached — this is a hard blocker right now, not a “check the docs later” footnote.

It’s public beta, not a stable, versioned product yet. Public beta status from OpenAI has historically meant real API surface changes between beta and general availability — parameter names shift, defaults change, edge-case behavior gets tightened. Building a production feature on top of a beta API is a reasonable bet for a fast-moving small shop that can absorb a breaking change with a day of rework; it’s a riskier bet for a product you can’t afford to touch for a few weeks once it ships.

That risk isn’t theoretical, and it has a recent, directly relevant precedent worth knowing about: OpenAI’s previous stateful agent abstraction, the Assistants API, was announced for deprecation on August 26, 2025 and actually shut down exactly one year later — August 26, 2026, roughly two weeks before the Agents API’s public beta went live. Developers who’d built production systems on Assistants API were left with a real migration project on a deadline, and the community reaction at the time flagged unpredictable costs, clunky performance under load, and a general feeling of not being in control of the abstraction layer they’d built on. None of that means the Agents API will meet the same fate — it’s architecturally different, built around the Codex harness rather than the older Assistants model, and OpenAI has an obvious reason to keep it stable given how much of their own Codex product now depends on it. But a shop deciding how much production weight to put on a beta API from this vendor specifically should weigh that history, not just this week’s announcement post.

Cost reality check

There’s no separate “Agents API fee” — you pay standard token pricing for whatever model the agent calls, plus the cost of any paid tools it uses, plus compute time for whichever sandbox option you choose. That last part is easy to underestimate: a self-hosted or partner-hosted sandbox running for hours on a long agent task carries its own infrastructure cost on top of the token spend, and it’s a cost that scales with how long you let an agent run unsupervised, not just with how many requests you send. For context on the broader pattern of AI usage costs quietly outrunning expectations, the piece on API bills having an expiration date covers the same dynamic from a different angle — a usage-based cost structure is only predictable if someone’s actually watching it, and an unattended multi-hour agent session run is exactly the kind of spend that’s easy to lose track of until the invoice arrives.

A worked example: the two-person shop building an inventory-reconciliation agent

Say you’re a two-person dev shop building a tool that watches a client’s inventory feed, cross-checks it against three sales channels, and flags mismatches — a multi-hour job that needs to browse data sources, run reconciliation logic, and occasionally hand a sub-task (like re-checking one specific SKU’s history) off to a focused subagent rather than re-running the whole pipeline.

Built the hard way, that’s a session-state layer to survive the job running longer than any single request, a context-management system so the agent doesn’t lose track of earlier findings by hour three, a sandbox to safely run the reconciliation code without touching the client’s production systems directly, and custom logic to fan work out to sub-tasks and merge the results back. Realistically, for two people also building the actual product logic, that’s two to four weeks of infrastructure work before the first real reconciliation run happens — time that isn’t going toward the thing the client is actually paying for.

Built on the Agents API: define the Agent (model, instructions, the specific tools it needs — feed access, sales-channel APIs, a code-execution tool for the reconciliation logic itself), pick a hosted Environment so the code runs in an isolated sandbox rather than on your own servers, and let the Session/Events structure handle the multi-hour persistence and streaming output. The max_concurrent_subagents setting handles the per-SKU re-check fan-out without custom coordination code. The actual engineering effort shifts from “build the infrastructure that lets an agent run for hours reliably” to “write the reconciliation logic and get the tool definitions right” — which is the part of the job that’s actually specific to your product.

This isn’t a case where the API magically makes the product itself easier to get right — reconciliation logic, tool definitions, and knowing what to actually tell the agent to do are still entirely your job, and getting those wrong produces a fast, confidently wrong agent instead of a slow, correct one. What moves is the amount of plumbing standing between “we have an idea” and “we have something running against real data.”

Frequently missed detail: this doesn’t replace judgment about what the agent should be allowed to do

None of the infrastructure above answers the actual risk question every agent product has to answer: what should this agent be allowed to touch, and what happens if it’s wrong. A well-built Session with a properly isolated Environment still needs someone to decide which tools an agent gets access to, what a sandbox is actually isolated from, and what a human needs to review before it goes live. The piece on sandbox-as-policy, not a wall covers this exact gap — better infrastructure makes it easier to build the guardrails correctly, but it doesn’t build them for you, and treating “we’re using OpenAI’s managed sandbox now” as equivalent to “we’ve thought through what this agent can actually break” is the mistake worth naming explicitly before it happens rather than after.

What “OpenAI owns the harness” actually means day to day

It’s worth being concrete about what’s actually happening behind the Session object, because “managed infrastructure” is a vague enough phrase to gloss over what you’re really outsourcing. Per OpenAI’s own description of the system: the platform keeps the session alive across the life of a task, automatically compacts context when a long-running job starts approaching the model’s context window, and recovers the session after a failure — a crashed container, a dropped connection, a tool call that errors out mid-task. Your application’s job, in that division of labor, is supplying the instructions, the tool definitions, and any connected MCP servers; OpenAI’s job is making sure the session that’s executing against those instructions doesn’t silently lose its place or die partway through a multi-hour job. That’s a genuinely different responsibility split than a typical stateless API call, and it’s the part that’s actually hard to replicate well — plenty of teams can write code that calls a model in a loop; fewer have written (and load-tested) their own context-compaction and crash-recovery logic well enough to trust it on a client-facing product.

How this compares to just building your own agent loop

Plenty of small shops have shipped working agent products without anything like this — a Python loop calling a model API, a hand-rolled tool router, a subprocess sandbox cobbled together with Docker. That approach still works, and for a genuinely simple, single-purpose agent (one tool, one task, short sessions), it may still be less overhead than learning a new API’s conventions. Where the Agents API earns its place is specifically at the point where your homegrown loop starts needing session recovery, multi-agent coordination, or context management that you’re maintaining yourself — the point where “our agent infrastructure” quietly becomes its own ongoing engineering project, competing for the same hours as the actual product. If you’re not at that point yet, the honest answer is you may not need this yet either — the same build-vs-buy math McKinsey’s build-vs-buy data covers for agentic coding tools generally applies here too.

What to actually do with this if you’re building an agent product right now

1. If you’re prototyping something new, start with the OpenAI-hosted sandbox option — it’s the lowest-friction path to a working multi-turn, tool-using agent, and switching to self-hosted or a partner sandbox later is a configuration change, not a rewrite, if you keep the Agent/Environment/Session structure consistent.
2. If you have a data-residency requirement, treat the current US-only limitation as a hard blocker today, and either wait for expanded support or evaluate self-hosting codex exec-server on infrastructure you fully control.
3. If you’re already maintaining custom session-recovery or context-compaction code, this is worth a real evaluation — not necessarily a migration, but at minimum a side-by-side comparison of what it would take to hand that specific piece off.
4. Budget the sandbox compute time separately from token spend when estimating cost, especially for any workflow involving long, unattended agent sessions — it’s the line item most likely to surprise you three weeks in.

Bottom line

The Agents API isn’t a new capability — small teams have been building multi-tool, multi-session agents for a while now, the hard way. What changed on September 10 is that OpenAI packaged the specific infrastructure it built to run Codex reliably and made it available as a general building block, for a usage-based price with no separate API fee. For a small dev shop, that’s a genuine trade of build-time for run-time cost on a piece of infrastructure that’s easy to underestimate until you’ve built it once yourself. It’s not a fit yet for anyone with a hard data-residency requirement, and it’s beta software, which means treat it accordingly — but for the specific problem of “our homegrown agent loop is becoming its own project,” this is worth an actual afternoon of evaluation, not just a bookmark.

Sources

6 refs

All facts accessed September 11, 2026.

1. Official announcement, architecture (Agent/Environment/Session/Events), pricing model, sandbox options, and subagent configuration — OpenAI, “Introducing the Agents API”openai.com
2. Public beta release date, detailed architecture breakdown, execution environment options (OpenAI-hosted, self-hosted codex exec-server, nine partner integrations), and data-residency/ZDR limitations — MarkTechPost, “OpenAI Launches the Agents API in Public Beta, Putting the Codex Harness Behind One API Call”marktechpost.com
3. Developer-reported evaluation score and latency improvement figures, and comparison to the Assistants API’s stateful session model — Data Studios, “OpenAI launches Agents API: cloud agents, subagents, hosted sandboxes, and the Codex harness”datastudios.org
4. Codex/Agents API usage-based pricing structure and rate-limit-vs-budget distinction — OpenAI Help Center, “Codex Rate Card”help.openai.com
5. Full nine-partner sandbox list and session/compaction/crash-recovery architecture description — OpenAI Developer Community, “Introducing the Agents API and hosted sandboxes”community.openai.com
6. Assistants API deprecation announcement (August 26, 2025) and August 26, 2026 shutdown date, plus developer migration concerns — OpenAI Developer Community, “Assistants API beta deprecation — August 26, 2026 sunset”community.openai.com