Model & provider access
Control which models and which providers your organization is allowed to route to.
The Models page in the console is both the catalog and the control surface for it. Every model Edgee can route to is listed there with its context window, pricing, and the providers that serve it — and an organization admin can switch any of them off.
Turning something off is a routing decision, not a billing one: the gateway stops routing to it, and every "pick a model" surface in the console stops offering it.
Three levels of control
| Level | Where | Effect |
|---|---|---|
| A whole model | Models tab → the model's switch | No provider serves it. The model disappears from every picker |
| One route | Models tab → expand a model → per-provider switch | That one model-on-that-provider pairing is off; the model's other providers keep serving it |
| A whole provider | Providers tab → the provider's switch | Every model that provider serves is off, across the entire catalog |
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:
| Status | Meaning |
|---|---|
| On | Every provider for this model is available |
| Mixed | Some routes are off, at least one still serves the model |
| Off | No route survives — the model is unavailable |
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.
If your reason for switching something off is about the vendor — a compliance boundary, a contract, a region you cannot use — disable it at the provider level so the decision keeps holding as the catalog grows.
What it affects
A disabled model or route is gone from the model pickers throughout the console: routing strategy rules 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.
The same filtered list feeds the model picker of Codex and the ChatGPT desktop app. To choose which of those models it features, and in what order, use Settings → Gateway → Codex model picker (see Choose which models Codex lists).
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:
| Model & provider access | Per-key model restriction | |
|---|---|---|
| Set by | Admin, org-wide | Per API key |
| Answers | What is this organization allowed to use at all? | What may this one key reach, within that? |
| Where | Models page | The key's settings |
An org-level block always wins. Adding a model to a key's allowlist does not re-enable something the organization has switched off.