OpenAI Agents API Review 2026: Codex's Agent Harness as a Managed Service — No Platform Fee, Three Meters, and a Lock-In You Should Price In
OpenAI Agents API Review 2026: Codex's Agent Harness as a Managed Service — No Platform Fee, Three Meters, and a Lock-In You Should Price In
Verdict first: the OpenAI Agents API (public beta, September 10, 2026) is not a model release, and reading it as one misses the point. It is OpenAI renting you the scaffolding — the same Codex harness that powers Codex and ChatGPT for Work, exposed as a managed cloud service where OpenAI owns the agent loop, sessions, context compaction and failure recovery, and you supply tools and a task. The pitch is compelling: no platform fee, low integration effort, sessions that run for hours to days, parallel subagents sharing a filesystem, and a choice of OpenAI-hosted, self-hosted or nine partner sandboxes. The catches are just as concrete: billing runs through three separate meters and the container meter is genuinely hard to forecast; data residency is US-only and Zero Data Retention is not supported even with a self-hosted sandbox; and developers spent launch day pointing at OpenAI's Assistants API retirement as the reason not to build on it. The scaffolding is good. The question is whether you want to depend on it.
OpenAI Agents API — the Codex harness as a service: OpenAI runs the loop, you bring the tools
What Is the Agents API?
OpenAI launched the Agents API in public beta on September 10, 2026, open to all developers. It exposes the Codex harness — the agent framework behind Codex and ChatGPT for Work — as an OpenAI-managed cloud service. You describe a task, pick a model, register your tools and choose an execution environment. OpenAI handles the agent loop, session lifecycle, orchestration, context compaction and failure recovery.
The harness itself is open source under Apache-2.0. The hosted runtime is the commercial product. That split matters and we will come back to it, because it is simultaneously the strongest reassurance and the weakest one — you can read exactly what the harness does, but the managed session service is what you would have to replace.
Two things distinguish this from the agents products you have already seen. First, it is not a new model: everything runs on models you can already call, at their existing rates. Second, the abstraction being sold is time. A single API call does not give you a response — it gives you a session that can survive for days, compact its own context as it fills, and recover from its own failures. If you have ever built that layer yourself, you know precisely what is being offered. If you have not, our Claude Code review covers the other end of this spectrum — an agent that runs on your machine rather than in someone's cloud.
The Four Primitives
The API reduces to four objects, and the design is clean enough to explain in a table:
| Primitive | What it is |
|---|---|
| Agent | The model plus instructions plus tools plus MCP servers. A reusable project-level resource — one agent_id can spawn many independent sessions. |
| Environment | An optional sandbox where code runs. Omit it entirely, use OpenAI's hosted sandbox, or point at your own or a partner's. |
| Session | A persistent agent instance that retains state across turns. Returns an ID, status, Required Actions and token usage — so you stop stuffing state into your own database. |
| Events / Items | Progress signals going in and saved outputs coming out. |
Invocation is a single call — POST /v1/agents/sessions with the header OpenAI-Beta: agents=v1, or client.beta.agents.sessions.create(...) in the SDK. Language support covers JavaScript, Python, Go, Java, Ruby and curl.
Three capabilities inside the harness deserve specific attention:
- Automatic context compaction. As a session approaches its context limit, the harness retains the important parts and discards the rest. This is the feature that makes multi-day sessions possible at all, and it is the piece most teams underestimate when building their own loop.
- Tool search. Tool definitions load on demand rather than being pasted into every request, which saves tokens when you have dozens of tools registered.
- Native subagents. Agents fan out into parallel subagents with independent contexts that share a filesystem.
One detail worth flagging: context compaction and tool search are themselves model calls, and they are billed. The optimisation that saves you tokens is not free — it just costs less than the alternative.
There is also a Required Actions mechanism that separates a model's decision from a real-world operation, giving you a place to insert permission checks and human confirmation. That is the right shape for anything that deletes, transfers money or deploys, and its existence tells you OpenAI expects this to be used for consequential work.
Where Your Code Actually Runs
This is the part that determines both your compliance posture and your bill, and it is more flexible than most launch coverage suggested. You have three primary options plus partner infrastructure:
| Option | Details |
|---|---|
| No environment | Run without code execution — pure model and tool orchestration. |
| OpenAI-hosted sandbox (default) | Linux workspace with Python and Node, configurable network access, and a 1-hour idle timeout that is not configurable. |
| Self-hosted | Run the sandbox on your own infrastructure or VPC via codex exec-server over an outbound WebSocket. |
| Partner sandboxes (9) | Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle Cloud, Runloop, Vercel. |
Read the last two rows together, because the distinction is where the marketing quietly stops. Choosing a partner or self-hosted sandbox changes where your code executes. It does not move the harness or the session service — those stay on OpenAI's side, which is why OpenAI states plainly that a self-hosted sandbox does not make the setup ZDR-compliant. If your mental model was "self-hosted means it stays in my perimeter", that model is wrong here, and it is better to learn that from a review than from an auditor.
The partner lineup is strategically interesting in its own right. By recruiting nine sandbox providers, OpenAI holds the control plane while outsourcing the infrastructure and capital risk to partners. Execution environments become the competitive layer — and OpenAI does not have to own the data centres to own the relationship.
Pricing: No Platform Fee, Three Meters
There is no additional platform fee for the Agents API. That headline is true and it is also the least informative thing about the pricing, because you are billed through three separate meters:
- Model tokens at the selected model's standard rates. For
gpt-6-astra, that is listed at $10 input / $50 output per 1M tokens in short context, $1 cached input, and $20 / $75 in long context. - Tools at their standard rates — web search and the rest.
- Container compute when you use an OpenAI-hosted sandbox.
Here are the published hosted-container rates:
| Container size | Rate (per 20-min session, per container) | Illustrative 24-hour session |
|---|---|---|
| 1 GB | $0.03 | ~$2.16 |
| 4 GB | $0.12 | ~$8.64 |
| 16 GB | $0.48 | ~$34.56 |
| 64 GB | $1.92 | ~$138.24 |
The right-hand column is our arithmetic for illustration, not an OpenAI quote — and the reason it needs a caveat is the next paragraph.
The container meter is the real forecasting problem. A footnote on the pricing page states sessions are billed by the minute with a 5-minute minimum, which is a different unit from the per-20-minute blocks in the main table. One published analysis notes that the container row is labelled "Hosted Shell and Code Interpreter" and linked to the Agents API only by a cross-reference, so it is not even unambiguous that these are the final rates. OpenAI's own guidance — worth quoting because vendors rarely say it — is to calculate the costs first. Usage and trace figures are described as "best-effort" and explicitly not a final bill.
Why this matters more than it sounds: container time accrues independently of tokens. A session that is thinking, waiting on a webhook or blocked on a human confirmation is still burning container minutes. Multiply that by subagent fan-out and a long-running agent's bill can be dominated by the meter you were not watching. The Agents API is cheap to start and easy to mis-budget — those are not contradictory statements.
What You Give Up
Four constraints are worth reading before you write a line of code:
- US-only data residency during the public beta.
- No Zero Data Retention — and OpenAI states explicitly that a self-hosted sandbox does not change this, since session records remain on OpenAI's side.
- Beta namespace. Calls live under
client.beta.*; production integrations should wrap them in an adapter layer. - Platform-defined state. Agents, sessions and run state use OpenAI's data structures. Migrating means converting full task state, not renaming a model.
For a startup shipping an internal agent, none of this is fatal. For finance, healthcare or government, the first two are hard blockers — not preferences, blockers. The absence of ZDR in particular removes the Agents API from consideration for a large class of regulated workloads regardless of how good the harness is. If your data cannot leave your perimeter, this product is not for you yet, and no amount of sandbox flexibility changes that.
The Lock-In Question
This dominated launch-day discussion, and the argument is not abstract. Community threads repeatedly invoked OpenAI's retirement of the Assistants API — deprecation with limited notice and a forced migration — as the concrete reason to keep a self-hosted path. Developers who lived through it are not being paranoid by remembering it.
The honest shape of the risk:
- What you keep: the harness is Apache-2.0, so you can read exactly how tools, memory and context management work, and you always have the option of self-hosting Codex CLI or switching to another vendor's managed agents.
- What you lose: session persistence, compaction, recovery and orchestration are the product, and they are not portable. Rebuilding an equivalent in-house means reconstructing exactly the layer you outsourced.
- What the open harness buys you: legibility, not portability. Knowing how the loop works helps you build a replacement — it does not let you take the running sessions with you.
There is a further consideration that received less attention than it deserves: a hosted session service is also a trajectory generation machine. Every long-running agent session produces structured records of real tasks being attempted, failed and corrected. Some commentary reads the whole release as OpenAI commoditising the scaffolding — give away the hard part, keep billing the tokens — while simultaneously accumulating exactly the real-world agentic signal that trains the next generation of models. Whether or not that is the intent, it is worth knowing what the arrangement gives OpenAI in return.
vs Responses API, Agents SDK and Anthropic
The three OpenAI options differ on exactly one axis: who runs the loop.
| Option | Who runs the loop | Trade-off |
|---|---|---|
| Responses API | Your application | Maximum control, lowest platform lock-in, most work |
| Agents SDK | Your application (SDK-assisted) | Moderate integration effort; you own deployment, storage and state |
| Agents API | OpenAI | Lowest integration effort; you trade control and portability |
Against Anthropic's managed agents offering, published comparisons identify several gaps on OpenAI's side: no scheduled deployment (cron-style), no cross-session persistent memory, a simpler multi-agent model, no web domain allowlists for permission policy, and no published runtime rates. Not all of these will matter to every team, but the first two are structural rather than cosmetic — if you need an agent that wakes on a schedule and remembers last week, this is not yet the product.
One more caveat that surfaced in developer discussion: the concurrency documentation is inconsistent. One source cites a max_concurrent_subagents default of 6 excluding the coordinator; documentation examples elsewhere show 4. OpenAI has not published clear rate limits in the overview, which means you cannot do capacity planning from the launch materials. Beta, fair enough — but plan for it.
What Developers Actually Said
A large Hacker News thread on launch day was split rather than hostile. One camp argued the value is in solving genuinely hard problems — state persistence above all. The other argued that a self-built harness offers more control, and that the Assistants API history justifies keeping one. Both positions are reasonable, which usually means the decision is context-dependent rather than universal.
Early customer results, all self-reported and without published methodology or independent audit — treat as directional, not proven:
| Customer | Claimed result |
|---|---|
| Ciridae | Evaluation score 0.71 → 0.85; 4× lower latency in subagent workflows |
| SafetyKit | 60% lower cost per case |
| Hypha | 86% fewer failed responses after separating harness from sandbox |
| Nash (logistics) | Thousands of agents deployed running across multiple days |
The Nash figure is the most interesting one, because multi-day agents at that scale are precisely what the harness was built to enable — and precisely what most teams cannot build themselves.
The Honest Take
The good: OpenAI has abstracted away the layer that consumes the most engineering time and produces the least product differentiation. Retry logic, context-window management, tool routing, subagent coordination, sandbox lifecycle — none of it is your moat, and all of it is now one call. Integration effort is genuinely low, the primitive design is clean, sessions that survive for days are a real capability rather than a bullet point, and Requires Actions shows the right instincts about human oversight. That the harness is open source under Apache-2.0 is a meaningful concession — you can read the thing you are depending on.
The real cost: pricing has three meters and one of them is hard to forecast from the published page, which is an uncomfortable property in a product designed for long-running workloads. Availability is US-only with no ZDR. State is platform-defined, so the exit cost is real, and the community's memory of the Assistants API retirement is a fair warning rather than a grudge. Beta concurrency limits are contradictory, so capacity planning is guesswork.
The strategy, stated plainly: this is a textbook commoditise-the-complement move. OpenAI gives away the scaffolding, keeps billing the tokens, and rents you the execution environment while letting nine partners carry the infrastructure risk. Meanwhile the hosted sessions generate the trajectories that train the next generation of agentic models. Every part of that is rational, and none of it is hidden — but you should decide whether you want to be the one running on it with your eyes open.
Bottom line: if you are building a long-running, multi-agent product and you are not in a regulated industry, this removes months of work and is worth prototyping against this week. If you are regulated, need ZDR, need cross-session memory or scheduled runs, or simply cannot accept that your session state lives in someone else's schema, the answer is still no — and the honest advice is to build on the open harness instead of the managed one.
Pros & Cons
Pros
- ✅ No additional platform fee — you pay only tokens, tools and container time
- ✅ Eliminates the orchestration layer most teams build badly: retries, compaction, tool routing, sandbox lifecycle
- ✅ Sessions persist for hours to days with automatic context compaction
- ✅ Parallel subagents with independent contexts sharing a filesystem
- ✅ Three execution options plus nine partner sandboxes (Cloudflare, Modal, Vercel, E2B and more)
- ✅ Underlying Codex harness is open source under Apache-2.0 — you can inspect what you depend on
- ✅ Clean four-primitive design; the same
agent_idcan spawn many independent sessions - ✅ Required Actions separates model decisions from real-world operations, enabling human approval gates
- ✅ SDKs for JavaScript, Python, Go, Java, Ruby and curl
- ✅ Multi-day agent deployments already running in production (Nash, self-reported)
Cons
- ❌ Zero Data Retention not supported — and a self-hosted sandbox does not fix it
- ❌ US-only data residency during beta
- ❌ Container billing mixes per-20-minute and per-minute units — cost forecasting is genuinely difficult
- ❌ Container time accrues independently of tokens; subagent fan-out multiplies it
- ❌ Platform-defined session state makes migration a full task-state conversion
- ❌ No scheduled/cron deployment and no cross-session persistent memory
- ❌ Concurrency defaults are inconsistent between docs and examples; no clear published rate limits
- ❌ Context compaction and tool search are themselves billed model calls
- ❌ Self-hosted sandbox changes where code runs, not where session data lives
- ❌ Beta namespace means production adoption needs an adapter layer
- ❌ Vendor lock-in concern amplified by the Assistants API retirement precedent
Who Should Use It (And Who Shouldn't)
Great fit
- Startups building long-running or multi-agent products who want to skip the orchestration build
- Teams already committed to the OpenAI stack, where the new lock-in is marginal rather than new
- Workloads needing multi-hour or multi-day sessions that compact their own context
- Prototypes and internal tools where low integration effort outweighs portability
- Anyone who wants parallel subagents without building a coordination layer
Poor fit
- Regulated industries — finance, healthcare, government — blocked by US-only residency and no ZDR
- Teams needing scheduled/cron-triggered runs or cross-session persistent memory
- Multi-model routing strategies that depend on calling whatever model is best per step
- Strict audit environments where session state must live in your own schema
- Anyone who needs to forecast costs to the dollar before committing
- Organisations that cannot accept beta namespace and changing limits
Frequently Asked Questions
How much does the OpenAI Agents API cost?
No platform fee. Three meters: model tokens at standard rates (gpt-6-astra at $10/$50 per 1M short-context, $20/$75 long-context), tools at standard rates, and hosted container compute at $0.03 (1 GB) to $1.92 (64 GB) per 20-minute session. A footnote says sessions are billed per minute with a 5-minute minimum — a different unit from the table, which is why forecasting is hard.
Does it support Zero Data Retention?
No. ZDR is unsupported in the public beta, and OpenAI states that choosing a self-hosted sandbox does not make the Agents API ZDR-compliant because session records still live on OpenAI's side. Data residency is US-only during beta.
What is the difference from the Responses API and Agents SDK?
Who runs the loop. Responses API: your app runs it, maximum control. Agents SDK: your app runs it with SDK help, moderate effort, you own state. Agents API: OpenAI runs it via a managed Codex harness — lowest effort, least portability.
Where does agent code execute?
Three options: no environment, the default OpenAI-hosted sandbox (Linux with Python and Node, configurable network, non-configurable 1-hour idle timeout), or self-hosted via codex exec-server. Plus nine partner sandboxes: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle Cloud, Runloop, Vercel. The harness and session service stay on OpenAI's side in every case.
Is the Agents API a lock-in risk?
Yes. Session state uses platform-defined structures, so migrating means converting full task state. Developers cited OpenAI's Assistants API retirement as the precedent. The Apache-2.0 harness gives you legibility and a fallback path, but not portability of running sessions.
Can agents run for days?
Yes. Sessions persist across turns and compact their own context as it fills; OpenAI describes hours-to-days runtimes. Logistics firm Nash reports thousands of multi-day agents in production, though that is a self-reported customer figure without published methodology.
Are there rate limits published?
Not clearly. Concurrency defaults for subagents are inconsistent between sources — one cites 6 excluding the coordinator, documentation examples show 4 — and OpenAI did not publish clear rate limits in the launch overview. Capacity planning from launch materials is not possible.
Sources
- OpenAI Developer Community — Introducing the Agents API and hosted sandboxes
- AI Tools Review — OpenAI Agents API: Cloud-Hosted Agents Explained (September 2026)
- DEV Community — OpenAI's Agents API Is Really a Hosted Codex Harness
- The Agent Times — OpenAI Exposes Codex Agent Harness as Public API
- FourWeekMBA — The Scaffolding Is the Strategy
- Creative AI News — OpenAI Agents API vs Claude Managed Agents
- Oflight — OpenAI Agents API: Pricing, Sandboxes & Quickstart (2026)
- Imisofts — OpenAI's Agents API Has No Fee. It Has a Third Meter.
- ZenML — OpenAI Agents are great. Production still needs a runtime.
- 艾瑞网 — OpenAI 开放 Agents API 公测：把 Codex 同款托管框架交给开发者
- 博客园 — OpenAI 突然上线 Agents API：自己写的 Agent 框架，还要不要留？
- 阿里云开发者社区 — OpenAI Agents API 正式发布：开发者的角色如何转变
Disclosure: pricing tiers, container rates and concurrency defaults are drawn from OpenAI's launch materials and secondary analyses, and some published figures are inconsistent or linked only by cross-reference. Data residency, ZDR support and beta limits may change. Early customer metrics are self-reported without published methodology. Verify all figures against OpenAI's official documentation before designing a production workload or budgeting for one.
评论
发表评论