AI API rate limits: every major provider compared

Quick answer: RPM, TPM, and RPD, and why the numbers differ so much

Every provider gates usage with roughly the same three letters, even though the actual ceilings look nothing alike. RPM, requests per minute, caps how often you can call an endpoint. TPM, tokens per minute, caps how much text moves through in that same window, counting both input and output, and it is usually the tighter constraint once prompts get long. RPD, requests per day, shows up mostly on free and entry tiers as a hard daily ceiling. Cross any of the three and the response is an HTTP 429, not a partial answer. The short version: OpenAI publishes the highest ceiling once an account has climbed its spend-based tier ladder, but getting there takes real weeks and real dollars. Anthropic starts the most conservative at every tier and climbs the slowest. Google's paid tier hands over meaningful throughput the moment billing is switched on, with no waiting period. DeepSeek does not publish a spend-based ladder at all; reported behavior looks more like shared-capacity throttling that scales with peak demand than a fixed per-account ceiling. None of that is a reason to avoid a provider. It is a reason to have retry logic in place before you need it, not after.

How each provider actually decides your ceiling

Rate limit systems fall into three shapes, and knowing which shape you are dealing with changes how you plan capacity. OpenAI and Anthropic both run spend-based tiers. An account starts at the bottom the moment a card is added, then climbs automatically as cumulative spend and account age cross published thresholds, with no ticket required. The catch is time: the higher tiers are gated by both a dollar total and a minimum number of days since the first payment, so a single large top-up does not skip the calendar requirement. Google runs a simpler two-state model. There is a free tier with modest, model-dependent caps, and a paid tier that grants a large jump in both RPM and TPM the instant billing is enabled, with no separate ladder to climb after that. DeepSeek does not document a spend-based tier ladder, and it does not publish fixed RPM or TPM numbers the way the tiered providers do. What gets reported instead, by users and by third-party trackers, is throttling and slower responses during peak hours that behaves more like shared-capacity rationing than a documented per-account ceiling, so treat any specific number attached to DeepSeek as an observation rather than an official limit. The practical effect on your code is the same either way: build retry logic that assumes the ceiling can move. xAI's Grok API sits between the two patterns: a low free tier, a few paid tiers that scale RPM and TPM with usage, and a negotiated enterprise tier above that for sustained high-volume traffic.

What you actually get on day one, by provider

The table below rounds each provider's entry-level ceiling for its current flagship chat model, the numbers a new account gets before any tier climbing, as reported as of July 2026. Treat every figure as an approximate, tier-dependent snapshot rather than a documented constant. Providers adjust these without much notice, and the exact number depends on which model you are calling, so confirm current figures in your own account console before sizing a production workload against them.

Why 429 errors catch teams by surprise

Two of these are worth dwelling on. Organization-level scoping means a second API key is not a second quota, just two credentials drawing on the same pool, which is a common surprise for teams that assume keys are the unit of measurement. And TPM counting the full request rather than just the prompt is why chat interfaces and agentic tools that resend growing history are far more likely to hit a token ceiling than a one-shot classifier making the same number of calls. The table below is a rough guide to which cap tends to show up first for a given workload shape. It will not match every account exactly, since real limits depend on your specific tier and model, but it is a reasonable starting point for deciding which fix to reach for first.

• Limits are usually scoped to the organization or project, not the individual API key, so a second key just pulls from the same bucket.
• Reaching the top tier is gated by cumulative spend and elapsed days, not by asking nicely; spending heavily in week one does not unlock a day-thirty tier early.
• TPM counts the entire request, input and output together, and in agentic tools it also counts the resent conversation history, so a token ceiling can hit well before the request-count ceiling does.
• Concurrent-request caps are often separate from RPM, so a synchronous load test can pass cleanly while parallel calls from real traffic trip a wall the test never found.
• Retrying immediately after a 429 usually extends the penalty window rather than clearing it, since the retry itself counts against the same short-term ceiling.

Entry tier versus top tier: how far the climb actually goes

Rate limits are not static, and the gap between an account's first day and its ceiling varies a lot by provider. The table below compares the entry-tier RPM most accounts see immediately against the highest RPM each provider publishes, along with a rough sense of what it takes to get there. Figures for OpenAI, Anthropic, Google, and xAI are tier-dependent approximations as of July 2026, not documented constants. OpenAI's ceiling is the highest on paper, but reaching it requires sustained four-figure monthly spend across several weeks. Anthropic's ceiling is lower and the climb is slower at every step. Google barely has a climb at all: what an account gets the moment billing is enabled is close to what it will ever get without a custom enterprise deal. DeepSeek does not publish a tier ladder in the first place, so there is no climb to describe beyond the throttling behavior noted above.

Practical fixes: what to build before you hit your first 429

None of these is a complete fix on its own. Backoff handles the occasional spike gracefully but does nothing if baseline traffic already exceeds the ceiling. Pre-emptive throttling prevents 429s entirely but also caps your own throughput below what the provider would otherwise allow. The combination that holds up in production is usually backoff for the unexpected plus a token bucket sized under the published cap for the everyday case, with a fallback model or endpoint ready for the rare day traffic outgrows both. Build the retry logic first regardless of anything else on this list. It is the one piece every account needs no matter which provider or tier it sits in.

• Retry failed calls with exponential backoff and jitter. Treat 429 as expected traffic under load, not an outage.
• Pre-emptively throttle your own client with a token bucket sized a bit under the published ceiling instead of waiting to get rejected.
• Split sustained load across more than one project or key where the provider allows it, since most caps are scoped to the organization or project, not the individual key.
• Cache repeated prompts and dedupe identical calls before they ever count against TPM.
• Auto-downgrade to a lighter model when the primary model is throttled, then switch back once headroom returns.
• Point the client at an OpenAI-compatible endpoint so absorbing a spike on a different model is a base_url and model-id change, not a rewrite. APIsRouter is one pay-as-you-go option built this way: the same request shape as the OpenAI SDK, no forced multi-week tier climb before reasonable throughput, and swapping models is just changing the model string.

Config example: retry with backoff, checked against a live endpoint

The pattern below works against any OpenAI-compatible endpoint. Set the base URL once, wrap the call in a function that backs off on HTTP 429, and add jitter so a batch of retrying clients does not all retry on the same tick. The second block is a plain curl request for confirming a key and model work from a terminal before wiring retry logic into an application. Most OpenAI-compatible APIs also return rate-limit headers on each response, commonly named along the lines of x-ratelimit-remaining-requests and x-ratelimit-remaining-tokens. Logging those on every call is the cheapest way to see a ceiling coming before a request gets rejected.

import time
import random
from openai import OpenAI

client = OpenAI(
    api_key="sk-APIsRouter-...",
    base_url="https://api.apisrouter.com/v1",
)

def call_with_backoff(messages, model="deepseek-v4-flash", max_retries=5):
    for attempt in range(max_retries):
        try:
            return client.chat.completions.create(
                model=model,
                messages=messages,
                max_tokens=500,
            )
        except Exception as e:
            status = getattr(e, "status_code", None)
            if status != 429 or attempt == max_retries - 1:
                raise
            wait = (2 ** attempt) + random.uniform(0, 1)
            print(f"Rate limited, retrying in {wait:.1f}s (attempt {attempt + 1})")
            time.sleep(wait)

FAQ