# OpenAI API Service Tier Controls: How to Fix Disallowed Tier Errors

Projects can now restrict processing tiers, giving teams a cost control that also changes how requests fail.

By Paras Madan | 2026-10-22


OpenAI added service-tier access controls on October 21, allowing teams to choose which processing tiers an API project can use. Organization settings can restrict tiers across every project. The change gives platform teams a way to control processing choices before requests consume a more expensive tier.

The [API changelog](https://developers.openai.com/api/docs/changelog) places these controls in Platform settings. This is an access-policy update, not an announcement of a new model or a reduction in token prices.

## What a service-tier restriction changes

A service tier selects how a request is processed. For example, [Fast mode](https://developers.openai.com/api/docs/guides/fast-mode) prioritizes latency and carries a per-token premium over Standard processing. Applications can select it per request or through a project default. The response's service_tier field records the tier actually used.

The new control adds a boundary around that choice. A developer might configure a background analysis project differently from an interactive customer application, even if both use the same model. Keeping those workloads in separate projects makes the intended processing policy easier to express and review.

**The model name alone does not describe the operating cost.** Request length, generated output and processing tier all belong in the explanation of what a workload is allowed to consume.

## Why the API returns an invalid service_tier error

OpenAI's [error reference](https://developers.openai.com/api/docs/guides/error-codes) documents a 400 response with type invalid_request_error and error.param set to service_tier when the requested or resolved tier is not allowed.

The policy covers default, flex and priority. Fast is evaluated as priority. A request using auto, or omitting service_tier, can still fail if its resolved tier is disallowed. Scale Tier is outside this project policy. A project also cannot enable a tier that its organization blocks.

Check both levels of settings, then select an allowed tier or have an authorized administrator change the policy. Removing the field is not a reliable fix because it leaves resolution to the configured behavior.

A useful troubleshooting step is to inspect the final request after shared wrappers and gateways have processed it. The application may not explicitly choose a tier while another layer supplies one. Log the relevant configuration and error fields without recording credentials or unnecessary prompt content.

## Tier access and monthly budgets solve different problems

OpenAI's [spend-limit guide](https://developers.openai.com/api/docs/guides/spend-limits) distinguishes alerts from hard caps. Alerts notify while traffic continues. Enforced organization or project caps cause affected requests to return 429 when tracked monthly spend reaches the limit. Enforcement can lag slightly, so recorded spending can exceed the configured amount.

A tier restriction answers which processing options a workload may use. A spend cap answers how much tracked spending is permitted before traffic is interrupted. Neither replaces the other.

For an overnight analysis job, the desired policy might allow a lower-cost processing route while also retaining a monthly cap. For a customer-facing workflow, the team might permit faster processing but require earlier spend alerts. Those choices should follow the application's latency and availability requirements, rather than one default applied to everything.

## Test the failure path before changing production settings

Before tightening access, exercise requests that explicitly select a tier and requests that rely on defaults. Include background workers and older clients, not only the main web application. Otherwise a settings change can break a path that did not change in the latest code release.

Treat a disallowed-tier response as a configuration decision to resolve, rather than repeatedly sending the same request. If an application falls back to another tier, that fallback should be intentional and tested against its latency requirements.

**A useful cost control makes the allowed behavior predictable.** The next step is ensuring the application explains policy failures clearly instead of turning a deliberate restriction into an unexplained outage.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn API changes and infrastructure decisions into clear stories developers can understand and use.

[Book a 30-minute call](https://cal.com/paras-madan/30min).