OpenAI Service Tiers After the Project Controls of 21 October: Flex, Fast and Default, the Resolved Tier and the New 400

Recent development · Practical technical guide · 26 October 2026

On 21 October 2026 OpenAI let projects and organisations restrict which service tiers requests may use. How default, flex, fast and auto resolve, why the documented flex fallback can now fail with a 400, what the response tier tells you, and a routing policy that survives the new controls.

What changed on 21 October

The OpenAI API changelog for 21 October 2026 adds one feature: you can choose which service tiers projects may use in Platform settings, and organisation settings can restrict tiers for every project. It links to a new entry in the error codes guide, a 400 Invalid service_tier argument. On its own that is a settings page. It matters because it interacts with how tiers are chosen and how the flex documentation tells you to recover from capacity errors, and those interactions can turn a working retry path into a hard failure.

The tiers and how a request picks one

service_tier value	What it means, per the documentation
default	Standard processing
flex	Batch API token prices with prompt-caching discounts, slower responses and occasional 429 Resource Unavailable; beta with limited models
fast	Fast mode, formerly called priority processing: faster and more consistent latency at a per-token premium
priority	Accepted as the same behaviour as fast on supported models
auto, or omitted	Resolves to the project default; a project can set its default to Fast
Scale Tier	Purchased capacity; outside the new project policy

Three details matter. The Fast mode guide says a project can opt in by setting its Project Service Tier to Fast, after which requests that do not specify a tier default to Fast. Fast mode traffic that ramps too quickly can be downgraded to standard speed and price, and the response then reports service_tier default; the guide's rule of thumb is to grow by no more than 50 percent every 15 minutes once traffic reaches a million input tokens per minute. And the response's service_tier field reports the tier actually used, which for GPT-5.6 and earlier models reads priority even when you asked for fast.

The new 400 and what triggers it

Per the error codes guide, the API returns Invalid service_tier argument: The requested service tier is not allowed for this project, as an invalid_request_error with error.param set to service_tier, when a request selects or resolves to a tier the project does not allow. Restrictions cover default, flex and priority, and fast is evaluated as priority. The important sentence is the one about resolution: a request that omits service_tier or sends auto can also get this error if it resolves to a disallowed tier. A project cannot enable a tier that its organisation blocks, and Scale Tier is outside the policy.

Now combine that with the flex guide. For 429 Resource Unavailable on flex, it suggests either backing off and retrying, or retrying with standard processing by setting service_tier to auto or removing it. If the project's default is Fast and an organisation administrator has since disallowed priority, that standard-processing retry resolves to Fast and fails with the new 400. The fallback that worked on 20 October breaks on the 21st without any code change. Nothing in the request changed, only a setting two levels above it, which is why the error is easy to misread as a bug in the client.

A worked example: a nightly enrichment job

A data team runs nightly enrichment with service_tier flex to get batch prices, and falls back to auto on 429 Resource Unavailable so the job finishes before the morning. The project default was set to Fast months ago for an interactive feature. Finance then restricts the organisation to default and flex to control spend. The next night, flex capacity is short, the job falls back, auto resolves to Fast, and every fallback request fails with the 400. The job does not finish, and the error looks like a malformed request rather than a capacity problem.

The fix is to name the fallback tier explicitly and to treat the 400 as a configuration error, not something to retry.

Illustrative Python with the openai package; the error body layout differs between versions, so the check reads both shapes.

import time
import openai

def create(client, **kw):
    """flex first; on capacity errors back off, then fall back to an explicit tier."""
    for delay in (5, 20, 60):
        try:
            return client.responses.create(service_tier="flex", timeout=900, **kw)
        except openai.RateLimitError as e:          # 429, including Resource Unavailable
            time.sleep(delay)
    try:
        return client.responses.create(service_tier="default", **kw)  # never "auto"
    except openai.BadRequestError as e:
        body = getattr(e, "body", None) or {}
        if (body.get("param") or body.get("error", {}).get("param")) == "service_tier":
            raise RuntimeError("Tier not allowed for this project: fix settings") from e
        raise

Also log the service_tier in every response. It is the only reliable record of what you were charged for, and it is how you notice a Fast request downgraded to default by the ramp limit, or a request you meant as flex that was not. A daily count of requests by requested tier and by served tier makes any mismatch obvious within a day.

Settings to review today

List each project's default tier and allowed tiers, and the organisation restrictions above them.
Search code for service_tier auto and for requests that omit the field; for each, decide which tier it should be and send that explicitly.
Change flex fallbacks from auto to an explicit allowed tier, and make sure the allowed list includes it.
Treat 400 with param service_tier as a configuration error: alert, do not retry.
Raise SDK timeouts for flex, whose documentation notes slower responses and the SDKs' default ten-minute timeout.
Record the response tier per request in your cost and latency dashboards.

Failure modes

Assuming auto means standard. It means the project default, which may be Fast or disallowed.
Retrying the 400. It will fail the same way until the settings change.
Assuming fast is a separate tier for policy. It is evaluated as priority.
Reading the request, not the response. The ramp limit can serve a Fast request at default, and older models report priority for fast.

Sources and what was not tested

This guide is based on the changelog, the error codes guide and the flex and Fast mode guides, read on 26 October 2026. No request was sent to the API, so the interaction described in the worked example is derived from the documented rules, not observed; confirm it in a test project by disallowing a tier and sending a request with auto before relying on it. If you never set service_tier and have no project-level defaults or restrictions, none of this changes your traffic today.

Sources and scope

Checked against these sources on 26 October 2026. Event: OpenAI API changelog: project service-tier controls, 21 October 2026; recheck it before acting. Documentation-based; no API request was sent. The fallback failure in the worked example follows from the documented rules and was not observed.

Send an explicit service_tier instead of auto, make sure fallback tiers are on the allowed list, treat a 400 on service_tier as a configuration error rather than retrying it, and log the tier reported in each response, which is what you were actually served.