The Hidden Rate Limits of Every Major AI API: September 2026 Update

Every major AI provider publishes a rate limit table. Almost none of them publish the limits that actually stop you.

The published numbers are a floor, not a ceiling. Between you and a successful response sit spend caps that pause your whole organization, ramp-rate throttles that fire even when you are under quota, cache rules that change how your tokens are counted, and per-region quotas that silently ignore the increase you requested. A developer on the second week of a project can hit any of these while the dashboard still shows healthy headroom.

This is the 2026 map, provider by provider, with the numbers that matter and the walls that do not appear in the tables.

Why tier tables mislead

Three structural facts apply almost everywhere now.

First, limits are tier-based. You start low and graduate on cumulative spend or payment history. The headline numbers in a provider blog post assume the highest tier. Most accounts, and almost all new accounts, sit two or three tiers below that.

Second, there is more than one dimension. Requests per minute (RPM), requests per day (RPD), tokens per minute (TPM), tokens per day (TPD), images per minute (IPM), concurrent sessions, batch queue depth, and per-organization aggregates all apply at once. You are stopped by whichever runs out first, and the dashboard rarely shows all of them side by side.

Third, soft limits are real. Under load, a request can be rejected as slow_down, queued behind paid priority, or degraded without a single entry in any published table. You cannot plan around these from docs. You find them in production, usually on launch day.

OpenAI

OpenAI’s usage tiers are spend-gated and the qualification bar is lower than most people assume. Tier 1 opens after $5 paid. Tier 2 at $50, Tier 3 at $100, Tier 4 at $250, Tier 5 at $1,000.

Each tier also carries a monthly usage limit, and this is the number people miss: Free and Tier 1 are capped at $100 per month, Tier 2 at $500, Tier 3 at $1,000, Tier 4 at $5,000, and Tier 5 at $200,000. That is separate from any spend limit you configure yourself.

The hidden parts:

• The ramp-rate throttle. OpenAI returns 429 with error code slow_down when your request rate rises too quickly, even if you are nowhere near your RPM or TPM ceiling. Their guidance is blunt: once you pass 1 million input TPM, increase traffic by no more than 50% every 15 minutes. A traffic spike from a viral post or a redeploy that resets your workers will trip this.
• slow_down and server_is_overloaded are different errors. Rapid traffic increases now return 429 / rate_limit_error / slow_down. Model overload returns 503 / service_unavailable_error / server_is_overloaded. If your error handler treats both as a retry, you will hammer an already overloaded model. Use Retry-After when present, otherwise back off exponentially with jitter.
• Shared model-family limits. Models grouped under a “shared limit” in your org’s limits page draw from one pool. Calling GPT-5.5 for a hard task and a cheaper sibling for a light one does not give you two budgets if they share a limit line.
• Long-context requests have a separate limit. Long context models meter long-context calls separately from standard ones, visible only in the console.
• Org and project scopes stack. The limit is defined at both levels. Splitting traffic across keys inside one project buys you nothing.
• Reasoning tokens count against TPM. A call that returns 300 visible tokens can burn several thousand against your minute budget once hidden reasoning is included.

Mitigation is procedural, not clever: handle 429 and 503 separately, respect Retry-After, add jitter, and ramp gradually after every deploy.

Anthropic

Anthropic restructured its tiers into Start, Build, and Scale, each with a monthly spend cap of $500, $1,000, and $200,000 respectively. Custom tier accounts have no published cap.

The single most useful Anthropic detail in 2026 is cache-aware ITPM.

Only uncached input tokens count toward your input tokens per minute limit. For most models, cache_read_input_tokens does not touch your rate limit at all. Only input_tokens (the tokens after your last cache breakpoint) and cache_creation_input_tokens count. Anthropic’s own example is stark: with a 2,000,000 ITPM limit and an 80% cache hit rate, you can process roughly 10,000,000 total input tokens per minute, because the cached 8 million are invisible to the limiter.

That makes prompt caching a throughput lever, not just a cost lever. If you cache system instructions, tool definitions, and large documents, your effective ceiling moves far above the published number.

On the Start tier, Sonnet 5, Opus 5, and Haiku 4.5 all sit at 1,000 RPM, 2,000,000 ITPM, 400,000 OTPM. Claude Fable 5.x is tighter at 500,000 ITPM and 100,000 OTPM. Building to Build tier multiplies most of those by five. Note that Claude Haiku 3.5 is the exception that counts cached reads against ITPM.

The hidden parts:

• Spend cap pauses everything. Hit the tier cap and requests return 429 with error_code: enforced_spend_limit_reached until 00:00 UTC on the first of the next month. There is no retry-after header, so SDK auto-retry loops spin uselessly. Match on the error code and stop retrying.
• Your own spend limit returns a different error. A limit you set returns 400 with invalid_request_error, not 429. Different status, different recovery path.
• Claude Code workspace limits are checked separately. Requests over that workspace limit can return a 429 that carries a retry-after header. This is the one Anthropic rate limit where retrying is the right move.
• OTPM is real-time and ignores max_tokens. Setting a generous max_tokens costs you nothing against OTPM because only generated tokens count.
• Acceleration limits exist on top of tier limits. A sharp usage increase can trigger 429s before you are anywhere near your tier numbers.
• The Rate Limits API is the ground truth. Read your configured limits programmatically rather than trusting the docs, which describe standard tiers, not your account.

Google (Gemini API and Vertex AI)

Google maintains two surfaces with different limit systems: the AI Studio Gemini API, which is project-scoped and resets RPD at midnight Pacific, and Vertex AI, which is quota-based and region-scoped.

Gemini API tiers are: Free (active project or trial), Tier 1 (linked billing, $250 cap), Tier 2 ($100 paid plus 3 days, $2,000 cap), Tier 3 ($1,000 paid plus 30 days, $20,000 to $100,000+ cap).

The distinctive Google mechanism is the spend-based rate limit, evaluated on a rolling 10-minute window: Tier 1 is $10, Tier 2 is $50, Tier 3 is $200. Exceed it and you get 429 RESOURCE_EXHAUSTED even when your RPM and TPM are fine. This is a cost throttle disguised as a rate limit, and it is the one that surprises people who move from cheap text calls to image or long-context work.

The hidden parts:

• Rate limits are per project, not per key. Rotating keys inside one project changes nothing.
• Priority inference draws from a smaller pool. Priority consumption has its own limits at roughly 0.3x the standard rate for each model and tier, while still counting toward your overall interactive traffic.
• Batch has an entirely separate budget. Up to 100 concurrent batch requests, 2GB per input file, 20GB total file storage, and a per-model enqueued token ceiling that grows dramatically with tier. On Tier 1 a single model might cap at 3 million enqueued tokens; on Tier 2 that same model can reach 400 million.
• Vertex quotas are per region and default low. Asking for an increase in us-central1 leaves europe-west4 at the default. Multiply every quota request by your region count.
• Live API session limits are far tighter than text limits and are easy to miss when scaling a voice product.
• Preview models are throttled harder than stable ones by design.

xAI (Grok)

xAI now runs a clean five-tier model based on cumulative spend since January 1, 2026: Tier 0 at $0, Tier 1 at $50, Tier 2 at $250, Tier 3 at $1,000, Tier 4 at $5,000, plus Enterprise on request. Once you qualify for a tier, you keep it permanently. Tiers never downgrade.

Limits are expressed as RPS and TPM, with RPS derived from your per-minute request budget (RPM divided by 60). You cannot spend a full minute’s requests in a single second, which is a hard stop for burst-oriented architectures.

For grok-4.6, the text limits run 150 RPS and 50M TPM at Tier 0 up to 500 RPS and 100M TPM at Tier 4. grok-4.5 shares those numbers. The multi-agent model is far tighter at 9 RPS and 2.5M TPM on Tier 0.

The hidden parts:

• Cached prompt tokens still count toward TPM. Unlike Anthropic, xAI meters cached reads against your limit, even though they are billed at a reduced rate. A caching strategy that buys throughput on Claude does not buy the same headroom here.
• Reasoning tokens count against TPM on reasoning models, same trap as OpenAI.
• Image and video generation are capped by RPS alone, with no TPM dimension. Video sits at 10 RPS on Tier 0.
• Voice has a concurrent session ceiling, not a token limit, so scaling voice means tracking CST as a first-class metric.

DeepSeek

DeepSeek remains the cheapest of the major providers and still officially advertises no published rate limits, with throttling based on load. That is not a promise. It is a description of an unpredictable system.

The hidden parts:

• Dynamic throttling tracks Asian business hours. During peak windows, 429s appear and latency climbs. The same workload that stalls at 04:00 UTC sails through at 22:00 UTC.
• There is no paid priority lane. You cannot buy your way out of a busy hour.
• Very long contexts are the first thing to queue. Above roughly 100K tokens, requests get deferred or refused ahead of shorter ones under load.

DeepSeek is excellent for non-time-sensitive batch work. As the sole provider behind an interactive product with a two-second budget, it is a gamble.

OpenRouter

OpenRouter enforces two distinct limit types, and conflating them causes most confusion.

Credit limits govern how much you can spend: account balance, per-key credit caps, and an in-flight spending budget. Exceeding these returns 402. Rate limits govern how many requests you can make, returning 429.

A critical line in their docs: making additional accounts or API keys does not increase your rate limits, because capacity is governed globally. You can, however, split load across different models, since limits are set per model.

The hidden parts:

• Shared pool dilution. Routing to Claude or GPT through OpenRouter puts you on OpenRouter’s organization-level capacity alongside every other user. At peak, that can be slower than calling Anthropic or OpenAI direct on your own paid tier.
• In-flight spending budget. Even with credit in the account, a burst of concurrent expensive requests can exceed the in-flight budget and return 402 mid-stream.
• Mid-stream rate limits exist. A stream can start successfully and then be cut by a limit error delivered as a stream event. Do not blindly replay a request whose output you already consumed.
• Free model limits change constantly and sit far below what the docs imply.

OpenRouter is the right tool for fallback diversity and model comparison. It is a poor choice as the sole dependency for a workload that needs predictable throughput.

The limits nobody publishes

Across every provider, the same categories of limit operate outside the tables.

Concurrency. In-flight request caps bite long-running agent sessions before RPM ever moves. Ten parallel Claude Code sessions on a heavy model can saturate concurrency on an account that looks idle on request counts.

Cache accounting. Whether cached reads count toward your token limit differs by provider: free on Anthropic, metered on xAI, priced differently again elsewhere. This single detail changes your effective throughput by an order of magnitude on context-heavy workloads.

Region and route. The same model behind a direct API, Bedrock, Vertex, or a router has a different ceiling each time. Routing decisions are capacity decisions.

Spend caps posing as rate limits. Anthropic’s monthly cap and Google’s 10-minute spend limit both return rate limit errors for what is fundamentally a billing event. Your retry logic will treat them as transient when they are not.

Acceleration limits. Providers throttle the rate of change in your traffic, not just the level. Any architecture that scales abruptly will meet this eventually.

What to actually do

Nothing here is exotic. The fixes are discipline.

1. Read your real limits from the API, not the docs. Anthropic ships a Rate Limits API. OpenAI and xAI expose limits in the console. Docs describe standard tiers, not your account.
2. Log the response headers. x-ratelimit-remaining-tokens and friends tell you which dimension is nearly exhausted, often hours before a 429.
3. Distinguish transient from terminal errors. slow_down is transient. enforced_spend_limit_reached is terminal until the month rolls over. Retrying the second one burns budget for nothing.
4. Cache aggressively and verify the accounting. A high cache hit rate beats a tier upgrade on providers that exclude cached reads, and does nothing on providers that include them.
5. Ramp after every deploy. Workers that cold-start into full traffic trip acceleration limits. Stagger them.
6. Instrument cost per request, not just tokens per request. Spend-based limits mean a single expensive call can block a hundred cheap ones.

The recurring issue is not that providers hide limits maliciously. It is that limits are dimensional, and most tooling watches only one dimension. Tracking requests per minute while your real constraint is a rolling spend window means discovering the wall from a 429 in production.

This is the gap tokenkarma was built for: watching the dimensions that actually stop you, across providers, so a limit shows up as a warning in your dashboard instead of an outage in your app.

The short version

• OpenAI: spend-gated tiers, monthly usage limits per tier, and a ramp-rate throttle that fires below your quota.
• Anthropic: cached reads do not count toward ITPM on most models, which makes caching a throughput lever. Spend cap pauses return a terminal 429 with no retry-after.
• Google: per-project limits plus a rolling 10-minute spend limit that returns RESOURCE_EXHAUSTED on a healthy RPM.
• xAI: fixed RPS and TPM per tier, cached and reasoning tokens both count, RPS derived from RPM means no bursts.
• DeepSeek: no published limits, load-based throttling, no priority lane, peak hours hit hardest.
• OpenRouter: credit limits return 402, rate limits return 429, capacity is global, and extra keys do not help.

Know your tier. Read your headers. Cache where it counts. Distinguish throttles from walls. That is most of the work.