Tier 2 to Tier 3 Does Not Raise Your RPM

The mistake

Paying to reach the third usage tier specifically to fix a requests-per-minute bottleneck, on the reasonable assumption that every tier upgrade raises every limit — and then finding the same 429s waiting on the other side of the upgrade.

Why this happens

Usage tiers bundle several limits together — RPM, TPM, monthly spend ceiling, batch queue size — and it's natural to assume they all move together as you climb. In most of the published limit groups, moving from the second tier to the third does raise the token-per-minute ceiling substantially and the batch-queue ceiling by a large multiple. Requests-per-minute, in those same groups, stays exactly where it was. It's not a smaller increase — it's genuinely unchanged.

Why it matters

If your workload's actual bottleneck is RPM — lots of small, fast calls rather than a few large ones — the third tier buys you nothing for the specific problem you upgraded to fix, while still costing the extra qualifying spend the higher tier requires. That's money spent on a lever that doesn't move the number you needed moved, and it's easy to only discover this after paying to qualify, since the plateau isn't obvious from a tier's headline "higher limits" framing.

The fix

Before paying to reach a higher tier, check which specific limit your workload is actually hitting — the rate-limit response headers on a throttled request will tell you plainly whether it's the request ceiling or the token ceiling that tripped. If it's RPM specifically, check the published per-tier table for your model before assuming the next tier helps; in several limit groups it won't, and the fix for a pure RPM ceiling is more often batching several small calls into fewer larger ones, or spreading load across time, than it is paying for a tier that leaves RPM untouched.

This plateau isn't universal across every model on the roster — it shows up in most of the published limit groups but not all of them, which is exactly why checking the specific table for your specific model matters more than remembering a general rule about tier upgrades.

See also

The Rate-Limit & Tier Planner checks a workload directly against the real published table for your model and tier, so this plateau is visible before you commit to an upgrade rather than after.