Multilingual speech-to-text in 2026: how Universal-3.5 Pro handles code-switching, language detection, and non-English audio

Every speech-to-text vendor publishes a language count. Almost none of them tell you what that number actually buys you.

A model can appear on a long language list and still fall apart the moment a speaker drops an English product name into a Spanish sentence. It can nail studio-read Mandarin and mangle the same speaker on a phone call. The count tells you what the model will attempt, not what it will get right.

So here's the useful version: what multilingual means at the model level, where the real numbers are, and how to run a test that predicts your production accuracy instead of flattering it.

What makes a speech-to-text API genuinely multilingual?

A genuinely multilingual speech-to-text API transcribes audio in more than one language without you declaring the language up front, and handles more than one language inside a single utterance. Those are two different capabilities, and most APIs only have the first.

Breadth and depth pull in opposite directions. A model spread across a hundred languages spreads its capacity thin. A model trained hard on 18 gets much better at each of them — and learns the boundaries between them, which is what code-switching requires.

Three things separate a real multilingual model from a long language list:

• Native code-switching. One pass, one model, mid-sentence language changes handled without configuration or a routing layer in front.
• Automatic language detection that's accurate enough to trust on unlabelled audio, plus the option to override it when you already know the answer.
• Accuracy that survives contact with real audio — accents, phone codecs, crosstalk, and domain vocabulary, not just clean read speech.

The rest of this post works through each of those, with the numbers.

How many languages does AssemblyAI support, and on which model?

Universal-3.5 Pro handles 18 languages with native code-switching. Universal-2 covers 99+ languages without it. Those are different models with different jobs, and conflating them is the single most common mistake in multilingual evaluations.

Here's the honest breakdown:

The 18 languages on the Universal Pro line: English, Spanish, French, German, Italian, Portuguese, Arabic, Danish, Dutch, Finnish, Hebrew, Hindi, Japanese, Mandarin, Norwegian, Swedish, Turkish, and Vietnamese. Universal-3.6 Pro Realtime covers all 18 plus 14 more for streaming — Afrikaans, Cantonese, Catalan, Estonian, Galician, Korean, Marathi, Norwegian Nynorsk, Persian, Romanian, Russian, Urdu, Xhosa, and Zulu — for 32 in total, with automatic language detection.

You don't have to choose one and live with it. The documented pattern is a fallback array — "speech_models": ["universal-3-5-pro", "universal-2"] — which takes the flagship where it's supported and drops to the broad-coverage model where it isn't. Omit speech_models entirely and you auto-upgrade to the latest Universal Pro model as it ships. Note the plural: async takes speech_models, streaming takes the singular speech_model. Full breakdown on the pricing page.

How good is code-switching, really?

On a five-language-pair code-switching benchmark, Universal-3.5 Pro averages 7.69% normalized word error rate — ahead of ElevenLabs Scribe v2 at 8.77%, Deepgram Nova-3 Multilingual at 12.22%, and OpenAI GPT-4o Transcribe at 44.58%. Lower is better. Every figure below is published on our public benchmarks page.

Two things worth reading out of that table. The generational gap is real — Universal-3.5 Pro improved on Universal-3 Pro by 1.38 points of average WER on exactly the task that's hardest to fake. And the spread at the bottom isn't a tuning problem. A 44% error rate on code-switched audio is a model translating when it should be transcribing, which is the classic failure mode when a multimodal model gets pointed at mixed-language speech.

None of this needs configuration. No language-pair parameter, no second pass, no routing layer deciding which model gets which segment. The 18-language model produces one transcript with the language changes intact.

Ollang, which delivers localization and subtitling for enterprise clients, put a number on what that's worth in production:

"The 30-40% reduction in speech-to-text errors has significantly improved our production efficiency and client satisfaction. We've achieved industry-leading word error rates for non-English audio, which is critical for serving our enterprise clients." — Ebru Yildirim, Founder & CEO

Notta, one of the leading transcription brands in Japan and across Asia, builds on the same non-English foundation. You can see more of who's building on this in our customer stories.

When should you use automatic language detection — and when should you skip it?

Automatic language detection identifies the spoken language across 130+ detectable languages and needs at least 15 seconds of audio to be reliable. Use it when the language genuinely varies and you can't know it in advance. Skip it when you can.

That second half matters more than people expect. If you already know the call is in German, setting language_code explicitly beats asking the model to work it out. You remove a class of error, you remove the 15-second warm-up, and you stop the model second-guessing itself on an accented speaker.

Detection and code-switching also aren't the same feature. Detection picks a language for the file; code-switching handles multiple languages inside it. If your audio mixes languages mid-sentence, you want code-switching, not detection running repeatedly.

One newer option, if your problem is spelling rather than language: async transcription accepts language_detection_options.localization, so you can pass ["en_au"] or ["en_uk"] for regional spelling conventions without giving up detection or code-switching. English-only today. If you've ever shipped "color" to an Australian customer base and heard about it, that's the parameter.

How do keyterms and contextual prompting improve non-English accuracy?

Keyterms prompting biases the model toward specific strings — names, SKUs, drug names, internal jargon — and it's the strongest accuracy lever you have on non-English audio, because domain vocabulary is exactly what a multilingual model is thinnest on.

The concrete limits differ by surface, so check which one you're on before you build a term list:

• Async / pre-recorded. keyterms_prompt accepts up to 1,000 words or phrases, with a maximum of six words per phrase, priced at +$0.05/hr. Treat 1,000 as a ceiling rather than a promise: actual capacity may be lower due to internal tokenization, each word in a multi-word phrase counts toward the limit, and capitalization and longer words consume more capacity.
• Streaming. A maximum of 100 keyterms per session, each string 50 characters or shorter. Go over 100 and the request errors; individual terms longer than 50 characters are ignored.
• Universal-2. Keyterms prompting is supported, with a lower ceiling than the Universal Pro line — check the docs for the current limit.
• On Universal-3.6 Pro Realtime, keyterm prompting is included free. No add-on line item.
• On streaming, both prompt and keyterms_prompt can be updated mid-session with an UpdateConfiguration message, no reconnect required. Sending an empty array clears them.

Contextual prompting is the other half. Rather than listing terms, you describe the situation — a meeting agenda, a prior clinical note, a product catalogue — and the model uses it to disambiguate. The two levers do different jobs: prompt tells the model what the conversation is, keyterms_prompt tells it which exact strings to expect. In internal healthcare testing, feeding a patient's prior-visit note cut missed medical terms by 31%. One practical note for multilingual work: if a session mixes three or more languages, prior-turn context can occasionally nudge the model toward translating rather than transcribing. If you see that drift, pin a single transcription language in the prompt.

Worth knowing: word_boost is being retired on September 11, 2026. If you're still on it, keyterms prompting is the migration path. The API documentation has the parameter-level detail.

Can you translate transcripts into other languages?

Yes — translation targets 100+ languages, and it's pre-recorded only. It runs as part of the Speech Understanding API, so one request can return the transcript, the translation, and whatever else you need alongside it: entity detection, sentiment, topics, PII redaction.

Keep the distinction clean, because it's the source of a lot of confused evaluations. Transcription in 18 languages means the transcript comes back in whatever was spoken. Translation in 100+ means you render that transcript somewhere else. You'll often want both — transcribe the call in the customer's language, translate it into the language your reviewers read.

How to run a multilingual accuracy test that predicts production

Vendor benchmarks are a filter, not a decision. Here's a test that takes an afternoon and will tell you more than any published table.

1. Build the corpus from your own recordings. Two to three hours per language of real production audio — the phone codecs, the background noise, the interruptions. Read speech overstates every model's accuracy by a wide margin.
2. Include the code-switching you actually see. If a third of your Spanish calls contain English product names, a third of your Spanish test set should too.
3. Cover your real accent distribution. Not "Spanish" — Mexican, Argentine, Castilian, and whatever else shows up in your logs, in roughly the proportions your traffic has.
4. Score entities separately from words. A 6% WER that misses every account number is worse for most products than an 8% WER that gets them all. Word error rate averages over exactly the tokens you care most about, which is a known weakness of the metric.
5. Normalize consistently across vendors. Casing, punctuation, and number formatting will swing WER by points if you don't. Our evaluation guide walks through the setup.
6. Test with the features you'll ship turned on. If you're running speaker diarization in production, benchmark with it on — multi-speaker multilingual audio behaves differently.

Final words

The interesting shift in multilingual speech-to-text isn't that language counts are going up. It's that at the top of the stack they're going down, on purpose.

Universal-3.5 Pro covers 18 languages and beats much broader models on the tasks that break in production. That's a deliberate trade: fewer languages, modelled properly, with the boundaries between them learned rather than bolted on. Universal-2 is still there for the long tail, and the fallback array means you don't have to pick.

Which means the right question for your evaluation was never "how many languages." It's "how many of my languages, and how well." Both are answerable in an afternoon with your own audio, and no vendor table will answer them for you.

Frequently asked questions

What speech-to-text API works best for multiple languages?

It depends on whether you need depth or breadth. For the 18 languages on the Universal Pro line, Universal-3.5 Pro leads the published code-switching benchmark at 7.69% average normalized WER, ahead of ElevenLabs Scribe v2, Deepgram Nova-3 Multilingual, and OpenAI GPT-4o Transcribe. For languages outside that list, Universal-2 covers 99+ languages, and you can chain the two so requests fall back automatically.

Which languages are supported by speech-to-text APIs?

Coverage varies by model, not by vendor. Universal-3.5 Pro supports 18 languages with native code-switching: English, Spanish, French, German, Italian, Portuguese, Arabic, Danish, Dutch, Finnish, Hebrew, Hindi, Japanese, Mandarin, Norwegian, Swedish, Turkish, and Vietnamese. Universal-2 supports 99+ languages, automatic language detection identifies 130+, and translation targets 100+.

Can AssemblyAI handle multilingual audio with code-switching?

Yes, natively and without configuration. Universal-3.5 Pro handles mid-sentence language changes across its 18 languages in a single pass, with no language-pair parameter and no separate routing step. The streaming model, Universal-3.6 Pro Realtime, does the same in real time across 32 languages, including Hinglish, and averages 7.20% word error rate on the same five code-switching language pairs.

How do transcription services handle multiple languages in the same audio?

There are two approaches, and they perform very differently. The older pattern detects a language, routes to a language-specific model, and re-detects when it thinks something changed — which loses accuracy at every boundary. The newer pattern uses one model trained across languages that has learned the transitions, which is what produces the benchmark gap on code-switched audio.

How do I transcribe multilingual conference calls where speakers switch languages mid-sentence?

Send the audio to Universal-3.5 Pro with speaker diarization enabled and let code-switching handle the language changes. Don't set a single language_code if speakers genuinely mix languages, since that commits the model to one language. Add keyterms prompting for names and internal vocabulary, which is where multilingual transcripts most often go wrong.

How do I enable bilingual transcripts in my application?

Transcribe with Universal-3.5 Pro so the source transcript preserves both languages as spoken, then request translation through the Speech Understanding API for the second rendering. Translation is available for pre-recorded audio only and targets 100+ languages, so a live bilingual view needs the transcription and translation steps handled separately.