GPT-Live-1 Technical Overview

GPT-Live is OpenAI’s third generation of voice model. It’s full-duplex, so it can listen and talk at the same time, and it hands reasoning and tool calls off to a separate backend model that you pick. It launched in ChatGPT on July 8, 2026, and gpt-live-1 went GA in the API on September 10. The voice layer costs $0.05 a minute, billed by the second. Whatever backend model you use is billed on top of that at its normal rates.

For our purposes, the part that matters is the Live sessions API (v1/live/sessions). You can connect over WebRTC from a browser, over WebSocket from a server, or over SIP for phone calls. When you create a session, you choose between Responses delegation, where OpenAI runs the backend model for you, and client delegation, where you run your own agent.

One thing that confused me at first: “Medium” and “High” aren’t separate API models. They’re reasoning tiers in the ChatGPT app. The API has exactly one model ID, gpt-live-1, and you control reasoning depth by choosing the backend model and setting reasoning.effort.

What GPT-Live is

How it differs from earlier voice systems

OpenAI’s voice products have gone through three designs:

• The original ChatGPT Voice chained speech-to-text, an LLM, and text-to-speech together. Information got lost between the steps, and it felt slow.
• Advanced Voice Mode used a single speech-to-speech model. Latency dropped, but the conversation still moved in rigid turns controlled by a silence detector.
• GPT-Live drops the turn detector altogether. The voice model keeps processing incoming audio while it generates output, and decides many times a second whether to talk, listen, pause, interrupt, or delegate. Heavy reasoning and tool work run asynchronously on the backend, so the conversation doesn’t stall while they finish.

OpenAI’s engineering write-up (“How we built a realtime system…”) covers the infrastructure. The highlights are stateful streaming inference, handing off between model instances when context gets compacted, and a Go rewrite of the media frontend (the new p95 latency matches the old p50). Two startup optimizations are worth knowing about. WARP cuts media and data startup from six round trips to one, and Instant Connect takes the SDP exchange off the critical path, so a client can start a session with a single UDP packet.

The model’s knowledge cutoff is July 31, 2025. For a sense of scale, OpenAI says more than 150 million people a week use ChatGPT’s voice and dictation features.

The two halves

It helps to think of GPT-Live as two pieces that you configure independently:

• The voice model (gpt-live-1) runs the conversation.
• The backend handles reasoning and tools. That can be a Responses model like GPT-6 Astra or GPT-5.6 Terra/Luna, or any model or agent you host yourself.

GPT-Live is also separate from the Realtime API. It only runs on v1/live/sessions and doesn’t support v1/realtime. Realtime (gpt-realtime-2.1) is a different, single-model design that bills per audio token.

Variants

gpt-live-1 is the only model ID in the API. OpenAI’s model page lists it as the default and calls it its “premier model for natural, expressive voice conversations.”

GPT-Live-1 mini exists in ChatGPT, where it’s the default for Free users. I didn’t find it documented anywhere as a separate public API model.

In ChatGPT, users pick between Instant, Medium, and High. A footnote in the launch post explains that Instant and mini both run on GPT-5.5 Instant behind the scenes, while Medium and High run GPT-5.5 Thinking at medium and high reasoning effort. To get the same effect in the API, you change the backend model and reasoning.effort. The voice model ID stays the same.

The backend model will keep changing. ChatGPT launched on GPT-5.5, and OpenAI has said it will swap in newer frontier models as they ship. The API docs already pair gpt-live-1 with GPT-6 Astra or GPT-5.6 Terra/Luna (third-party models work too). OpenAI’s top Tau3 result used Astra at medium effort, and some of the other eval footnotes used Terra at low effort.

Availability

ChatGPT got it on July 8, 2026, globally on iOS, Android, and the web. GPT-Live-1 became the default voice for Go, Plus, and Pro, and mini became the default for Free. It shipped with nine remastered voices. Video and screen sharing weren’t supported at launch, so ChatGPT kept the older voice modes around for those.

The API went GA on September 10, 2026. There’s no free tier, and custom voices have to go through sales.

Features

In ChatGPT

The launch was mostly about making conversation feel natural. The model uses backchannels (“mhmm,” “got it”), can be interrupted, knows when to stay quiet, and slows down when asked. It waits through thinking pauses instead of jumping in, and it’s better at picking out the user’s voice from background noise. When a question needs search or deeper reasoning, it hands that to a frontier model and keeps talking in the meantime.

ChatGPT also shows visual cards for things like weather, stocks, sports, and maps, and voice works with search, memory, images, and file uploads. Voices are limited to the predefined set, partly to prevent impersonation.

On safety, OpenAI ran audio-native and synthetic evals covering self-harm, psychosis and mania, emotional reliance, violence, and sexual content. Real-time safeguards can steer the conversation, add safety messaging, or end higher-risk calls. There are also teen protections, parental controls, and a published system card. Since July 31, 2026, all GPT-Live audio (ChatGPT and API) carries a SynthID watermark, and the API has a way to verify it.

In the API

The API launch post lists:

• Better interruption handling, since one model reasons over incoming and outgoing audio together
• Delegation of reasoning and tool calls to a backend text model
• Tone, pace, and style set through the system prompt
• Handling background noise and managing context quietly, without narrating every step
• More reliable long sessions
• Telephony support for full-duplex phone agents
• Native ASR transcripts and response text
• Good handling of alphanumerics (order numbers, codes)
• Keyword biasing
• Native turn detection, even though the model isn’t turn-based

There are 12 new voices: Quartz, Ripple, Vesper, Willow, Stone, Gleam, Meridian, Bossa, Tempo, Beacon, Delta, and Cinder. Marin and cedar are still available. OpenAI says more voices and languages are coming over the next few months.

Benchmarks

All of these come from OpenAI, and each depends on which backend was paired with the voice model:

• Full Duplex Bench: 30 percentage points better than GPT-Realtime-2.1, mostly from faster turn-taking and better interactive behavior.
• Tau3: ranked first when paired with GPT-6 Astra at medium effort. Tau3 tests spoken customer-service tasks in airline, retail, and telecom settings and scores task success at Pass@1.
• GPQA and BrowseComp: improvements over Advanced Voice Mode, reported with the ChatGPT launch.

Changelog notes

The September 10 changelog entry announces GA, the two delegation modes, and the pricing ($0.05/min billed per second, backend charged separately). Two related deprecations: the Realtime API Beta was removed on May 12, 2026, and whisper-1 and the gpt-4o-transcribe family shut down on February 26, 2027, with gpt-live-transcribe or gpt-transcribe as replacements.

Integration

You set up two things: a short conversation prompt for the voice model (how it should talk and when to delegate), and the backend (detailed instructions, business rules, tools).

Delegation mode

You pick this when you create the session, and you can’t change it afterward. Switching means starting a new session.

• Responses delegation. OpenAI runs the Responses model you choose, feeds it the conversation context, and returns the results. You still execute your own function tools.
• Client delegation. Your app builds the context, runs whatever model or agent you want, and sends the results back.

Transports

• WebRTC for browsers. Media goes over negotiated tracks, and JSON events go over a data channel called oai-events.
• WebSocket for servers. One connection carries both audio (base64 PCM16) and control events.
• SIP for phone calls.
• Sideband WebSocket, which lets a trusted backend attach to a running session to watch and steer it while the audio stays on the primary connection. The attach URL is /v1/live/sessions/{session_id}/attach. Use a standard API key for this, not an ephemeral one.

WebRTC setup

The sequence from the WebRTC guide:

1. Ask for microphone access in response to a user action, then add the tracks to an RTCPeerConnection.
2. Create the oai-events data channel and register its listeners before you create the SDP offer.
3. Set the local description, wait for ICE gathering to finish, and send the offer to your server.
4. Your server posts { session, transport: { type: "webrtc", sdp } } to POST /v1/live/sessions using the project API key.
5. Set the returned SDP answer as the remote description, then wait for session.started before sending anything. Don’t send session.start over the data channel, because the HTTP request already started the session.

The server gets back a 201:

{ "session": { "id": "live_123" }, "transport": { "type": "webrtc", "sdp": "<SDP answer>" } }

Server-side session creation in Node, from the official quickstart:

import OpenAI from "openai";
const client = new OpenAI({ maxRetries: 0 });

const result = await client.live.create({
  session: {
    model: "gpt-live-1",
    instructions:
      "Be concise. Delegate requests needing current information to the backend, which can search the web.",
    delegation: {
      type: "responses",
      responses: {
        model: "gpt-5.6-terra",
        instructions:
          "Use web search when current facts are needed. Return concise, grounded results for a spoken conversation.",
        tools: [{ type: "web_search" }],
        tool_choice: "auto",
      },
    },
  },
  transport: { type: "webrtc", sdp: request.body.sdp },
});
// Return result.session.id and result.transport.sdp to the browser.

In the browser, create the RTCPeerConnection, attach the mic tracks, and call createDataChannel("oai-events"). Add a message listener that watches for session.started (the session is ready) and session.closed (which carries the final event.usage). Then create and set the SDP offer, post it to your own endpoint with fetch("/api/session", { method: "POST", body: JSON.stringify({ sdp }) }), and call setRemoteDescription({ type: "answer", sdp: result.transport.sdp }). To hang up, send { type: "session.close" } and wait for session.closed.

WebSocket setup

From a server, open a WebSocket to the Live endpoint, send session.start, and wait for session.started before doing anything else:

{ "type": "session.start",
  "session": { "model": "gpt-live-1", "instructions": "Be concise.",
    "audio": { "output": { "voice": "marin" } },
    "delegation": { "type": "client" } } }

Authentication

The project API key stays on your server and never reaches the browser. With WebRTC, the browser sends its SDP offer to your server, your server calls OpenAI with the standard key, and then passes the SDP answer back. OpenAI calls this the unified-interface pattern. On that server request, set the OpenAI-Safety-Identifier header to a stable, hashed user ID. Before exposing /api/session publicly, put your own auth, rate limiting, and HTTPS in front of it.

Voices

Set audio.output.voice when you create the session. It can’t be changed later. The default is "marin", and "quartz" or any of the other voices work the same way. A custom voice is passed as an object, { "id": "voice_123" }. Custom voices currently cover English accents, and you should also state the accent in instructions (for example, “Speak British English”). They need sales approval.

Configuring the backend (Responses delegation)

export const session = {
  model: "gpt-live-1",
  delegation: {
    type: "responses",
    responses: {
      model: "gpt-5.6-terra",
      instructions: "[Your backend prompt]",
    },
  },
};

Tools go in delegation.responses.tools, and both function and web_search are supported. You can also set tool_choice (auto, required, none, or a specific tool), parallel_tool_calls, max_output_tokens (minimum 16), service_tier (auto, default, flex, or priority, where priority means Fast mode), and the reasoning and text settings.

You can change delegation.responses mid-session with session.update. Updates are sparse, so any field you leave out keeps its value. Setting delegation to null means client mode, and trying that on a running Responses session fails with immutable_field_update.

Configuring client delegation

export const session = { model: "gpt-live-1", delegation: { type: "client" } };

Closing a session

Send session.close and keep reading until session.closed arrives. That event has the final cumulative usage and the reason the session ended. Then close the peer connection and release the mic. With WebRTC, register the listener for that final event before you send the close. Once the service gets a close request, it stops taking new work, finishes any delegation and output already in progress, and then sends session.closed.

Payloads and events

Endpoints

• POST /v1/live/sessions creates a session. For WebRTC, this is where the SDP offer and answer get exchanged. It returns the session ID and the SDP answer.
• The primary WebSocket connects to the Live endpoint. Send session.start and wait for session.started.
• /v1/live/sessions/{session_id}/attach is the sideband WebSocket.
• GET /v1/live/sessions/{session_id}/content downloads the recording as a stereo WAV, with input on the left channel and output on the right. It only works if you set store: true, and recordings expire after 30 days.
• The Live resource also has methods for forking a session and for telephony (accept, reject, refer, hangup), plus a Fork WebSocket.

Session config

The config object is strict and rejects unknown fields. For WebRTC it goes in as session when you create the session. For WebSocket it goes inside session.start.

{
  "model": "gpt-live-1",
  "instructions": "Answer briefly and ask before taking an external action.",
  "audio": { "output": { "voice": "marin" } },
  "delegation": {
    "type": "responses",
    "responses": {
      "model": "gpt-5.6-terra",
      "instructions": "Use tools when current information is required.",
      "max_output_tokens": 2048,
      "service_tier": "priority",
      "reasoning": { "effort": "medium", "summary": "auto" },
      "text": { "verbosity": "low" },
      "tools": [
        { "type": "web_search" },
        { "type": "function", "name": "get_weather",
          "parameters": { "type": "object",
            "properties": { "location": { "type": "string" } },
            "required": ["location"], "additionalProperties": false } }
      ],
      "tool_choice": "auto",
      "parallel_tool_calls": true
    }
  }
}

A few rules to keep in mind:

• model, instructions, and audio.output.voice are locked once the session starts. To add instructions later, use session.instructions.append.
• After startup, session.update can only change delegation.responses. The delegation object gets replaced as a whole, so you can’t patch individual nested fields. A successful update returns session.updated with the full session resource.

Audio format

Over WebSocket, audio in both directions is raw mono PCM, signed 16-bit little-endian, at 24,000 Hz, base64-encoded. There’s no header, and the byte count has to be even. The format is set at startup and applies to both directions. Changing it means starting a new session.

Over WebRTC, the format is negotiated through SDP. Leave out audio.format, don’t send session.input_audio.append, and don’t expect session.output_audio.delta on the data channel.

Client events

The three append events take a plain-string content field (up to 500 tokens) and a required delegation_id, which is either a client-delegation ID or null for general session context.

Server events

• session.started and session.updated
• session.output_audio.delta (WebSocket). Each chunk has start_ms and end_ms. There’s no “done” event, and gaps between chunks are silence that was left out.
• session.input_transcript.delta and session.output_transcript.delta. These are timed fragments that can interleave, and they don’t mark turn boundaries.
• session.instructions.appended, session.thinking.appended, and session.commentary.appended. These are acknowledgments, which you match up using client_event_id.
• session.input_audio.muted and .unmuted
• session.delegation.created
• response.event, an envelope around nested Responses events. Dispatch on event.event.type, and hold on to the outer delegation_id.
• session.usage.updated, a cumulative snapshot sent roughly once a minute
• session.closed
• error

Some examples:

{ "type": "session.started",
  "session": { "id": "sess_123", "model": "gpt-live-1",
    "audio": { "output": { "voice": "marin" } },
    "delegation": { "type": "client" } } }

{ "type": "session.input_transcript.delta", "delta": "What is the", "start_ms": 600, "end_ms": 800 }

{ "type": "session.delegation.created", "offset_ms": 1000,
  "delegation": { "id": "item_delegation_123", "type": "delegation", "target": "client" } }

{ "type": "session.usage.updated", "usage": { "seconds": 12 },
  "context_window": { "usage_ratio": 0.42 } }

{ "type": "session.closed", "reason": "close_requested", "usage": { "seconds": 128 } }

session.closed.reason can be close_requested, expired, content, remote_hangup, or connection_lost.

Function calls with Responses delegation

Backend events come wrapped like this:

{ "type": "response.event", "event_id": "event_response_1",
  "delegation_id": "item_9tA2cB6n2V8c4X1z7Q5r9",
  "event": { "type": "response.output_text.delta", "sequence_number": 4,
    "item_id": "msg_123", "output_index": 0, "content_index": 0,
    "delta": "The forecast is", "logprobs": [] } }

Completed function calls show up in the nested response.output_item.done event, which includes call_id, name, and arguments. Run the function, send the result back, and tell the backend to continue:

connection.send({ type: "response.item.create", event_id: "tool_result_1",
  item: { type: "function_call_output", call_id: "call_123",
          output: '{"status":"confirmed","order_id":"order_123"}' } });
connection.send({ type: "response.create", event_id: "continue_1" });

Every pending function call needs its own response.item.create result before you send response.create. One gotcha: forwarded lifecycle events like response.completed have empty output and tools fields, so read function calls from the individual output-item events instead.

If the user types something, like an order number, queue it to the backend with response.item.create (type: "message", role: "user", content: [{ type: "input_text", text: "..." }]), then send response.create.

Results with client delegation

connection.send({ type: "session.commentary.append", event_id: "result_123",
  delegation_id: "item_9tA2bF3h7K9m2P5q8R1s4",
  content: "The order shipped today and should arrive tomorrow." });

Which event you use depends on what you want the model to do with the information:

• session.commentary.append for things the model should say out loud. It will paraphrase them.
• session.thinking.append for facts or progress the model should know about and can use later, without saying anything right now.
• session.instructions.append for system-level steering, such as a guardrail redirect with delegation_id: null.

Each one is acknowledged with the matching .appended event. The acknowledgment only means the content has been added to context. It doesn’t mean it has been spoken or played.

Errors

{ "type": "error", "error": {
    "type": "invalid_request_error", "code": "invalid_audio",
    "message": "PCM16 audio must contain an even number of bytes",
    "param": "audio", "client_event_id": "event_audio_1" } }

If an error happens during startup, you won’t get session.started. An error on a command doesn’t necessarily end a running session. error.client_event_id is only included when the error ties back to a specific client command, and param is left out when no single field caused the problem. At the API level, you might see 429 / slow_down if traffic ramps up too fast, or 503 / server_is_overloaded under load. Both can include a Retry-After header.

Usage and billing fields

session.usage.updated and session.closed report total voice time so far in usage.seconds, along with context_window.usage_ratio. These are running totals, so use the latest value instead of adding them up. Backend token usage is tracked separately, in the nested response.completed events inside response.event.

Pricing and limits

Voice. $0.05 a minute, billed per second and not rounded up, so a 30-second call costs about 2.5 cents. The clock runs for the whole active session: user speech, model speech, silence, and time spent waiting on the backend. Muting the mic doesn’t stop it. Use the duration the API reports for your own accounting. Creating a WebRTC session through POST /v1/live/sessions bills 15 seconds up front, which is then credited against the session’s actual duration.

Backend. Billed at the configured model’s normal rates, plus tools. Rates per million tokens (standard short context, September 2026):

The Sol price is promotional and runs through at least November 21, 2026. Hosted web search is billed per call.

For comparison, the Realtime API (gpt-realtime-2.1) charges by audio token: $32 per million input tokens ($0.40 cached) and $64 per million output tokens. The mini version is roughly $10/$20. Double-check all of these on the pricing page before committing to anything.

Concurrency. Limits are counted in concurrent sessions. The free tier isn’t supported. Tier 1 gets 25, Tier 2 gets 50, Tier 3 gets 200, Tier 4 gets 300, and Tier 5 gets 500.

Context window. 128,000 tokens, covering instructions, conversation text, and audio tokens. Once usage passes 90%, GPT-Live compacts in the background and starts a replacement engine inside the same session. The new engine gets your original instructions plus up to 8,192 tokens of recent or summarized history. Older details can get summarized or lost, so anything authoritative should live in your app rather than in the conversation.

Modalities. Text and audio, both in and out. The Live frontend doesn’t accept images or video, so send those to a vision-capable backend. Streaming and function calling work. Structured outputs, fine-tuning, and predicted outputs don’t.

Languages. Tuned for the languages people use most in ChatGPT. Others may come out with a non-native accent or some gaps in fluency.

Telephony and SIP

The docs treat telephony and SIP as a first-class option next to WebRTC and WebSockets, and list LiveKit, Twilio, Telnyx, and Daily/Pipecat as partner integrations. The Live resource has session methods for accept, reject, refer, hangup, fork, and downloading recordings, along with primary, sideband, and fork WebSockets. The general flow: an incoming call hits a project webhook on your server, your server accepts the call and configures the session (model, voice, instructions, delegation), and then it attaches a WebSocket or sideband connection to monitor and steer the call.

What I couldn’t confirm. I wasn’t able to load the official “Telephony and SIP” page or the Live method reference pages, even on a second try. That means I don’t have verified details for the SIP address format, the name of the incoming-call webhook event, or the exact paths and JSON schema for accept, reject, refer, and hangup.

What I do know for sure is that GPT-Live uses its own /v1/live/sessions resource. It isn’t /v1/realtime/calls/..., and it isn’t /v1/live/calls/... either.

For reference, the Realtime API’s SIP flow (a different API) uses sip:$PROJECT_ID@sip.api.openai.com;transport=tls, the realtime.call.incoming webhook, and POST /v1/realtime/calls/{call_id}/accept|reject|refer|hangup with a body like { "type": "realtime", "model": ..., "instructions": ... }. Don’t assume any of that carries over to GPT-Live unchanged. Either check the official guide and method reference first, or let a partner like Twilio, Telnyx, LiveKit, or Daily handle the SIP side.

Best practices and limitations

Keeping costs down

The official cost guide comes down to a few things:

• Close sessions as soon as they’re done. The clock keeps running through silence and backend work, and every minute you save is five cents.
• Match the backend model and reasoning effort to the job. Luna is fine for high-volume scheduling, and Astra can be saved for the hard cases. Use the lowest effort that still gets the task done reliably.
• Keep backend answers short. Leave big payloads and Markdown in the backend and let GPT-Live turn them into speech. There’s no need for a separate model call to rewrite text for speaking.
• Speed up tools. Run independent lookups in parallel, reuse results that are still valid, and take advantage of prompt caching and stable session affinity (Live keeps a persistent connection to Responses and can reuse earlier state).
• For quick checks on transcript fragments, a small model like gpt-5.6-luna at low effort is enough.

Prompting

Speaking behavior (backchannels, interruptions, when to delegate) goes in the live prompt. Business rules go in the backend prompt. Write the prompts and examples in the language your users will speak. Tell GPT-Live to wait for the backend before quoting prices or confirming bookings, and to acknowledge the user while it waits. OpenAI’s prompt template has separate sections for backchannel, interruption, and delegation policy, and that’s a good structure to copy.

Safety and guardrails

The built-in safeguards are only a starting point. On top of them:

• Run your own guardrails on the transcript over a sideband connection, and steer with session.instructions.append when needed.
• Enforce permissions, confirmations, and blocked actions in your application state. Appending an instruction won’t cancel backend work that’s already running.
• Require explicit approval before anything with real consequences, such as writes, payments, or messages sent outside the app.
• Check speech before it plays if your use case needs that.
• Verify both the backend action and the audio. A finished backend response doesn’t mean the user actually heard the result.
• Treat delegation IDs as opaque correlation keys, and keep business identifiers and audit records separate.

Limitations

• No image, video, or screen-share input on the Live frontend. These have to go through the backend.
• Transcripts arrive in fragments and can contain mistakes. They don’t give you reliable turn boundaries, and there’s no “turn completed” event.
• Older context may be summarized or dropped during compaction.
• No free API tier.
• Accent and fluency vary by language.
• No structured outputs, fine-tuning, or predicted outputs.
• Silence and backend wait time are billed as voice time.

Recommended plan

Week 1: prototype. Build the browser demo from the official WebRTC quickstart. The server calls POST /v1/live/sessions (or client.live.create in the SDK) with model: "gpt-live-1", Responses delegation to gpt-5.6-terra with web_search, and a short live prompt. The goal is simply to see session.started, transcripts, and at least one delegated answer come back. Keep the API key on the server and set OpenAI-Safety-Identifier.

Weeks 2 to 4: merchant backend. Because the merchant assistant handles orders and bookings and has business rules to enforce, I’d go with client delegation. That way we control how context gets assembled, can review results before they’re spoken, and can handle idempotency and approval gates ourselves. The flow runs from session.delegation.created to our agent, and then back through session.commentary.append for things the model should say or session.thinking.append for things it should just know. Verified facts, approvals, and idempotency keys belong in app state, not in the transcript. Terra or Luna can handle routine work like order status and scheduling, with Astra reserved for anything that needs real reasoning. If our routing turns out to be simple and we don’t need to check results before they’re spoken, Responses delegation is the easier choice.

Weeks 4 to 6: phone support. If we need phone calls, handle SIP through a partner (Twilio, Telnyx, LiveKit, or Daily) plus the Live accept and attach flow. Before building, read the official Telephony and SIP guide and the method reference to confirm the webhook name and accept endpoint (see section 6). Test what happens with voicemail, greetings, and when a person picks up, and adjust the guardrails and playback controls for the phone audio path.

After that: hardening and scale. Add sideband guardrails, playback verification, a clean shutdown that captures final usage, session forking for resuming conversations after a long gap, and per-second cost tracking from session.usage.updated. Watch concurrency against our tier limit (anywhere from 25 to 500) and ask for a tier increase well before launch.

When to change course:

• If the backend takes more than a second or two to return something useful, lower reasoning.effort or move to a smaller model.
• If turn-taking or interruptions feel worse than a turn-based baseline, revisit the backchannel and interruption sections of the live prompt.
• If the voice bill ends up being the biggest cost, close idle sessions more aggressively.
• If calls regularly go past 90% of the context window, move more state into the app so nothing important is lost in compaction.

Caveats

• “Medium” and “High” are ChatGPT reasoning tiers, not API models. The API only has gpt-live-1, and GPT-Live-1 mini isn’t documented as a separate public API model.
• The backend model changes over time. It was GPT-5.5 at the ChatGPT launch, and the API docs now use GPT-6 Astra and GPT-5.6 Terra/Luna. Check the model catalog before locking anything in.
• The benchmark numbers and customer results all come from OpenAI, and each depends on which backend was used.
• The telephony details in section 6 aren’t fully verified.
• Some lower-level details (audio format, the session.start and attach URLs, session.closed.reason values, error codes) are easiest to find in Microsoft Foundry’s “GPT-Live event API reference,” which mirrors OpenAI’s Live event contract. It describes the same API, but it’s a third-party host, and its base path is /openai/v1/live on a Foundry resource instead of OpenAI’s /v1/live.
• Prices and limits reflect the September 2026 docs. The Sol promo rate and any regional uplift (10% for eligible models released on or after March 5, 2026) could change, so recheck the pricing page.

References

Official OpenAI sources:

• Introducing GPT-Live (ChatGPT launch, Jul 8, 2026)
• Build more natural voice experiences with GPT-Live-1 in the API (Sep 10, 2026)
• How we built a realtime system for responsive voice AI in six months (engineering, Aug 3, 2026)
• Getting started with GPT-Live
• Prompting GPT-Live
• Managing GPT-Live sessions
• Delegation and tools in GPT-Live
• Migrate to GPT-Live
• GPT-Live partner integrations
• WebRTC connection guide
• WebSockets connection guide
• Telephony and SIP
• Server-side controls
• Cost optimization (voice)
• Voice agents (architecture comparison)
• Custom voices
• GPT-Live 1 model page
• API pricing
• API changelog
• GPT-Live system card

Third-party (mirrors the OpenAI Live event contract):

• Microsoft Foundry, GPT-Live event API reference