You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Lingo.dev supports several named LLM providers out of the box (OpenAI, Anthropic, Google, Groq, Mistral, OpenRouter, Ollama). There is no first-class provider entry for a smart-routing OpenAI-compatible gateway, so users who want to route all translations through such a gateway have to rely on the generic OPENAI_BASE_URL override (see #1729) and a hand-written provider:model string.
Solution
Add OrcaRouter as a named provider. OrcaRouter is an OpenAI-compatible LLM gateway with a smart routing model (orcarouter/auto). Adding it as a first-class provider entry mirrors the existing OpenRouter wiring and gives users a discoverable, documented option instead of a generic passthrough.
It also runs gateway-level, zero-trust security for AI agents on the same endpoint — screening every prompt/response and governing every tool call on a default-deny basis, with no application code changes.
Implementation sketch (mirrors the existing OpenRouter provider):
New orcarouter case in createAiModel (new compiler) that builds an OpenAI-compatible client pointed at https://api.orcarouter.ai/v1 with ORCAROUTER_API_KEY.
New orcarouter entry in providerDetails (new compiler + legacy compiler), the CLI settings schema, llm-api-key.ts, and the CLI processor / explicit localizer.
Update the providerSchema enum in @lingo.dev/_spec.
Add ORCAROUTER_API_KEY to docs and .env examples.
Alternatives
Leave users to the generic OPENAI_BASE_URL passthrough (Add openAI compatible provider #1729). This works but offers no discoverable, named integration and no provider metadata (key links, config keys).
Checklist
Add named orcarouter provider across the provider registries
Problem
Lingo.dev supports several named LLM providers out of the box (OpenAI, Anthropic, Google, Groq, Mistral, OpenRouter, Ollama). There is no first-class provider entry for a smart-routing OpenAI-compatible gateway, so users who want to route all translations through such a gateway have to rely on the generic
OPENAI_BASE_URLoverride (see #1729) and a hand-writtenprovider:modelstring.Solution
Add OrcaRouter as a named provider. OrcaRouter is an OpenAI-compatible LLM gateway with a smart routing model (
orcarouter/auto). Adding it as a first-class provider entry mirrors the existing OpenRouter wiring and gives users a discoverable, documented option instead of a generic passthrough.It also runs gateway-level, zero-trust security for AI agents on the same endpoint — screening every prompt/response and governing every tool call on a default-deny basis, with no application code changes.
Implementation sketch (mirrors the existing OpenRouter provider):
orcaroutercase increateAiModel(new compiler) that builds an OpenAI-compatible client pointed athttps://api.orcarouter.ai/v1withORCAROUTER_API_KEY.orcarouterentry inproviderDetails(new compiler + legacy compiler), the CLI settings schema,llm-api-key.ts, and the CLI processor / explicit localizer.providerSchemaenum in@lingo.dev/_spec.ORCAROUTER_API_KEYto docs and.envexamples.Alternatives
OPENAI_BASE_URLpassthrough (Add openAI compatible provider #1729). This works but offers no discoverable, named integration and no provider metadata (key links, config keys).Checklist
orcarouterprovider across the provider registries