Home / Articles

GPT-Live-1 Voice Agents: Sessions, Delegation Modes and Real Phone-Line Costs

A practical tour of OpenAI's full-duplex voice model: how a session runs, Responses versus client delegation, a worked cost estimate and the traps in the docs.

Publisher: REACTAPP.TOP8 min read1874 words

This article is published in English.

Sources: How to Use GPT-Live-1: Build a Voice Agent That Listens While It Talks

Anyone who has phoned a restaurant and landed on a voice bot knows the moment. You say something, there's a pause, and then the bot starts answering the question you asked five seconds earlier, just as you try to correct yourself. Most people end up pressing 0 for a human.

That awkward rhythm is built into the usual design. A classic voice bot waits for you to stop talking, converts the audio to text, thinks, converts the answer back to speech and plays it. Nobody can talk over anybody.

GPT-Live-1 is OpenAI's attempt at a different shape. It's the model behind ChatGPT Voice, offered through the API, and it listens while it speaks. This page covers what sets it apart, how a session runs, how it passes hard questions to a backend model, and what a small phone line would cost.

What GPT-Live-1 is

It's a full-duplex voice model. Full-duplex means both sides can talk at once, as on an ordinary phone call. If a caller cuts in with "actually, make it four people," the model stops, adjusts and carries on.

The model also leaves the heavy thinking to someone else. Whenever a request needs real effort, whether a search, a booking-system lookup or careful reasoning, the job goes to a separate backend model. OpenAI's launch material cites a turn-taking delay of roughly 0.8 seconds, down from about 1.4 seconds for the previous voice model. Treat that as a vendor figure.

The practical consequence is that the voice and the brain become separate jobs. The voice handles the conversation, and the backend handles reasoning and tools.

Delegation: a voice that talks and a brain that thinks

The hand-off is what OpenAI names delegation. Constantly, in fractions of a second, the voice model weighs whether to stay quiet and listen, stop, talk, or push a task to the backend. The call never freezes while that task runs, because the voice can say a quick "let me check" and keep the chat going.

Picture a caller asking a restaurant line whether a table for four is free at 7:30 on Friday. The model says "let me look," sends the availability check to the backend, and tells the caller the outcome once it returns.

The split also solves a quiet problem. According to its model page, the voice model's knowledge ends on July 31, 2025, so anything current has to come from the backend anyway.

Getting a voice session running

Connection options are WebRTC for browser apps, WebSockets for audio from a server, and SIP telephony for real phone numbers. Whichever you choose, the events look alike, so the steps below follow them.

Step 1: keep the API key on a server

Keep the key away from browsers. Your own trusted server creates the session while the browser deals only with microphone and speaker. A paid account is needed, because the free tier isn't supported, and rate limits count concurrent live sessions and rise with your usage tier.

Step 2: start the session

Once connected, you send a single session.start event containing your settings.

{
  "type": "session.start",
  "session": {
    "model": "gpt-live-1",
    "instructions": "Be concise and ask before taking an external action.",
    "audio": { "output": { "voice": "marin" } },
    "delegation": { "type": "client" }
  }
}

That one event picks the model, supplies instructions, selects a voice and declares who does backend work. Hold off on speaking until session.started comes back. Model, instructions and voice are frozen once the session begins, so later rules go through session.instructions.append instead of replacing the original text.

Step 3: stream audio both ways

With WebRTC, the browser takes care of audio. Over WebSockets, you send small chunks inside session.input_audio.append events. The format is strict: raw mono 16-bit PCM, base64-encoded, with no WAV header, at the sample rate you configured when starting (24 kHz is the default). The model's voice returns the same way, in session.output_audio.delta events. If your source audio uses a different rate, resample it yourself, because changing the format setting doesn't convert your bytes.

Step 4: read the transcripts

Live text for both sides arrives as session.input_transcript.delta and session.output_transcript.delta events. There's no "turn finished" event, because both parties may speak simultaneously. If your app needs tidy turns for logs, group the fragments on your side.

Step 5: close cleanly

Send session.close and keep reading until session.closed shows up. That last event carries the usage figures you'll be billed on. If the connection simply drops before it arrives, you don't get confirmed usage, which matters when you reconcile an invoice.

The step people most often forget is the fourth, building readable turns from transcript fragments.

Handing work to the backend

Here GPT-Live-1 stops being a pleasant voice and becomes a useful agent. One of two delegation modes is chosen when the session starts, and it can't change midway. To switch, begin a new session.

Option A: Responses delegation

You name the Responses model the voice should call and the tools it may use. The config sits in the session object alongside the model name.

"delegation": {
  "type": "responses",
  "responses": {
    "model": "gpt-5.5",
    "instructions": "Use tools when current information is required.",
    "tools": [{ "type": "web_search" }],
    "tool_choice": "auto"
  }
}

From then on, a caller's question that needs a search is handled by the backend, and the result streams into the ongoing conversation. Custom functions are different. A function like check_table isn't executed by the backend. Your app gets the call, runs it, returns the output and then tells the backend to continue.

Imagine a caller asking whether it will rain on Friday evening because the group might sit outside. The backend runs a web search, the voice says light rain is expected after six so indoors might be safer, and the caller never sits through a long silence.

Option B: client delegation

Here your own application is the backend. When the model wants help, you receive a session.delegation.created event carrying an ID. You do the work however you like and send the answer back with the same ID.

{
  "type": "session.commentary.append",
  "delegation_id": "item_delegation_123",
  "content": "Table for 4 is confirmed at 7:30 pm Friday."
}

A commentary message means the model should say the text aloud. If the model should know something quietly, session.thinking.append does that instead. Each message can run to about 500 tokens. In principle, a client handler could pass the job to an agent framework of your choice, though that combination deserves its own testing before you rely on it.

A sensible path is to start with managed Responses delegation and move to client delegation once you need more control over permissions, confirmations or the workflow itself.

What it costs

The voice layer costs $0.05 per minute, billed per second. That works out to $3 an hour, or $72 a day for a line that stays open around the clock. Backend models and tools are billed separately, so the real total depends on how often calls need help.

A worked example, using assumed numbers:

  • Suppose a restaurant line gets 2,000 calls monthly, each about 3 minutes. That's 6,000 minutes, so voice alone is 6,000 times $0.05, or $300.
  • Next assume two hand-offs per call, each with roughly 3,000 input and 300 output tokens, on a backend priced at $10 per million input and $50 per million output tokens. A single hand-off is $0.03 plus $0.015, or $0.045. Two make $0.09 per call, so 2,000 calls add $180.
  • The total is about $480 a month, or roughly 24 cents a call.

The token counts and the backend rates are guesses for a simple booking flow, so measure your own traffic before trusting them. The voice part is predictable, and the backend part is the one to watch.

Details the launch posts skip

Interrupting doesn't cancel the work

According to the docs, cutting off the assistant's speech doesn't automatically stop backend work. A caller who says "never mind" may still get the search or booking finished unless your app halts it. That's harmless for a weather lookup and serious for a "book it" followed by "wait, no."

Received isn't heard

Appending a result returns an acknowledgment, yet that doesn't show the model actually voiced it or that anybody listening heard it. Finishing a backend answer is one event, and a caller hearing it is another. For anything that has to be confirmed, a booking time for example, look for the text in the output transcript.

Benchmark numbers vary by source

Published benchmark scores for the model on customer-service tasks differ between OpenAI's own post and press coverage. Either way the reported jump over the older model is large, but these are vendor-supplied results, and independent testing is thin. Customer stories, like a language-learning company reporting far fewer interruptions during learners' thinking pauses, are anecdotes and not studies.

Quiet context isn't a safe place for secrets

Whatever goes in through session.thinking.append may still influence later speech. Keep account numbers and private notes out of it.

When it fits and when it doesn't

It suits:

  • Phone lines for bookings, orders and simple support
  • Learning apps, where users stop and think between sentences
  • Teams that want to retire a stitched-together pipeline of three separate models

Think twice about:

  • Calls where one wrong action is expensive, such as payments
  • Products that need custom branded voices right now, since those go through a separate approval process
  • Anything needing image or video input, which the model doesn't accept

A risky pattern is letting the backend confirm a booking the instant a caller says "sounds good," without checking what they said afterward. A safer one reads the confirmation back, waits for a clear yes and has your app cancel pending work if the caller changes their mind. The voice may be great, but your app still owns the safety checks.

Key points

  • Callers can interrupt or change course mid-sentence, because the model keeps listening as it speaks.
  • Substantive tasks go to a backend model, whether OpenAI manages it or your own app does.
  • Every session follows five steps: start, wait for session.started, stream audio, assemble turns from transcript fragments and close cleanly.
  • Voice runs at $0.05 per minute, putting a 2,000-call booking line near $480 monthly with a light backend under the assumptions above.
  • A caller's interruption leaves backend work running, so your app must deal with the "wait, no" case itself.