The Live API lands in the OpenAI SDK: gpt-live-1, dual WebRTC/WebSocket channels, and SIP call control

On the evening of 2026-09-10, OpenAI's two official SDKs shipped another matched pair of feature releases: openai-python v3.12.0 (17:28 UTC) and openai-node v7.14.0 (17:29 UTC), with the same line under Features — "Add Live API". The release writes an entirely new real-time session interface into both packages: a client.live namespace anchored on /live/sessions, with WebRTC and WebSocket access channels, a full set of SIP-semantics call-control endpoints, and a never-before-seen model literal, gpt-live-1.

This article follows the same discipline as our previous SDK-intel pieces: we only state what can be pointed to, verbatim, in the SDK source. Every citation comes from same-day (2026-09-11) re-fetches of GitHub release notes and the v3.12.0 / v3.13.0 tag sources (see officialReferences at the end); the official OpenAI docs domain returned 403 to us that day, so anything about official announcement status is date-anchored and never asserted beyond what was checked.

1. Overview: what this release confirms

The Live API is a real-time session interface that appeared in the official OpenAI SDK type layer on 2026-09-10, spanning four capability areas:

For the ❓ row we do not speculate. SDK types are auto-generated (the header comment reads "generated from our OpenAPI spec") — that proves the spec contains it, not that the service is open to you.

2. First-appearance check: the previous tag really did not have it

Following our "first appearance must be checked against the previous tag" rule, we compared GitHub tag trees on 2026-09-11:

• The openai-python v3.11.0 tree contains no resources/live path and no types/live directory; both appear in v3.12.0
• The openai-node v7.13.0 tree contains no src/resources/live; it appears in v7.14.0 (live.ts plus a live/ directory)
• The v3.11.0 ChatModel enum contains no gpt-live string at all; gpt-6-astra was already present (landed 2026-09-03)

One leading signal is worth recording: v3.11.0 already contained types/webhooks/live_call_incoming_webhook_event.py — the "incoming call" webhook type appeared one step before the Live resource surface. Type rollouts for new APIs evidently arrive in batches, and watching the webhooks directory can surface signals earlier than watching resources.

3. Two access channels: WebRTC for session setup, WebSocket for direct connection

3.1 WebRTC: POST /live/sessions

client.live.create() maps to POST /live/sessions, with parameters (LiveCreateParams):

class LiveCreateParams(TypedDict, total=False):
    session: Required[MediaSessionConfigParam]   # startup configuration
    transport: Required[Transport]               # WebRTC transport

class Transport(TypedDict, total=False):
    sdp: Required[str]                    # SDP message for the WebRTC connection
    type: Required[Literal["webrtc"]]     # SDK notes: Always webrtc

The LiveCreateResponse class docstring spells out the handshake: apply transport.sdp as the peer's remote answer, then wait for session.started on the data channel before sending commands. The returned session.id is the handle for every control endpoint; the SDK explicitly warns to "preserve the returned value unchanged, including its prefix."

from openai import OpenAI

client = OpenAI()

resp = client.live.create(
    session={"model": "gpt-live-1", "instructions": "..."},  # startup config
    transport={"type": "webrtc", "sdp": local_offer},        # browser-side SDP offer
)
print(resp.session.id)      # session ID for accept/fork/recording endpoints
print(resp.transport.sdp)   # SDP answer; set as the remote answer

(Source-verified code: fields cross-checked against v3.13.0 LiveCreateParams; not executed against a live key.)

3.2 WebSocket: client.live.connect()

connect() opens a WebSocket with no query parameters (the SDK rewrites the base URL to the ws scheme and appends /live/sessions) and returns a LiveConnectionManager. The docstring's ordering rule: send session.start with the model and session configuration first, then wait for session.started. The connection manager carries built-in reconnect parameters (defaults max_retries=5, initial_delay=0.5, max_delay=8.0) — a real-time-voice necessity that the SDK now bakes into the type layer.

4. SIP call control: accept / reject / hangup / refer

Four of the six sessions-subresource endpoints carry explicit SIP semantics in their docstrings (paraphrased below; the quoted originals match verbatim):

Together with the pre-existing live.call.incoming webhook (a webhook event already present in v3.11.0; the literal verified in its type file), this endpoint set points at inbound telephony: your backend receives the webhook, decides accept or reject, and can refer the caller onward mid-call. The scenario overlaps with the Realtime phone-support patterns we covered in Realtime Voice Agents in production: phone support and voice assistants with Realtime API + function calling — but the type layer says nothing about Live replacing Realtime; in v3.13.0 the two resource surfaces coexist, and architecture decisions should follow official announcements.

The remaining two endpoints:

• fork: POST /live/sessions/{id}/fork — fork a stored Live session onto a new WebRTC connection; transport carries the new connection's SDP offer, and the session override may be omitted (omitting or sending an empty object inherits the stored session's settings). A forks subresource offers a WebSocket variant, forks.connect(), whose docstring notes "The model is inherited."
• download_recording: GET /live/sessions/{id}/content — fetch the content of a session started with storage enabled; the SDK requires the session ID returned when that session started.

The sideband subresource provides attach (attach to an existing Live session over its own WebSocket connection) — typed for a side-channel observer/controller, e.g. audio on the main connection and monitoring on the sideband.

5. gpt-live-1: a model literal that exists only in the session config

The session-config type (types/live/session_config.py) defines the model field as:

model: Union[str, Literal["gpt-live-1"]]

Two boundaries matter:

1. It is not in the ChatModel enum. In v3.13.0 the enum is still led by gpt-6-astra, followed by gpt-5.6-sol / terra / luna (checked 2026-09-11). gpt-6-astra at least entered the enum; gpt-live-1 did not even do that — it hangs only off the Live session config, which carries strictly less information.
2. The type layer says nothing about its pricing, capabilities, or context window. The live prefix matches gpt-live-transcribe from the 2026-08-26 transcription-migration announcement, but the two are different IDs and the SDK contains no comment linking them — no inference.

The announced voice flagship remains GPT-Realtime-2.1 (released 2026-07-06); whether gpt-live-1 relates to it or represents a next-generation voice model is unknown as of 2026-09-11.

6. The event model and helper library

The types/live directory defines a full bidirectional event vocabulary (ClientEvent / ServerEvent families). The event names (type literals, verified file-by-file on 2026-09-11) share a session. prefix:

• Session lifecycle: session.start / session.started, session.update / session.updated, session.close
• Audio: session.input_audio.append, session.input_audio.mute / session.input_audio.muted, session.output_audio.delta
• Generation: session.instructions.append / session.instructions.appended, session.commentary.append, session.thinking.append, response.create, session.usage.updated, session.delegation.created, error
• Transport and telephony (server events): transport.ringing, transport.answered, transport.dtmf.received, transport.dtmf.send, transport.failed, call_error — the ringing / answered / DTMF group re-confirms the SIP semantics of section 4

The companion openai.lib.live helper library ships a transcript grouper (aggregating incremental delta events into readable segments) and listeners utilities, with two examples in the repo (audio_transcript.py, transcript_grouper.py). The "events plus grouper" combination addresses a known pain point from the Realtime era — incremental transcription streams previously required client-side aggregation, and the SDK now bundles a reference implementation.

7. Common mistakes and troubleshooting

• Treating an SDK surface as general availability: client.live existing does not mean the Live API is GA. Whether it is usable, and by which projects, is decided by the official changelog and docs; as of 2026-09-11 the docs domain returns 403 to us and could not be checked.
• Hard-coding gpt-live-1 in production: an unannounced model literal can change at any time. Experiment behind a feature flag and handle model_not_found-style errors.
• Passing audio.format on accept: the SDK is explicit that SIP media formats are negotiated and accept should omit audio.format — copying the create-path audio config breaks under negotiation semantics.
• Forgetting the reject status code: status_code is required and must be 300-699 (SIP semantics); values like 200 do not pass the type layer.
• Betting the architecture on Live-vs-Realtime either/or: both surfaces coexist with no official positioning statement. Existing Realtime pipelines (GPT-Realtime-2.1) remain the announced solution; do not start a migration because a new surface appeared.

8. Next steps

• Realtime Voice guide: gpt-realtime and Voice Mode: the full mechanics of the current announced voice flagship — the baseline to understand before judging the Live API.
• The Agents API appears in the OpenAI SDK (beta): /agents CRUD, environments, sessions, and vaults: the other brand-new API surface that landed the same evening (19:37 UTC).
• gpt-6-astra appears in the OpenAI SDK: the new ChatModel ID and the Safety Alerts API: the 09-03 batch that established the method and boundaries this article follows.
• openai-python 3.9/3.10 and openai-node 7.11/7.12: Prompt Cache Diagnostics, API Key Expiry, GPT Image 2.5: the six SDK releases from the previous two days, including the version table that now covers v3.12.0 / v3.13.0.
• OpenAI Models Release Notes (2026, Living Document): the timeline view — an official Live API announcement, if it happens, will be tracked there.