OpenAI's Agents API Has No Fee. It Has a Third Meter.

September 11, 2026. OpenAI put its Agents API into public beta on 10 September, handing developers the managed Codex harness that runs sessions, orchestration, context compaction and recovery so your application only supplies tools and picks where the code executes. The announcement says there are "no additional fees for using the Agents API" and that you "simply pay for the tokens and tools your agents use, as outlined on our pricing page." If you are an agency about to quote a client for an AI agent build, that is the sentence you will price from. It names two meters. OpenAI's own documentation runs three.

What OpenAI shipped on 10 September

The API changelog entry for 10 September reads: "Released the Agents API in public beta. Build agents with a managed Codex harness while OpenAI handles session orchestration, context compaction, and recovery." The short version of what is new:

1. A managed harness. OpenAI runs the loop that executes code in a sandbox, applies skills, connects to tools and MCP servers, summarises earlier work to manage the context window, delegates subtasks to subagents, and resumes a session where it left off.
2. Durable sessions. Work continues across turns without your application rebuilding the conversation context.
3. Three execution environments. An OpenAI-hosted sandbox, your own infrastructure, or one of nine named partners: Blaxel, Cloudflare, Daytona, DigitalOcean, E2B, Modal, Oracle, Runloop and Vercel.
4. Multi-agent delegation, with max_concurrent_subagents defaulting to 6, "excluding the coordinator".
5. No new fee, and no new SKU on the pricing page. That last point is the one worth reading twice.

The third meter the announcement leaves out

The Agents API overview states the billing model in one sentence: "Model usage is billed at the selected model's API rates. OpenAI tools use their standard rates, and OpenAI-hosted sandboxes use standard container rates." The page describing the hosted environment repeats it: "OpenAI-hosted sandboxes use standard container rates."

That is three meters, not two. Tokens, tools, and the container your agent runs inside. The announcement names the first two. The container is real compute with its own price, and it keeps running between model calls while your agent thinks, waits on a tool, or sits idle mid-session.

Two billing units on one page

Follow the link the announcement gives you and the container row on OpenAI's developer pricing page lists four memory tiers: 1 GB at $0.03, 4 GB at $0.12, 16 GB at $0.48 and 64 GB at $1.92, quoted "per 20-minute session per container". A footnote beneath the same table says eligible container sessions "will be billed by the minute, with a 5-minute minimum per session".

Those are two different billing units on one page, and nothing on the page reconciles them. A 20-minute block and a per-minute rate with a 5-minute floor produce different bills for the same workload, and the difference compounds across a fleet of agent sessions. Two further details are worth noting before you build a quote on that table. The row is labelled "Hosted Shell and Code Interpreter" and never names the Agents API at all, so the only thing connecting your agent sandbox to that price is a cross-reference in the docs. And OpenAI maintains more than one pricing surface, which do not carry identical container tables, so it matters which one you read.

Why you cannot forecast the bill precisely

The managed harness is the product, and the harness spends your tokens. OpenAI's observability guide is direct about it: "An agent may make several model calls while completing a task. Each call follows the model's token pricing and prompt-caching rules, as in the Responses API. Estimate cost across all calls needed to complete the task."

Context compaction is a model call. Tool search is a model call. Both are decisions OpenAI makes on your behalf, and both are billed to you. Neither has a line item on the pricing page, and the compaction guide publishes no figure for what a compaction pass costs, describing the compaction item itself as "opaque and not intended to be human-interpretable".

Reconciling after the fact does not close the gap either. The same observability page says session and turn usage is "best-effort", that it "can be null when unknown", that "missing usage does not mean zero usage", and, plainly, "These counts are not a final bill." It goes further and states that the usage fields "do not expose a separate cache-write count, so they cannot determine the exact model charge when that pricing applies". For any model with cache-write pricing, OpenAI is telling you in writing that its own usage object cannot compute your charge.

Even the saving is hedged. Tool search "may help reduce overall token usage and cost", and the observability page warns that "a high cached-input percentage does not measure savings on the total task cost. Cached input is still billed."

The idle hour that costs you the re-run

The hosted sandbox has a timeout you cannot change. If activity and keep-alives stop for an hour, OpenAI's environment documentation says the sandbox "can be deleted", and adds: "This timeout isn't configurable." The published recovery from an expired sandbox is to create a new session and supply the inputs again.

Put that next to OpenAI's cost guidance, which tells you to "account for root-agent and subagent work, including retries, plus any applicable tool, sandbox compute, and third-party service charges". A long job that stalls does not just fail. It is re-run, and the re-run is billed. There is no published retry cap, no refund, and no statement anywhere that a failed turn is not charged. Detection is your job too: streams do not replay missed events, and OpenAI warns that "an idle session alone does not mean the turn succeeded" and that "a completed turn does not guarantee every tool succeeded".

US only, and no zero data retention

This is the clause that will decide the question for some clients before price does. The overview page states that the Agents API "currently supports data residency only in the United States and does not support Zero Data Retention", and closes the obvious workaround in the next sentence: "Choosing a self-hosted sandbox does not make the Agents API ZDR-eligible." The API also retains session state by design so work can continue across turns, and deleting sessions and published artifacts is something you do afterwards.

If you build client-facing agents that touch confidential records, that is a hard gate rather than a preference. An agent handling privileged matter intake is the clearest case, which is why AI intake for law firms is usually designed around where the data rests before it is designed around which model runs it. Today the Agents API answers that question for you, and the answer is the United States.

This is not the Assistants API replacement

The timing invites a wrong conclusion. OpenAI removed the Assistants API on 26 August 2026, two weeks before this launch. The Agents API is not its named successor. OpenAI's deprecations page names the Responses API and the Conversations API as the replacement, and no OpenAI page positions the Agents API as a migration target for Assistants.

OpenAI's own comparison presents three parallel runtimes rather than a ladder. The Agents API is for "long-running tasks where OpenAI manages the agent and saves its progress". The Agents SDK "runs inside your application". The Responses API is for "calling models directly or building an agent from scratch". Integration effort is listed as low, medium and high in that order, which is an honest way of saying you are trading control for speed.

What it means for operators

The Agents API removes weeks of orchestration work, and that is genuinely valuable. It does not remove the need to price the thing. We ran the token side of that question separately when OpenAI published its own agent cost figures, in what an AI agent costs to run. The container is the meter that piece did not have to account for. Three practical moves:

1. Quote the container separately. Run one representative client workload end to end, read the container charge off the bill rather than off the table, and find out which billing unit your account is actually on before you commit to a fixed monthly price.
2. Instrument a hard stop yourself. OpenAI publishes no spend cap, no retry limit and no cost ceiling for the Agents API, and it says its own usage numbers are not a final bill. Track sessions, wall-clock sandbox time and retries on your side.
3. Check residency before you check benchmarks. United States only and no zero data retention will disqualify the Agents API for some UK and EU clients no matter how good the harness is, and no sandbox choice changes it.

Treat the customer numbers in the announcement as what they are. Ciridae reports an evaluation score moving from 0.71 to 0.85 and a 4x latency reduction, SafetyKit reports a 60% reduction in cost per case, and Hypha reports 86% fewer failed agent responses. Those are named launch customers, and the announcement does not describe how any of it was measured. They are a reason to run your own test, not a substitute for one.

The honest summary is that the headline is true and incomplete. There is no Agents API fee. There is a container meter the announcement does not mention, two published units for it, a harness that spends your tokens on decisions you do not see, and an explicit statement from OpenAI that the usage numbers you get back are not your bill. That is a workable trade, but only if you priced all three meters. If you are scoping agent work and want the cost model built before the code, that is the part of AI automation worth getting right first, and it is the first question to put to any AI engineer you hire.