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.
auto, default, and flex are required: routing only sends the request to a provider that supports the tier, and a request that names one no provider can serve fails rather than running at a different tier. priority, fast, scale, and ultrafast are preferences: routing prefers a provider that offers the tier, and otherwise steps down to the closest tier the provider does offer (see When a tier is not available). 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 flex fails the request when no provider supports it, and the tiers above default step down to one the provider offers. 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

default and flex are required capabilities of the request, like function calling or image input, and are never given up in feature degradation. The tiers above default are given up last, after every other optional feature.
  • flex fails the request when no provider can serve it. 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.
  • Tiers above default step down to the closest tier a provider offers. The order is scale → ultrafast → fast → priority → default. Each provider is sent the highest tier it offers at or below the one you asked for, so ultrafast on a provider that offers fast runs at fast, and on one that offers neither runs at default. The response reports the tier that was served.
  • A failed attempt steps down on the same provider first. If a tiered attempt fails, routing retries the same provider at its next lower tier, down to default, before moving on to another provider. This applies to pinned providers too, for example azure/gpt-5.6-luna.
  • 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 runs a fast-mode request at priority, the next tier down.
Last modified on October 23, 2026