GPT-Live-1 API Explained: Pricing, Access and Voice Agent Setup

What GPT-Live-1 does differently

Traditional voice agents often chain three systems together: speech-to-text, a language model, and text-to-speech. That architecture can work, but every handoff adds latency and makes interruptions, pauses, acknowledgments, and conversational timing harder to coordinate.

GPT-Live-1 moves the live conversation into a single full-duplex voice model. OpenAI describes it as capable of listening while it speaks, which allows the agent to react to interruptions and short backchannels such as “yeah” or “mm-hmm” without treating every sound as a new rigid turn.

The model also natively provides speech-recognition transcripts and response text, supports keyword biasing, understands alphanumeric strings more reliably, and still exposes turn detection for products that need explicit boundaries. Developers can control tone, pace, conversational style, and voice behavior through the live prompt.

The important design decision is that GPT-Live-1 does not need to perform every difficult task itself. OpenAI built delegation into the architecture so the voice conversation can continue while another model, agent, or service reasons, calls tools, checks records, or completes a workflow.

Official overview: OpenAI — Build more natural voice experiences with GPT-Live-1 in the API and Getting started with GPT-Live.

GPT-Live-1 pricing: what the $0.05 per minute actually covers

OpenAI’s current launch pricing is $0.05 per minute for the front-end voice layer, and the API release notes state that voice sessions are billed per second. This is not an all-in price for a complete intelligent voice agent.

The voice charge covers GPT-Live-1’s conversational layer. If the live model delegates a difficult question to a backend model, calls a paid tool, searches an external service, or triggers infrastructure in your own system, those costs sit outside the $0.05-per-minute voice price.

As a simple illustration, a ten-minute conversation creates $0.50 of GPT-Live-1 front-end voice charges before backend reasoning, tools, telephony, and your own infrastructure are added. Treat that calculation as arithmetic from the published rate, not as an estimate of the total cost of a production agent.

Pricing source: OpenAI pricing and availability and OpenAI release notes.

Who can access GPT-Live-1 in the API?

OpenAI made GPT-Live-1 generally available in the API on 10 September 2026. The API product is distinct from ChatGPT Voice: an API integration still needs an OpenAI API project, appropriate credentials, application code, and API billing.

For an API integration, create or use an OpenAI API project, keep the standard API key on a trusted server, and follow the Live connection flow appropriate to your application. For browser WebRTC, OpenAI explicitly says the standard project API key should remain on the server rather than being exposed to client JavaScript.

If a browser needs to authenticate directly to the media endpoint, OpenAI documents a short-lived ephemeral-token flow. Your backend uses the standard project key to mint the client secret, then the browser uses that short-lived credential for the WebRTC connection.

Production access can also be affected by project configuration, rate limits, spend controls, safety settings, and—for telephony—whether GPT-Live SIP support is enabled for the project.

Access and authentication flow: OpenAI WebRTC guide, Telephony and SIP guide, and release notes.

The architecture has two jobs: conversation and delegated work

OpenAI’s GPT-Live documentation separates a voice agent into two parts. GPT-Live-1 handles the conversation: listening, speaking, deciding when more help is needed, and keeping the interaction natural. The backend handles delegated tasks: reasoning, using tools, retrieving records, changing bookings, running code, or contacting your business systems.

This separation is useful because the best voice behavior and the best backend reasoning do not always require the same model. OpenAI gives examples of pairing GPT-Live-1 with a lower-cost model for high-volume routine tasks and using a stronger model such as GPT-6 Astra for difficult customer issues.

One subtle rule matters: an interruption in speech does not automatically cancel backend work. If a caller says “stop talking,” that can mean stop the current spoken response while a separate booking lookup keeps running. If the caller says “cancel my booking,” the application must explicitly update or cancel the business task and confirm the result.

Architecture: Getting started with GPT-Live. Task state and delegation: Delegation and tools.

WebRTC, WebSocket or SIP: which connection should you use?

OpenAI supports different connection paths because a browser microphone, a server audio pipeline, and a phone call have different transport needs.

For a normal web voice assistant, start with WebRTC. OpenAI specifically recommends WebRTC for browser environments because the browser’s peer connection handles the real-time media transport. For server-side audio, WebSockets expose a lower-level interface where your application is responsible for sending and processing audio data.

Connection guidance: Choose a connection, WebRTC, WebSockets, and Telephony and SIP.

A practical browser voice-agent setup

For a browser application, keep the permanent API key on your server. The browser captures microphone audio and establishes a WebRTC peer connection. Your trusted backend exchanges the browser’s SDP offer for the Live session configuration or mints an ephemeral credential, depending on which supported flow you choose.

1. Create the backend session endpoint. Your server authenticates to OpenAI with the standard project API key and creates or authorizes the Live session.
2. Define the session. Set model: "gpt-live-1", the live conversation instructions, the output voice, and the delegation mode.
3. Create a WebRTC peer connection in the browser. Add the user’s microphone as the local audio track and play the remote OpenAI audio track through an audio element.
4. Create the data channel. Use it for session events, transcripts, steering messages, and delegation-related events.
5. Exchange SDP. Send the browser offer through your trusted server or use an ephemeral token to negotiate the Live session.
6. Wait for the session to start. Do not send normal application commands until the session-start lifecycle event confirms the connection is ready.
7. Add delegation after the conversation path works. First verify clean microphone input, output audio, interruptions, and transcripts; then connect backend tools and business workflows.

The exact Live session contract can change as the API evolves, so use the current Live guide rather than copying an older Realtime example and only changing the model name.

Browser setup: OpenAI WebRTC guide. Live session structure: GPT-Live getting started guide.

Responses delegation vs client delegation

GPT-Live-1 supports two main ways to hand difficult work to the backend. The choice determines who owns the backend request, context, validation, and routing.

OpenAI recommends starting with Responses delegation when it meets the use case. The backend model is chosen independently of gpt-live-1. Current documentation uses GPT-5.6 Terra as a starting point and suggests Luna for cost-sensitive workloads; harder jobs can be routed to more capable reasoning systems where appropriate.

With client delegation, your application maintains the relevant conversation transcript and task state, runs the backend itself, then sends concise verified results back to GPT-Live. This is the better path if a result must be checked, redacted, combined with another system, or withheld before the voice agent is allowed to say it.

In either mode, your application—not the voice model—should own permissions, required confirmations, business records, and the truth about whether an external action really succeeded.

Delegation details: OpenAI — Delegation and tools in GPT-Live.

Prompt the live voice and the backend differently

OpenAI recommends keeping the live prompt short and conversational. It should define the assistant’s role, tone, pace, backchannel behavior, interruption behavior, and concrete rules for when to delegate.

Detailed procedures belong in the backend prompt. Put business rules, tool schemas, confirmation requirements, eligibility logic, record-update procedures, and long operational instructions there rather than stuffing them into the spoken agent’s prompt.

OpenAI also warns against overly rigid voice rules that accidentally suppress natural backchannels. Test prompts with real pauses, self-corrections, interruptions, noisy rooms, and frustrated users rather than judging the agent only from clean scripted demos.

Prompting guidance: OpenAI — Prompting GPT-Live.

How a GPT-Live-1 phone agent is set up

For phone calls, OpenAI supports telephony and SIP integration paths. A provider’s connection to your system and your system’s connection to OpenAI are separate architectural concerns, and OpenAI also documents provider-specific integrations for services such as Twilio, Telnyx, LiveKit, and Daily/Pipecat.

With direct SIP, the carrier or SIP provider carries the phone audio to OpenAI while your backend keeps control of authorization, routing, session configuration, and business logic. OpenAI requires TLS for SIP signaling and SRTP for call audio in this path.

1. Enable and route SIP for the project. Confirm GPT-Live SIP support and configure the provider’s SIP trunk.
2. Subscribe to the incoming-call webhook. OpenAI documents the live.transport.incoming webhook for new Live SIP calls.
3. Verify and deduplicate the webhook. Treat caller-provided SIP headers as untrusted metadata, not authorization.
4. Apply your routing rules. Decide whether the call should be accepted, rejected, escalated, or sent to a particular workflow.
5. Accept with a Live session configuration. Supply model: "gpt-live-1", conversation instructions, voice, and delegation mode from the trusted backend.
6. Attach sideband control when needed. Your server can monitor events and steer the running session while SIP continues to carry the audio.

Use idempotent action handlers. A telephony integration can observe retries or related events on more than one connection, and the same booking, refund, or record update should not execute twice merely because a webhook was delivered again.

Phone integration: OpenAI — Telephony and SIP.

What to test before putting a voice agent in front of customers

A voice agent that works in a quiet developer test is not automatically production-ready. Real callers pause, mumble, change their minds, talk over the agent, read out long identifiers, ask unrelated questions, and sometimes request actions they are not authorized to perform.

Interruptions

Test whether the agent stops speaking quickly without accidentally cancelling unrelated backend work.

Silence and background noise

Test thinking pauses, nearby speech, music, road noise, and side conversations.

Numbers and identifiers

Test phone numbers, order IDs, confirmation codes, dates, addresses, and corrections to previously spoken values.

Permissions

Require authentication and confirmation before consequential actions such as cancelling reservations, changing accounts, or placing orders.

Backend failure

Define what the voice layer should say when a tool times out, a database is unavailable, or the backend result remains uncertain.

Escalation

Provide a clear human handoff route for unsupported requests, repeated failures, complaints, or situations your policy requires a person to handle.

Cost

Measure voice minutes, backend-model usage, tool calls, telephony charges, and your own infrastructure together rather than optimizing only the $0.05 voice rate.

A useful first deployment is narrow: one customer problem, a small tool set, explicit permissions, and a reliable human fallback. Once you have real call data, expand the agent based on observed failure modes rather than adding every possible capability in the first version.