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 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.

​
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.
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, 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:
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). Auto-resolution requires the match to be unique. If two providers in the environment both serve the requested model name, the request is rejected with 409 Conflict rather than routed to one of them — pin the provider to resolve it. 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.

​
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::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 rather than falling back to auto-resolution. A pin that quietly became a guess would defeat the point of setting one. The to11 CLI sends this header, from the provider named in code.claude.yaml.

​
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. 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. 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.