OpenAI API usage tiers: a cheaper ceiling, the same agent limits

OpenAI’s three new API usage tiers make capacity cheaper to buy, and they leave every limit an agent hits in production where it was. On 6 October 2026 OpenAI replaced its five usage tiers with three, and a $5 credit purchase now unlocks a $500 monthly usage limit, according to a comparison of the old and new tiers. The top tier, with a $200,000 monthly limit, now opens at $500 of cumulative purchases instead of $1,000. That is a price change at the door. For a team running agents, the questions that decide whether the agent survives a busy hour are per-minute limits per model, how the agent behaves when it hits one, and who can buy more headroom, and the change answers none of them differently.

Every vendor fact in this post comes from public sources, read on 13 October 2026; the scores come from The Headless Index, which is our own measurement.

What changed on 6 October

OpenAI moved from five usage tiers to three, named Build, Launch and Grow, and halved the spend needed to reach the top one. OpenAI’s rate limits guide describes the mechanism: an organisation moves up automatically once its cumulative credit purchases pass $5, $100 and $500, and each tier raises the monthly usage allowance and the requests and tokens per minute allowed per model.

The old ladder ran from Free through Tier 5, with cumulative spend from $5 to $1,000 and waiting periods of up to 30 days between steps, as an older answer on OpenAI’s own forum sets out. Existing organisations migrate automatically, so nobody has to apply.

The top threshold fell from $1,000 to $500, so it halved. At the bottom, $5 of credit now carries a monthly ceiling of $500, a ratio of 100 to 1; at the top, $500 carries $200,000, a ratio of 400 to 1. A prototype whose team used to climb five steps, with waits of up to 30 days between them, can now pass the top threshold with a single $500 purchase.

A tier is a ceiling an agent cannot raise itself

A usage tier is a spending ceiling, and the only way through it is a purchase. OpenAI’s guide ties every promotion to cumulative credit purchases, not to traffic, age or a request. The Headless Index records that OpenAI’s account-level billing and team membership still require the dashboard, while fine-tuning, batch runs, file uploads, vector stores, evals and project-level usage are all reachable from code.

An agent can run every workload OpenAI exposes, and it cannot buy itself more room to run them. When a production agent needs a higher ceiling, a person with access to billing opens a browser. The tier change makes that step cheaper and faster. It does not remove it.

That is consistent with how the vendor meters everything else. In our post on AI agent pricing we noted that a per-request meter prices traffic. OpenAI’s tiers are a meter of exactly that kind: requests, tokens and dollars, with no notion of which agent spent them or on what task.

Per-minute limits are still per model, and agents spend requests in loops

The limit an agent hits first is rarely the monthly one. The tiers set requests per minute and tokens per minute for each model separately, and OpenAI’s guide also documents the response headers that report how much of each remains, with retries by exponential backoff as the recommended response to a refusal.

An agent that uses tools makes a model request for every step of its loop: the model asks for a tool, your code runs it, and the result goes back to the model in the next request. On a stateless endpoint such as Chat Completions each of those requests carries the conversation so far, so a long task fills its token allowance faster than its request count suggests. None of the five top search results for this change explains how to size an agent workload against those two limits. The method below carries no vendor numbers, because they differ per model and per tier:

requests per minute needed = concurrent tasks x model calls per task / task duration in minutes
tokens per minute needed   = concurrent tasks x tokens per task / task duration in minutes
headroom                   = tier limit for that model - the larger of the two needs

Measure model calls per task and tokens per task from your own traces, not from a single happy-path run. A task that retries a failed tool call or plans twice raises both numbers, and every backoff stretches the task’s duration. A higher tier moves the limit; it does not change the shape of that curve.

What the tiers do not touch: the machine surface

OpenAI’s machine surface is the strongest in its Index category, and the tier change did not alter any part of it that the Index measures. The Index scored OpenAI on 20 August 2026 at 86 of 100, band B: 20 of 20 for being API-first, 18 for headless operation, 14 for MCP and agent integration, 20 for schema observability and 14 for webhooks and events. That score predates the 6 October change, and none of its five criteria is a price or a rate limit, so the change neither raises nor lowers it.

The AI platforms category holds 80 vendors, all scored on the same day; OpenAI’s 86 is the highest total in it, and the category mean is 31.1. On webhooks and events only three of the 80 reach 14 of 20 or more: OpenAI with 14, mem0 with 15 and Replicate with 16.

For agents, the webhook score is the part of that record that interacts with rate limits. The Index credits OpenAI with webhooks for batch completions, beside Realtime server-sent events and fine-tuning job status callbacks, with HMAC signing documented. An agent that waits for long work through a signed webhook does not have to poll for the result. Moving long, non-interactive work onto the async surfaces is a design decision the tier change does not make for you.

The Index also records that OpenAI publishes no official MCP server and treats tool use as a first-class part of the API itself. For an agent builder that means the integration contract is OpenAI’s own API schema, and the tier decides only how hard you may call it.

Same models, a second ladder: Azure OpenAI

The tier change applies to OpenAI’s own API and to nothing else. Microsoft runs its own quota tiers for Azure OpenAI, with automatic moves between them, a process to request more quota, and a way to check which tier a subscription is on.

The Index scores Azure OpenAI separately, at 74 of 100 in band B, also measured on 20 August 2026. A team that runs the same model family through both front doors therefore has two capacity plans, two sets of limits and two ways of raising them. A capacity plan for an agent has to name the front door as well as the model.

The limits of this explainer

This post rests on public sources, and on one measurement of ours that is older than the change. The figures for the tiers were read on 13 October 2026, through a search-and-read pass over the five top results for “openai api usage tiers”; OpenAI’s own guide supplied the thresholds and the mechanism, and the monthly limits for Build and Grow come from a secondary comparison of the old and new tiers. We have not stated the monthly limit of the middle tier, Launch, because none of the pages read gives it in a form we could check. We reproduce no per-model request or token limits, because they differ per model and change without notice; read them in your organisation’s limits page and in the response headers.

The Index score of 86 was measured on 20 August 2026, before the change, and we have not re-scored OpenAI since. We have not run an agent workload against the new limits, so this post makes no claim about throughput in practice.

What it means for an agent’s architecture

The tier change lowers the cost of a ceiling, and an agent’s architecture should treat that ceiling as something a person moves, not the agent. Budget the per-minute limits per model from measured traces, read the remaining-limit headers on every call, and back off on refusal, because the higher tier only moves the point where that behaviour starts. Put long, non-interactive work on batch and webhooks, where the Index already credits OpenAI’s surface, so it stops competing with interactive loops for the same minute. Keep the billing step in your runbook as a human step, with an owner, because the dashboard is still the only place it happens. And when the same models run through Azure as well, plan capacity per front door, because the two ladders are raised separately.