ElevenLabs Launches Scribe v3 and Scribe v3 Live | Zeniteq
Loading
Loading article
Zeniteq is now available on mobile for iPhone, iPad and Apple Watch.Download nowLearn more
ElevenLabs Launches Scribe v3 and Scribe v3 Live
The new speech-to-text models bring claimed accuracy gains across 102 languages, a simple API upgrade and deployment choices that deserve a closer look.
ElevenLabs has launched Scribe v3 and Scribe v3 Live, claiming significant accuracy gains of 27% and 43% respectively over previous models. While upgrading requires only a simple model ID change, developers must carefully evaluate new features like speaker diarization, number formatting, and natural-language transcript editing, which carries a 30% cost surcharge. Furthermore, those utilizing Enterprise data residency must note that transcript editing is unavailable in isolated regional environments. Teams should prioritize testing domain-specific vocabulary and output parsing before full deployment, as these models introduce new behaviors that could disrupt existing downstream data pipelines.
ElevenLabs launched Scribe v3 for recorded audio and Scribe v3 Live for real-time transcription on November 10, 2026. The company says the batch model makes 27% fewer word errors than Scribe v2 across 102 languages, while Live makes 43% fewer errors than Scribe v2 Realtime. These are ElevenLabs’ evaluation results, without independent validation in the published evidence. (Announcement)
Both models are available through ElevenAPI and become defaults in the ElevenLabs app. Scribe v3 Live is also available in ElevenAgents.
Existing API customers can switch model IDs to upgrade. The consequential decisions come afterward: whether to enable new output controls, how to evaluate speaker labels and whether a regional deployment supports the features their workflow needs.
What the One-Line Upgrade Actually Changes
ElevenLabs describes migration from Scribe v2 as:
“a one-line change to the model ID.”
The replacement IDs are scribe_v3 for recorded audio and scribe_v3_live for streaming audio. For batch transcription, the existing POST /v1/speech-to-text endpoint accepts the model through its required model_id field. (Announcement, API reference)
That is a straightforward way to select the new recognizer. It does not automatically configure every new formatting or terminology feature, move a workspace into a residency environment or establish compatibility with downstream software.
I’d separate the rollout into two decisions: change the recognizer, then adopt optional output changes. That makes it easier to distinguish a recognition difference from a formatting change when reviewing transcripts. Speaker diarization improvements can still matter with the model upgrade; adopting every new parameter is not a prerequisite.
New Controls Affect More Than Transcript Accuracy
The batch API documents several controls worth reviewing before production migration:
Supplies additional languages alongside language_code; supported by Scribe v3
Gives the model hints for multilingual recordings
numbers_format
Selects digits or words; supported by Scribe v3
Lets applications choose between outputs such as 42 and forty-two
transcript_edit
Applies a natural-language instruction and returns edited_transcript alongside the original
Adds a separate edited output that downstream code must explicitly consume
diarize
Enables speaker annotations
Produces speaker labels for meeting notes, interviews and other multi-speaker recordings
These behaviors come from the transcription API reference. The announcement also says Scribe v3 accepts up to 1,000 keyterms, useful for product names, acronyms and specialist vocabulary. (Announcement)
Number formatting is particularly consequential for systems extracting amounts, dates or identifiers. Applications should check their expected output representation instead of assuming that a more accurate transcript will fit every existing parser.
Natural-language editing has a separate economic and compatibility cost. The API reference specifies a 30% surcharge over base transcription cost, billed for at least 10 seconds of audio. Instructions can contain up to 2,000 characters. Because the edited result is returned separately, simply changing the model ID will not make an application start displaying that version.
For media captions, formatting may be valuable. For clinical documentation, retaining the original transcript alongside the edited version provides a clearer basis for checking whether an edit changed meaning.
Scribe v3 Live Adds Speaker Labels and Contextual Turn Detection
Scribe v3 Live introduces diarization, meaning labels indicating who spoke, to ElevenLabs’ real-time transcription model. It also adds multilingual mode for conversations that switch languages mid-sentence and a keyterm library designed to hold thousands of potentially relevant terms. (Announcement)
The other major change is turn detection. A silence-based system faces a familiar compromise: respond quickly and risk interrupting a pause, or wait longer and make the agent feel slow.
ElevenLabs says Live uses conversation context together with audio to predict when a speaker has finished. The company identifies someone pausing midway through a number as an example of the problem this addresses.
That could matter more to a voice agent than a small improvement in transcript wording: an interruption can prevent the caller from finishing the information the agent needs. The opened API reference covers batch conversion, however, so it provides no basis for describing Live’s turn-detection controls or assuming how developers can tune them.
What the Accuracy Claims Actually Measure
ElevenLabs reports several improvements against the previous generation:
Vendor-reported measure
Claimed improvement
Comparison
Batch word error rate across 102 languages
27% fewer errors
Scribe v3 versus Scribe v2
Real-time transcription errors
43% fewer errors
Scribe v3 Live versus Scribe v2 Realtime
Batch diarization errors overall
12% fewer errors
Scribe v3 versus Scribe v2
Batch diarization errors with three or more speakers
The multilingual evaluation used an internal version of FLEURS, containing short, clean, read speech in 102 languages. Word error rate measures substitutions, deletions and insertions against reference text. A relative reduction of 27% would take a hypothetical 10% error rate to 7.3%; it does not mean a 27-percentage-point improvement.
Clean, single-speaker clips cannot measure speaker attribution in meetings. ElevenLabs therefore also evaluated a company-built dataset of meetings, agent calls and voice notes across 16 languages. It said that dataset would be open-sourced, but it had not been released at publication.
The useful distinction is between evidence of multilingual recognition and evidence of performance on messy conversations. Both matter, but neither guarantees results on a particular hospital’s vocabulary, an overlapping meeting or a noisy phone channel. My view is that these numbers justify evaluating the upgrade, while workload-specific checks should determine rollout.
Data Residency Changes the Deployment Plan
ElevenLabs’ data-residency documentation lists isolated environments in the EU, India and Singapore. Residency is an Enterprise feature; standard customer data storage is in the US.
Residency environment
API base URL
EU
https://api.eu.residency.elevenlabs.io
India
https://api.in.residency.elevenlabs.io
Singapore
https://api.sg.residency.elevenlabs.io
These are separate workspaces, with separate API keys. A new isolated workspace starts blank, and ElevenLabs documents limited migration support. Moving an existing deployment into one of these environments therefore involves more than replacing the model ID.
Regional storage also does not automatically mean all processing stays in-region. ElevenLabs says processing can occur outside the selected location, including through international affiliates and subprocessors for support and moderation.
For EU residency, the documentation describes a configuration using the API and Zero Retention Mode that restricts processing to the EU. Optional integrations, such as custom LLMs or post-call webhooks requiring out-of-region processing, can introduce exceptions.
One feature restriction directly affects the Scribe v3 upgrade: transcript editing is unavailable in isolated environments. Requests setting transcript_edit return an error. A team choosing regional deployment therefore cannot assume it can also use the announced plain-English formatting feature.
That is a concrete deployment tradeoff. If an application requires both residency and standardized output, its formatting plan needs to account for this restriction before migration.
A Practical Rollout Sequence
The published documents support a staged upgrade:
Select the matching model ID. Use scribe_v3 for recorded audio or scribe_v3_live for real-time audio.
Compare representative recordings. Check words, speaker attribution, language switching and domain terminology against the existing deployment.
Choose output controls deliberately. Review language hints, number formatting and terminology support against downstream requirements.
Check editing costs and restrictions. Account for the surcharge, separate edited output and isolated-environment limitation.
Validate the deployment environment. Confirm regional access, credentials, processing conditions and any integrations that move data elsewhere.
The model-selection change is small. The production work is making sure the new transcript, its optional transformations and its handling of sensitive audio match the application’s requirements.
Frequently Asked Questions
3 questions
1
How Large Can Uploaded Files Be?
The batch API accepts uploaded files smaller than 5 GB, with at least 100 milliseconds of audio. Major audio and video formats are supported. (API reference)
2
Can Transcript Editing Be Combined With Redaction?
No. The documented transcript_edit parameter cannot be combined with entity_detection, entity_redaction or use_multi_channel. (API reference)
3
Does Scribe v3 Replace the Medical Model?
The product page still lists Scribe v2 Medical separately as a clinical transcription fine-tune. The published evidence does not provide a head-to-head comparison establishing Scribe v3 as its replacement. (Product page)
