OpenAI service tier restrictions add project controls

OpenAI service tier restrictions now let API teams choose the processing tiers a project may use, with organization-wide restrictions available in Platform settings. OpenAI announced the feature in its October 21, 2026 API changelog. For administrators and application owners, the immediate task is to compare those permissions with the configuration their software actually sends. This article was first published on October 22.

What OpenAI service tier restrictions change

The update adds a centrally managed permission decision to processing-tier selection. The announcement names project and organization settings; it does not announce a new token price. An operations team can therefore review processing choices as a configuration policy, rather than relying only on conventions documented beside application code.

Keep this event separate from the earlier Build, Launch, and Grow usage-tier update. That story concerns organization capacity and qualification. Here, the question is which processing choices a workload is permitted to make. Label both fields explicitly in deployment notes so that a request to change one does not accidentally become a request to change the other.

Recognize the policy error before retrying

The error reference specifies HTTP 400, type invalid_request_error, and error.param equal to service_tier when a selected or resolved tier is disallowed. Its scope covers default, flex, and priority; fast is evaluated as priority. Scale Tier is outside this project policy. A project cannot enable a tier blocked by its organization. Omitting the parameter, or sending auto, can also fail if resolution selects a prohibited tier.

The documented remedies are to choose an allowed tier or correct the relevant settings. This is a rejection, not a promise to downgrade the request automatically.

For incident triage, preserve the parameter and error classification in the failure report. Our recommendation is to route this case to the configuration owner instead of putting it into a generic transient-failure retry loop. Keep credentials and customer prompt content out of that report. A concise diagnostic record is more useful than a screenshot that hides which application configuration produced the request.

Check project defaults alongside explicit choices

Existing Fast mode documentation describes both per-request selection and a project default, under Project settings > Default Service Tier: Fast. That default is equivalent to Priority, and requests can override it. This is supporting context about an existing setting, not the documented menu path for the newly announced restriction controls.

The same FAQ describes a different behavior: rare downgrades to Standard when Fast performance is degraded and traffic ramps too quickly. Keep that performance mechanism separate from the policy error above. Otherwise, a team might interpret a denied request as a latency event and investigate the wrong system.

For auditing, the FAQ also points to the Usage dashboard: group token usage by Service Tier and costs by Line Item. It notes that requests using either Fast or Priority currently appear as Priority. Use that naming when reconciling dashboard observations with application configuration, rather than treating the two labels as separate permission categories.

Review the configuration without disturbing production

OpenAI’s production guidance recommends separate staging and production projects, with project-level access, rate, and spend controls. It also distinguishes spend alerts from hard limits: alerts notify, while hard limits stop affected traffic once tracked spend reaches the configured amount. These remain separate controls to review alongside processing permissions.

Our proposed rollout starts with a saved configuration inventory. For each application, record the intended organization and project, the owner, the model, the request-level processing choice, and any default inherited from a shared client wrapper. Check background jobs as well as the interactive application. A setting embedded in an evaluation script can be easy to miss when the production frontend uses a different client.

Next, review the desired policy with the person responsible for the workload. Explain why each processing option is needed before changing permissions. For example, an interactive assistant and an overnight analysis job may have different latency requirements even when the same team maintains them. Document the decision per workload rather than copying one application’s settings into every project.

A small acceptance test for the next release

This is an original test plan, not a test executed by this site. In a staging project, keep a short, non-sensitive prompt and model fixed. Run the application’s explicit processing configuration, then its default-driven configuration. Record the selected settings, completion status, error classification if present, and the project used. Compare the observations before and after the proposed policy change.

Include shared libraries and scheduled workers in the check. Ask a reviewer to reproduce the recorded configuration from the release notes; if that requires undocumented local defaults, fix the record before deploying. Preserve the previous settings so the team can identify exactly what changed during a later investigation.

Use the API setup guide for integration basics and the pricing guide for cost comparisons. The October 21 announcement does not specify initial policy defaults, effects on requests already in flight, or a complete UI walkthrough. Verify those details for the intended account before a production change; do not infer them from the older Fast default setting.