Model and provider access is admin-only and applies org-wide. Members see the catalog, but not
the switches — and non-admins are redirected away from the Providers tab entirely.
Three levels of control
The per-route level is the one worth knowing about. A model like Claude Opus may be served by Anthropic directly, by Bedrock in several regions, and by Vertex — and you can keep the ones that satisfy your data-residency rules while switching off the rest, without losing the model.
Model status
Each model shows where it stands for your organization:Providers apply to future models too
This is the practical difference between the two switches:- Disabling a provider is a standing rule. Models added to the catalog later that are served by that provider arrive already disabled, with no action from you.
- Disabling a model covers only that model. A new model from the same author is unaffected.
What it affects
A disabled model or route is gone from the model pickers throughout the console: routing strategy rules, fallback and reroute lists, and per-key model restrictions all read the filtered list. The gateway will not route to it even if an older configuration still names it. Disabling a provider does not delete your BYOK credentials for it. The keys stay registered and start working again the moment you re-enable the provider.Org access vs per-key restrictions
These are two different levers and they stack:
An org-level block always wins. Adding a model to a key’s allowlist does not re-enable something the organization has switched off.