Choose a model

Read the catalog at runtime

Browse Supported Models for concise model labels, providers, token limits, and capabilities. Those labels are for display and are not guaranteed to be valid request values. GET /v1/models is authoritative for the exact callable model IDs available to the caller's key, and the catalog can change over time, so read it at runtime instead of hardcoding names. The quickstart has the request.

Two ways to name a model

A model ID pins one exact model. Use an id from GET /v1/models:

{
  "model": "your-model-id",
  "input": "Classify this support request."
}

For open-weight models the listed id is a provider-agnostic name such as kimi-k3. Requesting it lets Router serve the model from any provider that carries it, in the catalog's documented preference order, with in-order fallback when the preferred provider fails. Each row's router.aliases lists the provider-pinned names (accounts/fireworks/models/kimi-k3) that remain callable when you need one exact serving provider.

An explicit list names providers directly and is tried in order. See Add fallbacks.

Provider and model syntax

Entries in a models list use provider:provider-model:

openai:gpt-5.4-mini
fireworks:accounts/fireworks/models/kimi-k2p7-code

Add a service tier as a third segment to pin it, for example openai:gpt-5.4-mini:flex. See Service tiers.

Every candidate must be available to your key.

Capability differences

Streaming, function tools, and JSON Schema output work across providers, subject to model support. Input types differ more:

Support varies by model within a provider, so test the features your request actually uses before putting a model into a fallback list.