Usage Tiers, Rate Limits & Response Headers

Two different things both get called "rate limits" on OpenAI's platform, and conflating them is a common source of confusion: spend-based usage tiers, which gate how much you can spend in a month and which limits you qualify for, and per-model RPM/TPM tables, which cap how fast you can send requests once you're in a given tier.

The tiers themselves

Qualification is entirely spend-based — reaching a tier is a function of how much you've already paid, not how long you've had an account or how you've used it — and each tier raises your monthly usage ceiling alongside its throughput limits. This site's own first research pass initially reported per-model throughput as unpublished; that was wrong, corrected after checking each model's own reference page directly rather than only the general rate-limits guide, which is recorded honestly in this site's sourcing notes because the mistake is worth knowing about, not just quietly fixing.

Three things worth knowing before you plan around a tier upgrade

Moving up a tier doesn't always raise every limit — in several of the published limit groups, going from the second to the third tier raises your token-per-minute ceiling and your batch queue substantially while leaving requests-per-minute completely unchanged, which means a workload bottlenecked on RPM specifically gains nothing from that particular upgrade. The largest, most capable models are also throttled far harder relative to their price than smaller ones — one premium model's starting tier allows a small fraction of the request rate every standard-tier model gets, despite costing dramatically more per token, which is easy to miss if you're only comparing sticker prices. And the model built specifically for agentic coding work sits in the same throughput group as the general frontier models, so choosing it over the CLI's own default costs nothing in requests-per-minute or tokens-per-minute — only in context window and training recency.

Reading the response headers

Every response carries a set of rate-limit headers reporting the current ceiling and remaining budget for both requests and tokens, plus a retry-after value on a throttled request — worth knowing that a retry-after header specifically does not mean a billing or account-level problem will resolve itself by waiting and retrying; those need direct action, not patience.

What the table shows

Every tier's qualification and monthly ceiling, and every published model's per-tier RPM/TPM/batch-queue table side by side, so the five distinct limit-group shapes are visible at a glance rather than buried across ten separate model pages.