What Tier 2 to Tier 3 Used to Buy You

Update, October 6, 2026: this step no longer exists

On October 6, 2026 OpenAI replaced Tier 1 to Tier 5 with three paid tiers: Build, Launch and Grow. Read against OpenAI's own tables from before and after the change, the new ladder kept some of the old rows' figures and dropped the rest. Build carries the limits Tier 2 had, at the entry spend Tier 1 used to need. Launch carries Tier 4's, and Grow carries Tier 5's. Tier 1 and Tier 3 are gone, and with Tier 3 went the step this post is about — the one where requests-per-minute stood still.

On the new ladder every step raises both requests and tokens per minute for every model this site prices. The rate-limit tier planner works that out from the published tables rather than asserting it, and it will say so if a flat step ever comes back. What follows is the post as written for the five-tier ladder, moved into the past tense. Its lesson outlives the ladder: read the row for the limit you actually hit before paying to move tiers.

The original post

Usage tiers are sold, implicitly, as a ladder — climb it, and everything gets better. More monthly spend headroom, higher rate limits, a bigger batch queue. For the jump from the second tier to the third, that story was only partly true, and the part that wasn't true was exactly the part most likely to bite someone who upgraded specifically to fix a throughput problem.

What actually does improve

Across most of the published rate-limit groups on this site's roster, moving from Tier 2 to Tier 3 raised the monthly spend ceiling substantially, and it raised tokens-per-minute meaningfully too — often close to doubling it. The batch-queue ceiling jumped by a much larger multiple again, which matters a great deal for anyone running large asynchronous jobs. None of that was in question, and for a workload bottlenecked on token throughput or batch volume, that upgrade genuinely delivered.

What stayed exactly where it was

Here's the part that wasn't obvious from a tier's marketing framing: in most of the published limit groups, requests-per-minute at Tier 3 was identical to requests-per-minute at Tier 2. Not a smaller increase — unchanged. A workload whose actual bottleneck was the rate of individual calls, rather than the volume of tokens within those calls, got nothing from that specific upgrade, while still paying the qualifying spend the higher tier required.

Why this asymmetry is easy to miss

Tier tables are usually read as a single row moving up — "Tier 3 is better than Tier 2," full stop. That framing collapses several genuinely independent numbers (RPM, TPM, monthly ceiling, batch queue) into one implied verdict, and it's the collapsing that causes the mistake. Nobody reading "Tier 3 has higher limits" in the abstract was wrong, exactly — most of the limits were higher. But "most" isn't "all," and the one that stayed flat is often the one a specific workload actually needed to move.

A concrete way this plays out

Picture a workload making frequent, small, latency-sensitive calls — a live feature calling the API on every user interaction, say, where each individual call is modest in token size but the call rate itself is what's constraining throughput. That workload hits its RPM ceiling well before it comes close to its TPM ceiling. Paying to reach Tier 3, in the hope that "higher limits" would relieve the pressure, changed nothing for this specific shape of workload in several of the published groups — the ceiling that was actually binding was the one number that didn't move.

Why this isn't a criticism of how tiers are designed

There's a reasonable, defensible logic behind an asymmetric upgrade like this, even if it's not stated anywhere explicitly: RPM, TPM and monthly spend represent genuinely different kinds of infrastructure pressure, and there's no requirement that they all scale at the same rate as an account's trust and spend history grows. A provider might reasonably decide that a customer's demonstrated spend justifies more total throughput and a bigger batch allowance, without that same signal justifying a proportionally faster request rate specifically. The mistake isn't in how the tiers were designed — it's in assuming, without checking, that every tier upgrade moves every number in the same direction by a similar amount.

The fix costs nothing but a few minutes

Before paying to reach a higher tier specifically to solve a throughput problem, the response-headers on an actual throttled request tell you plainly which ceiling you hit — the request limit or the token limit. Checking that, and checking the specific model's published rows for the two tiers in question, for exactly that limit, takes a few minutes and either confirms the upgrade will help or reveals it won't, before any money changes hands based on an assumption.

What actually fixes a pure RPM ceiling, if not a tier upgrade

If the diagnosis comes back "RPM specifically, and this tier group doesn't raise it," the actual fix usually isn't a further tier upgrade either — it's restructuring the workload. Batching several small calls into fewer, larger ones reduces the request count without necessarily reducing the useful work done per call. Smoothing bursty request patterns with client-side backoff avoids tripping a per-minute ceiling that a steadier request rate would have stayed under. Both of these are engineering changes to how the workload calls the API, not billing changes, and they're often both cheaper and more effective than paying for a tier that was never going to move the number that mattered.

The broader lesson about published limits generally

This asymmetry is a specific instance of a more general habit worth having with any published table on this site, or anywhere else: read the actual row for your actual model and your actual limit, not the general shape of "higher tier, higher limits." A table with several distinct groups and genuinely different per-group behavior, the way this site's own rate-limit reference is built, exists precisely because a general rule of thumb — however intuitive — gets the specifics wrong often enough to be worth checking every time real money or real throughput is on the line.

Why this matters more the further up the ladder you go

The old ladder's one plateau sat at the Tier 2-to-3 jump, and the replacement ladder has none — but a team planning a multi-tier growth path (expecting to climb several tiers as usage scales) can't assume either fact holds forever. Tier tables get revised, and each individual jump is its own question, answerable only by reading that specific pair of rows in the specific model's own published table, not by assuming the previous jump's behavior predicts the next one's.

Budgeting the qualifying spend against the real benefit

Reaching a higher tier isn't just about the tier's own fee structure — qualifying for one means having already bought a real, specific amount of credits, which is itself a cost worth weighing against what that tier actually delivers for your workload. Framing the decision as "will the numbers that actually move be worth having reached this spend threshold" rather than "should I upgrade" is a more honest way to evaluate whether pursuing a higher tier is worth actively planning for, versus simply arriving there naturally as usage grows regardless of any deliberate push toward it.

Where this leaves a team actually planning capacity

The practical takeaway for anyone doing real capacity planning against these tiers: build the plan from the specific published numbers for your specific model and your specific bottleneck, not from a general sense that "more spend equals more headroom." A five-minute check against the real table, done before committing a budget or a timeline to a tier upgrade, is the difference between a plan grounded in what will actually happen and one grounded in an assumption this page exists specifically to correct.