OpenAI Splits Transcription Into Four Model IDs: The Routing Decision Every Audio Pipeline Needs

OpenAI launched two new speech-to-text models on July 28 — gpt-transcribe and gpt-live-transcribe — and immediately made them the recommended defaults for all new transcription work. What looks like a model update is actually a routing architecture change: OpenAI has split transcription into a matrix of four model IDs, each covering a different capability set, and two of those capabilities no longer exist in the new defaults at all.

If your audio pipeline was built around gpt-4o-transcribe, your code still works today — but the routing table you're relying on has been replaced.

What changed and what each model ID now covers

Before July 28, gpt-4o-transcribe was the recommended model for all transcription work — file uploads, streaming, and realtime audio. It accepted the /v1/audio/transcriptions endpoint and covered most use cases from a single model name.

The new model matrix:

The routing consequence: you now need to know the capability you want before you pick a model. The old gpt-4o-transcribe let you request features and the endpoint handled them. The new architecture puts each capability in a distinct model ID.

The endpoint split is the breaking change

gpt-live-transcribe does not support v1/audio/transcriptions. It only works through v1/realtime/transcription_sessions — OpenAI's WebSocket-based Realtime API. If your pipeline opens a file, uploads it, and expects a transcript back synchronously, gpt-live-transcribe will not serve that request.

Conversely, gpt-transcribe does not support the Realtime endpoint. It is a request-response model: send a file, get text back. It does work in the Realtime endpoint for one specific sub-case — transcribing committed turns (what the user already said in a voice session) — but live streaming transcript deltas require gpt-live-transcribe.

This matters for operators building voice agents. If you are running a WebSocket voice session and need partial transcripts while the user is still speaking, you need gpt-live-transcribe on the Realtime endpoint. If you only need to read back what the user said after each turn, gpt-transcribe on the Realtime transcription endpoint is cheaper and sufficient.

Pricing gap: 3.8x between file and live

gpt-transcribe costs $0.0045 per minute of audio. gpt-live-transcribe costs $0.017 per minute — roughly 3.8× more expensive for the same underlying speech content.

The premium is for latency: gpt-live-transcribe streams partial transcripts as they arrive, keeping connection state across the audio session. If your use case does not require partial transcripts before a speaker finishes — if you just need an accurate transcript of what was said, at the end — gpt-transcribe is the correct routing decision at a significant cost reduction.

For operators running call center analytics, meeting recorders, or podcast transcription pipelines: those workloads almost never need streaming partials. The work happens after the audio is captured. Every one of those pipelines should route to gpt-transcribe, not gpt-live-transcribe.

What whisper-1 still owns

Neither new model supports word-level timestamps, SRT output, VTT subtitles, or audio translation into English. Those capabilities remain exclusively on whisper-1. If you are building subtitle pipelines, captioning workflows, or any output that requires a timestamp per word, the new models are not a migration target.

This is the most common mistake to check in an existing integration: teams that were using gpt-4o-transcribe with timestamp_granularities: ["word"] or response_format: "srt" will need to keep whisper-1 for those calls, not upgrade to gpt-transcribe.

The context parameters are new and improve accuracy

gpt-transcribe and gpt-live-transcribe add two parameters that were not available on gpt-4o-transcribe:

• keywords: an array of terms the model should prefer when the audio is ambiguous — model names, product SKUs, proper nouns, technical jargon
• languages: a list of language codes to hint expected input language; the model can handle code-switching within a clip

The prompt field continues to work as an unstructured context string. The new keywords parameter is structured and carries more weight for specific terms. For domain-specific audio — customer support calls mentioning product IDs, engineering meetings using API names — the keywords array is worth adding to existing integrations even before any other migration work.

Migration path from gpt-4o-transcribe

For most file transcription work:

# Before
transcription = client.audio.transcriptions.create(
    model="gpt-4o-transcribe",
    file=audio_file
)

# After
transcription = client.audio.transcriptions.create(
    model="gpt-transcribe",
    file=audio_file,
    keywords=["your-domain-terms"]  # new, improves accuracy
)

For live audio streams, the endpoint itself changes:

# gpt-live-transcribe requires v1/realtime/transcription_sessions
# Not v1/audio/transcriptions — these are distinct WebSocket sessions

Teams that hardcode the endpoint URL (not just the model name) need to verify that their endpoint matches the model. Sending gpt-live-transcribe to /v1/audio/transcriptions will fail; sending gpt-transcribe to /v1/realtime for streaming transcripts will return committed-turn results only, not partial deltas.

What routing teams should watch

The GPT Transcribe launch signals that OpenAI is treating audio as a capability cluster rather than a single model. Expect this matrix to grow — speaker diarization is already in a separate model (gpt-4o-transcribe-diarize), and translation remains in whisper-1. Planning a voice pipeline today means planning a routing policy across multiple model IDs, not a single alias.

For teams routing to OpenAI through an AI gateway, the model-to-endpoint mapping needs to be verified. A proxy that accepts any model name and forwards it to a fixed /v1/audio/transcriptions endpoint will silently mis-route gpt-live-transcribe requests. Operator-level routing rules for audio endpoints are now distinct from text completion routing.