OpenAI added project and organization service-tier controls on October 21, 2026, according to its API changelog. The update lets administrators choose which processing tiers projects may use and restrict them across an organization. This catch-up report matters for business agents because a tier-policy change can reject a request rather than simply alter its processing speed.
Organization restrictions set the boundary
The changelog places the controls in Platform settings. OpenAI's error-code documentation clarifies the hierarchy: projects cannot enable a tier blocked by the organization. Project choices therefore operate inside the organization's restrictions, not around them.
The documented policy covers default, flex, and priority; fast is evaluated as priority. Scale Tier sits outside this project policy. Do not assume the announcement covers every other processing option.
Allowed tiers and a project's selected processing tier are different concepts. The Responses API reference says auto uses the project's configured tier, normally default unless changed; omitting service_tier also uses auto.
A blocked tier needs a configuration fix
OpenAI documents an HTTP 400 with type invalid_request_error and error.param = service_tier when the requested or resolved tier is disallowed. Even auto or an omitted parameter can fail. The documented remedy is an allowed tier or a settings change.
Operational recommendation: treat this as a policy/configuration failure, not a transient capacity problem. Before tightening production settings:
- Inventory explicit tier selections and project defaults in agent workers, gateways, and background jobs.
- Test both explicit and implicit selections in staging, including a deliberately blocked request.
- Route the specific tier-policy error to an actionable alert rather than repeatedly sending the unchanged request.
- Permit fallback only to a preapproved, allowed tier; otherwise stop or queue the task for operator review.
For successful requests, record the response's service_tier alongside the requested value. The API reference notes that the actual processing tier can differ from the requested one.
Tier governance is not a budget or latency promise
This announcement controls which processing tiers may be used, not how many dollars an application may spend. It should not be presented as a spending cap.
The existing tier trade-offs still matter. OpenAI describes Flex as lower-cost processing with slower responses and occasional resource unavailability; Fast mode carries a per-token premium. Neither the new permission controls nor choosing a permitted tier guarantees an agent's end-to-end completion time.
For teams reviewing last week's change, the useful next step is narrow: align organization policy, project defaults, and application fallback behavior before rollout. Measure task completion and failure rates after the change rather than assuming a settings update is operationally neutral.