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.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.
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:Model routing
The gateway routes each request based on themodel field in the request body. The field can take several forms.
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-levelsystemfield. max_tokensis forwarded directly.toolsdefinitions are translated from OpenAIparametersto Anthropicinput_schema.- The response is translated back to OpenAI
choices[].messageformat.
Anthropic to OpenAI
When an Anthropic-format request is routed to OpenAI:- The top-level
systemfield 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.
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.
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.
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.