Service Tiers

Many providers sell more than one grade of capacity for the same model:

flex: a discounted tier that trades latency and availability for a lower price.
priority: a tier that costs more for faster, more reliable service.

OpenRouter exposes each of these as its own endpoint, so you can reach them either by letting them compete for your traffic or by asking for one explicitly. Whichever way you route, the response reports the tier that actually served the request, and you are billed at that tier’s rate.

The `:nitro` and `:floor` Variants

The simplest way to use service tiers is to append a variant to the model ID. :nitro sorts every endpoint for the model by throughput and admits priority tier endpoints into that sort. :floor sorts by price and admits flex endpoints.

{
  "model": "openai/gpt-5:nitro"
}

Because a tier endpoint has to win that sort like any other endpoint, you pay a priority rate only when the priority endpoint is genuinely the fastest option, and a flex endpoint serves only when it is genuinely the cheapest. Nothing else about the request changes, and fallbacks keep working: if the tier endpoint is unavailable, the next endpoint in the sorted pool serves the request at its own rate. This is the recommended starting point for most traffic. Reach for the service_tier parameter below when you need a specific tier regardless of how it compares to the alternatives. See Nitro and Floor for the variants in full.

Using Service Tiers

To pin a tier explicitly, pass service_tier as a top-level parameter in your request body. Supported values:

flex: lower cost, higher latency.
priority: faster, higher cost.
fast: an alias for priority (see Fast mode below).

The example below requests the flex tier from OpenAI’s gpt-5 for a 50% discount in exchange for higher latency and lower availability. The service_tier parameter is also accepted on the Responses API and the Anthropic Messages API. See API Response Differences below for where the response field is returned in each.

Anthropic Messages API

curl https://openrouter.ai/api/v1/messages \
  -H "Authorization: Bearer <OPENROUTER_API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-5",
    "service_tier": "flex",
    "max_tokens": 1024,
    "messages": [
      { "role": "user", "content": "What is the meaning of life?" }
    ]
  }'

Fast mode

Three spellings request the priority tier. They are fully interchangeable on all APIs and providers:

service_tier: "priority"
service_tier: "fast" (OpenAI’s Fast mode rename of priority processing)
speed: "fast" (Anthropic’s native parameter)

Reported tier. The response always reports the tier as priority, never fast. This matches OpenAI’s own API, which returns priority even when the request spelled the tier fast. Anthropic models. The reported tier is derived from the speed Anthropic returns:

A fast-served request reports service_tier: "priority", plus usage.speed: "fast" on the Messages API.
Anthropic’s own API would echo service_tier: "standard" for the same request.
On models that support fast mode, the request routes to the model’s fast service tier endpoint like any other provider’s priority tier. See Fast Mode in the Claude Code guide.

Conflicting values. If you set conflicting values explicitly (e.g. speed: "standard" with service_tier: "priority"), both are honored as written and neither is derived from the other. Deprecated *-fast models. The dedicated *-fast models (e.g. anthropic/claude-opus-5-fast) are deprecated. They keep working and are served by the same fast tier capacity, but new integrations should target the regular model.

Anthropic itself has deprecated its priority tier. Per Anthropic’s service tiers documentation: “Priority Tier capacity commitments are no longer available for purchase. Organizations with an existing commitment can continue to use Priority Tier through their contract end date.”

How Routing Works

Non-default tier endpoints (flex, priority) are only considered when your request asks for them. There are three ways to do that.

1. The `:nitro` and `:floor` model variants

:nitro makes priority endpoints eligible. :floor makes flex endpoints eligible.
Unlike the service_tier parameter, tier endpoints get no special treatment. The whole pool is sorted by the variant’s metric (throughput for :nitro, price for :floor), so a tier endpoint is used only when it wins that sort.
Setting provider.order replaces sorting with your explicit ordering, which disables the variant’s tier admission. Name a tier endpoint slug in the order list to include it.
An explicit service_tier: "default" also disables the variant’s tier admission, so you can use :nitro/:floor purely for their sorting while pinning the standard tier.

2. The `service_tier` parameter

priority: matching endpoints are tried first (sorted by throughput), with fallback to other endpoints if none succeed. Billing always follows the endpoint actually used, so a priority request that falls back off-tier is charged at that endpoint’s standard rate, not the tier rate.
flex: routing is restricted to flex endpoints (sorted by price). Flex never falls back to a default-tier endpoint, since that would cost more than the tier you requested, so a flex capacity error surfaces instead.
If the pool contains no flex endpoints at all (for example, the model has no flex-capable provider), the request routes normally at standard rates.
Combine with allow_fallbacks: false to route only to the top endpoint of that tier.

3. Tier endpoint slugs in `provider.order` or `provider.only`

Each tier has its own endpoint slug, formed by appending the tier to the provider slug, e.g. openai/fast or google-vertex/flex.
"provider": { "only": ["openai/fast"] } restricts routing to OpenAI’s Fast tier. See Provider Selection for provider.order and provider.only in full.
The fast and priority slug suffixes are interchangeable, so openai/priority matches the same endpoint.

Requests that don’t use any of these are never routed to a non-default service tier.

Comparing Tier Selection Options

Option	Eligible pool	Ordering	Fallback
`:nitro` variant	Default + priority endpoints	Entire pool sorted by throughput, no tier preference	Next-fastest endpoint of any tier
`:floor` variant	Default + flex endpoints	Entire pool sorted by price, no tier preference	Next-cheapest endpoint of any tier
`service_tier: "priority"` (or `"fast"`)	Default + priority endpoints	Priority endpoints first, each group sorted by throughput	Falls back to non-priority endpoints
`service_tier: "flex"`	Flex endpoints only (when any exist)	Sorted by price	No fallback to default endpoints, capacity errors surface
`provider.only` with a tier slug	Only the endpoints the slugs name (tier slugs opt in that tier)	Default load-balanced ordering unless a sort is set	Within the named endpoints only
`provider.order` with a tier slug	Unchanged (tier slugs opt in the named tier endpoints)	Listed endpoints first, in your order	Falls back to unlisted endpoints unless disabled
`provider.sort` (`"throughput"` / `"price"`)	Unchanged (does not opt into any tier)	Entire pool sorted by the chosen metric	Next endpoint in sorted order

In every case, billing follows the tier that actually served the request: if a provider sheds a tier request to its default tier, you’re billed the default rate. The variants are the recommended default, since a tier endpoint serves only when it wins on the metric you asked for. The service_tier parameter is the right choice when the tier itself matters more than how it compares, for example when you want flex pricing even where a default endpoint would be faster.

Tier Endpoints in the API

Tier endpoints are listed in the model endpoints API alongside standard endpoints. Each appears as its own entry with a tier-suffixed tag (e.g. openai/fast) and its own tier pricing (the same pricing used for billing). Their presence in the listing doesn’t change routing: they remain opt-in as described above.

Supported Providers

The following providers support flex and priority service tiers for select models:

OpenAI (the priority tier is branded Fast mode)
Anthropic (priority only, served via Anthropic’s fast mode — requesting the priority or fast tier sends speed: "fast" upstream)
Google Vertex
Google AI Studio
SpaceXAI (priority only)

The response’s service_tier field reports which tier was actually used. Possible values:

default
flex
priority
null when no service tier is available from upstream

OpenRouter normalizes provider-equivalent base tier labels, such as Google’s standard, to default. The exception is the Anthropic Messages API, which preserves standard to match Anthropic’s spec (see API Response Differences below). Provider documentation:

OpenAI: Flex and Fast mode
Anthropic: Fast mode
Google Vertex: Flex and Priority
Google AI Studio: Flex and Priority
SpaceXAI: Priority Processing

API Response Differences

The API response includes a service_tier field that indicates which capacity tier was actually used to serve your request. The placement of this field varies by API format:

Chat Completions API (/api/v1/chat/completions): service_tier is returned at the top level of the response object, matching OpenAI’s native format.
Responses API (/api/v1/responses): service_tier is returned at the top level of the response object, matching OpenAI’s native format.
Messages API (/api/v1/messages): service_tier is returned inside the usage object, matching Anthropic’s native format.

`service_tier` value in the Messages API

Anthropic’s spec uses standard rather than the OpenAI-style default as the base tier label. So the Messages API returns service_tier: "standard" where the Chat Completions and Responses APIs return "default". Other tier values are returned unchanged.

Overview

Models & Routing

Tool Calling

Features

Ori

Privacy

Best Practices

Community

Service Tiers

Service Tiers

The `:nitro` and `:floor` Variants

Using Service Tiers

Fast mode

How Routing Works

1. The `:nitro` and `:floor` model variants

2. The `service_tier` parameter

3. Tier endpoint slugs in `provider.order` or `provider.only`

Comparing Tier Selection Options

Tier Endpoints in the API

Supported Providers

API Response Differences

`service_tier` value in the Messages API

​Service Tiers

​The :nitro and :floor Variants

​Using Service Tiers

​Fast mode

​How Routing Works

​1. The :nitro and :floor model variants

​2. The service_tier parameter

​3. Tier endpoint slugs in provider.order or provider.only

​Comparing Tier Selection Options

​Tier Endpoints in the API

​Supported Providers

​API Response Differences

​service_tier value in the Messages API

Service Tiers

The `:nitro` and `:floor` Variants

Using Service Tiers

Fast mode

How Routing Works

1. The `:nitro` and `:floor` model variants

2. The `service_tier` parameter

3. Tier endpoint slugs in `provider.order` or `provider.only`

Comparing Tier Selection Options

Tier Endpoints in the API

Supported Providers

API Response Differences

`service_tier` value in the Messages API