GPT-Live API: Availability and Prep

I would not plan a launch around the GPT-Live API today. Not with that name.

OpenAI’s Help Center confirms a ChatGPT “Live” voice experience powered by GPT-Live-1 on paid plans and GPT-Live-1 mini on Free. That is a ChatGPT product surface. It is not the same thing as developer API access.

The public API docs I checked list Realtime API models such as gpt-realtime-2.1, gpt-realtime-2.1-mini, gpt-realtime-translate, and gpt-realtime-whisper. I did not find a public GPT-Live-1 API model entry.

That distinction is the whole note.

Current GPT-Live API Status

The current status is split.

ChatGPT has a Live voice experience. Developers have the Realtime API. They may be related behind the curtain. That does not make them the same product contract.

ChatGPT voice experience versus developer API access

The ChatGPT Voice Help Center page says Live is powered by GPT-Live-1 on paid plans and GPT-Live-1 mini on Free. It also says Live is designed for natural back-and-forth conversation, can use web search and memory, and can work with text and images in the same chat.

That is useful if you are evaluating the ChatGPT experience.

It does not give developers a model ID, endpoint, SDK behavior, rate limit, pricing row, or enterprise API control. I paused here because this is exactly where internal docs usually get sloppy. Someone writes “GPT-Live is available,” and two weeks later engineering discovers the API name is different.

The OpenAI Realtime and audio guide is the developer source to use. It says realtime sessions are best for live audio that needs low latency, while request-based audio APIs fit files, bounded requests, or generated speech that does not need a live session.

Different surface. Different evidence.

What is confirmed, reported, or still unavailable

Confirmed: ChatGPT Live exists as a user-facing voice mode. Confirmed: OpenAI has a documented Realtime API for low-latency voice agents. Confirmed: the API model catalog lists realtime models, not GPT-Live model IDs.

Still unavailable in the public API docs I checked: a documented gpt-live-1 or gpt-live-1-mini developer model ID, a public GPT Live developer API guide, and pricing for GPT-Live-branded API usage.

Here is the status map I would keep internally:

Claim	Status	Acceptable source
ChatGPT Live uses GPT-Live-1 / mini	Confirmed for ChatGPT	OpenAI Help Center
Developers can build realtime voice agents	Confirmed	OpenAI Realtime API docs
GPT-Live-1 API is publicly available	Not confirmed	Needs API docs or official OpenAI announcement
GPT-Live API pricing exists	Not confirmed	Needs OpenAI pricing page
gpt-realtime-2.1 is an API model	Confirmed	OpenAI model catalog

The OpenAI models page lists GPT-Realtime-2.1, GPT-Realtime-2.1 mini, GPT-Realtime-Translate, GPT-Realtime-1.5, GPT-Realtime mini, and GPT-Realtime-Whisper under realtime and audio models. It does not list GPT-Live.

This is where my data ends.

What Developers Can Prepare Now

You can prepare the voice-agent architecture without pretending the GPT-Live API is open.

That means building against abstractions: audio transport, event schema, session state, interruption handling, tool execution, confirmation flows, and fallback models. Boring pieces. The ones that save launches.

Audio streaming, session state, cancellation, and interruption handling

Start with transport. OpenAI’s Realtime docs describe WebRTC for browser and mobile clients that capture or play audio directly, and WebSocket for server media pipelines, call systems, or workers. The WebRTC guide shows /v1/realtime/calls and gpt-realtime-2.1 in the session config.

That is enough to build a test harness.

Do not hard-code the model name everywhere. Put it behind a provider adapter. Store the session events in a normalized format. Keep cancellation separate from “end call.” Keep interruption separate from “new user turn.” These distinctions look fussy until a caller talks over the model and the agent finishes the old answer anyway.

Speed isn’t the goal. Not breaking flow is.

A realtime voice model has to handle partial input, output audio, transcript drift, barge-in, silence, background sound, and network wobble. A text-first agent can fail politely. A voice agent fails in the user’s ear.

Tool calling, user confirmation, safety, and fallback paths

Voice agents become risky when they can act.

The Realtime docs describe voice-agent sessions as sessions where the model can respond, call tools, and manage conversation state. The Realtime with tools guide covers connecting tools, MCP servers, and connectors to a realtime session.

That does not remove your responsibility. The model proposes tool use. Your application validates it.

For anything sensitive, keep a confirmation step outside the model’s spoken confidence. Payments, account changes, cancellations, address edits, medical triage, financial actions, legal workflows, and identity verification need explicit confirmation.

I would also build a fallback path from day one: realtime voice to text chat, realtime model to text-first model plus TTS, API outage to human handoff, tool failure to a safe spoken explanation.

Good enough. That’s the most honest assessment I can give.

What Must Be Verified Before Integration

Before integration means before public roadmap, not just before code freeze.

A prototype can use a placeholder. A customer-facing commitment cannot.

Model ID, SDK support, pricing, rate limits, and availability

For GPT-Live API planning, verify five things from official OpenAI sources:

Exact model ID.
Supported endpoint.
SDK support and event shape.
Pricing.
Rate limits and regional availability.

The OpenAI pricing page lists realtime pricing for gpt-realtime-2.1, gpt-realtime-2.1-mini, gpt-realtime-translate, and gpt-realtime-whisper. It does not show GPT-Live pricing in the section I checked.

That is the answer. Not “coming soon.” Not “probably the same.” Just not confirmed.

If a salesperson, partner note, or media article mentions GPT-Live-1 API access, save it under “reported,” not “confirmed.” Customer-facing copy should point to docs, model catalog, pricing, or an official OpenAI announcement.

Data retention, recording, and enterprise controls

Voice data has more surface area than text. It can include identity signals, background voices, location clues, health context, and emotion. Treat it accordingly.

OpenAI’s data controls guide explains API data categories such as abuse monitoring logs and application state. It also describes Zero Data Retention and notes endpoint-specific behavior, including cases where audio output application state may be stored briefly to enable multi-turn conversations.

ChatGPT Voice has separate user-product rules. The Help Center says Live and Advanced Voice audio clips are retained with chat history for 30 days, while Standard audio is deleted after transcription unless the user has opted to share audio. That is ChatGPT behavior. Do not copy it into API documentation unless the API docs say the same thing.

I don’t know. Better than making something up.

Migration Paths if API Opens Later

The safest migration plan is an adapter.

Your app should not care whether the backend model is gpt-realtime-2.1, a future GPT-Live-branded model, or a text-first fallback with speech output. Your app should care about events: user audio started, user audio committed, assistant audio started, assistant interrupted, tool requested, confirmation required, response completed, session ended.

Adapter layer, event schema, observability, and testing fixtures

Define a local voice-agent interface now. Keep the provider-specific Realtime events behind it. Store raw provider events for debugging, but expose normalized events to the product.

Build fixtures from real calls. Include noisy rooms, slow speakers, overlapping speech, tool failures, long pauses, and users changing their mind mid-sentence. The pretty demo call is not the test case. It is the one that makes everyone overconfident.

Keep observability boring:

Audio in/out timing.
First response latency.
Interruption timing.
Tool call attempts.
Tool confirmations.
Cancellation events.
Fallback triggers.
Transcript mismatch reports.

If GPT-Live later opens as a documented developer API, the migration should be a model and adapter change. Not a rewrite.

FAQ

Who maintains the internal GPT-Live availability watchlist?

Product operations should own the watchlist. Engineering should own technical verification. Legal or security should own public-claim review.

The watchlist should track official OpenAI docs, model catalog entries, pricing, SDK changelogs, API reference pages, and account-level availability. One owner. One update date. No “someone saw it on X” as evidence.

What source is acceptable for customer-facing API claims?

Use official OpenAI API docs, model catalog, pricing pages, Help Center pages when discussing ChatGPT behavior, or written OpenAI account communication that your team is allowed to cite.

For API claims, the strongest sources are API docs and pricing/model pages. Help Center pages are acceptable for ChatGPT product behavior, not developer API promises.

When should teams remove GPT-Live from launch planning?

Remove it when the launch depends on an undocumented model ID, an unavailable endpoint, unknown pricing, missing rate limits, or unconfirmed regional access.

Keep it as a watch item if the product can launch on the documented OpenAI voice API path. Remove it as a dependency if the plan specifically requires GPT-Live-1 or GPT-Live-1 mini through API access.

Conclusion

The GPT-Live API is not publicly confirmed under that name in the OpenAI API docs I checked. ChatGPT Live is real. GPT-Live-1 and GPT-Live-1 mini are documented for ChatGPT Voice. Developer access is currently documented through the Realtime API and realtime model IDs such as gpt-realtime-2.1.

That is enough to prepare. It is not enough to promise.

Previous posts: