> ## Documentation Index > Fetch the complete documentation index at: https://to11.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Providers > Supported LLM providers, model routing, and format translation. The to11 AI Gateway routes requests to LLM providers on your behalf. **to11 operates the gateway for you** — you add providers, configure credentials, and define routing in the dashboard (**project → Gateway**), not by editing any configuration file directly. This page lists the providers the gateway supports and describes how model routing and format translation behave. For the conceptual model, see [Providers](/deploy/concepts/providers). For the underlying configuration format behind the dashboard, see [Configuration](/reference/configuration). ## Supported providers The gateway supports the following providers. The **canonical id** is the identifier the gateway uses internally for each provider; you will see it in the dashboard and in routing prefixes. The **format** indicates whether the gateway uses a dedicated native adapter for the provider's request, response, and error shapes, or treats it as an OpenAI-compatible endpoint. All providers support streaming. Some providers are in beta; their error handling and parameter coverage may be less complete than providers with native adapters. ### Native-format adapters These providers have dedicated request/response and error translation. | Provider | Canonical id | Format | | ---------------- | --------------- | --------------------------- | | OpenAI | `openai` | Native | | Anthropic | `anthropic` | Native | | Cohere | `cohere` | Native | | Google Gemini | `google-gemini` | Native or OpenAI-compatible | | Google Vertex AI | `gcp-vertex-ai` | Native or OpenAI-compatible | | AWS Bedrock | `aws-bedrock` | Native | Google Gemini and Google Vertex AI are dual-protocol: they can be addressed in their native format or in OpenAI-compatible mode. ### OpenAI-compatible providers These providers speak the OpenAI `/chat/completions` format. | Provider | Canonical id | Format | | --------------------- | --------------- | ----------------- | | xAI | `xai` | OpenAI-compatible | | Mistral | `mistral` | OpenAI-compatible | | Groq | `groq` | OpenAI-compatible | | Together AI | `together` | OpenAI-compatible | | Fireworks AI | `fireworks` | OpenAI-compatible | | DeepSeek | `deepseek` | OpenAI-compatible | | Perplexity | `perplexity` | OpenAI-compatible | | Azure OpenAI | `azure-openai` | OpenAI-compatible | | OpenRouter | `openrouter` | OpenAI-compatible | | Cerebras | `cerebras` | OpenAI-compatible | | SambaNova | `sambanova` | OpenAI-compatible | | AI21 | `ai21` | OpenAI-compatible | | Databricks | `databricks` | OpenAI-compatible | | HuggingFace | `huggingface` | OpenAI-compatible | | DeepInfra | `deepinfra` | OpenAI-compatible | | NVIDIA NIM | `nvidia-nim` | OpenAI-compatible | | Cloudflare Workers AI | `cloudflare-ai` | OpenAI-compatible | | Novita AI | `novita-ai` | OpenAI-compatible | | Nebius | `nebius` | OpenAI-compatible | | Moonshot | `moonshot` | OpenAI-compatible | | Ollama | `ollama` | OpenAI-compatible | | vLLM | `vllm` | OpenAI-compatible | ## Configuring a provider You add and configure providers in the dashboard under **project → Gateway**. For each provider you select the provider, supply credentials, and choose which models it serves. Models are configured per project — the dashboard lists the models available for the provider you select. See [Providers](/deploy/concepts/providers) for the conceptual walkthrough. Behind the dashboard, each provider is represented as a named entry in the gateway's configuration. The shape of a single provider entry is: ```toml theme={null} [providers.openai] base_url = "https://api.openai.com/v1" models = ["..."] credential = "env::OPENAI_API_KEY" timeout_ms = 30000 ``` You do not edit this format directly in the hosted product; the dashboard manages it for you. See [Configuration](/reference/configuration) for the full configuration reference. ## Model routing The gateway routes each request based on the `model` field in the request body. The field can take several forms. | Form | Example | Behavior | | ----------------- | ------------------------------ | ------------------------------------------------------- | | Unprefixed model | `gpt-4o` | Auto-resolves to the provider configured for that model | | `provider::model` | `anthropic::claude-sonnet-4-6` | Pins the request to a specific provider | | `function::name` | `function::summarize` | Dispatches to a named function | | `route::name` | `route::balanced-gpt4o` | Dispatches to a named route | The prefix separator is `::` (two colons). You can also pin a provider with the `x-genai-provider` request header. If the header and a `provider::` prefix are both present and disagree, the request is rejected with `400 Bad Request`. ## Cross-format translation The gateway translates between request and response formats automatically when the caller's SDK format differs from the upstream provider's format. ### OpenAI to Anthropic When an OpenAI-format request is routed to Anthropic: * Messages with `role: "system"` are extracted and sent as Anthropic's top-level `system` field. * `max_tokens` is forwarded directly. * `tools` definitions are translated from OpenAI `parameters` to Anthropic `input_schema`. * The response is translated back to OpenAI `choices[].message` format. ### Anthropic to OpenAI When an Anthropic-format request is routed to OpenAI: * The top-level `system` field is converted to a `{"role": "system"}` message. * Content blocks are normalized. * The response is translated to Anthropic `content[]` format. ### Streaming translation Streaming uses a fast path when the client and upstream wire formats match, and a normalized path when they differ. | Client SDK | Upstream | Path | Why | | ---------- | --------- | ---------- | ------------------------------------------ | | OpenAI | OpenAI | Fast path | Wire formats match | | OpenAI | xAI | Fast path | xAI uses OpenAI-compatible SSE | | Anthropic | OpenAI | Normalized | Incompatible SSE wire formats | | Anthropic | Anthropic | Normalized | Anthropic ingress uses the normalized path | Both paths produce identical telemetry and apply the same output guardrail checks. ### Extended thinking Anthropic extended thinking blocks (`thinking` content type) are preserved in Anthropic-format responses. When a response is serialized to OpenAI format, thinking blocks are omitted, since OpenAI has no equivalent. ## Credentials A project's provider credentials can be supplied in two ways: * **Managed (server-side).** You store the provider credential in the dashboard. to11 holds the credential and attaches it to requests routed to that provider. * **Caller-supplied (BYOK).** The caller passes the provider credential on the request, and the gateway forwards it to the upstream provider. These determine how the gateway authenticates to the upstream provider. They are distinct from to11 platform authentication, which uses the `x-to11-authorization` and `x-to11-project-id` headers; see the [API reference](/reference/api). ## Provider limitations Chat completions are supported for every provider. Other endpoints are available only for specific provider families. | Feature | OpenAI-family | Anthropic | | ----------------------------------------------- | :-----------: | :-------: | | Chat completions | Yes | Yes | | Embeddings | Yes | No | | Image generation | Yes | No | | Audio transcription | Yes | No | | Audio speech (TTS) | Yes | No | | Files API | Yes | No | | Token counting | No | Yes | | `json_object` / `json_schema` structured output | Yes | No | Anthropic does not support `json_object` or `json_schema` structured output; such a request returns `400 Bad Request`. Requests for any other unsupported feature also return `400 Bad Request`.