Model catalog and model IDs
Last updated September 15, 2026
The format of model IDs and alias rules, what each field in the catalog means, and how to fetch the callable model list programmatically.
The model catalog lists every model the platform currently offers, and under each model every provider serving it with its price. A model is the unit of capability; a provider is the entity serving it — see providers and supply tiers for how the two relate.
Model IDs
Set model to the canonical ID, in the form vendor/model:
anthropic/claude-opus-5
openai/gpt-5.6
deepseek/deepseek-v3.2
Canonical IDs are shown on each model detail page and can also be fetched with GET /v1/models.
Aliases
The platform maintains aliases for common models so that code carried over from another environment keeps working. Bare names such as claude-haiku-4-5-20251001 usually resolve directly.
Aliases are unique platform-wide: the same name never points to two models. There is therefore no ambiguity in resolution and no "try the full ID first, then the bare name" fallback.
For new integrations, prefer canonical IDs. Aliases are a migration convenience, while a canonical ID states the vendor explicitly.
When the name itself contains a colon
A colon after the model ID introduces a suffix (model:provider, model:@strategy), yet some model names contain colons of their own — llama3.1:70b, or Bedrock-style ...-v2:0.
Resolution therefore looks up the complete string in the alias table first; a hit is treated as a full model name, and only a miss falls back to splitting on the last colon. These names can be used as-is, with no escaping.
Fields in the catalog
| Field | Meaning |
|---|---|
| Type | Chat, image, video, audio, embedding, or rerank |
| Input modalities | What kinds of input it accepts: text, image, audio, video, file |
| Output modalities | What kinds of output it produces |
| Context length | Context window in tokens. May differ per provider; the provider's own row is authoritative |
| Max output | Maximum output tokens for a single call |
| Released | The model's release date |
| Supported protocols | Which protocols can call this model |
Capabilities
| Capability | Meaning |
|---|---|
| Streaming | Supports incremental responses |
| Tool calling | Supports function and tool calls |
| Reasoning | Has a separate thinking phase; reasoning tokens may be priced separately |
| Structured output | Can constrain output to a given JSON Schema |
| Prompt caching | Supports prompt caching; cache reads and writes are priced separately |
| Vision | Accepts image input |
Capability flags describe the model itself. Whether a capability is reachable through a particular protocol, and how parameters map across protocols, is covered in protocol conversion compatibility.
Status
| Status | Meaning |
|---|---|
| Active | Callable as normal |
| Upcoming | Announced but not released. Visible in the catalog with a badge, not callable, no prices or providers shown |
| Deprecated | Still callable, but the vendor has announced end of life |
| Retired | No longer callable |
"Deprecated" exists to give you an early migration signal. Plan the switch when it appears rather than waiting until the model stops working.
Browsing and filtering
The catalog supports search by name or ID, and filtering by vendor, provider, input modality, output modality, context length, and supported protocol. Sorting options are newest first, price ascending, context descending, and by name.
- Vendor pages (
/models/<vendor>) list every model from that vendor - Provider pages (
/provider/<provider>) list every model that provider serves - Model comparison puts several model-provider pairs side by side across price, context, performance, endpoints, and capabilities
Model detail pages also show that model's performance metrics and usage trends per provider; see providers and supply tiers for how those are measured.
Fetching the model list programmatically
OpenAI shape
curl https://gateway.amux.ai/v1/models \
-H "Authorization: Bearer $AMUX_API_KEY"Without a key this returns every callable model on the platform; with a valid key it returns only the models that key can call — that is, with the key's model allowlist, supply-tier scope, and pinned providers already applied. This is the most direct way to confirm what a given key is actually able to call.
Alongside the standard OpenAI fields, each entry carries these extensions:
| Field | Meaning |
|---|---|
display_name | Display name |
context_length / max_output | Context window and maximum output tokens |
input_modalities / output_modalities | Input and output modalities |
capabilities | Capability flags |
aliases | Every alias for this model |
pricing | Starting price for each billing component |
providers | Each provider's price and parameter support |
pricing and providers are the authoritative source for prices. This documentation does not restate specific rates, to avoid a second copy that will drift.
Gemini shape
curl https://gateway.amux.ai/v1beta/models \
-H "x-goog-api-key: $AMUX_API_KEY"Returns the same models in the shape Gemini clients expect.
For full field definitions and response examples, see the API reference.
Related
- Providers and supply tiers — why one model has several prices
- Routing and failover — which provider a request lands on
- Billing overview — what each billing component means