A model catalog is the list a platform team keeps of the AI models its organization may use, and everything needed to use each one safely: which providers serve it and under which id, what it can take and return, what it costs on your contract, when it will stop working, and who is allowed to call it. Without one, those answers live in a wiki page, three SDK config files and somebody's memory of the last vendor email.
This guide covers what an AI model catalog should record, how it differs from an ML model registry and from the catalogs cloud platforms publish, how to keep it current when vendors retire models on their own schedules, and how to make it something the request path enforces rather than a document people consult.
What is a model catalog?
For a team that consumes models from providers, a model catalog is an inventory with one row per model and one sub-row per place that model is served. It is the source that other systems read: the gateway reads it to decide whether a request is allowed and where it can go, finance reads it to price usage, and the people who own a feature read it to find out that the model they depend on retires in six weeks.
The word is used for three different things, which is where most confusion starts:
| ML model registry | Cloud provider catalog | Platform team's model catalog | |
|---|---|---|---|
| Example | MLflow Model Registry | Vertex AI Model Garden, Amazon Bedrock model cards | Your own inventory, enforced by a gateway |
| What it lists | Models you trained | Models one platform offers | Models your organization approved, on every provider it uses |
| Unit of change | A new version from a training run | The platform adding or retiring a model | An approval, a contract, a vendor retirement |
| Lifecycle | Your own stages and aliases | The platform's states and dates | Each provider's dates, per provider |
| Answers "may we call it?" | No | No | Yes |
Model registry vs model catalog
MLflow describes its registry as a centralized model store, with a set of APIs and a UI, that versions each model registered under a name, attaches mutable aliases such as champion to a version, records tags and annotations, and links every version back to the run or notebook that produced it1. That is lineage for artefacts your team builds and deploys. A frontier model you call over an API has no training run of yours to link to and no version you control; the vendor decides when a snapshot changes and when it disappears.
If you fine-tune or train models, keep the registry for them. The catalog then points at the registry for those rows and at providers for everything else.
Cloud catalogs
Cloud platforms publish catalogs of what they host. Google's Model Garden groups Google's own models, partner models such as Anthropic's Claude and Mistral's, and open models that can be run as a managed service or deployed by you2. Amazon Bedrock's "Models at a glance" page lists models by provider, with a card per model holding its ids, Regions, modalities and inference parameters3.
These are the right reference for that platform. They are not an organization's catalog, for two reasons. They list what you could use, not what you approved. And a team that calls Anthropic's own API, Bedrock and an aggregator ends up with three catalogs, three lifecycle schedules and three spellings of the same model.
What an AI model catalog should record
A useful entry is short. What matters is that every field has an owner and a source.
| Field | What it holds | Where it comes from |
|---|---|---|
| Canonical id | One name your code and reports use, such as vendor/model | You |
| Served by | Each provider that can serve it, and the wire id that provider expects | Provider docs and each key's own model list |
| Modalities and task | Text, image, video, speech, transcription, embeddings; chat, edit, rerank | Vendor model page |
| Limits that change behaviour | Context window, maximum output, parameters the model refuses | Vendor model page, per snapshot |
| Reference list rate | The vendor's published rate, in the vendor's billing unit | Vendor pricing page |
| Negotiated rate | Your contract's rate, per provider where it differs | Your contracts |
| Lifecycle | State, deprecation date, shutdown date, named replacement, per provider | Vendor deprecation pages |
| Access | Which organization, projects and keys may call it | Your approval process |
| Owner and evidence | Who approved it, against which evaluation | You |
Three of these deserve more care than they usually get.
Wire ids are per provider. The same model can be addressed by a different string on its vendor's API, on a cloud platform and on an aggregator, and a regional or dated snapshot can add another. A catalog that stores only a marketing name cannot answer "which of our keys can serve this?", and a gateway cannot route on it.
Two prices, kept apart. The list rate is reference data: what the vendor publishes. The negotiated rate is what your provider will actually bill you under contract, and it can differ per provider for the same model. Estimates that silently use the list rate drift from the invoice; negotiated rates vs list price walks through every way that happens. Where no rate is known, the honest value is "unpriced", never zero.
Lifecycle is not one date. It is a state per provider, covered next.
Lifecycle: preview, active, deprecated, shut down
Every major provider publishes a lifecycle, and they do not use the same words or the same notice.
- OpenAI treats a model as deprecated as soon as a retirement is announced, at which point it receives a shutdown date, after which it can no longer be reached. It commits to at least six months' notice for generally available models, at least three months for specialised variants, and much shorter notice, such as two weeks, for preview models, unless safety or compliance requires faster action4.
- Anthropic uses four states — active, legacy, deprecated and retired — and gives at least 60 days' notice before retiring a publicly released model. Its dates apply to Anthropic-operated platforms; Amazon Bedrock and Google Cloud set their own schedules for the same models5.
- Amazon Bedrock, for models launched from 7 September 2026, uses active, legacy and end-of-life. Most models get a six-month legacy period, some 45 days; once a model is legacy, new customers cannot adopt it and existing customers may lose access after 15 days of inactivity. After end-of-life, requests fail. Bedrock states that its dates may differ from the model provider's own6.
So the lifecycle field in a catalog is a small table per model: one row per provider, each with its own state and dates. A catalog that records "Claude X retires on date Y" without saying where will be wrong for some of your traffic.
The useful states for a catalog are a superset that maps onto each provider's terms:
- Preview: callable, not approved for production; expect short notice.
- Active: approved and supported.
- Deprecated or legacy: still works; has a shutdown date and, usually, a named replacement. New use is refused.
- Shut down: requests fail at the provider. Your own gateway should refuse them first, with an error that names the replacement.
The per-date view across vendors is maintained in the AI model deprecation calendar, and the step-by-step move to a replacement is in the model deprecation migration playbook.
Keeping the catalog current
A catalog edited by hand is accurate on the day it is written. Three feeds keep it accurate afterwards.
Vendor lifecycle pages. Deprecations are announced on pages, not in an API every vendor shares. Someone or something has to read them and write each new date into the catalog with its source. Some APIs help: OpenAI's list-models response now carries a shutdown_date per model, null when none is announced7; Bedrock exposes a model's state in a modelLifecycle field on its model APIs6.
Each provider key's own model list. What a vendor's page says is served and what your key can call are different facts. Aggregators move models between groups, accounts are scoped to projects, and access can lapse: Bedrock's own policy says existing customers may lose a legacy model after 15 days without using it6. Reading each key's model list on a schedule, and marking a model your key has stopped listing, catches this drift before a user does.
Your request data. The catalog says what is approved; traffic says what is used. Join them weekly. A model in traffic and not in the catalog is an unapproved dependency. A deprecated model still in traffic is a migration with a deadline. Anthropic suggests the same audit from its own usage export, broken down by key and model5.
Governance: turning the catalog into policy
A catalog that nobody enforces is a recommendation. It becomes policy when the request path checks it before a provider is called.
The simplest enforcement is an allow list per scope — organization, project, key — with block entries for exceptions:
- An organization list sets the outer boundary, for example every model from approved vendors.
- A project list narrows it to what that workload has been evaluated on.
- A key list narrows it again for a single service or environment.
- Block entries remove one model or one vendor even when a broader rule allows it, which is how a deprecated model is cut off on a date.
Two rules keep this manageable. Each scope can only narrow, never widen, what the scope above allows; and a named route or a fallback target must be checked against the same lists, or routing becomes a way around policy. The wider approval process — who proposes a model, what evidence is required, how exceptions expire — is covered in model access governance.
Approval should also record why. "Approved for summarisation in project X after an evaluation on 200 recorded tickets" is something a reviewer can check and re-run when the model changes; "approved" is not.
A minimal checklist
- One canonical id per model, with the wire id each provider expects.
- List rate and negotiated rate stored separately; unknown rates recorded as unpriced.
- Lifecycle state and dates recorded per provider, each with its source page.
- A scheduled read of every provider key's model list, with drift flagged.
- A weekly join of request data against the catalog.
- Allow and block lists at organization, project and key, enforced before the provider call.
- Shut-down models refused with the replacement named, never swapped.
How INFRO keeps the catalog in the request path
INFRO is a BYOK control plane: you connect your own provider accounts, and the catalog it keeps is reference data about the models those accounts can serve, not a price list. The public model directory lists those models with each vendor's published list rate and the provider kinds that serve them in production, with search, filters and sorting. Inside an organization, GET /v1/models returns only what the calling key can reach: models served by an enabled connection in the key's environment and permitted by every allowlist that applies.
The feeds described above are built in. INFRO records each vendor's deprecations and shutdown dates; before the shutdown it marks the model in the console and sends a model.retiring alert to organizations that sent it in the last 30 days, and from the shutdown date it refuses the model before any provider call with model_shut_down, naming the vendor's replacement. It never answers with a different model on your behalf; to keep an old name working you point a route at the replacement (model lifecycle). It reads each connected key's own model list every three hours and stops offering a model the key has stopped listing, with the date (provider connections). Model allowlists apply at organization, project and key, with ! entries to block a model or a vendor. Estimated cost uses the rates in your contracts before the list rate when you enter them, from the Team plan.