GPT Transcribe Explained: OpenAI Speech-to-Text for Accurate Audio

GPT Transcribe is OpenAI’s recommended speech-to-text model for turning completed recordings into text in their original language. It is designed for uploaded audio files, streamed transcription results from completed files, and committed audio turns in Realtime WebSocket sessions. That scope makes it useful for meetings, interviews, podcasts, support calls, research recordings, and any product that needs searchable text from speech.

The important detail is the exact model name: gpt-transcribe. It is not merely shorthand for gpt-4o-transcribe, and it is not a general ChatGPT model that happens to accept an MP3. OpenAI documents it as a dedicated, high-accuracy transcription model with audio and text inputs, text output, contextual hints, multilingual guidance, language detection, and streaming support. This guide explains what those capabilities mean in practice—and where a different model is still the right choice.

Sources and product details were reviewed on July 30, 2026. Recheck model availability, pricing, limits, and data controls before moving production traffic.

Key takeaways

• Start with gpt-transcribe for a completed recording that should remain in its original language.
• Send files to POST /v1/audio/transcriptions; the response contains transcript text and any languages the model can reliably detect.
• Use prompt, keywords, and languages as relevant context, not as instructions to invent content.
• Streaming a completed file’s transcript is not the same as continuously transcribing a live microphone.
• Keep specialized routes for speaker labels, word timestamps, subtitle files, and translation into English.
• Evaluate names, numbers, omissions, code-switching, latency, and false insertions on your own audio before deployment.

What is GPT Transcribe?

GPT Transcribe is an automatic speech recognition model. Its core job is narrower than that of a conversational model: receive spoken audio plus optional textual context and return a written transcript. The official GPT Transcribe model card lists audio and text as input modalities, text as the output modality, and both transcription and Realtime transcription as supported endpoints.

The “GPT” name matters because the interface can use language context that a traditional acoustic pipeline might treat separately. A request can describe the recording, list literal terms likely to appear, and identify multiple expected languages. However, OpenAI has not published a detailed architecture or training recipe on the model card. Claims about an internal parameter count, dataset size, decoder design, or universal accuracy would therefore be speculation.

The practical definition is more useful:

GPT Transcribe is a context-aware speech-to-text model for accurate file transcription and committed audio turns, with a JSON-first output and detected-language metadata.

That definition also prevents a common naming error. gpt-transcribe, gpt-4o-transcribe, gpt-4o-mini-transcribe, gpt-4o-transcribe-diarize, gpt-live-transcribe, and whisper-1 are separate model choices. They overlap, but their best workflows and supported outputs are not identical.

Where it fits in OpenAI’s speech-to-text stack

OpenAI’s current documentation recommends starting with the model that matches the audio lifecycle and required output. The decision is not simply “new model versus old model.”

This distinction is easy to miss because “streaming” describes two different things. A completed file can already exist on disk while the API streams partial transcript events back to the application. Live transcription is different: microphone or call audio is still arriving, and the system must manage an ongoing Realtime session. OpenAI’s Whisper-to-GPT migration guide explicitly advises teams to treat live audio and streaming output as separate decisions.

For a concise browser-oriented description of the model and its practical limits, the GPT Transcribe model overview is a useful companion to the API documentation.

How /v1/audio/transcriptions works

For a completed file, the integration remains deliberately simple. The application opens the audio file, sends it as multipart form data, selects gpt-transcribe, and receives JSON.

curl --request POST \
  --url https://api.openai.com/v1/audio/transcriptions \
  --header "Authorization: Bearer $OPENAI_API_KEY" \
  --header "Content-Type: multipart/form-data" \
  --form file=@/path/to/meeting.mp3 \
  --form model=gpt-transcribe

A successful response can include both text and detected languages:

{
  "text": "Bonjour, can everyone see the AC-42 billing record?",
  "languages": [{ "code": "fr" }, { "code": "en" }]
}

Language detection is probabilistic metadata, not a required echo of the hints supplied by the caller. An empty languages array is valid when the model cannot make a reliable prediction; it does not by itself mean the audio was silent or the request failed.

OpenAI’s speech-to-text guide currently caps a Transcriptions API upload at 25 MB and summarizes support for MP3, MP4, MPEG, MPGA, M4A, WAV, and WebM. The current endpoint reference additionally lists FLAC and OGG. Because guide summaries and endpoint schemas can evolve at different times, check the Create transcription API reference when implementing validation rather than copying a static format list into a permanent product promise.

Context is the model’s most important control surface

Real recordings are full of words that are easy to mishear but expensive to get wrong: customer IDs, drug names, model numbers, people, organizations, acronyms, and mixed-language phrases. GPT Transcribe separates three types of context.

prompt: describe the recording

A prompt is free-form context about the setting or subject. A useful prompt might say:

A customer support call about enterprise billing and an account migration.
Preserve filler words because the transcript will be used for conversation research.

This tells the model what linguistic neighborhood it is operating in. It can also state formatting preferences or carry context from the preceding chunk of a long recording. It should not contain a fabricated transcript or ask the model to summarize; transcription and post-processing are separate tasks.

keywords: supply literal terms

Keywords are words or phrases that may actually appear in the recording:

["AC-42", "Premium Plus", "ZyntriQix", "SOC 2"]

They are hints, not required output. This distinction is operationally important. A terminology list can improve recall, but an irrelevant or oversized list can bias recognition toward a word that was never spoken. OpenAI recommends evaluating keyword hallucination explicitly: the transcript should contain a keyword only when the audio supports it.

languages: identify expected languages

The languages array can describe multilingual audio and code-switching. Current documentation accepts ISO 639-1 codes such as en, es, and fr, selected ISO 639-3 codes, and regional Chinese locale codes such as zh-cn, zh-tw, and zh-hk.

This is a migration detail as well as a feature. gpt-transcribe uses the plural languages field. Older models may use the singular language field. Do not send both and assume the server will choose one; the current guidance says the API rejects incompatible or malformed values.

Streaming a completed file is not live transcription

Set stream=true when the audio file is complete but the interface should display text as processing progresses. GPT Transcribe emits transcript.text.delta events and finishes with transcript.text.done.

This can improve perceived responsiveness for a long interview. The user sees the first paragraphs before the full result is ready, while the application still has a clear final event for saving, indexing, or enabling downstream actions.

It does not turn /v1/audio/transcriptions into an open microphone. The whole file is supplied with the request. For an ongoing source, OpenAI directs developers to Realtime transcription and recommends gpt-live-transcribe for continuous low-latency work.

There is one advanced middle path: gpt-transcribe can run in a Realtime WebSocket transcription session after the application manually commits an audio turn. This is useful when accuracy after a bounded utterance matters more than continuous captions. The application appends audio, commits the buffer, and receives deltas followed by a completed transcription event for that turn.

That gives product teams three distinct interaction patterns:

1. Blocking file transcription: upload a finished recording and wait for the final JSON.
2. Streamed file result: upload a finished recording and render transcript deltas.
3. Realtime transcription: send audio over an ongoing connection, either continuously with a live model or in manually committed turns.

Naming these patterns correctly prevents architecture surprises later.

What accuracy means in production

There is no honest universal accuracy number for speech to text. Word error rate changes with language, accent, microphone distance, codec, noise, overlap, vocabulary, speaker behavior, and the scoring rules used to normalize punctuation or casing. A benchmark on clean English narration cannot predict performance on a bilingual support call recorded through an 8 kHz telephone channel.

GPT Transcribe should therefore be evaluated as a component in a specific workflow, not as a leaderboard label. Build a small, permissioned evaluation set that represents the audio users will actually submit. Keep the human-approved reference transcript and compare at least three configurations:

• the current production baseline;
• a model-only switch to gpt-transcribe;
• gpt-transcribe with relevant prompt, keyword, and language hints.

Measure more than aggregate word error rate:

Do not “improve” an evaluation transcript with a general text model before scoring it. Post-processing may create a more readable document while silently changing the speaker’s words. Keep a verbatim layer, then derive a cleaned or summarized layer with an audit trail.

What GPT Transcribe does not replace

The newest default is not automatically the most feature-complete model for every output.

Speaker diarization

If the product must answer “who said what,” use gpt-4o-transcribe-diarize. Its diarized_json response contains segments with speaker, start, and end metadata. For recordings longer than 30 seconds, OpenAI requires an automatic or configured chunking strategy. The model can also accept short reference samples for a limited number of known speakers, but speaker labeling is not supported in Realtime transcription sessions.

Word timestamps and subtitles

GPT Transcribe’s JSON-first output does not provide a drop-in replacement for every Whisper response format. If an editor depends on word-level timestamps, segment timestamps, SRT, VTT, or verbose_json, retain whisper-1 or build and validate a separate alignment and subtitle layer. Do not manufacture timecodes by distributing words evenly across the file duration.

Translation

Transcription preserves the original spoken language. Translation changes languages. OpenAI’s completed-recording route for translation into English remains /v1/audio/translations with whisper-1. For other translation workflows, separate recognition from translation so that each stage can be reviewed.

Unlimited input length

The 25 MB upload limit is not a duration promise. A compressed mono recording can fit far more minutes than uncompressed stereo WAV. For larger inputs, compress appropriately or split on semantic boundaries. Cutting in the middle of a sentence removes acoustic and linguistic context, and overlapping chunks without a reconciliation strategy can duplicate words.

Cost and throughput

The OpenAI pricing page listed gpt-transcribe at $0.0045 per minute when this article was reviewed. That is approximately $0.27 for one hour of source audio before storage, network, orchestration, retries, post-processing, and human review.

Price per minute is only one part of production cost. Include:

• failed or repeated uploads;
• media normalization and chunking;
• storage for source files and approved transcripts;
• terminology management;
• quality review for high-impact content;
• downstream summarization, search, or redaction;
• data residency or enterprise controls where applicable.

A cheaper model can become expensive if it increases correction time. A more accurate model can still be the wrong choice if the workflow requires native subtitles or continuous live captions. Compare total workflow cost against the output contract, not just the model row.

Privacy and responsible handling

Recordings often contain more sensitive information than ordinary text: voices, identity cues, background conversations, addresses, health details, and confidential meetings. Obtain a valid right to record and process the audio, minimize what is collected, protect the source file, and set a deletion schedule.

OpenAI’s current API data controls documentation states that API data is not used to train models unless the customer explicitly opts in. Its endpoint table lists /v1/audio/transcriptions with no application-state retention, no abuse-monitoring retention, and eligibility for Zero Data Retention. Those are platform-level statements, not a complete privacy program. Your uploader, object storage, logs, analytics, support tools, and downstream processors have their own policies and retention behavior.

For regulated or high-risk work, confirm the current contractual, regional, security, and human-review requirements with the responsible legal and security teams. Never treat an automatic transcript as the sole record for a decision that could materially affect a person.

A production-ready transcription architecture

A reliable implementation separates ingestion, transcription, review, and derivative content:

1. Authorize and ingest. Validate the user, recording rights, media type, file size, and malware controls.
2. Normalize media. Convert unsupported containers, preserve a source copy when required, and avoid unnecessary lossy re-encoding.
3. Attach scoped context. Select only the languages, keywords, and recording description relevant to this job.
4. Transcribe idempotently. Give each source a stable job ID so a retry does not create duplicate billable work or conflicting transcripts.
5. Store the raw result. Preserve the exact model response, model ID, context fields, source checksum, and processing date.
6. Review critical fields. Route low-confidence or high-impact names, numbers, commitments, and medical or legal language to a human.
7. Create derivatives. Generate summaries, chapters, captions, search indexes, redacted versions, or action items from the approved transcript.
8. Apply retention. Delete or archive source audio and derivatives according to the documented policy.

Transcription can also be the first half of a bidirectional audio workflow. After the transcript is corrected, a team can revise it and use text to speech to create accessible narration, localization drafts, or an approved voiceover. Keep the recognized source and generated output clearly labeled; one is evidence of what was said, while the other is newly synthesized media.

API integration versus a browser tool

Use the API when transcription is part of a product, automation, data pipeline, or repeatable internal process. It provides control over authentication, context, job tracking, downstream storage, and error handling.

Not every evaluation needs an integration first. A browser workflow is useful for testing a few representative recordings, understanding expected outputs, or serving an occasional user who needs export formats rather than SDK code. The GPT Transcribe online speech-to-text workspace provides a practical upload-and-review path before a team commits to building its own interface.

The evaluation standard should remain the same in either route: use audio you are authorized to process, compare against a human reference, inspect critical entities, and understand which application—not merely which underlying model—creates timestamps, speaker labels, exports, or storage.

When should you choose GPT Transcribe?

Choose gpt-transcribe when:

• the input is a completed recording or a bounded committed turn;
• the desired output is accurate text in the original language;
• the recording may switch among expected languages;
• domain vocabulary can benefit from scoped keywords;
• detected-language metadata is useful;
• partial transcript events would improve the file-processing interface.

Choose a specialized alternative when:

• audio is continuously arriving and low latency is essential;
• speakers must be labeled;
• word-level timestamps or native subtitle files are mandatory;
• the output must be an English translation;
• an existing integration depends on a response format that gpt-transcribe does not provide.

The right selection is based on the required artifact. “A transcript” may mean plain text, a searchable JSON object, captions synchronized to video, a court-style speaker record, or live captions. Those are different products even when all begin with speech recognition.

FAQ

Is GPT Transcribe the same as GPT-4o Transcribe?

No. gpt-transcribe is a separate current model ID and OpenAI’s recommended starting point for ordinary file transcription. Existing gpt-4o-transcribe integrations may continue to work, but their request fields, pricing, and output behavior should not be assumed to match.

Can GPT Transcribe transcribe an MP3 or video file?

Yes. The file transcription endpoint accepts common audio and media containers. Verify the current input list and 25 MB request limit in the API reference, especially when validating FLAC, OGG, or video containers.

Does GPT Transcribe identify different speakers?

Not by itself. Use gpt-4o-transcribe-diarize and request diarized_json when speaker-labeled segments are required.

Can it create SRT or VTT subtitles?

Not as a drop-in native GPT Transcribe output. OpenAI currently directs timestamp and native SRT/VTT workflows to whisper-1, or you can build a separately tested alignment layer.

Can GPT Transcribe process live microphone audio?

For continuously arriving audio, use the Realtime transcription workflow and start with gpt-live-transcribe. GPT Transcribe can be used for manually committed turns over WebSocket, which is different from uninterrupted live captioning.

How can I improve transcription of names and technical terms?

Describe the recording with prompt, supply literal expected terms through keywords, and provide the expected languages. Test that hints improve recall without inserting terms that were never spoken.

Is GPT Transcribe free?

The OpenAI API is usage-priced. At the review date, official pricing listed $0.0045 per audio minute for gpt-transcribe. A third-party interface may offer its own trial, credits, limits, or subscription.

The useful default, not the universal answer

GPT Transcribe gives new OpenAI speech-to-text projects a strong default: one model for accurate recorded-audio transcription, multilingual context, language detection, and streamed file results. Its real advantage is not that it makes every older route obsolete. It gives developers a clearer general path while leaving specialized jobs to specialized models.

Define the required output first. Then test gpt-transcribe on the noisiest, most multilingual, and most terminology-heavy recordings users will submit. A transcript that survives those cases—with traceable context, human review, and honest limitations—is ready to become part of a product rather than just an impressive demo.