Model catalog

The model catalog stores normalized metadata and external reference prices used to enrich model resources. It does not contain provider credentials, create upstreams, or define the model price charged to users.

Catalog fields

Field	Purpose
Model author	Identifies the organization that created the model
Canonical model ID	Uniquely identifies the model within its author
Display name	Human-readable console label
Context length	Describes the supported context size
Capabilities	Chat, streaming, tools, vision, JSON, reasoning, and similar features
Status	Indicates whether the catalog entry is active or needs attention
Updated time	Helps identify potentially stale metadata

Reference pricing

Prices imported from models.dev, OpenRouter, and similar catalogs are comparison metadata only. They never participate in user settlement. An administrator maintains actual model prices manually on the Platform models page, and catalog imports cannot overwrite them.

Reference prices use controlled semantic pricing units:

Meter type	Pricing unit
Input, output, cache token	Per million tokens
Reasoning and audio token	Per million tokens
Image token	Per million tokens
Request and tool call	Per event
Image	Per image
Audio and video duration	Per second
Speech characters	Per 1,000 characters

Price records do not accept arbitrary multipliers. models.dev token prices are stored directly; OpenRouter per-token prices are converted through an exact decimal adapter at the import boundary. The database, internal APIs, and UI use per-million-token prices exclusively; only the LiteLLM runtime adapter converts them back to per-token prices. Currency, source, observation time, and conditional tiers remain part of the immutable reference-price version.

Import rules

The models.dev models collection is authoritative for canonical model identities. Its providers collection only contributes inference-provider mappings, provider model IDs, and reference prices.
Provider records first match catalog models by exact source identity. Name matching is allowed only when the display name is globally unique. Ambiguous records are reported as unmatched and never create guessed catalog models.
OpenRouter uses the permanent canonical_slug for author and canonical-model identity, while its callable id becomes the OpenRouter provider-model ID. A record without a permanent identity is invalid.
Cache write, reasoning, image/audio tokens, fixed requests, web search, long-context tiers, and time conditions remain distinct meters or conditional rates instead of being collapsed into three token prices.
Every source record stores raw and normalized data, normalization version, and a content hash. A normalization-version upgrade forces a fresh fetch and reprocessing even if the upstream ETag is unchanged.

Relationship to model resources

Upstream discovery creates model resources. A catalog model can link to resources through multiple inference-provider and provider-model-ID mappings. The model author describes who created the model; the inference provider describes where the model can be called. A missing mapping does not mean the model is unavailable; it means complete capability metadata is not known.

Callability still depends on the upstream, credential, and connection result.

Permissions and use

Regular users normally read catalog models. Authors are global entities: an administrator manages the author code, name, and logo separately before creating a manual catalog model. Editing a catalog model never creates or renames an author implicitly, and an author referenced by a catalog model or inference provider cannot be deleted. Updating a catalog model or provider mapping synchronizes linked resources.

Check required streaming, tool, vision, or reasoning capabilities before configuration.
Compare the model author, canonical model ID, and provider mappings rather than relying on the display name alone.
Rediscover models after an author releases a new version.
Validate custom models directly when no catalog model exists.