Model Catalog and Providers
Browsing every model the gateway can route to, what each provider charges for it, and how to read a price that is absent rather than zero.
Model Catalog and Providers
Two screens read the same synced snapshot from two directions.
Catalog is model-first: every model in the synced snapshot -- including ones no upstream can route to -- marked with what your team is allowed to call and what it already uses, with per-model pricing.
Providers is provider-first: every provider in the synced directory, routable or provenance-only, with how much of the catalog each one serves. Opening one lists the models it serves at that provider's own prices, context windows and quantizations -- which differ from the model-level price on the Catalog page.
The catalog is global, not scoped to the providers your team has connected. A model's price claim belongs to the model; each provider serving it prices its own endpoint. Both facts need somewhere to live, which is why there are two axes rather than one.
Reading a model row
| Column | Meaning |
|---|---|
| Model, ID | Its name and its neutral author/slug id. |
| Good for | Capability tags, below. |
| Your traffic | Your team's share of the matched requests in the window -- not of all your traffic. |
| Availability | Whether your team holds its own provider credential for this model's author -- your key, a failing key, or no key. Not whether the gateway can route to it. |
| Context | The context window. |
| In / Out / Cache read per 1M | Prices in USD per million tokens. |
| Endpoints | How many provider endpoints serve it. |
| Knowledge cutoff |
Provider, Modality, Routable via and Source are carried on the row but are not rendered as columns: they drive the filter chips and the model drawer.
The model drawer adds tabs: an overview, the providers serving it, its full pricing -- with the price-history chart -- and your own usage.
Capability tags
| Tag | Means |
|---|---|
| Tool use | Accepts a tools parameter -- the prerequisite for agentic work. |
| Reasoning | |
| Vision | Accepts image input. |
| Structured output | |
| Long context | A context window of 400K tokens or more. |
| Low cost | A blended rate at or under $1 per 1M tokens. |
Capability filters are all-of: selecting two tags returns models with both. Within any other filter, multiple values are any-of, and different filters are combined with AND.
Absent is not zero
This is the rule to internalise before you read any price in the catalog.
An absent price component means the feed publishes no rate for that component -- not that it is free. Two feeds may also disagree about the same model, which is why every row records the source that produced it.
The same applies to the live endpoint statistics -- uptime, latency, throughput. All of them are optional, and absence means unknown, never zero. Those figures are fetched on demand behind a short cache and are never stored; when the upstream is unreachable you get a stale snapshot marked as stale, and an outright "unavailable" only when there is nothing cached at all.
Routable upstreams
A model's routable upstreams are the upstreams where traffic for it could actually be sent. That is a different axis from the providers within an upstream.
Empty is a real state, not an error. A provenance-only feed -- one DevZero reads prices from but never sends requests to -- can price a model no upstream offers.
It is also deliberately not filtered by staleness: a sync outage degrades the catalog, it does not make your models unroutable.
Price history
The catalog stores only the current price claim, and an update destroys its predecessor -- so a price that changed would be recoverable from nowhere. Both pricing feeds therefore append what they observed, one point per source per day, read back as a chart on the model drawer.
Two properties matter when you read it:
- There is no backfill. The series begins when collection began, and the response says since when -- so a three-day chart can tell you "we have only been collecting for three days" rather than implying the model is three days old.
- A negative "settled at routing time" sentinel, which some dynamic models publish, is normalised to absent rather than stored. An unpublished component is not a free one, and a stored negative rate would plot as a spectacular discount.
Provider rows
| Column | Meaning |
|---|---|
| Provider | |
| Models | How many models it serves. |
| Authors | Distinct authors of those models -- who made them, never who serves them. A provider serving many authors is a marketplace; one serving a single author is usually that author's own endpoint. |
| Source | Its sync feed. |
| Synced | |
| Policies |
A provider's feed is either routable or provenance only, and the filter for that is a real three-state control rather than a checkbox -- so "I do not care" cannot silently mean "provenance only".
Where usage ranking comes from
The catalog table can rank models by your team's own traffic, over a trailing 30-day window by default. That is the one place the catalog reads your telemetry, and the dependency is deliberately non-fatal:
If the telemetry read fails, you lose the ranking and the usage column -- never the page -- and the response says it is degraded. A silently reordered catalog reads as a catalog that changed, and an absent count reads as a team that stopped using the gateway.
The join is also imperfect in a way worth knowing: telemetry records the model string the client asked for, which is not always resolvable to a catalog id. The response reports matched and unmatched request counts so you can see how much of your traffic the annotation actually speaks for.