OpenAI’s transcription update is a small API change with a useful product lesson: file transcription and live transcription should be treated as different workflows, not as one speech-to-text feature with a streaming toggle.
The new guide recommends starting from the shape of the audio. If the application has a completed recording or bounded audio request, use file transcription and start with gpt-transcribe. If the application has a microphone, call, or other live audio stream, use realtime transcription and start with gpt-live-transcribe.
The guide also separates streaming output from live audio. A completed file can stream text while it is processed. A Realtime session is for audio that is arriving live or needs a persistent connection.
What changed
The specialized paths stay explicit:
- speaker-labeled transcripts route to diarization;
- word timestamps, SRT, VTT, and completed-recording translation still point to
whisper-1paths; - detected input languages start with
gpt-transcribe; - committed-turn transcription over WebSocket uses
gpt-transcribeinside realtime transcription.
The context fields are also becoming a first-class API surface. prompt, keywords, and languages help the model with topic, domain terms, product names, acronyms, and multilingual expectations. They are hints about the audio, not extra task instructions.
New Runtime Read
The useful pattern is workflow routing. The model name matters, but the product boundary matters more: bounded audio, live audio, diarization, timestamps, translation, language detection, and committed realtime turns all imply different operating paths.
This is how model APIs become application interfaces. The platform is not only offering a better speech model. It is teaching developers to choose the right runtime path for the user’s audio state.