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.

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.

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.

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). 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.