Skip to main content

Overview

Service tiers let you choose how a request is processed. flex trades slower, queue-based processing for a lower price. priority trades a higher price for lower latency. Requests without a tier run at the standard tier, exactly as before. Set the tier with the service_tier request parameter:
The response reports the tier the request was actually served and billed at:

Tier values

string
default:"auto"
One of auto, default, flex, scale, priority, fast, or ultrafast.
The tier you name is the tier you get. Routing only ever sends the request to a provider that supports it, and the tier is never traded away to reach a cheaper or faster provider. A request that names a tier no provider can serve fails rather than running at a different tier. The response always reports the tier that was served.

Availability

Tiers are available on select OpenAI, Azure, Vertex AI, and Google AI Studio models, and a model can support different tiers on different providers. Check before you send: read supports.service_tier on each provider block from GET /v1/models, since a tier no provider supports will fail the request. Each supported tier that carries its own rates also appears as an entry in that block’s pricing array with condition.service_tier set; the last entry, with no condition, is the standard rate. The models page shows the same data with a per-tier price view.

Where the tier is reported

The reported value is always the tier you were billed at, so "service_tier": "default" always means standard pricing. Messages uses Anthropic’s vocabulary, where standard covers both standard and flex billing. The exact billed tier is still on the request’s cost breakdown.

Billing

A request is billed at the pricing entry matching the tier it was served at. If a provider accepts the tier but reports serving a different one, you are billed for what it served. Tool calls such as web search are billed at their flat rates regardless of tier.

When a tier is not available

The tier is a required capability of the request, like function calling or image input, and it is never given up in feature degradation. Routing only considers providers that support it, so a tiered request is never quietly served at a price or latency you did not ask for.
  • A tier no provider can serve fails the request. If you ask for flex on a model where no provider offers it, the request errors rather than running at standard rates. Retry without service_tier to run at the standard tier.
  • Pinned providers forward the tier as-is. If you pin a specific provider, for example azure/gpt-5.6-luna, the tier is sent to that provider unchanged. If it does not accept the tier, its own error is returned to you.
  • Vertex AI serves its tiers on the global endpoint only. A Vertex BYOK key pinned to a region runs at standard rates, because the regional host ignores the tier headers.

Streaming and timeouts

Streaming requests carry the tier on every response event, including response.created and the final response.completed:
Flex requests can spend several minutes in a queue before producing output, so set a client timeout that covers the wait. Streaming connections stay open through the queue with periodic keepalive events. Long flex work does not require streaming. A non-streaming flex request gets the serving provider’s full flex window, up to 30 minutes on Google providers and 15 minutes on OpenAI. The gateway holds that connection open with whitespace padding in a chunked response body, which JSON parsers ignore. Requests without a tier keep the standard timeout.

Chat Completions and Messages

The Chat Completions API accepts service_tier with the same values and reports the served tier on the response and on every streamed chunk. The Messages API accepts the tier two ways: Anthropic’s fast-mode spelling, "speed": "fast", which is the fast tier; or service_tier with flex, priority, or fast. When both are sent, service_tier wins and speed is the fallback. Anthropic’s own service_tier request values (auto, standard_only) mean no tier on their own. A request that sends one of them alongside "speed": "fast" still runs as fast, because fast mode and the tier are independent products. Because fast is its own tier rather than a spelling of priority, a model whose providers offer priority but not fast will reject a fast-mode request. Send service_tier: "priority" for those models.
Last modified on September 22, 2026