OpenAI usage tiers in 2026: Build, Launch, Grow and rate limits

OpenAI's API has three paid usage tiers since 6 October 2026, down from five: Build, Launch and Grow¹. Build starts after $5 of total purchases on the organization, Launch after $100 and Grow after $500, with monthly usage limits of $500, $5,000 and $200,000; a Free tier, for users in an allowed geography, carries a $100 monthly limit. Tiers advance automatically when total purchases reach each threshold².

The tier sets two different ceilings: how much the organization may spend in a month, and how fast it may send requests and tokens to each model. This guide covers both, how to read where you stand, and what to do when you hit the second.

The three tiers

The monthly usage limit is the organization's approved ceiling. It is separate from the spend limits you set yourself on an organization or project, which come in two kinds: a spend alert that notifies and lets traffic continue, and a hard spend limit at which affected requests return a 429². Remember that second one when you write retry logic.

OpenAI's guide shows current limits under Settings > Organization > Limits and offers Upgrade tier in the Usage Tiers section². It does not describe the old five tiers any more, so compare against your own records rather than old blog posts.

Rate limits by tier and model

Rate limits apply per model and are measured in requests per minute (RPM), requests per day (RPD), tokens per minute (TPM), tokens per day (TPD), images per minute (IPM), audio minutes per minute for some streaming audio models, and a Batch queue limit counted in queued input tokens. Whichever dimension runs out first stops you: 20 short requests can exhaust a 20 RPM limit long before a 150,000 TPM limit².

Each model page repeats its own row: the GPT-6 Luna page lists the same 5,000, 10,000 and 30,000 RPM and 2M, 10M and 180M TPM by tier³. Older models keep their own figures. The GPT-4o page, for example, lists 5,000 RPM and 450,000 TPM on Build, 10,000 RPM and 2M TPM on Launch, and 10,000 RPM and 30M TPM on Grow, with separate Batch queue limits⁴. Read the model page for each model you call; do not assume the GPT-6 table applies.

Two more rules from the guide shape capacity planning²:

• Shared limits. Models listed under a "shared limit" on your organization's limits page draw on one pool. Spreading traffic across models in the same group does not add capacity.
• Long context. Long-context models have a separate limit for long-context requests.

Read the headers

Every response tells you where you stand. These are the headers OpenAI documents²:

Export the remaining-tokens and remaining-requests values as metrics per model and per service. A dashboard that shows them falling toward zero at the same hour every day tells you about a limit before a customer does.

Handle 429s by type

OpenAI documents two temporary errors and how to treat them²:

And the rules that keep retries from making things worse²:

1. Treat Retry-After as a minimum and add a small random delay. If it is missing or invalid, use exponential backoff with jitter.
2. Cap both attempts and total retry time.
3. Do not nest retry loops. The official SDKs already retry eligible 429 and 503 responses; if you retry yourself, turn theirs off or account for them.
4. Do not retry quota, billing or other errors that need a person, including a hard spend limit.
5. Failed requests count toward per-minute limits, so resending at full speed digs the hole deeper.
6. Ramp gradually. Once traffic reaches about 1 million input TPM, raise it by no more than 50% every 15 minutes; the exact threshold varies by model and conditions.
7. Size max_tokens close to the expected response. The rate limiter accounts for it.

import random, time

RETRYABLE = {("rate_limit_error", "slow_down"), ("service_unavailable_error", "server_is_overloaded")}

def call_with_retry(send, max_attempts=5, deadline_s=60):
    # `send` performs one request with SDK retries disabled and returns (status, headers, body).
    start, delay = time.monotonic(), 1.0
    for attempt in range(1, max_attempts + 1):
        status, headers, body = send()
        if status < 400:
            return body
        err = (body or {}).get("error", {})
        if (err.get("type"), err.get("code")) not in RETRYABLE:
            raise RuntimeError(f"not retryable: {status} {err.get('code')}")  # spend limit, quota, 4xx
        try:
            wait = float(headers.get("retry-after", "")) + random.uniform(0, 0.5)
        except ValueError:
            wait = delay + random.uniform(0, delay)
            delay = min(delay * 2, 30)
        if time.monotonic() - start + wait > deadline_s or attempt == max_attempts:
            raise RuntimeError("gave up after rate limiting")
        time.sleep(wait)

The sketch keys on the documented error type and code rather than the status alone, so a 429 from a hard spend limit falls through to "not retryable" instead of looping. A broader treatment across providers is in provider rate limits compared.

Spreading load: what it does and does not do

OpenAI defines rate limits "at the organization level and at the project level, not user level"². So:

• More keys in one project add nothing. Every key draws on the same limit; round-robin across them gives you more ways to reach one ceiling.
• Separate projects isolate. A project-scoped token limit keeps one workload from consuming the organization's headroom, and project spend limits and reporting follow the same boundary. Use projects to protect your critical path from a batch job, not to multiply a quota.
• Capacity has other sources. A higher tier; the Batch API for work that can wait, with its own queue limit; batching several prompts into one request when RPM, not TPM, is the constraint; and, per the guide, Scale Tier for enterprise traffic that routinely hits ramp-rate limits, or Reserved Tier for GPT-5.6 and later models².
• Another provider account is real capacity. The same or an equivalent model on another platform you hold an account with has its own limits. That is a routing and evaluation decision, covered in load balancing LLM API keys.

What changed for teams

For most teams the change is administrative: fewer steps between a new account and production-sized limits, and three names to learn. Three practical consequences:

• Re-read your limits page. Your organization was mapped to one of the new tiers; check its current RPM and TPM for each model you call rather than relying on numbers in a runbook.
• Check the monthly ceiling against your forecast. Launch stops at $5,000 a month. A product growing into that needs Grow before the month it crosses it.
• Do not confuse usage tiers with service tiers. Service tiers are chosen per request and change how a request is processed and billed. Since 21 October 2026, platform settings let you choose which service tiers each project may use, and organization settings can restrict them for all projects¹.

Spreading traffic across your own keys with INFRO

INFRO is a control plane between your applications and the provider accounts you connect; your providers bill you directly and keep their own rate limits, which INFRO does not raise.

Across your keys and providers. When a request names a model directly, INFRO tries your connections that serve it: providers in the order you connected them, and within one provider, requests spread across its active keys. Keys that just answered 429, keys marked standby and keys that just said they cannot serve the model are tried last. If an attempt fails before the first token, the request moves to the next connection, so your client sees a provider 429 only when every connection tried failed. A route sets that order, weights and failure rules explicitly. See fallbacks. Within one OpenAI project, spreading across keys still shares one limit; failover pays off when the next connection is a different project, account or provider.

INFRO's own limit is per key. Each INFRO gateway key has its own requests-per-minute tier, up to 50,000 RPM, independent of your plan, and INFRO's responses carry X-RateLimit-Limit and X-RateLimit-Remaining with Retry-After on its own 429. One key per service keeps a spike in one from starving another. See limits.

Seeing it. Usage analytics break down requests and errors by model, key and connection, and traffic changes flag a rise in the share of requests served by a fallback, the usual sign that a primary is being rate limited.