LLM Models
Every localization engine on Lingo.dev uses LLM models to produce translations. You choose which model handles each locale pair, configure fallbacks for reliability, and use wildcard locales to set defaults - all without managing API keys or provider accounts.
Available models#
Lingo.dev provides access to hundreds of models from every major provider through a single platform:
| Provider | Notable models |
|---|---|
| OpenAI | GPT-6.1 Sol, GPT-6 Astra, GPT-6 Luna, GPT-5.6 Terra |
| Anthropic | Claude Opus, Claude Sonnet, Claude Haiku, Claude Fable |
| Gemini 3.8 Flash, Gemini 3.1 Pro, Gemma 4 | |
| xAI | Grok 4.7, Grok 4.20 |
| Meta | Muse Spark 1.3, Muse Glimmer 30B, Llama 4 Maverick |
| Mistral | Mistral Large 3, Mistral Medium 3.5, Mistral Small 4 |
| DeepSeek | DeepSeek V4.1 Flash, DeepSeek V4 Pro |
| NVIDIA | Nemotron 3.5 Lightning, Nemotron 3 Ultra |
| Qwen | Qwen3.8 Max, Qwen3.8 Flash |
The full catalog - with context window sizes - is in the model picker when you add a model config to a localization engine. Your AI assistant can list it too, through the MCP server.
No provider accounts needed
You don't need API keys from individual providers. Lingo.dev handles authentication, billing, and routing to all models through a unified infrastructure.
Pinned versions and latest aliases#
Most entries in the catalog name an exact release, so a model config keeps producing the same translations until someone changes it. Several providers also publish a moving alias - claude-sonnet-latest, gpt-sol-latest, gemini-pro-latest, deepseek-pro-latest - that resolves to the newest release in that family at request time. Pick an exact release when reproducibility across model generations matters, and an alias when the localization engine should follow the frontier without edits.
Model configs#
A model config assigns a specific model to a source-target locale pair within a localization engine.
| Field | Description |
|---|---|
| Provider | The model provider (e.g., openai, anthropic, google) |
| Model | The specific model (e.g., gpt-6.1-sol, claude-sonnet-5.5) |
| Source locale | The source locale, or * for any source |
| Target locale | The target locale, or * for any target |
When the engine receives a translation request, it selects the most specific matching config based on the source and target locales.
Defaults and customization#
The Lingo.dev team has been researching which models produce the best translations for each language pair since 2023. When a new localization engine is created, it comes pre-configured with sensible model defaults - primary models and fallbacks selected based on that research, optimized for quality across common and low-resource languages alike. Most teams won't need to change them.
These defaults are designed to work well out of the box. You can edit any model config, swap providers, add fallbacks, or override specific locale pairs with models you prefer - but the defaults already reflect what we've found works best across hundreds of language pairs. The engine's model configuration is fully yours to control.
Fallback models#
LLMs evolve fast - new models ship weekly, capabilities improve with each generation, and pricing drops as competition intensifies. But that velocity comes at a cost: provider outages, rate limits, content filter changes, and model deprecations are routine. A production localization pipeline that depends on a single model is a pipeline that will eventually break.
Lingo.dev's localization engine is purpose-built for production-grade translation workflows. Each locale pair supports a fallback model - if the primary model fails, the engine automatically and transparently tries the next fallback model, without any intervention or failed requests reaching your users.
How fallback ordering works#
The engine sorts available configs by specificity, then by priority:
- Target locale specificity - exact target locale beats wildcard
* - Source locale specificity - exact source locale beats wildcard
* - Priority - default, then fallback
Example#
Given these configs for an engine:
| Source | Target | Model | Priority |
|---|---|---|---|
en | de | GPT-6.1 Sol | Default |
en | de | Claude Sonnet 5.5 | Fallback |
* | de | Gemini 3.8 Flash | Default |
* | * | Claude Haiku 4.5 | Default |
A request translating en → de tries models in this order:
- GPT-6.1 Sol - exact match, default
- Claude Sonnet 5.5 - exact match, fallback
- Gemini 3.8 Flash - wildcard source, exact target, default
- Claude Haiku 4.5 - wildcard both, default
A request translating fr → de skips the first two (source doesn't match) and starts at Gemini 3.8 Flash.
Fallback tracking
When a fallback model handles a request, the engine records it in the request log. Open an engine's Logs tab – the Model column shows which model served each request – to spot primary models that keep falling through.
Wildcard locales#
Set source or target locale to * to create default configs that apply when no locale-specific config exists.
Common patterns:
| Source | Target | Model | Purpose |
|---|---|---|---|
* | * | GPT-6.1 Sol | Catch-all default for any locale pair |
en | * | Claude Sonnet 5.5 | Default for all English-source translations |
* | ja | Gemini 3.8 Flash | Use a specific model for Japanese targets |
en | de | Mistral Large 3 | Override default for this specific pair |
Specific configs always take priority over wildcard configs. Use wildcards to set sensible defaults, then override for locale pairs that need special handling.
Managing model configs via MCP#
If you use the Lingo.dev MCP server, your AI coding assistant can configure models directly:
"Set GPT-6.1 Sol as the primary model for English to German,
with Claude Sonnet 5.5 as fallback.""Add a catch-all model config using Claude Haiku 4.5 for
all locale pairs."