The Hidden Rate Limits of Every Major AI API (2026 Update)

Every major AI provider publishes a rate limit table. None of them tell you the full story. The published numbers are the floor of what you can hit before things break, not the ceiling of what the system will actually let you do, and not the list of every silent throttle sitting between you and your next response.

If you have ever stared at a 429 error from a provider whose dashboard said you were nowhere near your quota, you already know the gap exists. This is a practical map of where the real walls are in mid-2026, provider by provider, and what to do when you hit them.

How rate limits actually work in 2026

Three things are worth stating up front because they apply almost everywhere.

First, almost every major provider now uses tier-based limits. You start at a low tier with tight RPM (requests per minute) and TPM (tokens per minute) caps, and you graduate to higher tiers based on cumulative spend, payment history, or sometimes a manual review. The published “max” limits assume you are at the top tier. Most accounts are not.

Second, rate limits are not just RPM and TPM. Concurrency limits, daily token caps, input vs output token budgets, batch queue limits, and per-organization aggregates all ride on top of per-key limits. Several providers also track prompt caching reads separately from generation tokens.

Third, soft limits exist. When the system is under load, your request can be rejected, slowed down, or quietly degraded (smaller context window, lower priority queue) without that showing up in any published table. This is the part you cannot plan around by reading docs. You only see it in production.

With that out of the way, let us go through the providers.

OpenAI

OpenAI runs five usage tiers (Tier 1 through Tier 5) plus a Free tier. You move up by spending money and waiting. Tier 1 unlocks after a $5 payment and 7 days; Tier 5 requires $1,000 paid and 30 days. Each tier sets different RPM, TPM, and batch queue limits per model.

The published numbers you should know for mid-2026:

• Tier 1 on GPT-5 family models: 500 RPM, 30,000 TPM.
• Tier 5 on the same models: 10,000 RPM, 30,000,000 TPM.
• Reasoning models (o-series) have separate, lower limits than non-reasoning models at the same tier.
• Image generation models have their own much tighter limits, often 5 to 50 images per minute even at high tiers.
• Embeddings have a separate TPM budget, usually 1,000,000 at Tier 1 and 10,000,000 at Tier 5.

The hidden parts:

• Daily token caps exist on lower tiers, but they are not always shown in the dashboard. A Tier 1 account on a reasoning model can hit a per-day cap that the per-minute display will never warn about.
• Reasoning models bill output differently. Hidden reasoning tokens count against your TPM. A request that returns 200 visible tokens can consume 8,000 against your minute budget.
• Org-wide aggregation. If you split traffic across multiple API keys in the same organization, you do not get more capacity. The cap is org-level, not key-level.
• Realtime API limits. The Realtime API (voice, WebSocket) has its own session-minute and concurrency quotas that are far tighter than the HTTP API limits. Easy to miss if you scaled out a voice product on Tier 1 limits.
• Batch queue ceilings. The Batch API offers 50 percent discount but has its own queue limits, typically 90,000,000 enqueued tokens at Tier 5. Hit that and new batches sit until older ones drain.

The recovery path is straightforward: pay more, wait longer. There is no support ticket that meaningfully accelerates this for solo developers.

Anthropic

Anthropic uses four named tiers: Start, Build, Scale, and Custom. Movement up requires both cumulative spend and elapsed time. Monthly spend caps are enforced: Start caps at $500, Build at $1,000, Scale at $200,000. Custom tiers have no cap.

Anthropic is unusual in that it tracks input TPM (ITPM) and output TPM (OTPM) separately, not as a single token bucket. This matters more than most users realize.

Published numbers at the Build tier (the most common paid tier for individuals and small teams):

Model	RPM	ITPM	OTPM
Claude Fable 5	2,000	1,500,000	300,000
Claude Opus 5	5,000	5,000,000	1,000,000
Claude Opus 4.x	5,000	5,000,000	1,000,000
Claude Sonnet 5	5,000	5,000,000	1,000,000
Claude Sonnet 4.x	5,000	5,000,000	1,000,000
Claude Haiku 4.5	5,000	5,000,000	1,000,000

At the Scale tier, limits approximately double: RPM goes to 10,000 on most models, and both ITPM and OTPM roughly double. Start tier gives 1,000 RPM with lower ITPM and OTPM across all model classes.

The hidden parts:

• Input and output TPM are tracked separately. This is the biggest trap. Most providers count everything in one bucket. With Anthropic, a long-context summarization workload (heavy input, light output) will hit the input ceiling while output TPM sits at 5 percent used.
• Prompt caching effectively raises your ITPM. Cached reads do not count toward ITPM for most models. Only cache writes count. With an 80 percent cache hit rate, a 2,000,000 ITPM limit can effectively process 10,000,000 total input tokens per minute. Claude Haiku 3.5 is the exception — it counts cache reads toward ITPM.
• Concurrent request limits exist even when you are under RPM. Long-running Claude Code sessions on Opus can saturate this without ever approaching RPM.
• The Messages API and Bedrock paths have different limits. Same model, same prompt, different ceiling depending on whether you call Anthropic direct or go through AWS Bedrock or Google Vertex. Vertex tends to be the loosest for high-volume workloads.
• Fast mode (research preview) on Opus 5 and Opus 4.8 has separate, dedicated rate limits. Fast mode is not available on Opus 4.7 or 4.6.

If you hit Anthropic limits often, the practical move is to add a Bedrock or Vertex fallback for spillover rather than wait for a tier upgrade.

Google (Gemini API and Vertex AI)

Google publishes two distinct surfaces: the AI Studio Gemini API (developer-friendly, free tier, smaller limits) and Vertex AI (cloud-grade, project-level quotas, higher ceilings).

Published numbers on AI Studio for Gemini 2.5 and 3.x Pro lines in mid-2026:

• Free tier: 5 RPM, 250,000 TPM, 100 requests per day.
• Tier 1 (linked billing): 1,000 RPM, 2,000,000 TPM, 10,000 RPD.
• Higher tiers can push to 10,000+ RPM with quota increase requests.

On Vertex AI, quotas are project-level and adjustable through the Google Cloud console. Default new-project quotas are surprisingly low (often 60 QPM per model per region) and need a quota request to scale.

The hidden parts:

• Per-day caps are real and brutal on the free tier. “5 RPM” sounds usable; “100 RPD” means a single test loop can burn your daily budget in two minutes.
• Region matters. Vertex quotas are per region. If you only ask for higher quota in us-central1, your europe-west4 deployment is still at default.
• The Live API (streaming voice/video) has separate session-minute quotas that are much tighter than the text API. Easy to miss if you scaled a multimodal product on Tier 1 limits.
• Context caching on Gemini has minimum lifetime billing. This is not technically a rate limit, but it is a hidden floor on cost that shows up the moment you cache a 1M-token context for “just one query.”
• Quota increase requests are not instant. They can take 24 to 72 hours to process, which matters if you are launching with unexpected traction.

xAI (Grok)

xAI has matured its API documentation significantly through 2026. It now publishes clear tiered rate limits (T0 through T4) tied to usage history. Grok models are available across multiple regions (us-east-1, eu-west-1, us-west-2).

Published numbers for key models at base tier (T0):

Model	RPM	TPM
Grok 4.5	7,200	50,000,000
Grok 4.3	1,800	10,000,000
Grok Build 0.1	1,800	10,000,000
Grok 4.20 (reasoning)	1,800	10,000,000
Grok 4.20 multi-agent	450	2,500,000

Higher tiers (T1 through T4) scale these progressively. At T4, Grok 4.3 reaches 208 RPS and 85M TPM. Grok 4.5 at T4 reaches 500 RPS and 100M TPM.

The hidden parts:

• Launch-day throttling is still a pattern. When a new Grok model ships, paid customers routinely see effective limits well below the published ones for the first 48 to 72 hours. There is no dashboard signal for this.
• Live Search adds its own per-request quota. Search-enabled completions are billed and rate-limited differently from base completions.
• Batch discounts. xAI offers 20 percent batch discounts on most models except Grok 4.5 (no batch discount currently).
• Image and video generation have separate, much lower limits. Grok Imagine models cap at 5 RPS and 300 RPM for image generation. Video generation caps at 10 RPS.
• Tier progression is not automatic in all regions. Some regions require manual requests via the API console to move up tiers.

DeepSeek

DeepSeek’s pricing remains the cheapest of the major providers, but the rate limit profile is unusual and has not changed much from earlier in the year.

Published position: DeepSeek officially advertises “no published rate limits, throttled based on load.” This sounds generous. It is actually a warning.

The hidden parts:

• Dynamic throttling. During Asia business hours (roughly 02:00 to 14:00 UTC), the API is noticeably slower and 429s appear more frequently. Off-peak the same workload sails through.
• No tier escalation path. There is no way to “pay for higher priority.” You get what the system gives you that hour.
• Context length surprises. The advertised context window is honored, but very long contexts (above 100K tokens) get queued or refused first under load.
• Caching behavior is opaque. DeepSeek does not publish cache hit rates or cache-specific rate limits, making capacity planning harder than with Anthropic or OpenAI.

For batch workloads that are not time-sensitive, DeepSeek is excellent. For interactive product traffic that must respond within 2 seconds, it is risky as a sole provider.

OpenRouter

OpenRouter is a router, not a model host, so its rate limits are a composite of its own infrastructure limits plus whichever underlying provider it routes you to.

Published numbers:

• Free tier (BYOK or routed free models): 20 RPM, 50 RPD if you have less than $10 in credits, 1,000 RPD if you do.
• Paid: limited primarily by the upstream provider’s limits applied to OpenRouter’s shared pool.

The hidden parts:

• Shared pool dilution. When you hit Claude or GPT through OpenRouter, you are sharing OpenRouter’s organization-level capacity with thousands of other users. During peak hours this can be lower effective throughput than calling Anthropic or OpenAI direct on a mid-tier account.
• Provider routing changes silently. OpenRouter may switch you from Anthropic direct to Bedrock mid-session based on availability. Both work, but observability gets harder because your latency profile shifts.
• Free models throttle aggressively. The “free” tier on hosted open models is rate-limited far below what the docs imply, and the limits change weekly.

OpenRouter is the right choice for fallback diversity and experimentation. It is a poor choice as the single dependency for a production workload that needs predictable throughput.

Mistral, Cohere, Together, Fireworks (quick takes)

• Mistral: tiered like Anthropic, with separate input and output TPM. La Plateforme limits are roughly half of what AWS Bedrock allows for the same models. Mistral Large 2 at the highest tier reaches about 5,000 RPM and 2,000,000 ITPM.
• Cohere: trial vs production keys. Trial keys have hard daily caps (1,000 calls/month historically). Production keys negotiate limits per account. The Command R+ rate profile is roughly 1,000 RPM at standard tier.
• Together AI: per-model RPM/TPM with relatively generous defaults for fine-tuned models. Together’s edge is that many open models run on dedicated inference engines with predictable throughput. Typical limits for Llama 3 class models are 500-1,000 RPM at standard tier.
• Fireworks: explicit “serverless” vs “dedicated” tiers. Serverless is rate-limited per project at around 500 RPM for most models. Dedicated removes the limit but you pay for idle capacity.

What to do about it

Rate limits will not disappear. The realistic options are:

1. Spread load across providers. A multi-provider setup with a router (homebuilt or OpenRouter for non-critical paths) absorbs spikes that any single provider would 429 on.
2. Cache aggressively. Both prompt caching (Anthropic, OpenAI, Gemini) and response caching for repeated queries pull massive load off your rate limit budget.
3. Batch what can be batched. Most providers offer batch APIs at 20 to 50 percent discount with looser limits. Anything non-interactive (summaries, classification jobs, embeddings backfills) belongs there.
4. Observe upstream signals. The x-ratelimit-remaining-* headers (or equivalents) are present on almost every provider. Surface them. Most teams discover their real ceiling only after their first outage because nothing was plotting these headers.
5. Know your tier honestly. Tier 1 or Start tier is not a production tier on any major provider. If you are running a real workload at entry tier, you are one viral moment away from a 429 cascade.

This is also where having a single view of your usage across providers becomes useful rather than nice-to-have. The kind of dashboard tokenkarma builds exists exactly because rate limit data lives in six different consoles, in six different formats, and no provider has any incentive to tell you “you are about to hit a wall on the other guy’s API.” The numbers you actually need to make a decision are scattered, and the only way to act on them in time is to put them in one place.

The short version

The published rate limit table is the start of the conversation, not the end. The real ceiling is shaped by your tier, your region, your context length, your input-to-output ratio, whether the provider is having a load spike, and which gateway you go through. Treat every published number as optimistic, plot the response headers, and never run a serious workload against a single provider’s lowest tier.

The providers will not warn you before you hit the wall. The wall is there anyway.