gpt-4o, claude-sonnet-4-6, text-embedding-3-small, and so on. Each provider you connect has an access policy, which decides which models the gateway serves through it.
Access policy
The access policy has two settings.- Allow by default — allow all models except those that are explicitly blocked. This is the default for a newly connected provider, which starts with nothing blocked, so every model the provider offers is served, including models the vendor releases later.
- Deny by default — only allow models that are explicitly allowed. Deny otherwise. The allowed models are matched exactly as written. Providers connected before access policies existed keep this setting.
* matches any run of characters, including none; every other character is literal. *opus* blocks every model whose id contains opus. gpt-4o blocks gpt-4o and GPT-4o, but not gpt-4o-mini.
The access policy belongs to a provider’s version. Each environment is pinned to one version of the provider, so staging can allow by default while production denies by default — pin a different version in each. The provider’s Environments tab shows each environment’s setting: Allow by default (with · N blocked when patterns are blocked) or Deny by default · N models. You choose the policy when you connect a provider, and change it later on the provider’s Models tab; see Change the access policy.
Naming the provider in a request
A model id alone does not tell the gateway which of your connected providers to use, so every request names one. There are three ways to do it:
The provider slug is the routing identifier you give the provider when you connect it. The connect drawer shows the resulting prefix under the field, as
<slug>::<model>. The examples in these docs assume an OpenAI provider with the routing identifier openai and an Anthropic provider with anthropic; replace them with your own. The provider id is the identifier in the address of the provider’s page in the dashboard.
A request whose model has no :: prefix and that carries no x-to11-provider-id header is rejected with 400 Bad Request:
The access policy applies to every request
The access policy is enforced however the model is reached: a<provider-slug>::<model> request, a bare model with x-to11-provider-id, a target inside a route or function, and a later turn of a chained Responses API conversation. The prefix or header picks the provider; it is not a way around that provider’s access policy.
A model the provider does not serve in the request’s environment returns 404 Not Found. A chained Responses turn whose model is no longer served by the provider that handled the earlier turn returns 410 Gone. See Error handling for the response bodies.
Models in routing rules
When you build a routing rule under Project → AI Gateway → Routing, each target picks a Provider and names a Model. The Model field suggests the provider’s listed and catalog models and accepts any id you type. The access policy is still enforced when the target is used. See Targets.Next steps
Providers
Connecting a provider and what it holds.
Connect a provider
Choose the access policy when you connect, and change it later.
Routes
How a route maps a name to a strategy and targets.
Error handling
The 400, 404, and 410 routing errors.