# Providers

> What the Providers screen lists, how it shows the routed clutch-layers models and their reachability, and where GPU provider keys and capacity live.

The Providers screen in the inference console shows **where your models run**.
Afterburner serves only clutch-layers models, on model servers that
FirstByte runs. The screen has no vendor rows. It lists the models that the
router sends traffic to. It answers one question: "which models are routed
now, and does their address answer?"

The screen does not store or edit credentials. Provider keys and GPU capacity
are on **Compute › GPUs**. The **Manage GPU provider keys** button on the
screen opens that tab.

<a id="what-the-catalogue-contains"></a>
## What the screen lists

The screen calls one procedure, `models.local`, and shows the routed models in
a table. This is the same registry that the
[Models screen](/modalities/inference/model-registry) shows. Each row has these
columns:

| Column | Shown as | Meaning |
| ------ | -------- | ------- |
| Model | Row title, with the weights path below it | The registry name of the model. The sub-line is the repo id or weights path that the model serves. |
| Engine | Tag | The engine of the model. This is `clutch-layers`. The column shows `—` when the spec has no engine. |
| Namespace | Text | The Kubernetes namespace that the model targets. |
| Upstream | Pill | Whether the routed address answered on its last turn. See [Reading the Upstream pill](#reading-the-upstream-pill). |

The search box filters the rows by name, weights path, engine, and namespace.
The count beside it shows the rows that match against all rows.

The screen has these states:

| State | What it tells you |
| ----- | ----------------- |
| Loading | The query is in progress. |
| `Could not load models` | The model registry did not answer. Press **Retry**. |
| `No models routed` | The registry has no model. Deploy a model on the Models screen. It then appears here. |
| `No models fit this search` | The registry has models, but none match your search. Press **Reset search**. |

<a id="categories-llm-asr-tts"></a>
## Reading the Upstream pill

The Upstream pill describes the address that the model routes to. It does not
describe the registry entry.

| Pill | Meaning |
| ---- | ------- |
| up | The address answered on its last turn. |
| down | The address answered nothing on its last turn. A model can be configured correctly and still have no process behind its address. |
| untried | No turn has used the address, or the engine reports no upstream health. |

The verdict comes from real turns. It is not a probe. An endpoint that nobody
has called reads `untried`. The screen has no separate connectivity test.
Routing failures also show in agent runs and in the telemetry of the fabric.
See [Telemetry](/platform/telemetry).

<a id="base-url-and-routing"></a>
## Adding a model and adding capacity

The Providers screen has no write path. Use these screens instead:

| Task | Where |
| ---- | ----- |
| Add a model to the registry | Models screen |
| Set the engine, image, namespace, GPUs, replicas, and port of a model | Models screen |
| Add GPU capacity | Compute › GPUs |
| Set or rotate a GPU provider key | Compute › GPUs |
| See which models are routed, and whether they answer | This screen |

Powerful, long-lived credentials stay on the surface that owns them. The
operator console reads names and states only. See
[Authentication](/concepts/authentication).

## Related

- [Model registry](/modalities/inference/model-registry) — how to deploy, change, and remove a model
- [Authentication](/concepts/authentication) — where credentials live and how they are scoped
- [Telemetry](/platform/telemetry) — where request behaviour is observable