GPT Transcribe Explained: OpenAI’s Next-Generation Speech-to-Text Model and How to Use It

GPT Transcribe is OpenAI’s recommended speech-to-text model for turning completed recordings into text in their original language. It can process an uploaded file, stream partial text while it works through that file, or transcribe committed audio turns in a Realtime session. More importantly, it accepts recording context, expected keywords, and multiple language hints—controls that make transcription easier to adapt to real products than a bare “upload audio, receive text” call.

This guide explains what the model does, where it fits among OpenAI’s other audio models, how to call /v1/audio/transcriptions, and how to design a production workflow around its limits. The API details and model boundaries were checked against OpenAI’s official documentation on July 30, 2026.

The short answer: what GPT Transcribe is

GPT Transcribe is a high-accuracy automatic speech recognition model whose job is to preserve spoken content as written text. To decide whether it fits a project, inspect the audio source and required output before choosing the model: use GPT Transcribe for ordinary recorded speech, but route work elsewhere when the deliverable must include speaker labels, word-level timing, subtitle files, or continuous low-latency live captions.

That decision matters because “speech to text” describes several different jobs. Transcribing a finished interview is not the same as captioning a live call. Producing a readable paragraph is not the same as producing an SRT file aligned to video frames. OpenAI’s current file transcription guide therefore recommends GPT Transcribe as the starting point for recorded speech and names specialized paths for the other outputs.

The following model map is a useful first filter:

This is also the first important correction to a common assumption: GPT Transcribe is a model, not a complete transcription application. A usable application still needs upload validation, job status, transcript storage, editing, export formats, and quality review.

Why GPT Transcribe is more than “the next Whisper”

Whisper established a widely used baseline for multilingual automatic speech recognition. GPT Transcribe keeps the familiar Audio API pattern but changes how developers can provide context and how the model participates in file and Realtime workflows.

Context is a first-class input

Speech is ambiguous even when humans hear it clearly. A customer may say “AC-42,” but a generic model could hear “eighty-four two.” A researcher may mention an uncommon surname, a pharmaceutical product, or a code repository whose spelling is impossible to infer from sound alone.

GPT Transcribe provides three different controls:

• prompt describes the recording or supplies unstructured background.
• keywords lists literal names, terms, or phrases expected in the audio.
• languages lists the input languages that may occur.

Keeping these controls separate is useful. A prompt such as “a quarterly earnings call about renewable energy” establishes the domain, while keywords such as “Solgrid,” “EBITDA,” and “Q4” identify exact strings. The language array tells the model that a conversation may move between English and French without forcing one language for the entire file.

Keywords are hints, not instructions to insert text. OpenAI explicitly recommends evaluating them because an overly broad list can encourage terms that were never spoken. The right question is not “Did adding 500 keywords improve one demo?” but “Did a small, relevant list reduce proper-noun errors across a held-out audio set without increasing false insertions?”

Multiple languages are part of the request and response

Older transcription integrations commonly use a singular language hint. GPT Transcribe instead accepts a languages array. Do not send both fields in the same request.

The response also contains reliably detected languages:

{
  "text": "Bonjour, pouvez-vous m'entendre ?",
  "languages": [{ "code": "fr" }]
}

An empty languages array means the model could not make a reliable detection. It should not be silently converted into a confident “unknown equals English” decision. Store the empty state, flag it when language affects routing, and let downstream logic fall back explicitly.

File streaming and live transcription are different

The word “streaming” causes avoidable architecture mistakes. With a completed recording, stream=true means the file already exists and the server returns transcript deltas while processing it. This improves perceived responsiveness, but it does not turn the request into a live microphone session.

For audio that is still arriving, use Realtime transcription. OpenAI’s migration guidance distinguishes GPT Transcribe for completed files, streamed file transcripts, and committed Realtime turns from GPT Live Transcribe for continuously streaming, low-latency speech.

How to transcribe audio with the OpenAI API

The simplest integration sends multipart form data to:

POST https://api.openai.com/v1/audio/transcriptions

OpenAI’s current file guide documents a 25 MB upload limit and accepts MP3, MP4, MPEG, MPGA, M4A, WAV, and WebM files. If a recording exceeds the limit, compress it or split it at natural speech boundaries. Cutting in the middle of a sentence removes context from both adjacent chunks.

Keep the API key on a trusted server. Never place it in public browser JavaScript, a mobile application bundle, or a client-visible environment variable.

cURL example

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/interview.mp3 \
  --form model=gpt-transcribe

The default JSON response includes text and detected languages. A basic server can store that response as the immutable raw result, then create a separate editable transcript version. Separating raw and edited text makes corrections auditable and prevents a later export from being mistaken for model output.

Python example

Install the current OpenAI Python package, set OPENAI_API_KEY in the server environment, and pass an open file object:

from openai import OpenAI

client = OpenAI()

with open("interview.mp3", "rb") as audio_file:
    transcription = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=audio_file,
    )

print(transcription.text)
print(transcription.languages)

Use a context manager so the file handle closes even when the request fails. In a production worker, also record a request identifier, source-file checksum, model ID, processing time, and terminal status. Do not log the transcript itself by default if recordings can contain personal or confidential information.

JavaScript example

import fs from 'fs';
import OpenAI from 'openai';

const openai = new OpenAI();

const transcription = await openai.audio.transcriptions.create({
  file: fs.createReadStream('interview.mp3'),
  model: 'gpt-transcribe',
});

console.log(transcription.text);
console.log(transcription.languages);

The SDK call is intentionally small. Most production work happens around it: validating the upload, placing it in durable storage, retrying transient failures, enforcing quotas, and making the finished transcript available to an authorized user.

Adding prompts, keywords, and language hints

A context-aware request can materially improve names and domain vocabulary, but only when the supplied context is precise. OpenAI’s transcription context documentation uses prompt, keywords, and languages together.

Here is the Python shape:

from openai import OpenAI

client = OpenAI()

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

print(transcription.text)

Use these rules to keep hints useful:

1. Describe the recording, not the desired conclusion. “A cardiology lecture about atrial fibrillation” is context; “the doctor recommends treatment X” risks biasing the transcript.
2. Include only terms that could plausibly occur in this recording.
3. Preserve the exact spelling, capitalization, and punctuation required downstream.
4. Test the hinted and unhinted request against the same human transcript.
5. Watch for false insertions as well as corrected spellings.

For GPT Transcribe, each keyword must stay on one line and cannot contain <, >, carriage returns, or line feeds. Unsupported language codes and invalid combinations should fail validation before the request reaches the API.

Streaming partial text from a completed file

Set stream=true when a user should see progress while a finished file is being transcribed:

from openai import OpenAI

client = OpenAI()

with open("long-interview.wav", "rb") as audio_file:
    stream = client.audio.transcriptions.create(
        model="gpt-transcribe",
        file=audio_file,
        stream=True,
    )

    for event in stream:
        print(event)

The API emits transcript.text.delta events followed by a final transcript.text.done event containing the complete transcript. The final GPT Transcribe event also includes detected languages.

Do not treat every delta as permanent text. A UI should render partial content as provisional and persist the final event as the authoritative result. If a connection closes early, the worker needs an explicit incomplete state rather than a transcript that merely stops mid-sentence.

For a microphone or call, move to the Realtime transcription flow instead. Repeatedly uploading tiny audio files to the file endpoint creates artificial boundaries, loses conversational context, and usually produces a worse latency model than a protocol designed for ongoing audio.

From raw text to subtitles, timestamps, and speaker labels

GPT Transcribe’s focused output is a strength when plain text is the actual deliverable. It becomes a limitation when a user expects a full media-production package.

OpenAI’s current model guidance routes the following needs to specialized tools:

• Speaker labels: use gpt-4o-transcribe-diarize and request diarized_json.
• Word or segment timestamps: use whisper-1 with verbose_json and timestamp_granularities[].
• SRT or VTT subtitle output: use a model and response format that supports those files, or build an alignment step.
• English translation: call /v1/audio/translations with whisper-1.
• Continuous live captions: use Realtime transcription with gpt-live-transcribe.

This is where product layers add value. Developers who want to inspect a finished user experience before building every upload, editing, and export component can try the GPT Transcribe online workspace, which combines browser-based transcription with practical transcript outputs. Later in development, a team can compare its own API result with a browser speech-to-text workflow to clarify which features belong to the model and which belong to the surrounding application.

The distinction prevents misleading claims. A product may offer timestamps and speaker-aware exports while using more than one processing stage. That does not mean the base GPT Transcribe response natively contains every field.

A production-ready transcription architecture

A reliable system is a pipeline, not a single API call.

1. Ingest and validate

Verify the file type, byte size, claimed duration, and ownership before placing a job on the queue. Decode enough of the media to detect corrupt files rather than trusting the extension. Apply per-user quotas before uploading a large object to downstream services.

2. Preserve the source

Give the original recording an immutable object key and checksum. If policy allows source retention, keep it long enough to reproduce disputed text. If policy requires deletion, document when the source disappears and make the resulting limits clear to users.

3. Choose the model from the deliverable

Ask whether the output needs plain text, live partials, speakers, timestamps, subtitles, or translation. Route on those requirements. Do not choose GPT Transcribe first and discover at export time that an editor needs word-level timing.

4. Normalize and segment only when necessary

For files under the documented limit, avoid premature chunking. When splitting is necessary, prefer pauses or sentence boundaries and retain a small contextual overlap. Remove duplicate overlap during assembly, not by dropping the context that helped recognition.

5. Transcribe and retain raw evidence

Store the model ID, request settings, detected languages, raw response, source checksum, and processing timestamp. If prompts or keyword lists can change, version them with the job.

6. Review uncertain or consequential content

Names, figures, medical terms, legal commitments, and safety instructions deserve targeted human review. Automatic transcription can support high-stakes work, but it should not become an unverified factual record merely because the prose looks fluent.

7. Produce downstream artifacts

Create the editable transcript, captions, summary, search index, or translation from the retained result. If the transcript later feeds a text-to-speech workflow, review semantic changes before generating new audio; a polished synthetic voice can make an unnoticed transcription error sound authoritative.

How to evaluate transcription quality

One clean podcast clip cannot establish production quality. Build an evaluation set that represents the audio users actually submit:

• quiet and noisy rooms;
• close and distant microphones;
• fast speech and long pauses;
• relevant accents and dialects;
• overlapping speakers;
• names, numbers, acronyms, and product vocabulary;
• every expected language combination;
• silence, music, and non-speech segments.

Word error rate (WER) is useful but incomplete. It counts substitutions, insertions, and deletions relative to a reference transcript, yet a low average can hide a costly failure. Replacing “15” with “50” may change only one token while changing the meaning of an instruction.

Track at least five measures:

1. WER or character error rate for broad recognition quality.
2. Critical-term accuracy for names, numbers, codes, and domain vocabulary.
3. False insertion rate during silence or ambiguous noise.
4. End-to-end latency from accepted upload to final usable output.
5. Human correction time per audio minute.

Compare requests with and without context hints. Use the same source audio and reference transcript, and keep the evaluator blind to which configuration produced each candidate. A hint configuration wins only if it improves the target terms without increasing hallucinated or biased text.

Security, privacy, and operational controls

Audio frequently contains more sensitive information than a typical text prompt: voices, background conversations, account numbers, health details, or internal meetings. Design the data path before launch.

At minimum:

• send API requests from a trusted backend;
• encrypt stored source audio and transcripts;
• restrict object access by job owner and role;
• avoid transcript bodies in routine logs and error trackers;
• define retention separately for source audio, raw output, and edited output;
• provide deletion that covers derived artifacts;
• rate-limit upload and transcription endpoints;
• review the current provider data policy for the organization’s account and region.

Also separate transcription permission from publication permission. The fact that a user can technically upload a call does not prove they are authorized to record, transcribe, analyze, or publish every participant’s speech. Recording-consent and privacy requirements vary by jurisdiction and use case.

Common GPT Transcribe mistakes

Treating GPT Transcribe as ChatGPT

The model converts speech to text. Summarization, question answering, sentiment analysis, and extracting action items are downstream language-model tasks. Keep the raw transcript separate so those transformations cannot overwrite the evidence.

Using file streaming for live audio

Streaming the response to a completed upload is not the same as streaming microphone input. Choose Realtime transcription for ongoing audio.

Sending both language and languages

GPT Transcribe uses the plural array. The singular field belongs to older model patterns. Validate this at the API boundary.

Stuffing the request with keywords

Hints can help uncommon terms, but irrelevant keywords create bias. Keep lists small, recording-specific, and covered by regression tests.

Assuming fluent text is exact text

Good punctuation can make a transcript feel trustworthy. Always review the terms whose errors would change money, identity, timing, safety, or legal meaning.

Promising captions from plain text

A paragraph does not contain time alignment. Select a timestamp-capable path or add an alignment stage before promising subtitle files.

When GPT Transcribe is the right choice

GPT Transcribe is a strong default for podcast drafts, interview archives, research recordings, support-call text, meeting notes, searchable media libraries, and voice-message ingestion when the primary artifact is accurate text in the original language.

Choose another path when the primary requirement is live captions, native speaker attribution, word-perfect subtitle timing, or direct speech translation. In mixed workflows, it is reasonable to use GPT Transcribe for the main text and a specialized stage for media metadata—as long as the system records which stage produced which field.

FAQ

Is GPT Transcribe the same as Whisper?

No. Both perform speech recognition, but they are different OpenAI model families with different capabilities. The current documentation recommends GPT Transcribe for general recorded speech. Whisper remains useful when a workflow specifically needs timestamp granularities, subtitle response formats, or English translation.

Does GPT Transcribe use /v1/audio/transcriptions?

Yes. Upload the audio file as multipart form data and set model to gpt-transcribe. The endpoint returns transcript text and detected languages.

Can GPT Transcribe process more than one language?

Yes. Supply expected languages through the languages array. The model can also report languages it reliably detects, which is useful for multilingual recordings and code-switching.

Can it transcribe audio in real time?

It can transcribe committed turns inside a Realtime session, and it can stream partial output for an existing file. For continuously arriving, low-latency audio, OpenAI recommends GPT Live Transcribe through the Realtime API.

Does it identify speakers?

The base model is not the speaker-diarization path. Use gpt-4o-transcribe-diarize when speaker labels are required. Speaker labeling is available through the file transcription endpoint rather than Realtime transcription sessions.

Does it return timestamps or SRT files?

Not as the normal GPT Transcribe response. OpenAI currently directs timestamp and subtitle-format requirements to specialized model paths such as Whisper, or to an additional application layer.

How should long recordings be handled?

The documented file limit is 25 MB. Compress larger recordings or split them into smaller files at natural pauses. Carry useful context between chunks and test the assembled transcript for missing or duplicated boundary text.

Can I expose the OpenAI API key in a browser transcription tool?

No. Send the file to an authenticated backend or use a trusted hosted application. A client-visible key can be copied and used outside your product.

The practical takeaway

GPT Transcribe makes the most sense when developers treat transcription as a controlled data pipeline. Choose it for recorded speech, provide concise context and language hints, preserve the raw result, and evaluate the errors that matter to the business—not only average WER.

The model removes much of the speech-recognition work, but it does not remove product decisions. File limits, live transport, speaker attribution, timing, export formats, security, and human review still determine whether a transcript is merely impressive or genuinely usable.