OpenAI's Agents API Has No Platform Fee, And That Is The Trap

OpenAI shipped the Agents API in public beta on September 10, and the headline is genuinely good news: there is no platform fee. You pay for the tokens and the tools your agents use, nothing else. Searches for “openai api pricing” are up 153% in three months, so a lot of people are trying to model what that sentence actually costs them.

Here is the problem. “No platform fee” is true, and it is also the least useful number in the launch. The Agents API is a token multiplier with three named mechanisms, and every one of them increases spend rather than reducing it. If you run heavy agentic workloads, the question is not whether there is a surcharge. There is not. The question is how many extra tokens you are now being billed for because the harness is doing work your own code used to do.

What the Agents API actually charges you for

The pricing page is refreshingly short. OpenAI states plainly: “There are no additional fees for using the Agents API, you simply pay for the tokens and tools your agents use.”

So the entire cost model reduces to your model mix. The current per-million-token rates on the models that matter for agent harnesses:

Model	Input	Cached input	Output
gpt-6-astra	$10.00	$1.00	$50.00
gpt-5.6-sol	$4.00	$0.40	$20.00
gpt-5.6-terra	$2.00	$0.20	$12.00
gpt-5.6-luna	$0.20	$0.02	$1.20

Long-context requests double those input rates and push Astra output to $75 per million. GPT-6 Astra is a smart default for a coordinator agent and a financially dangerous one for anything a subagent does. The spread between Astra and Luna output is roughly 42x. In an agent system, that spread is not a detail. It is the whole bill.

The three features that quietly raise your token count

OpenAI documented three harness capabilities as improvements. All three are real improvements. All three also consume tokens that a hand-rolled pipeline would not have spent.

Multi-agent support. A coordinator breaks a task into pieces and delegates to subagents that run in parallel. Each subagent “maintains its own context.” That is the point, and that is the cost: N subagents means N separate context windows, N sets of system prompts, N sets of tool definitions. Parallelism does not reduce token spend. Parallelism multiplies it, then reduces wall-clock time.

Run the arithmetic on a modest research task. Three subagents, each carrying 200,000 tokens of input and producing 30,000 tokens of output, coordinated by an Astra agent:

• On gpt-6-astra: about $10.50
• On gpt-5.6-luna: about $0.23

That is a 46x difference for the same shape of work. Now compare it to the single-agent version of the same task at the same token volume: $3.50 on Astra. Delegation did not cut your bill. It tripled it, and bought you latency instead of money.

Automatic compaction. As a session approaches its context limit, the API compacts earlier context and preserves what the agent needs to continue. Convenient, and billed: compaction is itself a model call over the context being summarized, and the compacted summary then enters every subsequent turn as fresh input. Long sessions used to fail loudly when they hit the wall. Now they keep going and keep charging.

Tool search. Loads relevant tool definitions on demand instead of all of them up front, which genuinely cuts prompt tokens and preserves cache. This is the one feature on the list that saves you money by default. It is also the one that makes it easier to build an agent that touches twenty tools, because the up-front cost of tool definitions stops being visible. Cheaper per call, more calls.

GPT-Live-1 is billed per second, not per token

The same week, OpenAI put GPT-Live-1 into the API. It is a full-duplex voice model: it listens and speaks at once, handles interruptions in a single model, and delegates reasoning to a backend text model like Astra or Luna.

Pricing for voice sessions is $0.05 per second.

That is $3.00 per minute, or $180.00 per hour of connected voice session. Every comparison you have internalized about token pricing stops applying here, because you are no longer buying tokens. You are buying wall-clock time on a socket. A support agent that sits on hold, handles silence, and lets a caller think is billing for all of it.

The architectural win is real. Replacing a chained STT to LLM to TTS pipeline with one model removes a latency handoff and cuts interruptions substantially. But the cost profile inverts for anything conversational that has dead air in it. For agents that are mostly listening, per-second billing is worse than per-token billing, and no amount of prompt engineering changes that.

Why this matters more than the model price war

For the past six months the story on TokenKarma has been deflation: GPT-5.6 Sol price cuts, MAI-Code-1.1-Flash at 73% less, Gemini and Qwen flagships racing downward, Meta handing out 100M-token tiers. Per-token rates are falling almost everywhere.

The Agents API moves the bill in the other direction without touching a single rate. Provider pricing is stable. The number of billed tokens is not. This is how the industry grows revenue while every headline reads “cheaper”: sell the same tokens to a harness that uses more of them, and call the mechanism a feature.

Compare it to what the rest of the field is doing. Cursor launched Projects with cloud agents that “delegate tasks to thousands of subagents” and run without your laptop open. Anthropic’s Claude Cowork and the Opus 5 agent tier push the same direction. Nobody is competing on making agents cheaper to run. They are competing on making agents capable enough that you stop counting.

That is a legitimate trade if you count deliberately. It is a trap if you do not.

What heavy users should do this week

Pin the model per role, explicitly. Coordinator on Astra, subagents on Terra or Luna, embedding and classification work on the cheapest model that passes. Never leave a subagent inheriting the coordinator’s model. The 46x spread in the arithmetic above is entirely a model-routing decision, and it is yours to make.

Set a per-run token ceiling before you launch anything agentic. A run ID with a hard budget is the only thing that stops a delegation loop at three in the morning. The Agents API makes runaway loops easier to build, not harder.

Verify compaction cost with a real trace. Turn on usage reporting, run one of your existing long sessions, and read the input tokens on the turn after compaction lands. Do not estimate. The number will be larger than you expect, and it recurs on every subsequent turn.

Audit cached input before optimizing prompts. Cached input on Astra is $1.00 versus $10.00 fresh, a 10x discount. If your agent rebuilds context in a new order each turn, you are paying full price for tokens you already paid to cache. Cache-write rates sit above standard input rates, so caching only pays off if cache reads actually happen.

Treat per-second voice as a capacity plan, not a rate. At $180 per hour per concurrent session, ten simultaneous voice agents is a $1,800-per-hour ceiling. Model concurrency the way you model compute, and put a timeout on silence.

Re-run your per-task unit economics. Every cost-per-task guide you built last quarter assumed one context window per task. Multi-agent harnesses break that assumption. Recompute before you commit a workflow to production, not after.

The bottom line

The Agents API has no platform fee, and the documentation is honest about it. What it does not do is hand you a smaller bill. Subagents multiply context windows, compaction adds recurring input tokens, and voice bills by the second. Model rates are unchanged, so the only variable left is how many tokens your harness consumes, and the harness is now OpenAI’s to improve on your behalf.

None of that makes the Agents API a bad product. Codex-grade infrastructure behind one API call is genuinely valuable, and the tool search feature is a real saving. It just means the cost conversation moved. It is no longer “what does this model cost per million tokens.” It is “how many millions of tokens does this agent architecture consume per task,” and that number is decided at design time, by you, before the first request is ever billed.

Start with the model routing table. That single decision is where most of the savings live.