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

URL: https://infro.io/blog/openai-usage-tiers-rate-limits-2026
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-27
Last modified: 2026-10-27
Last reviewed: 2026-10-27 (next review due 2026-11-26)
Topic: Routing and reliability
Format: Guide

> Since 6 October 2026 OpenAI has three paid usage tiers: Build after $5 of total purchases, Launch after $100 and Grow after $500, with monthly usage limits of $500, $5,000 and $200,000; a Free tier has a $100 monthly limit. Rate limits are set per organization and project, per model, in requests and tokens per minute; on GPT-6 Luna they run from 5,000 RPM and 2M TPM on Build to 30,000 RPM and 180M TPM on Grow. Read the x-ratelimit headers, honour Retry-After with jitter, never retry a spend-limit or quota 429, and remember that extra keys in one project share one limit.

Key takeaways:
- OpenAI's paid tiers are Build ($5 of total purchases), Launch ($100) and Grow ($500), with monthly usage limits of $500, $5,000 and $200,000; tiers advance automatically.
- Limits are per model group: on Grow, Astra, Sol and Terra get 15,000 RPM and 40M TPM, Luna 30,000 RPM and 180M TPM.
- A hard spend limit also answers 429, so a retry loop that treats every 429 alike can spin on a request that will never succeed.
- Above 1 million input TPM, OpenAI asks you to raise traffic by no more than 50% every 15 minutes; a sudden jump earns 429 slow_down.
- Keys in one project share one limit. Projects isolate workloads; capacity comes from a higher tier, the Batch API, reserved capacity or another provider account.

OpenAI's API has three paid usage tiers since 6 October 2026, down from five: **Build**, **Launch** and **Grow**[1]. 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[2].

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

| Tier | Qualification | Monthly usage limit |
| --- | --- | --- |
| Free | User in an allowed geography | $100 |
| Build | $5 in total purchases | $500 |
| Launch | $100 in total purchases | $5,000 |
| Grow | $500 in total purchases | $200,000 |

Table: OpenAI usage tiers, from the rate limits guide read 2026-10-27.

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`[2]. 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[2]. 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[2].

| Tier | Astra, Sol, Terra | Luna |
| --- | --- | --- |
| Build | 5,000 RPM, 1M TPM | 5,000 RPM, 2M TPM |
| Launch | 10,000 RPM, 4M TPM | 10,000 RPM, 10M TPM |
| Grow | 15,000 RPM, 40M TPM | 30,000 RPM, 180M TPM |

Table: Standard rate limits for the GPT-6 model groups, from the rate limits guide read 2026-10-27.

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[3]. 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[4]. 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[2]:

- **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[2]:

| Header | Meaning |
| --- | --- |
| `x-ratelimit-limit-requests` / `x-ratelimit-limit-tokens` | The limit for the current window |
| `x-ratelimit-remaining-requests` / `x-ratelimit-remaining-tokens` | What is left |
| `x-ratelimit-reset-requests` / `x-ratelimit-reset-tokens` | Time until the limit resets |
| `x-ratelimit-limit-project-tokens`, `-remaining-project-tokens`, `-reset-project-tokens` | The same for a project-scoped token limit, sent only when one applies |
| `Retry-After` | Minimum seconds to wait, on temporary `429` and `503` responses |

Table: OpenAI rate-limit headers, from the rate limits guide read 2026-10-27.

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[2]:

| Status | Type and code | Meaning | What to do |
| --- | --- | --- | --- |
| `429` | `rate_limit_error`, `slow_down` | Request rate rose too quickly | Follow `Retry-After` if present, reduce the rate, then increase gradually |
| `503` | `service_unavailable_error`, `server_is_overloaded` | Model temporarily overloaded | Follow `Retry-After`, retry, lengthen the delay if errors continue |

Table: Temporary errors, from OpenAI's rate limits guide read 2026-10-27.

And the rules that keep retries from making things worse[2]:

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.

```python
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](https://infro.io/blog/llm-rate-limits-429-handling).

## 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"[2]. 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[2].
- **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](https://infro.io/blog/load-balance-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[1].

## 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](https://infro.io/docs/routes) sets that order, weights and failure rules explicitly. See [fallbacks](https://infro.io/docs/features/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](https://infro.io/docs/api/limits).

**Seeing it.** [Usage analytics](https://infro.io/docs/observability/analytics) break down requests and errors by model, key and connection, and [traffic changes](https://infro.io/docs/observability/traffic-changes) flag a rise in the share of requests served by a fallback, the usual sign that a primary is being rate limited.

## Questions

### What are OpenAI's API usage tiers now?

Since 6 October 2026 there are three paid tiers, Build, Launch and Grow, plus a Free tier for users in an allowed geography. Build needs $5 of total purchases, Launch $100 and Grow $500; the monthly usage limits are $500, $5,000 and $200,000, and $100 on Free.

### How do I move up an OpenAI usage tier?

Tiers advance automatically when the organization's total purchases reach the threshold. OpenAI's guide also points to an Upgrade tier option in the Usage Tiers section, and shows current limits under Settings, Organization, Limits.

### Do more API keys give me higher OpenAI rate limits?

No. OpenAI defines rate limits at the organization and project level, not per key or user, so keys in the same project draw on the same limit. More capacity comes from a higher tier, the Batch API for work that can wait, Scale Tier or Reserved Tier, or the same model on another provider account.

### Should I retry every 429 from OpenAI?

No. Retry a 429 rate_limit_error such as slow_down after Retry-After plus jitter. A 429 caused by a hard spend limit, or a quota or billing error, needs a person to act and will not clear on retry. Failed requests also count toward per-minute limits.

### What is the difference between a usage tier and a service tier?

A usage tier (Build, Launch, Grow) sets your organization's rate and monthly limits. A service tier is chosen per request and changes how a request is processed and billed; since 21 October 2026 OpenAI's settings let you choose which service tiers each project may use.

## Sources

1. Changelog — OpenAI. https://developers.openai.com/api/docs/changelog (accessed 2026-10-27)
2. Rate limits — OpenAI. https://developers.openai.com/api/docs/guides/rate-limits (accessed 2026-10-27)
3. GPT-6 Luna model page — OpenAI. https://developers.openai.com/api/docs/models/gpt-6-luna (accessed 2026-10-27)
4. GPT-4o model page — OpenAI. https://developers.openai.com/api/docs/models/gpt-4o (accessed 2026-10-27)