Choosing a Transcription API by Latency, Output Contract, and Cost

I start with one question when choosing a transcription route: does the application need text before the speaker finishes? That separates gpt-transcribe from gpt-live-transcribe more usefully than an accuracy headline.

OpenAI introduced both models on July 29, 2026. gpt-transcribe handles completed recordings and committed audio turns; gpt-live-transcribe produces low-latency updates while audio arrives. Neither eliminates the need for specialized Whisper or GPT-4o transcription workflows.

Treat These as Different Input Pipelines

Decision	gpt-transcribe	gpt-live-transcribe
Input workflow	Uploaded file or committed Realtime turn	Continuous microphone, call, or media stream
Transport	File upload; optional streamed response; WebSocket for committed turns	WebSocket for server pipelines, WebRTC for browser audio
Transcription starts	After submission or turn commitment	While audio arrives
Context controls	prompt, keywords, languages	prompt, keywords, languages, delay
Detected languages	Returned when prediction is reliable	Not returned
Base price	$0.0045/audio minute; $0.27/hour	$0.017/minute; $1.02/hour

Both routes can emit partial text. The distinction is what triggers processing: streaming a response from an uploaded recording is not continuous microphone ingestion. I would use file transcription for post-meeting notes, interviews, asynchronous jobs, and backfills. Live captions, agent assistance, moderation, and interactive features justify evaluating the live route.

There is also a middle option: gpt-transcribe inside a Realtime transcription session over WebSocket. Processing starts after a turn is committed, earlier transcribed turns can provide context, and completed events can include detected languages. That is useful for turn-based applications that do not need text during speech.

Implement the File Route First

The file transcription guide documents /v1/audio/transcriptions, a 25 MB upload limit, and accepted formats: mp3, mp4, mpeg, mpga, m4a, wav, and webm. A complete Python request looks like this:

from openai import OpenAI
client = OpenAI()
with open("support-call.wav", "rb") as audio_file:
    transcript = client.audio.transcriptions.create(
        model="gpt-transcribe", file=audio_file,
        prompt="A support call about a premium plan and account AC-42.",
        extra_body={"keywords": ["premium plan", "AC-42", "billing"], "languages": ["en"]},
    )
print(transcript.text)

Set stream=True to receive transcript deltas during file processing. For a Whisper migration, replace model="whisper-1" and singular language="en" with the new model and languages array. A multilingual request can use "languages": ["en", "fr"]; response_format="json" is another explicit option. Do not assume existing text, verbose_json, srt, or vtt response handling transfers unchanged.

Wire Live Audio Around Item IDs

For arriving audio, create a Realtime session with type: "transcription" and select gpt-live-transcribe. Session creation uses the Realtime transcription-session route; the following is a session-update event, not a complete connection implementation:

{
  "type": "session.update",
  "session": {
    "type": "transcription",
    "audio": {"input": {
      "format": {"type": "audio/pcm", "rate": 24000},
      "transcription": {
        "model": "gpt-live-transcribe",
        "prompt": "A support call about a premium plan and account AC-42.",
        "keywords": ["premium plan", "AC-42", "billing"],
        "languages": ["en"], "delay": "low"
      },
      "turn_detection": null
    }}
  }
}

Send chunks with input_audio_buffer.append. With the manual turn configuration above, commit through input_audio_buffer.commit; alternatively, configure server-side voice activity detection. The Realtime transcription guide specifies conversation.item.input_audio_transcription.delta for incremental text and conversation.item.input_audio_transcription.completed for the committed item. Completions across turns can arrive out of order. I would reconcile by item_id, never by arrival order.

Context Is Input, Not a Guarantee

Both models accept prompts describing the recording, domain, speaker, or topic, plus literal keyword hints and expected languages. These controls can help with names, numbers, acronyms, product terminology, accented speech, multilingual audio, and code-switching. They can also bias results: test whether supplied terms appear when nobody said them.

For these models, languages replaces language; never send both. Unsupported or incorrectly formatted language codes cause rejection. Each keyword must be a single-line literal without <, >, carriage returns, or line feeds, otherwise the request or session update is rejected.

The live model supports minimal, low, medium, high, and xhigh delay settings. Lower settings favor earlier partial text; higher settings provide more acoustic context and may improve quality. These are not promised millisecond budgets. I would measure first-delta and final-transcript latency across representative microphones, codecs, networks, languages, and session lengths.

Price the Requirement, Then the Workflow

The published pricing makes live transcription about 3.8 times as expensive per audio minute. At 100 hours/month, file transcription costs $27 versus $102 live, a $75 difference. At 1,000 hours, it is $270 versus $1,020, a $750 difference; at 10,000 hours, $2,700 versus $10,200, a $7,500 difference.

Those estimates are simply audio hours × 60 × the per-minute rate. They exclude storage, transport, retries, hosting, post-processing, human correction, and fallback providers. Batch work benefits from the stated $0.0045 rate versus Whisper's $0.006, but I would still track cost per accepted transcript, not just billed minutes. A two-route design can use live transcription for the interface and file transcription for post-call processing or backfills.

GPT-Realtime-Whisper and gpt-live-transcribe have the same published $0.017/minute base rate. That migration is a quality, latency, event-handling, and compatibility decision, not a list-price saving. For comparisons through a unified multi-model API such as CometAPI, check current route availability and pricing, pin exact model IDs, and collect the same telemetry across providers.

Read the Benchmarks Narrowly

OpenAI's launch announcement reports Context Aware ASR semantic accuracy of 44.6% with free-form context versus 38.5% without, an improvement of 6.1 percentage points. On Common Voice across 22 languages, gpt-live-transcribe recorded 19.70% transcription error versus 20.33% for GPT-Realtime-Whisper-1: 0.63 points lower, about 3.1% relative. On Real-World Audio Recording across nine languages, the result was 9.60% versus 11.65%: 2.05 points lower, about 17.6% relative.

That supports a limited conclusion: the live model did better on those vendor-reported tests, and context improved the reported semantic-accuracy score. It does not establish the same gains for a particular telephony codec, language, vocabulary, microphone, delay setting, or correction policy.

Preserve Specialized Output Routes

I would inventory downstream fields before changing a model ID. gpt-live-transcribe does not return word-level timestamps, speaker labels, or confidence scores. The new models do not replace Whisper's timestamp, subtitle, and English-translation workflows. Use whisper-1 with timestamp_granularities[] for word or segment timestamps, and /v1/audio/translations with whisper-1 for translating completed non-English audio into English.

For speaker labels on completed recordings, use gpt-4o-transcribe-diarize with diarized_json through the file Transcriptions API. Realtime transcription sessions do not support speaker labeling. Recordings longer than 30 seconds require chunking_strategy set to "auto" or a voice-activity-detection configuration. Existing Whisper and GPT-4o transcription integrations continue to work; the new default routes do not remove those feature dependencies.

Make Migration an Evaluation, Not a Rename

The official migration cookbook is a useful implementation reference. For live migration, retain the Realtime/WebSocket architecture and delta/completed handling, update the model and language fields, then evaluate optional prompts, keywords, and delay. Keep audio format, turn-detection policy, test set, and latency target constant when comparing against GPT-Realtime-Whisper.

My evaluation would start with at least 50 licensed recordings covering real use cases, languages, devices, and conditions. Include accents, interruptions, noise, code-switching, short utterances, numbers, dates, currency, email addresses, and domain terms. Run files with and without context; replay live samples at three delay settings, including low, medium, and high, with consistent formats, turn boundaries, prompts, and scoring.

Measure transcription error, domain-term recall, partial-text revisions, p50/p95 latency, failures, retries, human correction time, and accepted-transcript rate. Log audio duration, delay level, first-delta latency, and final-transcript latency. Then shadow test, canary a small traffic share, and retain a fallback. My default is file transcription for completed audio and live transcription only where immediate text is a product requirement, subject to the output contract and the cost of producing an accepted transcript.

---

Originally published at cometapi.com