OpenAI Agents API & GPT-Live 1 Voice 2026 Pricing

Two Shipments in One Week, and They Point in Opposite Directions

OpenAI's API surface moved twice in the same week, and the two changes are worth reading together because they solve opposite problems. The Agents API answers "how do I stop writing my own agent loop?" — OpenAI now runs a managed Codex harness, keeps the session state, and hands your application a durable session object instead of a transcript you have to reassemble. GPT-Live 1 answers a different question: "how do I let a user interrupt a spoken assistant mid-sentence?" It is a full-duplex voice model that listens while it speaks, and delegates the actual thinking to a backend agent.

For an integration team, these are the two most expensive pieces of glue in the modern stack. Orchestration and voice are where teams spend weeks rebuilding infrastructure that the vendor could host. What matters for a comparison site is not the launch copy — it is what each one costs per unit of work, what it forces you to give up, and which of your existing stacks it quietly obsoletes. This review works through both from the vendor's own documentation.

Agents API: A Hosted Codex Harness Under Session Semantics

The Agents API gives your application access to the Codex harness through an OpenAI-managed API. OpenAI manages sessions, orchestration, context compaction, and recovery; your application provides tools and chooses the execution environment. The four concepts the docs build everything on are an Agent (the model, instructions, tools and MCP servers), an Environment (an optional sandbox or computer where the agent reads files, loads skills and runs commands), a Session (a durable instance of an agent that works on tasks and responds to input), and Events and items (the inputs and outputs produced during a session).

The loop is deliberately short. You create a session and configure the agent; OpenAI provisions the environment. You give it a task, which starts a turn of work once the environment is ready. You follow progress by streaming output or by receiving webhooks that tell you the agent finished or needs input. Then you either continue the same session or steer it mid-turn. In the hosted mode, your application only sends input and receives events.

What the managed harness actually provides is the part that used to be your codebase: running commands and code in a sandbox, applying skills and instructions, connecting external data through tools or MCP, steering the agent while it works, summarizing previous work to manage its context window, breaking work into subtasks and delegating to subagents, and resuming a session where it left off. That summary step is the one to look at if you have ever watched a long agent run die because the transcript outgrew the model.

It Is One of Three Runtimes, Not a Replacement for All of Them

The most useful thing in the docs is a comparison table most launch coverage skips. OpenAI now ships three ways to run an agent, and they are not interchangeable:

The practical reading: if you have already built an agent loop on the Agents SDK and it works, moving to the Agents API buys you managed context compaction and recovery but costs you control over deployment, storage, approvals and runtime integration — the four things the SDK exists to give you. If you are on the raw Responses API and still hand-rolling history, the Agents API is the larger win, because session durability is exactly what you are currently faking.

What the Agents API Costs

The Agents API is not priced as its own SKU, and this is the detail that trips up cost forecasts. Model usage is billed at the selected model's API rates; OpenAI tools use their standard rates; OpenAI-hosted sandboxes use standard container rates. So the cost of an agent session decomposes into three lines — tokens, tools, and container time — and only the first of those is the model price you already know.

Container pricing is where the ceiling comes from, because a long-running agent holds a container open for the whole session. Hosted Shell and Code Interpreter containers are billed per 20-minute session per container:

Two footnotes matter when you forecast. Eligible container sessions are billed by the minute with a 5-minute minimum per session, so a burst of very short agent runs is priced at five minutes each rather than at their real duration. And GB here means binary gigabytes — 1 GB is 2^30 bytes — which is a trivial distinction until you are sizing a 64 GB container against a 60 GB workload and wondering why it does not fit.

Stack that against the model and the arithmetic becomes concrete. Sessions in the vendor's own examples run on gpt-6-astra, priced at $10 per 1M input tokens, $1 per 1M cached input, $12.50 per 1M cache writes and $50 per 1M output. Two pricing rules apply on top: prompts above 272,000 input tokens are billed at 2× input and cache rates and 1.5× output for the entire request, and batch and flex modes run at 50% of standard while fast mode runs at 2×. For a coding agent that reads a repository once and then iterates, the cached-input line is where your money actually goes — which is why cache writes are billed separately at 1.25× the uncached input rate.

The Compliance Caveat You Should Read Before Prototyping

The documentation states it plainly, and it is the kind of constraint that only becomes visible after you architect around the API: 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 make the Agents API ZDR-eligible. If your organization treats ZDR as a hard requirement, the Agents API is not a candidate regardless of how much orchestration code it would replace — the hosted harness is the product, so self-hosting the sandbox does not move the data boundary.

GPT-Live 1: Full Duplex Voice With a Backend That Earns Its Keep

GPT-Live 1 is OpenAI's "premier model for natural, expressive voice conversations with smooth interruption handling." The model ID is gpt-live-1, and the defining capability is full duplex: it can listen and speak at the same time. The architecture splits the job in two. GPT-Live handles the conversation — listening, speaking, and deciding when to ask the backend for help. A backend handles delegated tasks — reasoning, tools, and returning results for GPT-Live to communicate.

That split is the design decision worth understanding, because it is what separates GPT-Live from the Realtime API. With Realtime, one model does speech, reasoning, and tool selection together. With GPT-Live, you choose the backend model or agent independently of the voice model. The docs frame the tradeoff directly: keep detailed instructions, business rules and tool workflows in the backend; keep conversation style and delegation triggers in a short prompt for GPT-Live. Your application still owns permissions, confirmations, private function execution, and durable task state.

One behavioural detail with real product consequences: interrupting speech does not automatically cancel backend work. The conversation can continue while a delegated task runs, which is exactly what makes "add a detail while the backend checks the order status" feel natural instead of broken — and exactly what you have to account for when you design cancellation, since stopping the user's speech is not the same as stopping the job behind it.

GPT-Live 1 Pricing: Per Second, Not Per Token

Voice is priced on duration, and this changes how you model cost. GPT-Live 1 sessions cost $0.05 per minute, billed per second, and session duration is not rounded up to the next whole minute. Backend model and tool usage is billed separately at normal rates for whatever you configure. That last clause is the one to internalize: the $0.05 buys you the voice layer only. Every delegation your backend performs is a second bill.

The two delegation modes are the cost-shaping decision. With Responses delegation, GPT-Live calls a supported Responses model, supplies conversation context, and returns results — managed, but you pay OpenAI for both halves and your context travels. With client delegation, your application controls backend execution, context, and which results reach GPT-Live — which is how you reach a non-OpenAI model, or an agent harness you already run. The mode is chosen when the session is created; to change it you start a new session.

Rate Limits and the Endpoint Shape

Voice sessions are rate-limited by concurrency, not requests per minute, and the free tier is unsupported for GPT-Live 1:

The endpoint table is where teams get surprised. GPT-Live 1 supports only v1/live/sessions. Chat Completions, Responses, Realtime, the realtime transcription and translation endpoints, Assistants, Batch, Fine-tuning, Embeddings, image and speech endpoints — all marked not supported. Supported features are streaming and function calling; structured outputs, fine-tuning, and predicted outputs are explicitly unsupported. This is a purpose-built endpoint, not a new model on the old Realtime path, and any integration that assumed it could point an existing Realtime client at gpt-live-1 will need rework.

Input modalities are audio and text; output is audio and text; image and video are unsupported, and the knowledge cutoff is July 31, 2025. Connection options cover the real deployment shapes: WebRTC for browser voice applications (media tracks for audio, a data channel for JSON events), WebSockets for server-side audio integrations, sideband connections for backend access to an existing session, and SIP/telephony guidance for phone integration. There are also documented partner paths for LiveKit, Twilio, Telnyx, and Daily/Pipecat — which matters if your media pipeline already exists and you would rather not replace it.

Where These Two Meet Cloudflare Containers

The bridge between the two announcements is Cloudflare's own changelog, dated September 10, 2026. The Agents API's environment concept lets you supply a self-hosted execution environment instead of an OpenAI-hosted sandbox, and Cloudflare Containers can now serve as one, with an open-source Workers template as the reference implementation. The Worker maintains a Cloudflare Container for each Codex session, keeps active work running, reconnects on follow-up input, and shuts down automatically when idle.

The economic logic is the reason this is worth a section rather than a footnote. Self-hosting the execution environment moves the container line of your agent bill off OpenAI's per-20-minute rate and onto infrastructure you already pay for, while keeping the managed harness — sessions, orchestration, context compaction, recovery — that you were going to the Agents API for in the first place. Note the boundary: self-hosting the sandbox does not make the session ZDR-eligible, because the managed harness remains the orchestrator. What it changes is where code executes and what the container costs, not where the session state lives.

Migration Decisions, Stated Plainly

If you run a voice product on the Realtime API, the question is whether independent backend reasoning is worth a new endpoint. GPT-Live's value is that the model doing the talking is not the model doing the thinking, so the backend can be a stronger model, a cheaper model, or an agent harness you already trust. If your voice agent is a single-model turn-taking experience, Realtime still fits and the migration is not obviously worth it.

If you hand-roll context management for a long agent, the Agents API removes real code. It also removes control: deployment, storage, and approvals move to the vendor unless you go the self-hosted-environment route. The honest framing is that you are trading a codebase for a dependency, and the trade is only good if the harness features — compaction, subagent delegation, resume — are things you would otherwise build badly.

If compliance requires ZDR or non-US residency, stop here. Neither the hosted nor the self-hosted sandbox variant makes the Agents API ZDR-eligible, and residency is US-only today. This is a documented constraint, not a limitation to be worked around at the integration layer.

Verdict

The two shipments answer questions that were previously answered by your own code. The Agents API is the more consequential of the two for most teams, because agent orchestration glue is pure cost center — nobody's customers notice your context compactor, they only notice when it fails. The pricing structure rewards understanding it: sessions are billed as tokens plus tools plus container-minutes, the container clock has a 5-minute floor, and prompts past 272K input tokens charge double on the way in. A team that models those three lines correctly will predict its bill; a team that multiplies a token rate by its token count will be surprised.

GPT-Live 1 is the narrower but cleaner win. Full duplex with an independent backend is the right architecture for voice, the endpoint shape is clear about what it does not do, and $0.05 per minute billed per second is a rate you can put in a spreadsheet without guessing. The catch is that it is voice-layer pricing only — the backend conversations are the variable you actually have to forecast, and that is where a comparison site's model tables earn their keep.

What makes this week's pair notable is not either feature alone but the direction of travel: OpenAI is productizing the harness and the voice layer, which means the remaining differentiation for integration teams moves up the stack. The teams that win the next two quarters are the ones that know exactly which parts of their agent stack they are still paying to maintain by hand.

Fact-checked against OpenAI's developer documentation for the Agents API, GPT-Live 1, GPT-Live-Transcribe and GPT-6 Astra, OpenAI's pricing page, and Cloudflare's September 10, 2026 changelog on September 11, 2026. openai.com marketing pages returned 403 to automated fetches; all figures here come from developers.openai.com documentation, which served markdown versions directly.