Service Tiers
Control cost and latency tradeoffs with service tier selection
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.
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). 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.
The following providers support flex and priority service tiers for select models:
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.
Provider documentation:
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:
/api/v1/chat/completions): service_tier is returned at the top level of the response object, matching OpenAI’s native format./api/v1/responses): service_tier is returned at the top level of the response object, matching OpenAI’s native format./api/v1/messages): service_tier is returned inside the usage object, matching Anthropic’s native format.