OpenAI’s Assistants API Is Gone. Four Transcription Models Are Next.
OpenAI’s Assistants API Is Gone. Four Transcription Models Are Next.
OpenAI put two very different API events into one August 26 changelog entry. The Assistants API reached its shutdown date and is now unavailable. On the same day, OpenAI deprecated whisper-1, gpt-4o-transcribe, gpt-4o-mini-transcribe, and gpt-4o-transcribe-diarize, giving them a February 26, 2027 cutoff.
Calling both events “migration work” hides the useful distinction.
If an Assistants integration is still in production, its deadline has already passed. The job is service restoration, state recovery, and behavior reconciliation. The old thread-message retrieval call no longer works, according to OpenAI’s migration guide. A clean code diff is no longer the hardest part; finding the conversation data your application did or did not save may be.
Transcription is the opposite problem. Builders have 179 days from August 31 to inventory workloads, run shadow traffic, and qualify fallbacks. But the replacement table overstates practical parity. OpenAI’s current guide still points to models being retired for speaker diarization, word timestamps, SRT/VTT subtitles, and completed-audio translation into English. This is an output-contract migration, not a model-name edit.
The shared message is not simply that OpenAI is removing old products. OpenAI is compressing its platform around Responses for agent execution and two new transcription lanes organized by latency. That can make the catalog easier to understand while transferring more responsibility for orchestration, state, portability, and specialist audio outputs into application architecture.
One announcement, two clocks
The dates decide the operating plan.
The left track is incident recovery. The right track is a planned, testable migration window.
OpenAI’s deprecations page says deprecated models remain accessible until their shutdown date. It also says shutdown means the model or endpoint is no longer accessible. That makes the two workstreams operationally opposite:
- Assistants: restore critical paths first, then recover parity and clean up architecture.
- Transcription: measure current behavior first, then migrate through shadow tests and canaries.
Do not put both into one “platform modernization” backlog. One can be sequenced. The other may already be an incident.
Assistants: restore execution before chasing elegance
The old object model was comfortable because OpenAI hosted several concerns behind four nouns: Assistant, Thread, Run, and Run step. The replacement mapping is straightforward on paper:
| Assistants-era object | Named replacement | What actually changes |
|---|---|---|
Assistant | Prompt or app-owned configuration | Model, instructions, tools, and schemas need a versioned home. |
Thread | Conversation or app state | You must choose hosted persistence, retention, deletion, and portability semantics. |
Run | Response | The execution call is simpler, but tool-call loops and retries are explicit. |
Run step | Item | Messages, tool calls, and tool outputs share a more general event model. |
The table is a vocabulary map, not a parity guarantee. OpenAI explicitly assigns history pruning, tool loops, and retries to application orchestration in the Assistants migration guide. Production teams must also make duplicate side effects impossible when a retry happens after an ambiguous timeout.
That is where migrations fail expensively. A basic Responses call can work while the surrounding system sends the same email twice, repeats a payment action, loses a tool result, or rebuilds context differently enough to change decisions.
The minimum recovery sequence should be:
- Search production code and telemetry for
beta.assistants,beta.threads, Runs endpoints, and theOpenAI-Beta: assistants=v2header. - Restore the smallest critical execution path on Responses.
- Reconcile conversation state from application-controlled storage.
- Rebuild tool execution with idempotency keys, timeouts, retry boundaries, and replayable traces.
- Compare behavior with saved production cases before calling the migration complete.
SDK types are not a health check. A legacy client can still compile after its server endpoint is gone. Require runtime integration tests.
The official Prompt bridge is already expiring
There is another trap in the object map. The guide maps Assistant configuration to reusable Prompts, but OpenAI’s deprecation schedule says the /v1/prompts API and reusable prompt objects shut down on November 30, 2026—96 days after Assistants.
Building a fresh, deep dependency on dashboard Prompt IDs would create a second migration almost immediately. OpenAI now recommends moving reusable prompt content into application code.
The durable destination is boring and good: prompt text, tool schemas, model policy, and rollback history in the same version-control and deployment system as the application that depends on them.
Conversation state is a compliance choice
A mechanical Thread-to-Conversation migration is also unsafe. OpenAI documents that Response objects are stored for 30 days by default unless store is false, while Conversation items persist until deleted. The data controls table marks /v1/conversations as ineligible for Zero Data Retention.
Choose the state model based on the workload:
Use when durable OpenAI-hosted state is acceptable. Add explicit deletion jobs, retention ownership, export tests, and reconciliation against your application records.
Use store: false and keep encrypted state in your own system when ZDR eligibility, regional controls, or customer portability outweigh convenience.
Store the canonical conversation and tool-side-effect history yourself, then use hosted state as a performance feature rather than the only copy of customer history.
My preference is the third option for serious agent products. It costs engineering time, but it prevents a provider sunset from becoming an archaeology project.
Transcription: migrate the output contract, not the slug
The transcription deadline looks generous next to the Assistants cutoff. It is still a broad production change. On August 26, OpenAI deprecated four widely used models and pointed every one of them to either gpt-transcribe or gpt-live-transcribe. Both successors had launched only 29 days earlier, according to the API changelog.
That is little public soak time before the retirement notice, especially for multilingual calls, noisy recordings, medical or financial vocabulary, and telephony audio. A six-month notice is useful, but it is not six months of proven production history.
The first decision is not “which new model is better?” It is “what kind of clock does this audio run on?”
| Workload lane | Recommended model | List price | Contract to test |
|---|---|---|---|
| Completed file or bounded request | gpt-transcribe | $0.0045/min | Final text, streamed file output, detected languages, terminology accuracy |
| Committed turn in a Realtime session | gpt-transcribe | $0.0045/min | Turn boundaries, event reconciliation, final language metadata |
| Microphone, call, or genuinely live stream | gpt-live-transcribe | $0.017/min | Partial corrections, delay setting, out-of-order completion, UI stability |
| Diarization, word timestamps, subtitles, or English translation | No parity path documented yet | Depends on fallback | Speaker boundaries, timestamp drift, output schema, provider composition |
OpenAI’s transcription guide makes an important distinction: streaming the text output of a completed file does not make the workload live. Use Realtime when audio is arriving live or the application needs a persistent connection. That decision changes price, endpoint behavior, event ordering, and available metadata.
At current list prices, the live lane is about 3.78 times the file lane. For 1,000 audio hours, the arithmetic is roughly $1,020 for gpt-live-transcribe versus $270 for gpt-transcribe, before retries and post-processing. That $750 gap is not an argument against live transcription. It is an argument against paying for live behavior when the source is already a file.
Four specialist outputs are still attached to retiring models
The clean replacement table collides with OpenAI’s own capability guide.
As of August 31, the guide still directs builders to:
gpt-4o-transcribe-diarizefor speaker-labeled transcripts;whisper-1for word timestamps;whisper-1for SRT and VTT subtitle output;whisper-1for translating a completed recording into English.
Meanwhile, the Realtime transcription guide says gpt-live-transcribe does not return word-level timestamps, speaker labels, confidence scores, or detected-language predictions. Completion events from different turns can arrive out of order, so clients must correlate them by item_id.
This does not prove that OpenAI will leave the gaps open through February. It does mean builders cannot assume the replacement table is a promise of schema and feature parity.
The contract test
If a downstream parser, compliance archive, caption editor, or analytics job consumes more than plain transcript text, its output schema is the migration unit. Preserve fields and timing semantics first; choose the model or composed pipeline second.
The voice stack will probably become a two-pass system
Here is the useful architectural implication: low-latency interaction and an authoritative record are different products.
Use gpt-live-transcribe when a person needs text while speaking. It can make captions, agent turn-taking, and live assistance feel immediate. Then, when richer metadata or lower unit cost matters, send the completed recording or committed segment through gpt-transcribe or another qualified file service.
That hybrid design sounds redundant until the requirements are separated:
live lane -> fast partial text -> conversation UX
authoritative lane -> final file pass -> archive, search, QA, compliance
The second pass can repair unstable partials, normalize terminology, attach durable identifiers, and supply specialist outputs through a fallback component. It also prevents the expensive live lane from becoming the default batch processor.
This is RohitAI’s prediction, not an announced OpenAI roadmap: the cost-optimal production voice stack will increasingly split interaction from recordkeeping. The current 3.78x price ratio and live model’s missing metadata make that split economically and technically sensible.
A migration plan that tests the failures users will notice
Generic word error rate is not enough. A transcript can score well and still fail the product by mangling a drug name, invoice number, customer surname, or language switch.
OpenAI itself recommends representative audio. Build a golden corpus from real conditions: accents, code-switching, telephony compression, overlapping speakers, background noise, long silence, names, numbers, acronyms, and domain terminology. Add adverse network behavior for live sessions.
For Assistants, add failure injection around tools. Simulate timeouts after an external action succeeds, duplicated webhooks, missing tool outputs, stale conversation state, and a retry after the client loses the response. These tests find the migration bugs that a happy-path API call misses.
RohitAI’s read: consolidation makes portability more valuable
The sourced facts are clear. Assistants is gone. Responses and Conversations are the named replacements. Four transcription models have a February cutoff. Two newer models divide the primary workload by file/committed-turn versus genuine live audio.
Our interpretation is that OpenAI is moving toward a smaller set of platform centers:
agent execution -> Responses
hosted state -> Conversations
file speech -> gpt-transcribe
live speech -> gpt-live-transcribe
That is directionally good. Product catalogs become hard to navigate when every generation leaves another endpoint, object model, and alias behind.
But consolidation does not remove complexity. It relocates it. The application now owns more of the agent loop and must choose state-retention semantics. Audio teams must compose fallbacks when the simpler model taxonomy does not preserve the old output contract.
Three consequences are easy to miss:
- The safest abstraction is your workload contract, not OpenAI’s current noun. Define “live captions,” “authoritative transcript,” “durable conversation,” and “exactly-once tool action” inside your architecture. Map providers to those contracts.
- Hosted state is a convenience layer, not a recovery plan. If customer history matters, keep an application-owned ledger and test exports before you need them.
- The hidden migration risk sits outside direct API calls. Aliases, old SDK paths, Zapier-style connectors, subtitle parsers, Free-tier prototypes, and regional control planes are more likely to be missed than one obvious model string.
This extends our earlier analysis of OpenAI’s July audio and Realtime retirement wave. The first wave showed that aliases accumulate migration debt. The August wave adds a harder lesson: a successor can cover the core workload while leaving the production output contract unresolved.
For the agent side, our recent piece on durable runs and the Agents SDK is the useful companion. Replay, tracing, and side-effect boundaries are not optional plumbing once the hosted Run abstraction disappears.
What to watch before February 26
The most likely product update is clearer successor support for at least some combination of diarization, timestamps, subtitles, and completed-audio translation. That is a medium-confidence prediction based on the mismatch between the blanket replacement table and the current specialist-capability guide, not a claim that OpenAI has promised those features.
Also watch for documentation changes to exact aliases and snapshots. The family-level retirement notice does not explain every dated identifier, cloud marketplace, reseller, or regional deployment. The canonical OpenAI API date should not be copied onto Azure OpenAI or a third-party platform without checking that control plane.
Finally, watch support and incident patterns around Assistants. OpenAI documents no public post-sunset export route for thread messages, but that does not prove underlying data was deleted or that support has no account-specific recovery options. Teams without local copies should ask carefully and describe the evidence they still possess. They should not design a recovery plan around an exception that OpenAI has not published.
FAQ
When does whisper-1 shut down?
OpenAI says whisper-1 will be removed from the API on February 26, 2027. The same date applies to gpt-4o-transcribe, gpt-4o-mini-transcribe, and gpt-4o-transcribe-diarize.
What replaces Whisper and the GPT-4o transcription models?
OpenAI lists gpt-transcribe or gpt-live-transcribe. Use gpt-transcribe for completed files, streamed processing of completed files, and committed Realtime turns. Use gpt-live-transcribe for genuinely live microphone or call audio.
Does gpt-live-transcribe replace diarization and timestamps?
Not according to current documentation. OpenAI says the live model does not return word timestamps or speaker labels, and its transcription guide still assigns those specialist outputs to models scheduled for retirement. Qualify a fallback rather than assuming parity.
Is the Assistants API still available during a grace period?
No. OpenAI says it was officially sunset on August 26, 2026 and is no longer available. New integrations should use Responses, with Conversations or application-managed state as appropriate.
Can old Assistants Threads be exported now?
OpenAI’s guide says the API call that retrieves thread messages no longer works and tells builders to use messages already stored by their application. It does not document a public post-sunset export path. Account-specific support options are unknown.
Should every old Thread become a Conversation?
No. Conversations persist until deleted and are not ZDR eligible. Privacy-sensitive workloads may need stateless Responses with store: false and an application-owned state layer.
The deadline behind the deadline
February 26 is the visible date. The practical deadline is earlier: the day your team still has enough production traffic, engineering attention, and fallback capacity to run a meaningful canary.
Assistants users no longer have that luxury. Their lesson should shape the audio migration. Store the state you cannot afford to lose. Version the contracts you cannot afford to rediscover. Keep model and provider choices behind a route you can change.
OpenAI is simplifying the center of its platform. Builders should use the remaining transcription window to simplify their edge of it too.