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. For the underlying configuration format behind the dashboard, see 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.
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 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:
[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 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.
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.
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.