Skip to main content
Model access rules decide which models a key is allowed to call. They sit alongside usage limits, content guardrails, and routing. Limits cap how much a key spends, guardrails inspect content, routing picks a provider, and model access governs the model name the client asked for.

​
Create a rule

On the Model access page under Policies, create a rule and choose:
  • Who it’s for: one API key, a user, a group, keys with no group, or the whole deployment (All traffic).
  • Allow or block: Block refuses the named models and leaves everything else callable. Allow only makes the named models the whole menu — nothing else is callable, on any API.
  • Which models: the names from the request body, such as gpt-4o or claude-sonnet-4-5. Names match exactly, case included. A trailing * is a prefix wildcard (claude-opus-*), so a rule keeps covering a model when a vendor stamps a new date on the name.
A rule names models only. It does not distinguish OpenAI from Anthropic: the same name means the same thing on either API. Each key’s detail page also has a Model access section for the rules that cover that key.

​
How rules combine

Rules stack. For one requested model:
  • Any matching block refuses it, including a block on a wider target than an allow. A key-level allow list cannot escape a deployment-wide block.
  • Every target carrying an allow list must name the model. Allow lists from different targets intersect; two on the same target union.
  • No allow list anywhere means everything not blocked is callable.
Enforcement is on the model the client asked for, before routing. A routing rewrite is not second-guessed. A block takes effect on the next request.

​
What callers see

A refused request never reaches a provider. It returns 403 in the caller’s dialect, mapped to permission_error. The same policy filters GET /v1/models for that key, so the client’s picker cannot offer a blocked model.