Migrate Off whisper-1 and gpt-4o-transcribe Before Feb 26, 2027

Last updated: October 17, 2026

OpenAI will shut down whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe and gpt-4o-transcribe-diarize, plus the /v1/audio/translations endpoint, on February 26, 2027. For most file-transcription apps the move is a one-line model swap: send recorded files to gpt-transcribe on the same /v1/audio/transcriptions endpoint, and send live audio to gpt-live-transcribe in a Realtime transcription session. The hard part is the set of capabilities with no clear replacement yet - word timestamps, srt/vtt subtitles, speaker diarization, file-to-English translation, logprobs confidence and user-input transcription inside voice-agent Realtime sessions - so audit for those before you touch a model ID.

Every TypeScript and Python sample below was type-checked against openai@7.37.0 (Node, strict) and compiled against openai 3.34.0 (Python); the curl and WebSocket snippets are copied from OpenAI's guides. No live API calls were made while writing this, so run them against your own audio before you ship.

What is being retired and what replaces it#

OpenAI posted the notice on its deprecations page on August 26, 2026. Each retiring model lists the same recommended replacement: "gpt-live-transcribe or gpt-transcribe". The changelog tags v1/audio/transcriptions and v1/realtime as affected surfaces.

Prices come from OpenAI's pricing page. The gpt-4o transcribe models are billed per audio token ($2.50 / $10 per 1M input/output tokens for gpt-4o-transcribe, $1.25 / $5 for the mini), so the per-minute numbers are OpenAI's own estimates.

Three timeline details are worth knowing:

• The replacements are already out. GPT Transcribe and GPT Live Transcribe shipped on July 28, 2026, a month before the deprecation notice.
• Six months is the floor, not a courtesy. OpenAI's policy is at least 6 months notice for generally available models, at least 3 months for specialized variants and as little as 2 weeks for previews. Aug 26, 2026 to Feb 26, 2027 is exactly the 6-month minimum.
• One snapshot goes earlier. A separate July 20, 2026 notice already schedules gpt-4o-mini-transcribe-2025-03-20 for removal on January 20, 2027. The gpt-4o-mini-transcribe alias points at the 2025-12-15 snapshot, but if you pinned the March snapshot your deadline is five weeks sooner.

Not on the list: gpt-realtime-whisper (released May 7, 2026, $0.017/min). The transcription guide says existing integrations can keep using it, though it is no longer the recommended starting model for new work.

If you are also moving text models, the general retirement checklist is in Migrating Off Retired GPT Models in 2026. This post is the audio companion.

%% title: Which replacement do you need
flowchart TD
    Start[Your current call] --> Q1{Audio already recorded?}
    Q1 -- yes --> Q2{Need timestamps, srt/vtt or speakers?}
    Q2 -- no --> GT[gpt-transcribe on audio/transcriptions]
    Q2 -- yes --> GAP[No documented replacement - plan a fallback]
    Q1 -- no, live --> Q5{Voice agent session?}
    Q5 -- yes --> VA[Test gpt-transcribe in your own session]
    Q5 -- no --> Q3{Need detected language per turn?}
    Q3 -- no --> GLT[gpt-live-transcribe in a transcription session]
    Q3 -- yes --> GTR[gpt-transcribe over WebSocket, committed turns]
    Start --> Q4{Translating to English?}
    Q4 -- live audio --> RT[gpt-realtime-translate]
    Q4 -- recorded file --> TT[gpt-transcribe, then a text model]

Why it matters to developers#

It is a hard shutdown. OpenAI's deprecations page defines "shut down" as the model no longer being accessible. After February 26, 2027, requests to these model IDs stop resolving, so any code path still naming them fails.

Costs move in both directions. whisper-1 and gpt-4o-transcribe users save 25% per minute ($0.006 to $0.0045). gpt-4o-mini-transcribe users pay about 50% more ($0.003 estimated to $0.0045). If you picked the mini model for cost, budget for that now.

Request parameters change. gpt-transcribe takes languages (an array) instead of the singular language, and adds a keywords array. Code that builds the request body generically needs a small branch.

Some features have no announced successor. Subtitle generators, meeting-notes tools and call-analytics products lean on word timestamps, srt/vtt output or speaker labels. Voice agents that show users a transcript of what they said lean on a gpt-4o transcribe model inside the Realtime session. The guides still point the first group at the deprecated models, and the docs disagree with themselves about the second, so those teams need a plan in October, not February.

Step 1: Find every retiring model in your code and account#

Start with a grep across your repos. Model IDs often live in config files (.env, YAML, JSON, TOML) and in .tsx or .mjs files as well as source code, so search everything and exclude dependency and build folders instead of filtering by extension:

grep -rnE "whisper-1|gpt-4o(-mini)?-transcribe(-diarize)?|audio/translations|audio\.translations" \
  --exclude-dir=node_modules --exclude-dir=.git --exclude-dir=dist --exclude-dir=build .

Then ask the API. GET /v1/models returns each model with an optional shutdown_date field: a YYYY-MM-DD string, or null if nothing is announced. The Retrieve-a-model endpoint returns it too. In openai@7.37.0 the Model type includes shutdown_date?: string | null, so this compiles under strict mode:

// audit-shutdowns.ts - type-checked against openai@7.37.0
import OpenAI from "openai";

const client = new OpenAI();

const RETIRING = new Set([
  "whisper-1",
  "gpt-4o-transcribe",
  "gpt-4o-mini-transcribe",
  "gpt-4o-transcribe-diarize",
]);

for await (const model of client.models.list()) {
  if (RETIRING.has(model.id) || model.shutdown_date) {
    console.log(`${model.id}\tshutdown_date=${model.shutdown_date ?? "none announced"}`);
  }
}

Run this on a schedule and alert on any model your code references that gains a shutdown_date. It is the official programmatic signal, and it catches the next deprecation too.

A grep and a model list are signals, not proof of what your production traffic actually calls. Model names that live in a database row, a secrets manager or a teammate's config service will not show up in either. Check your OpenAI usage dashboard for which model IDs are actually receiving requests, and treat that as the real inventory.

Step 2: Audit which features you use (the gap check)#

This is the step that decides whether your migration takes an afternoon or a quarter. The table is built from the file transcription guide, the realtime transcription guide, the model pages and the openai@7.37.0 type definitions.

If any "No", "Not documented" or conflicting row matches something you ship, the swap is not one line for that code path. Split those calls out now (Step 6 shows a config pattern) and read the section on features with no replacement below.

Note the logprobs row in particular. In openai@7.37.0, the doc comment on include says logprobs "only works with response_format set to json and only with the models gpt-4o-transcribe, gpt-4o-mini-transcribe, and gpt-4o-mini-transcribe-2025-12-15". gpt-transcribe is not in that list. If you route low-confidence transcripts to human review, that signal disappears on migration unless OpenAI adds support.

Step 3: Migrate file transcription to gpt-transcribe#

gpt-transcribe uses the same endpoint, the same multipart upload and the same 25 MB file cap, so the basic call is a model-ID change. The new context parameters are where the accuracy gains are meant to come from:

// file-transcribe.ts - type-checked against openai@7.37.0
import fs from "node:fs";
import OpenAI from "openai";

const client = new OpenAI();

const transcription = await client.audio.transcriptions.create({
  model: "gpt-transcribe",
  file: fs.createReadStream("support-call.wav"),
  prompt: "A customer support call about a premium plan and account AC-42.",
  keywords: ["premium plan", "AC-42", "billing"],
  languages: ["en", "fr"],
});

console.log(transcription.text);
console.log(transcription.languages?.map((l) => l.code) ?? []);

On openai@7.37.0, keywords and languages are first-class typed fields on TranscriptionCreateParams (the type comments say "Supported by gpt-transcribe"). OpenAI's guide shows them passed through a body: request-option override, which older SDK versions needed. If you are on a current SDK, pass them directly; if you are pinned to an old one, upgrade or use the override.

The Python SDK is the same story. On openai 3.34.0, Transcriptions.create accepts keywords and languages as native keyword arguments (the docs pass them through extra_body, the escape hatch for fields an SDK does not type yet):

# transcribe.py - compiled against openai 3.34.0
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.",
        keywords=["premium plan", "AC-42", "billing"],
        languages=["en", "fr"],
    )

print(transcription.text)

And the raw HTTP form from the guide, with array fields sent as repeated [] keys:

curl https://api.openai.com/v1/audio/transcriptions \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  -H "Content-Type: multipart/form-data" \
  -F model="gpt-transcribe" \
  -F file="@/path/to/file/meeting.wav" \
  -F 'prompt=A customer support call about a premium plan and account AC-42.' \
  -F 'keywords[]=premium plan' \
  -F 'keywords[]=AC-42' \
  -F 'keywords[]=billing' \
  -F 'languages[]=en' \
  -F 'languages[]=fr'

The response gains a languages array of detected languages:

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

When the model cannot make a reliable prediction it returns "languages": []. Handle the empty case explicitly rather than assuming index 0 exists.

What each field is for, per OpenAI: prompt is unstructured context about the recording, keywords are literal terms you expect to hear, and languages are the expected input languages. Accepted codes are ISO 639-1 (en, es, fr), selected ISO 639-3 (eng, spa, yue, cmn) and regional zh locales (zh-cn, zh-tw, zh-hk). The API rejects unsupported or badly formatted codes, so validate them before you send.

%% title: File transcription with gpt-transcribe
sequenceDiagram
    participant App
    participant API as audio/transcriptions
    App->>API: POST multipart - model, file up to 25MB, prompt, keywords, languages
    alt stream=false
        API-->>App: JSON with text and languages
    else stream=true
        API-->>App: transcript.text.delta, repeated
        API-->>App: transcript.text.done with text and languages
    end

Step 4: Stream a completed file (optional)#

Streaming output and live audio are separate decisions. You can stream the transcript of a finished recording without opening a Realtime session - useful for showing progress on long uploads:

// file-stream.ts - type-checked against openai@7.37.0
import fs from "node:fs";
import OpenAI from "openai";

const client = new OpenAI();

const stream = await client.audio.transcriptions.create({
  model: "gpt-transcribe",
  file: fs.createReadStream("standup.wav"),
  stream: true,
});

for await (const event of stream) {
  if (event.type === "transcript.text.delta") process.stdout.write(event.delta);
  if (event.type === "transcript.text.done") console.log("\n", event.text);
}

The final transcript.text.done event carries the full text and, for gpt-transcribe, the detected languages. This is new for whisper-1 users: the guide states plainly that whisper-1 does not support file streaming. The gpt-4o transcribe models already did.

Step 5: Migrate live audio to gpt-live-transcribe#

If you were feeding live microphone or call audio through a transcription model in a dedicated transcription session, the recommended path is now gpt-live-transcribe in a Realtime session with type: "transcription". Connect over WebSocket for server-side pipelines or WebRTC for browser audio; the connection basics are covered in our Realtime voice API guide. If your live transcription happens inside a speech-to-speech voice agent instead, skip to the voice-agent subsection below - this path does not cover you.

The session configuration, typed with the SDK's SessionUpdateEvent:

// realtime-session.ts - type-checked against openai@7.37.0
import type { SessionUpdateEvent } from "openai/resources/realtime/realtime";

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

turn_detection must be omitted or null. gpt-live-transcribe does not support server_vad or semantic_vad, so if your old integration relied on server-side turn detection, you now run voice activity detection on the client and commit each turn yourself. From the guide:

ws.send(
  JSON.stringify({
    type: "input_audio_buffer.append",
    audio: base64Pcm16,
  })
);

// at the end of each turn, detected by your client-side VAD
ws.send(
  JSON.stringify({
    type: "input_audio_buffer.commit",
  })
);

ws.on("message", (data) => {
  const event = JSON.parse(data);

  if (event.type === "conversation.item.input_audio_transcription.delta") {
    process.stdout.write(event.delta);
  }

  if (event.type === "conversation.item.input_audio_transcription.completed") {
    console.log("\nFinal transcript:", event.transcript);
  }
});

Completion events from different turns are not guaranteed to arrive in order. Key your transcript store by item_id, not by arrival order, or a slow turn will land in the wrong place.

The delay setting trades latency for accuracy. It accepts five levels, and the guide gives a starting point for each:

• minimal for the most latency-sensitive interactions
• low for low-latency live captions
• medium for a balanced tradeoff
• high when accuracy matters more than immediate display
• xhigh when your workflow can tolerate the most delay

Higher values give the model more audio context and can improve word error rate. OpenAI does not publish milliseconds per level and says the exact delay varies by configuration, so benchmark with representative audio rather than assuming a number. For background on why OpenAI moved live speech onto dedicated models, see How OpenAI Built GPT-Live.

If you need detected languages on live turns, the guide documents a narrower option: run gpt-transcribe in the transcription session instead. It only starts transcribing after each committed turn, requires WebSocket, returns languages in the completion event and automatically uses earlier turns as context.

%% title: Live transcription session
sequenceDiagram
    participant Mic as Client with local VAD
    participant RT as Realtime transcription session
    Mic->>RT: session.update - gpt-live-transcribe, turn_detection null
    loop while speaking
        Mic->>RT: input_audio_buffer.append
        RT-->>Mic: input_audio_transcription.delta
    end
    Mic->>RT: input_audio_buffer.commit
    RT-->>Mic: input_audio_transcription.completed with item_id
    Note over Mic,RT: Order completions by item_id, not arrival

Voice agents: input transcription in a v1/realtime session#

Speech-to-speech apps often set audio.input.transcription.model to gpt-4o-transcribe or gpt-4o-mini-transcribe in a type: "realtime" session, so the app can show or log a text transcript of what the user said while the realtime model answers. That path is retiring too: the gpt-4o-transcribe and gpt-4o-mini-transcribe model pages list v1/realtime as Supported, and the August 26 changelog entry tags v1/realtime as affected.

Neither replacement clearly covers it:

• gpt-live-transcribe does not. Its model page lists v1/realtime as Not supported and supports only v1/realtime/transcription_sessions. The same is true of gpt-realtime-whisper per its model page.
• gpt-transcribe might. The realtime transcription guide says: "When gpt-transcribe performs input transcription in a Realtime API session or runs in a dedicated transcription session, it automatically uses earlier transcribed turns as context." But the gpt-transcribe model page lists v1/realtime as Not supported. The docs contradict each other, and we could not resolve which is current without live API access.

The SDK accepts the swap - openai@7.37.0 lists gpt-transcribe among the input transcription model options - so the change is easy to type:

// voice-agent-session.ts - type-checked against openai@7.37.0
import type { SessionUpdateEvent } from "openai/resources/realtime/realtime";

export const voiceAgentUpdate: SessionUpdateEvent = {
  type: "session.update",
  session: {
    type: "realtime",
    audio: {
      input: {
        transcription: {
          // was "gpt-4o-transcribe" or "gpt-4o-mini-transcribe"
          model: "gpt-transcribe",
          languages: ["en"],
        },
      },
    },
  },
};

A type that compiles is not proof the server accepts it. Test gpt-transcribe in your own voice-agent session - confirm the session update is accepted and that conversation.item.input_audio_transcription.completed events arrive for each user turn - before you rely on it, and keep your current model behind a config flag until you have. Per the guide, gpt-transcribe only starts transcribing after a committed turn, so expect the user transcript to land later than it did with streaming deltas.

Step 6: Put the model name in config and run both side by side#

Do not hard-swap the model ID in one deploy. Put it behind configuration so old and new paths can run in parallel until you trust the new one, and so the parameter difference lives in one place:

// model-config.ts - type-checked against openai@7.37.0
import fs from "node:fs";
import OpenAI from "openai";

const client = new OpenAI();
const MODEL = process.env.TRANSCRIBE_MODEL ?? "gpt-transcribe";

export async function transcribe(path: string): Promise<string> {
  const usesNewParams = MODEL === "gpt-transcribe";
  const result = await client.audio.transcriptions.create({
    model: MODEL,
    file: fs.createReadStream(path),
    ...(usesNewParams ? { languages: ["en"] } : { language: "en" }),
  });
  return result.text;
}

Then shadow a slice of real traffic through both and compare. OpenAI's transcription guidance is specific about what to test: your target languages and accents, telephony audio, background noise, names, numbers, dates, currency, email addresses and alphanumeric IDs, plus empty, truncated and delayed transcripts tracked separately from word error rate. Weight the errors that matter to your product - a wrong order number or medication name costs more than a dropped "um".

Two reasons not to lean on a headline WER number. Our analysis of ASR benchmark optimization found that public benchmark scores can overstate real-world accuracy, and our Apple SpeechAnalyzer vs Whisper benchmark found that a clean-data WER gap did not predict noisy-room behavior. The eval-before-switch method in the GPT retirement checklist applies here unchanged.

%% title: Migration plan before Feb 26 2027
flowchart TD
    A[Grep code and list models with shutdown_date] --> B[Gap check: timestamps, srt, speakers, translation, logprobs, voice agents]
    B -- no gaps --> C[Swap model, rename language to languages]
    B -- gaps --> D[Keep legacy path for that feature and pick a fallback]
    C --> E[Shadow traffic on your own audio]
    D --> E
    E --> F[Ramp behind a flag]
    F --> G[Remove legacy IDs before Feb 26 2027]

Gotchas and limits#

• 25 MB file cap. Supported formats are mp3, mp4, mpeg, mpga, m4a, wav and webm. Compress or split longer recordings into chunks of 25 MB or less, and avoid splitting mid-sentence, which costs context and accuracy.
• Never send both language and languages. The guides say not to; a shared request builder that adds both will break.
• Keyword validation is all-or-nothing. A keyword containing <, >, a carriage return or a line feed, or a prompt over the model's length limit, makes the API reject the entire request. Sanitize keywords that come from user input or a CRM.
• Keywords can hallucinate. They are hints, not required output. OpenAI says to include only relevant terms and check that they improve accuracy without making unspoken terms appear in the transcript. A keyword list bloated with every product SKU is a likely way to get that.
• No Batch API. gpt-transcribe is not supported on Batch, per its model page.
• Client-side VAD is mandatory for live. gpt-live-transcribe rejects server_vad and semantic_vad.
• Live output is text only. gpt-live-transcribe returns no word timestamps, speaker labels, confidence scores or detected-language predictions.
• gpt-transcribe in Realtime is WebSocket only. The committed-turn workflow needs a WebSocket connection, so a browser WebRTC client cannot use it directly.
• Voice-agent support is contested in the docs. The realtime transcription guide says gpt-transcribe can do input transcription in a Realtime API session; its model page lists v1/realtime as Not supported. Verify in your own session (Step 5).
• No dated snapshots to pin. Both new models list a single snapshot named after the model itself (gpt-transcribe, gpt-live-transcribe). You cannot pin a dated version the way you could with gpt-4o-mini-transcribe-2025-12-15, so keep your eval set around and re-run it periodically.
• SDK comment lag. In openai@7.37.0, the doc comment on the Realtime delay field still says it is only supported with gpt-realtime-whisper in GA Realtime sessions. The realtime transcription guide uses delay: "low" with gpt-live-transcribe, and the model page lists tunable latency. Treat the guide as authoritative, but verify the behavior in your own session.
• Different rate-limit shapes. At the Build tier, gpt-transcribe allows 5,000 RPM / 2,000,000 TPM, while gpt-live-transcribe allows 2,000 RPM / 210,000 TPM (model page). gpt-realtime-whisper is limited by audio duration instead: 350 minutes of audio per minute at Build, 1,000 at Launch and 1,300 at Grow (model page). If you plan to push file workloads through live sessions, you will hit the lower ceiling first.

gpt-transcribe vs gpt-live-transcribe (and gpt-realtime-whisper)#

The closest alternative to each replacement is the other replacement, plus the still-supported gpt-realtime-whisper for live audio. Compared only on documented capabilities:

Note the units in the last row: the two new models are limited by requests and tokens per minute, while gpt-realtime-whisper is limited by minutes of audio processed per minute, so the numbers are not directly comparable.

The verdict follows from the table. gpt-transcribe is the default for anything already recorded: it is the only one of the three on the file endpoint, it returns detected languages, and it is about 3.8x cheaper per minute than either live model. gpt-live-transcribe earns its price when users need to see text as they speak - live captions, agent assist on a call, dictation - and it adds context hints and tunable latency to that path. gpt-realtime-whisper remains a supported option if you already have a working live integration on it, and its model page describes it as designed for developers who need to tune latency and accuracy, but OpenAI's guide steers new work to gpt-live-transcribe.

What to do about features with no replacement#

As of October 17, 2026, OpenAI has not announced word-timestamp, subtitle-format or diarization support for gpt-transcribe or gpt-live-transcribe, and the transcription guide's specialized-capability table still points those workloads at whisper-1 and gpt-4o-transcribe-diarize. Your options, factually:

• Keep the legacy model for that one feature, for now. Migrate everything else, isolate the timestamp or diarization call behind its own config key, and watch the deprecations page and changelog for an update. Set a hard internal date well before February 26 to decide, so you are not choosing under pressure.
• Subtitles: generate timing in your own pipeline. If you only used srt/vtt as a convenience, you can build cues from your own segmenting, at the cost of owning the alignment logic.
• Self-host Whisper for timestamps. The open-source Whisper repository is the upstream OpenAI's own guide links to for whisper-1's language list (98 languages, accuracy varies by language). Self-hosting moves the GPU and ops cost onto you, but it does not have a shutdown date.
• Voice-agent user transcripts: test gpt-transcribe as audio.input.transcription.model in your own v1/realtime session (Step 5). If the session rejects it, a fallback is to also stream the user's audio into a separate Realtime transcription session running gpt-live-transcribe. That is our suggestion, not an OpenAI-documented pattern, and it doubles the audio you send, so price it and test turn alignment before committing.
• Translation of live audio: use gpt-realtime-translate on /v1/realtime/translations, over WebRTC or WebSocket (wss://api.openai.com/v1/realtime/translations?model=gpt-realtime-translate). The realtime translation guide describes streaming live source audio and does not document translating a completed file.
• Translation of recorded files: transcribe with gpt-transcribe, then translate the text with a text model. OpenAI documents post-processing transcripts with a text model for spelling and formatting correction; using that same two-step pattern for translation is our suggestion, not an OpenAI-documented replacement, so evaluate it against the whisper-1 output you have today.
• Confidence scores: if you used logprobs to route uncertain transcripts to review, you will need a different trigger, such as keyword-presence checks, empty or truncated output detection, or a sampled human review rate.

FAQ#

When exactly do whisper-1 and gpt-4o-transcribe stop working?#

February 26, 2027. They have been deprecated since the August 26, 2026 notice and keep working until then; after the shutdown date, requests to those model IDs fail. If you pinned gpt-4o-mini-transcribe-2025-03-20, that snapshot goes earlier, on January 20, 2027.

Is gpt-transcribe a drop-in replacement for whisper-1?#

For plain file transcription, nearly: same endpoint, same upload, same 25 MB cap, and language becomes languages. It is not drop-in if you use timestamp_granularities[], verbose_json word timing, srt/vtt output or /v1/audio/translations, none of which are documented for gpt-transcribe.

What should voice agents that use gpt-4o-transcribe for user transcripts do?#

Test gpt-transcribe as the input transcription model in your own v1/realtime session before relying on it. The realtime transcription guide says it can do input transcription in a Realtime API session, but its model page lists v1/realtime as Not supported, and gpt-live-transcribe is limited to transcription sessions.

Will migrating raise my transcription bill?#

It depends on where you start. whisper-1 ($0.006/min) and gpt-4o-transcribe (est. $0.006/min) both drop to $0.0045/min on gpt-transcribe. gpt-4o-mini-transcribe (est. $0.003/min) rises to $0.0045/min. Live transcription on gpt-live-transcribe is $0.017/min.

What replaces gpt-4o-transcribe-diarize for speaker labels?#

Nothing documented as of October 17, 2026. The file transcription guide still points speaker labeling at gpt-4o-transcribe-diarize, and speaker labels are not supported in Realtime transcription sessions. Isolate that call and plan a fallback before the shutdown date.

Sources#

• OpenAI API deprecations
• OpenAI API changelog
• Transcription overview
• File transcription guide
• Realtime transcription guide
• Realtime translation guide
• gpt-transcribe model page
• gpt-live-transcribe model page
• gpt-realtime-whisper model page
• whisper-1 model page
• gpt-4o-transcribe model page
• gpt-4o-mini-transcribe model page
• OpenAI API pricing
• openai on npm
• openai/whisper on GitHub

Continue Reading#

• Migrating Off Retired GPT Models in 2026: A Working Checklist - the text-model side of the same retirement wave, with the eval-before-switch plan this post reuses.
• OpenAI Realtime Voice API: Getting Started Guide - WebSocket and WebRTC connection setup for the transcription and voice-agent sessions in Step 5.
• 6 of 11 ASR Models Transcribe the Benchmark, Not the Audio - why you should test gpt-transcribe on your own audio before trusting a WER number.