> ## Documentation Index
> Fetch the complete documentation index at: https://www.edgee.ai/docs/llms.txt
> Use this file to discover all available pages before exploring further.

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

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

## 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](/docs/features/routing-strategies) rules, [fallback and reroute](/docs/features/retry-and-fallback) 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](/docs/features/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.