A TTS model that switches accents mid-sentence is doing one of two things: routing to a different language-specific model at a transition point, or reverting to its dominant training language when it encounters a word it associates with that language. Both produce the same audible result, which is a voice that sounds inconsistent and artificial.
This is a structural problem, not a configuration problem. It cannot be fixed by tuning parameters on a model that was not built to handle mixed-language content. It requires a model that handles language transitions natively, within a single inference pass, without routing to separate models per language.
This guide covers why accent drift and mid-sentence language switching happen, what architectures produce them, and how Gradium handles code-switching across its five supported languages.
Why do TTS models switch accents mid-sentence?
Model architecture: language-specific routing
Many multilingual TTS systems are not truly multilingual models. They are collections of monolingual models, one per language, with a router that detects the language of the input and sends the request to the appropriate model. This architecture scales easily to many languages but creates two problems for mixed-language content.
First, a sentence that contains words from two languages triggers a routing decision that was designed for monolingual inputs. The router either assigns the sentence to one language model (which then mispronounces words from the other language) or attempts to split the sentence and route segments to different models (which creates a discontinuity in voice, prosody, and timing at the transition point).
Second, latency is not consistent across languages, because different monolingual models may run on different infrastructure with different throughput characteristics.
Gradium uses a single model that serves all five of its supported languages, including mid-sentence transitions. Routing does not select per-language models; the same model serves all 5 languages, which keeps the latency profile stable regardless of which language a given utterance contains, including across in-sentence code-switches.
Training data distribution: English dominance
Most TTS models are trained primarily on English data. When non-English data is added, it is typically added at lower volume, which means the model's phonological patterns for non-English languages are less well-learned. When the model encounters input in a supported non-English language, it produces output that reflects both the target language's patterns and the English-dominant model's baseline, resulting in accented output in the non-English language.
This is what Gradium's multilingual content describes as the "native fluency" distinction: "a TTS model trained primarily on English data and extended to other languages often produces accented output in non-English languages. The synthesized voice sounds like a non-native speaker of the target language. Native fluency in a language requires training on substantial native-speaker data, with attention to phoneme inventory, prosody patterns, and natural speech rhythm specific to the language."
For mid-sentence transitions specifically, an English-dominant model that encounters a French phrase will tend to produce the French words with English phonological patterns, because the model's default phonological inventory is English.
Input boundaries that break language detection
A third cause is specific to streaming pipelines: the language detection system, if external to the synthesis model, may not have enough context to detect a language switch correctly when text arrives in small fragments. A sentence that arrives word by word may have its language assigned incorrectly on the first words and then never corrected when subsequent words arrive in a different language.
This is why mid-sentence code-switching handled inside the TTS model itself, rather than by an external language detector, is architecturally more reliable. The model has access to all the text in the message when making phonological decisions.
What does code-switching actually require?
Code-switching without quality degradation requires the model to handle three things simultaneously at every language transition point.
Language detection from context. The model must recognize that the input has shifted language within the sentence, not just from one sentence to the next. This requires the model to process the text as a sequence rather than applying a fixed language assignment to the whole input.
Phoneme inventory switching. Each language uses a different set of phonemes. At a transition point, the model must switch from one phoneme inventory to another cleanly, without bleeding one language's phonological patterns into the other. A French phrase surrounded by English text must be produced with French phonemes, not English phonemes approximating French sounds.
Prosodic continuity. The voice should not sound discontinuous at the transition. Pitch contour, rhythm, and timing patterns should flow naturally across the language boundary rather than resetting at the switch point.
Most TTS systems that handle individual languages well fail on at least one of these three when the languages appear in the same sentence.
How does Gradium handle code-switching?
Gradium supports native mid-sentence code-switching across English, French, German, Spanish, and Portuguese. A single API call can synthesize text that transitions between languages within the same utterance. For example, a voice agent serving bilingual speakers can move naturally between English and Spanish within a single turn without restructuring the pipeline or issuing separate TTS requests.
No configuration is required to enable code-switching. The same API call and the same model handle monolingual and mixed-language input identically. No language flag is required in the request for the switch to be handled correctly.
Latency is consistent across languages and transitions. Because a single model serves all five languages, the TTFA profile does not change when the input language changes or when a sentence mixes languages. On the independent Coval benchmark (May 4, 2026), Gradium records 155 ms TTFA P50 regardless of input language.
Code-switching is relevant for a specific set of markets, particularly those where it is natural in spoken communication, such as US Spanish-English. Other common contexts include multilingual customer support where the agent may need to confirm information in a different language than the conversation is conducted in, and international calling scenarios where the agent addresses content in one language and identifiers or proper nouns in another.
How does language depth show up in WER?
Pronunciation accuracy varies per language across providers, and that variance is directly related to the training data depth problem. On the MiniMax Multilingual TTS Test Set benchmark (April 29, 2026), comparing Gradium against competitors on WER per language:
| Provider | Avg WER | EN | FR | ES | PT | DE |
|---|---|---|---|---|---|---|
| Gradium | 1.11% | 0.41% | 2.16% | 0.40% | 2.02% | 0.54% |
| ElevenLabs Flash v2.5 | 1.52% | 0.36% | 2.45% | 0.99% | 3.18% | 0.61% |
| Cartesia Sonic-3 | 1.56% | 0.83% | 2.66% | 1.19% | 2.74% | 0.37% |
| ElevenLabs Multilingual v2 | 1.68% | 0.37% | 2.06% | 1.93% | 3.34% | 0.72% |
Source: Gradium blog, gradium.ai/blog/word-error-rate-evaluations, April 29, 2026. ASR: Qwen3-ASR.
The gaps between providers are widest on Spanish and Portuguese, where training data for non-Castilian and non-Brazilian variants is most likely to be underrepresented. This is the same distributional problem that causes accent drift: a model with lower WER per language has deeper phonological coverage in that language, which directly reduces the likelihood of accent bleed at code-switch boundaries.
Code-switching vs language breadth: what is the tradeoff?
Gradium supports 5 languages with native code-switching. Cartesia supports 40+ languages; its code-switching capability is not publicly documented. ElevenLabs supports 32 to 70+ languages; its code-switching is documented as limited. Deepgram Aura-2 supports 7 languages; code-switching is not documented.
The tradeoff is explicit: a model optimized for native fluency and reliable code-switching across 5 languages is built differently from a model optimized to cover 40+ languages at varying quality levels. Rather than optimizing for breadth, Gradium's multilingual capability is built around depth in each supported language and the ability to handle mixed-language content natively.
For products targeting English, French, German, Spanish, or Portuguese, native code-switching without quality or latency penalty is available in a single model. For products requiring more than these five languages, Cartesia (40+ languages) or ElevenLabs (32 to 70+ languages) are the options, with code-switching behavior to be evaluated per provider.
How do you keep a regional accent consistent?
Code-switching is distinct from regional accent consistency, though both trace back to the same training data problem.
Regional accent consistency refers to whether a TTS model maintains a specific regional accent throughout a session, rather than reverting to a generic "standard" variant of the language mid-output. A model trained on General American English may produce a Scottish English clone correctly on short inputs but revert to General American patterns on longer outputs.
Gradium's voice cloning preserves the accent of the reference speaker from a single 10-second sample. Coverage spans regional accents documented across all five languages: American, British (RP and regional), Australian, Indian, Irish, Scottish, and South African English; Metropolitan French, Quebecois, Belgian, Swiss French, and African French; Castilian, Mexican, Argentinian (including Rioplatense), Colombian, and Caribbean Spanish; High German, Austrian, Swiss German, and Bavarian; European and Brazilian Portuguese.
For voice cloning specifically, Gradium's cross-lingual cloning means a voice cloned in one language can synthesize text in any of the other four supported languages, with the speaker's characteristic timbre preserved and the phoneme inventory of the target language applied. This is documented for English, French, Spanish, and German.
What should you check if you are seeing accent switching?
Four questions help diagnose the cause:
Is the model routing to different language-specific models? If the TTS system uses routing, language transitions trigger model switches, which produce discontinuities at transition points. The fix is to use a TTS model that handles all required languages in a single model rather than routing.
Is the model reverting to an English-dominant baseline on non-English words? This is the training data distribution problem. The fix is to use a model with documented native fluency in the target languages, not just nominal language support.
Is the language transition within a single API message, or split across messages? In streaming pipelines, sending each word as a separate message can fragment the language context available to the model. Sending complete phrases or sentences in single messages gives the model more context for accurate language detection at transition points.
Is the voice clone degrading on language boundaries? Cross-lingual voice cloning is not universally supported. If the clone was created in one language and is being used to synthesize another, the cloning pipeline must explicitly support cross-lingual synthesis for the voice characteristics to remain consistent across the language switch.
Glossary
Code-switching
The presence of two or more languages within a single utterance or conversational turn. In TTS, handling code-switching natively means producing natural-sounding output at language transition points without routing to different models, without audible discontinuity, and without applying one language's phonological patterns to the other. Gradium supports code-switching natively across English, French, German, Spanish, and Portuguese.
Language-specific routing
An architecture where a multilingual TTS system detects the language of the input and sends it to a corresponding monolingual model. Produces clean output for monolingual inputs but creates discontinuities at mid-sentence language transitions and inconsistent latency across languages.
Native fluency
The property of a TTS model that produces output reflecting the actual phoneme inventory, prosody patterns, and natural speech rhythm of the target language, rather than projecting English-dominant patterns onto non-English languages. Requires substantial native-speaker training data per language.
Accent drift
The tendency of a TTS model to revert to its dominant training language's phonological patterns when producing output in a non-dominant language, resulting in accented output. Related to code-switching failures at language transition points.
Cross-lingual voice cloning
Voice cloning where a voice created from a reference speaker in one language can synthesize text in one or more other languages, preserving the speaker's characteristic timbre while adapting to the target language's phoneme inventory. Documented for Gradium across English, French, Spanish, and German.
Phoneme inventory switching
The process by which a TTS model applies the correct set of speech sounds (phonemes) for each language segment in a mixed-language input. Required for clean code-switching: a French phrase must be produced with French phonemes, not approximated with English phoneme patterns.