Skip to main content

​
Service Tiers

The service_tier parameter lets you control cost and latency tradeoffs when sending requests through OpenRouter. You can pass it in your request to select a specific processing tier, and the response will indicate which tier was actually used. Your request is billed at the actual served tier’s rate.

​
Using Service Tiers

Pass service_tier as a top-level parameter in your request body. Supported values are flex (lower cost, higher latency) and priority (faster, higher cost). fast is also accepted as 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

​
Fast mode

service_tier: "fast" (OpenAI’s Fast mode rename of priority processing), service_tier: "priority", and Anthropic’s native speed: "fast" parameter are fully interchangeable on all APIs and providers. Any of the three requests the priority tier (the response reports priority), and on Anthropic models with a fast sibling (e.g. anthropic/claude-opus-5-fast) reroutes to the fast sibling (see Fast Mode). 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. 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 two ways to do that:
  1. The service_tier parameter. For 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. For 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.
  2. 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/priority or google-vertex/flex. For example, "provider": { "only": ["openai/priority"] } restricts routing to OpenAI’s priority tier.
Requests that don’t use either of these are never routed to a non-default service tier.

​
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/priority) and pricing with the tier multiplier already applied (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
  • Google Vertex
  • Google AI Studio
  • SpaceXAI (priority only)
The response’s service_tier field reports which tier was actually used. Possible response values are default, flex, priority, or null when no service tier is available from upstream. Note that OpenRouter normalizes provider-equivalent base tier labels, such as Google’s standard, to default, except in the Anthropic Messages API, which preserves standard to match Anthropic’s spec (see API Response Differences below). Provider documentation:

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