Available models

The full catalogue lives on the model browser. It’s generated from the same data the API exposes at GET /v1/models, so the two agree by construction.

How model IDs are formed

A model ID has three parts, with an optional fourth for region pinning:

<provider>/<creator>/<model>[/<locode>]

Examples:

• openai/openai/gpt-4o-mini
• anthropic/anthropic/claude-sonnet-4.5
• aws-bedrock/mistralai/ministral-3-3b-instruct/br-gru

The <provider> segment is the upstream that serves the request; the <creator> segment is who created the model (these differ for re-hosted models); the <model> segment is the model name, with version numbers written dotted (e.g. claude-sonnet-4.5). Two-part IDs are rejected: a request must carry at least the three-part form.

The optional fourth segment is a UN/LOCODE that pins the request to a specific region (e.g. sg-sin for Singapore). Appending it is how you route a request through a particular region.

Every ID listed here is callable as printed. If you omit the region, it resolves to the model’s global endpoint or, for models served only in specific regions, to its lowest-carbon one; if you omit the version, it resolves to the most recent version of that same model. The response echoes the fully resolved ID. See how IDs resolve for the exact rules and for what stays strict.

What each model card shows

• Display name: the human-readable name, sometimes versioned.
• Provider and owner: who serves it and who created it (these differ for re-hosted models, e.g. Llama on Mistral).
• Context window: max input tokens.
• Pricing: prompt, completion, and (where applicable) cached prompt rates per 1M tokens, in your account currency.
• Capabilities: function-calling (function_calling on GET /v1/models), streaming, and the input modalities the model accepts (text, image, document, …). A model whose provider publishes no function-calling statement shows no tag; that is “unknown”, not “no”. The browser’s Function calling filter keeps the three apart (Supported, Not supported, No statement), and each is linkable, e.g. /models?function_calling=yes.
• Eco data: active parameter count and the energy estimate per 1K tokens. Both numbers come from the methodology. The confidence band (accurate, medium, gross) reflects how well-sourced the parameter count is.
• Regions: where the upstream serves it, as UN/LOCODEs (se-arn, sg-sin, …) or global.

Auto-routed IDs

An auto/<creator>/<model> ID names the model you want and leaves the provider and region to the router. The weights and output are the same; only the route is chosen for you. These appear in this listing alongside the explicit IDs for every model served by more than one route. See routing.

An auto-routed entry carries no regions[], because the region is the routing decision, but it does carry auto_routing: the list of concrete routes it can resolve to and the price and carbon bounds across them, so it can be budgeted before you send. See budgeting an auto ID.

Each auto-routed ID is also listed with a jurisdiction scope as its 4th segment (eu-sovereign, eu, cloud-act-free, europe and us), once for every scope the model has at least one route in:

auto/mistralai/mistral-large-2512
auto/mistralai/mistral-large-2512/eu-sovereign
auto/mistralai/mistral-large-2512/eu

A scoped ID routes and fails over only inside its jurisdiction, and its auto_routing covers only the routes inside it. See scoping an auto ID.

When an auto-routed ID is used, the response’s model field is the resolved four-segment ID.

Alias IDs

When the listing is requested with your API key, it also contains one alias/<name> entry per alias on your account. Each entry is described by its target: provider is the target’s real provider, the capability fields are the target model’s, regions[] holds exactly the pinned target region with its pricing and carbon, and alias_target carries the concrete four-segment ID the alias currently points at. An unauthenticated request lists no alias entries, because aliases are per-account.

This is what makes aliases usable from clients that only offer what GET /v1/models returns. See aliases in the model list.

Curating the listing

When the listing is requested with your API key, it also honours your account’s catalog curation settings: an optional model allowlist and region allowlist that trim the response to a short, relevant selection, so pickers in third-party clients stay usable. Curation only affects display: hidden IDs still resolve and still route.

Lifecycle

• Added. When an upstream releases a new model and we integrate it, it appears on the model browser. Brand-new models start with a medium or gross eco confidence band until the parameter count is verified.
• Deprecated. When an upstream announces deprecation, the model card flags it with a deprecated badge and a sunset date. Routing still uses it until the sunset date.
• Removed. After the sunset date, requests for the model return model_deprecated. A migration suggestion is included in the error body when we have one.

Fields for catalogs and integrations

Every entry on GET /v1/models (and GET /v1/models/{id}) also carries the facts a model catalog or a client’s model picker needs, so they can be copied from the API rather than restated by hand. A field is omitted when LowRouter has nothing to state, which lets a catalog fall back to the model creator’s own figures.

lifecycle and retires_on. lifecycle is deprecated once the provider has announced the model’s retirement, and active otherwise, including when the provider publishes no lifecycle information. A deprecated model still serves and bills at its listed price until it retires. retires_on is the date the provider committed to, and is omitted when the announcement gave none (“not before…” is never turned into a date). An auto-routed ID is deprecated only when every route it can resolve to is, and retires with the last of them.

endpoints. The LowRouter endpoints the entry can be called on: chat.completions, messages and responses for chat models, embeddings for embedding models. It comes from modality by the same rule the router applies, so a listed endpoint never refuses the model, and then drops any endpoint the provider says it does not serve the model on. An empty list means the model is listed but no endpoint serves it yet, such as a model its provider offers only on its own Responses API. An auto-routed ID lists only the endpoints every one of its routes serves.

regions[].upstream_model_id. The model ID LowRouter sends to that route’s provider, in the provider’s own spelling (for example mistral-medium-2604 behind mistral/mistralai/mistral-medium-3.5). Use it to match a route to the provider’s own documentation or catalog entry.

regions[].context_length and regions[].max_output_tokens. The token limits that route’s provider was verified to enforce — learned from a refusal the upstream itself produced (or a LowRouter probe), never restated from the catalogue. They can disagree with the entry-level context_length / max_output_tokens, which are scraped figures: a provider may publish 1,000,000 and reject prompts beyond 524,288, and only the region fields carry the enforced number. Both are omitted unless verified within the last 7 days — never a guess, never 0 — so an omitted field means “inherit the entry-level figure”. The entry-level context_length defers to the verified figure only when every route of the entry carries the same fresh verified value; otherwise it stays the scraped figure.

regions[].reasoning_effort, reasoning_mode, reasoning_effort_probed_at and reasoning_toggle. These describe what the route does with reasoning_effort. reasoning_effort lists the values the route applies as sent. A value the route maps onto a neighbouring level is left out, and so is any value LowRouter rejects itself. reasoning_mode says how a value reaches the provider:

• forwarded: the value is passed on unchanged, and the listed values are the ones LowRouter’s own probes found the model accepts. reasoning_effort_probed_at dates that probe. A probe result is published for a week, then dropped until a request the route refuses at some level probes it again.
• unsupported: the route has no reasoning control. Every value is then disclosed as not applied, and reasoning_effort is [].

reasoning_toggle is false: LowRouter passes no separate reasoning on/off control. The fields are omitted when LowRouter cannot yet state the behaviour. That covers a route that has not been probed, and Anthropic and Gemini routes, where the source data does not say which models reason.

auto_routing.default_routes and routing_reason. On an auto-routed ID, default_routes lists the routes a plain request resolves to under the standard routing profile, and routing_reason says why they won, in the same vocabulary as the response’s lowrouter_metadata.routing_reason. It lists several routes when they tie, and requests then rotate across them (round_robin). Your account’s routing policy, an unavailable route or a reached quota can send a request to another of the candidates. The response always names the route that served it. auto_routing.reasoning_effort and reasoning_mode summarise the default routes, so no second lookup is needed: reasoning_effort lists the values every default route applies as sent, and both are published only when every default route states its behaviour under the same reasoning_mode.

Filtering the catalogue

The model browser supports filtering by:

• Provider
• Context window
• Capability flags
• Eco confidence band
• Price range

The same filters are reflected in GET /v1/models query parameters. Three of them are closed enums the API validates, returning 400 with the accepted values for anything else:

modality

Models of one interaction mode; chat means “what /v1/chat/completions can serve”. Models with no published mode are excluded by any value.

input_modality

Models whose provider publishes support for that input. Silence excludes.

function_calling

Models by the provider’s tool-use statement. yes is exactly the capabilities.function_calling: true set; unknown lists the models with no statement, which are untested rather than unsupported.

For example, GET /v1/models?modality=chat&function_calling=yes is the set a tool-using agent can pick from. An auto/ entry is resolved across every provider serving the model: yes if any states support, no only if all state none, unknown otherwise.

Filtering by jurisdiction

GET /v1/models and GET /v1/providers accept ?jurisdiction=, which restricts the catalogue to providers meeting a sovereignty test. Omit it for the full catalogue. An unrecognised value returns 400, and the error names every accepted value.

There are four values, and they are not interchangeable. Two test legal control of the provider company, and two test where the request is served. A Frankfurt datacentre run by a US-controlled company passes a location test and fails a control one.

Pick eu-eea-hosted to answer “does any processing happen outside the EU/EEA?”. europe-hosted is deliberately wider: the UK and Switzerland hold adequacy decisions, so routing there is lawful, but they are third countries and it would be wrong to report them as EU/EEA.

cloud-act-free makes no location claim. It is a test of who controls the provider company, not of where the request is served, so it can and does return US-hosted routes: a provider outside US legal reach may still run its inference in a US region. Today several models under this facet are served only from us-mci. If you need both properties, use eu-sovereign (control and EU/EEA location), or combine cloud-act-free with a region pin.

Under a facet, the unscoped auto/ IDs are left out, because their ranking is global and could land outside it. The scoped auto IDs whose promise implies the facet stay in:

Rather than hardcoding these four strings, list them at runtime:

curl https://api.lowrouter.ai/v1/jurisdictions

Each entry carries its id, a description, and the exact countries a region must sit in to satisfy it (null for cloud-act-free, which makes no location claim), and auto_scope, the auto ID scope that makes the same promise. New facets appear there without a client change.

GET /v1/providers also reports each provider’s own jurisdiction, country, legal_entity, eu_sovereign and the jurisdictions it satisfies, so a sub-processor register can be built from one unfiltered call rather than by diffing filtered ones.

Renamed. eu-hosted is gone; it now returns 400. It spanned the UK and Switzerland without saying so, so a caller filtering for “inside the EU/EEA” silently got adequacy countries too. Use eu-eea-hosted for the strict reading or europe-hosted for the old behaviour under an honest name. We did not keep eu-hosted as an alias on purpose: an alias would have left existing callers reading UK and Swiss regions as EU.

Prices in USD

Catalogue prices are in EUR, the currency your balance is debited in. Add ?currency=usd to GET /v1/models or GET /v1/models/{id} to get the same entries with regions[].pricing and auto_routing.pricing_range in USD. A USD-billed provider shows its own list price; a EUR-billed one is converted at a monthly ECB fixing. Each entry then carries an fx array citing the conversions applied. It combines with every filter above, ?jurisdiction= included. The figures are for display only: see Pricing and currency conversion for the exact rule and how it relates to what you are billed.