Skip to main content
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, describes how model routing works, and shows which SDK reaches each provider. 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 reads the provider’s responses and errors through a dedicated native adapter, or treats it as an OpenAI-compatible endpoint. Either way, the gateway forwards your request body as written; see Which SDK to call a provider with. 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 a dedicated adapter for their own response and error shapes.
Google Gemini and Google Vertex AI each serve two wire formats: their native one and an OpenAI-compatible one. The gateway uses the OpenAI-compatible one unless the provider is set to native mode; see Which SDK to call a provider with.
Cohere chat uses Cohere’s Compatibility API. Chat requests are sent to Cohere’s OpenAI-compatible surface, so you call Cohere models with an OpenAI-shaped request and the gateway forwards it unchanged. Cohere-only chat features are not available through that surface — connectors, documents, citation_options, and the citations they return. Embeddings and rerank are unaffected and still use Cohere’s own /v2/embed and /v2/rerank.

​
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, give it a routing identifier, and choose its access policy: Allow by default (every model except blocked patterns, the default) or Deny by default (only the models you allow). See Providers for the conceptual walkthrough and Models for access policies. Behind the dashboard, each provider is represented as a named entry in the gateway’s configuration. The shape of a single provider entry is:
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. The prefix separator is :: (two colons); everything after the first :: is the model id sent upstream. The examples assume providers whose routing identifiers are openai and anthropic. The gateway never infers a provider from an unprefixed model name. Whichever form names the provider, the provider’s access policy in the request’s environment decides whether the model is served; a model it does not serve returns 404 Not Found. The x-genai-provider request header names a provider type, not one of your connected providers, and does not choose where a request goes. If it is present alongside a prefix that is also a provider type name, such as openai::, and the two disagree, the request is rejected with 400 Bad Request.

​
Pinning a provider by id

x-to11-provider-id names one provider by its id, for a caller that cannot put a pin in the model string — a coding agent picks its own model, and rewriting it to route the request would change what the agent asked for. It is a fallback, not an override: it is read only for an unprefixed model. A <provider-slug>::model, function:: or route:: model keeps deciding and the header is ignored. A model is chosen per request, while a header is often fixed for a whole session by the environment a client runs in, so the model is the more specific statement. When the header names a provider that is not activated in the request’s environment, the request is rejected with 404. The provider id appears in the address of the provider’s page in the dashboard. The to11 CLI sends this header, from the provider named in code.claude.yaml.

​
Which SDK to call a provider with

The gateway does not translate between wire formats. It forwards your request to the provider as written, and the provider’s response comes back in that same format. The endpoint you call sets your request’s wire format, and the provider the request resolves to — named in the model field or selected as a route’s target — must speak that format. Two formats are served on provider-native routes that mirror the provider’s own API, not on the endpoints above. The gateway forwards these bodies as written too:
  • bedrock.converse — AWS Bedrock on its bedrock-runtime endpoint, which is a Bedrock provider’s default base URL. Call /v1/bedrock/runtime/model/{modelId}/converse or /v1/bedrock/runtime/model/{modelId}/converse-stream, the paths of the AWS Bedrock Runtime Converse API under the gateway.
  • gemini.generate — Gemini models on Google Vertex AI in native mode. Call /v1/vertex/projects/{project}/locations/{region}/publishers/{publisher}/models/{model}:generateContent or :streamGenerateContent, the paths of the Vertex AI REST API under the gateway. Google Gemini in native mode, outside Vertex AI, has no route on the gateway; use it in OpenAI-compatible mode.
A request whose wire format differs from the provider’s is rejected with 400 Bad Request and the x-to11-error-code: cross_dialect header before anything is sent to the provider. The message names both formats and the provider. See Routing errors. The same applies to routes: every target of a route must be on a provider that speaks the format your application sends. A request that lands on a target speaking another format is rejected the same way.

​
What reaches the provider

The gateway does not rebuild the request. Three edits to the body are its own:
  • model is replaced by the upstream model id: your model without its <provider-slug>:: prefix, or the model of the route target that serves the request.
  • Keys that the gateway reads for its own telemetry, and that no provider defines, are removed.
  • On a streaming /v1/chat/completions request, stream_options.include_usage is set to true so the provider reports token usage, for every provider except Cohere. The stream then includes a usage chunk whose choices array is empty.
A successful response comes back as the provider sent it; a stream may gain the two additions listed in Streaming. For error bodies, see Error handling.

​
Extended thinking

Anthropic extended thinking blocks (the thinking content type) reach your client as Anthropic sent them, because the response is not rebuilt.

​
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

Every provider serves chat on the endpoint that matches its wire format; see Which SDK to call a provider with, including the provider-native routes for AWS Bedrock and Google Vertex AI. Other endpoints are available only for specific provider families. Requests for an unsupported feature return 400 Bad Request.