Service Tiers
Theservice_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
Passservice_tier as a top-level parameter in your request body. Supported values are flex (lower cost, higher latency) and priority (faster, higher cost). 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
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:
-
The
service_tierparameter. Forpriority, 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. Forflex, 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 withallow_fallbacks: falseto route only to the top endpoint of that tier. -
Tier endpoint slugs in
provider.orderorprovider.only. Each tier has its own endpoint slug, formed by appending the tier to the provider slug, e.g.openai/priorityorgoogle-vertex/flex. For example,"provider": { "only": ["openai/priority"] }restricts routing to OpenAI’s priority 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-suffixedtag (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 supportflex and priority service tiers for select models:
- OpenAI
- Google Vertex
- Google AI Studio
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:
- OpenAI: Chat Completions, Responses, and pricing
- Google Vertex: Flex and Priority
- Google AI Studio: Flex and Priority
API Response Differences
The API response includes aservice_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_tieris returned at the top level of the response object, matching OpenAI’s native format. - Responses API (
/api/v1/responses):service_tieris returned at the top level of the response object, matching OpenAI’s native format. - Messages API (
/api/v1/messages):service_tieris returned inside theusageobject, 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.