Lock down OpenAI service tiers per project before costs drift

What changed on 21 October, and what it does not tell you

OpenAI's changelog for 21 October 2026 says you can now choose which service tiers projects can use in Platform settings, and that organization settings can restrict service tiers for all projects.¹ That is the whole announcement. It points to a "service tier errors" section of the error codes guide, which this article did not read, so the exact status code and error code a blocked request returns are left for you to capture in the probe below.

Two facts matter for the rest of this checklist. First, a tier is chosen per request with the service_tier parameter or by a project default. For Fast mode, setting Project Service Tier to Fast in project settings makes requests that omit service_tier default to Fast, and the project transitions gradually over time.² A project can therefore change its own cost profile without any code change. Second, Fast accepts both fast and priority as values, so a policy that only thinks about one spelling is incomplete.²

This article is for teams that share one OpenAI organization across many projects. It does not repeat the tier comparison in LLM service tiers compared or the cap mechanics in provider spend limits compared. It covers where to set the restriction, what to allow in each environment, and how to prove it holds.

Why an unrestricted tier is a cost multiplier

The list rates make the case. For GPT-6.1 Sol, up to 272K input tokens, OpenAI's pricing page lists these per-million-token rates by tier.³

The same page lists GPT-6 Astra at $10 and $50 on Standard, $20 and $100 on Fast, and $60 and $300 on Ultrafast, and lists no Ultrafast row for GPT-6 Luna.³ These are OpenAI's list rates; your own contract may differ.

Fast also bills Standard when it silently downgrades. If traffic ramps too quickly, some Fast requests are downgraded to standard speed and charged standard rates, and the response carries service_tier: "default".² That protects you from a surprise in one direction, but it means "we are on Fast" and "we are billed Fast" are not the same claim. Verify from the response, not from the setting.

Decide which tiers each environment may use

The restriction is set per project, so the first design decision is the project layout: one OpenAI project per team per environment, for example payments-dev, payments-staging and payments-prod. That recommendation is ours, not an OpenAI requirement, but without it you cannot give production a different policy from development.

Set the organization restriction to the union of what any project legitimately needs, and keep it narrower than "everything". Because the organization setting restricts tiers for all projects,¹ it is your ceiling: if Ultrafast is off there, no project can use it. Whether an exception for one project can sit under an organization-level block is not described in the changelog entry, so test it rather than assume.

Set the restrictions

Do this in order, outside peak hours, and write down each change with its owner.

• List every project in the organization with its owner team and environment. Projects nobody can name are the first ones to restrict.
• For each project, open its settings and choose the allowed service tiers according to the table above.
• In each project's General settings, check that Project Service Tier is not set to Fast unless the project is on your approved list.²
• In organization settings, restrict tiers to the union you decided on, and leave Ultrafast off until a project has an approved exception.
• Restrict who can create keys. OpenAI's 15 September change lets administrators allow only service-account keys, allow only user-owned project keys or disable new key creation at organization and project level, and organization restrictions take precedence over project settings; existing keys are unaffected.¹
• Set a maximum key lifetime where your policy requires one. Administrators can enforce it at organization or project level, which limits how long a forgotten key keeps its tier access.¹
• Record the change, the date and the approver in your change log. Treat the tier list like a budget: it needs an owner and a review date.

Prove traffic cannot bypass the policy

A settings page shows intent. A probe shows behaviour. For each project key, send the smallest request you can on every tier, through every endpoint your teams use, and record the result.

import os
from openai import OpenAI, APIStatusError

# One key per project, supplied by the project owner for this test.
KEYS = {
    "payments-dev": os.environ["KEY_PAYMENTS_DEV"],
    "payments-prod": os.environ["KEY_PAYMENTS_PROD"],
}
TIERS = [None, "auto", "default", "flex", "fast", "priority", "ultrafast"]

for project, key in KEYS.items():
    client = OpenAI(api_key=key)
    for tier in TIERS:
        kwargs = {} if tier is None else {"service_tier": tier}
        try:
            r = client.responses.create(
                model="gpt-6.1-sol",
                input="ping",
                max_output_tokens=16,
                **kwargs,
            )
            print(project, tier, "OK", "served as", r.service_tier)
        except APIStatusError as e:
            # Capture status and body; do not assume a specific code.
            print(project, tier, "REFUSED", e.status_code, e.response.text[:200])

Each allowed request is real, billed traffic, so keep the prompt trivial and the output capped. Compare the table the probe prints with your policy.

• A tier you blocked is refused, and you have saved the status code and error body so alerting can match it.
• A tier you allowed succeeds, and the returned service_tier is what you expected. Fast can return default when it was downgraded, billed at standard rates.²
• fast and priority behave identically under the policy. They are the same behaviour for supported models.²
• An omitted service_tier and auto resolve to a tier your policy allows, including in a project whose default you changed.
• Run the probe through both Chat Completions and Responses. Fast is documented for either API,² but Ultrafast for GPT-6.1 Sol was added to the Responses API on 8 October.¹
• Probe the Agents API too. Ultrafast was added there on 16 October through agent.service_tier, a separate place to ask for a tier.¹
• Repeat the probe with a key from a project you did not configure, and with a key created after the policy, to catch projects that inherited a default.
• If your applications reach OpenAI through a gateway or proxy, run the same probe through it with a real gateway key. The gateway must forward or refuse service_tier the way you expect.

Failure modes to design around

A default you did not choose. The Fast project setting changes the tier for every request that omits the field.² Review project settings after any reorganization, not only API code.

Retry logic that rewrites the tier. OpenAI's Flex guidance, as summarized in INFRO's tier comparison, suggests retrying with service_tier: "auto" when finishing matters more than price.⁴ Under a restriction, check what auto resolves to before you ship that fallback, and make a blocked-tier error alert instead of retry.

Mislabelled usage on older models. For GPT-5.6 and earlier, Fast requests appear as priority in the usage dashboard even when the request said fast. To review them, group usage by service tier, and group costs by line item.² Match your report filters to both labels.

Ramp limits shared across projects. All your traffic contributes to the same Fast ramp limit, across projects and organizations.² One team ramping Fast can push another team's Fast requests into Standard-speed, Standard-priced processing.

Models without the tier. GPT-6 Luna has no Ultrafast row on the pricing page.³ A policy that allows Ultrafast does not make it available on every model, so keep the model dimension under its own control.

Keep the policy from drifting

A one-time probe decays. Schedule it after every project creation, key rotation and settings change, and keep a weekly check of usage grouped by service tier against the allowed list.

If you route OpenAI calls through INFRO, a few shipped pieces cover the neighbouring controls. Model allowlists (opens in a new tab) restrict which models an organization, project or key may call, with a denied model returning a 403 model_not_allowed.⁵ They restrict models, not tiers, so the tier restriction stays in OpenAI's settings. Spend controls (opens in a new tab) add organization, project, member and key budgets on estimated spend, alongside your provider's own limits.⁶ Every request also records its estimated provider cost by project and key, and daily reconciliation against OpenAI's cost API can show whether the tier mix you intended is the one you were billed for. Traffic that never touches the gateway is invisible to these, which is why the provider-side restriction and the probe come first.