← Blog

AI API Rate Limits: OpenAI, Claude & Gemini Explained

How RPM, TPM, daily quotas and usage tiers work—and how production applications should handle HTTP 429 responses without creating retry storms.

What are AI API rate limits?

AI API rate limits cap how many requests or tokens your application can process within a time window. A provider may enforce requests per minute (RPM), tokens per minute (TPM), separate input and output token limits, requests per day (RPD), batch queue limits or spend controls.

There is no single “OpenAI limit” or “Gemini limit.” Your effective quota depends on the provider, model, account or project, usage tier and sometimes the endpoint. Check your own dashboard before designing capacity around a number from a comparison article.

The limit types that matter

AI providers need both request and token limits because ten tiny classification calls place a different load on infrastructure than one request containing a million-token context. You can remain below RPM while exhausting TPM, or stay below token limits while a traffic burst exhausts RPM.

OpenAI vs Claude vs Gemini rate limits

Last verified: September 2026. Exact model quotas change and can differ by account. The table compares allocation mechanics, not supposedly universal maximums.

OpenAI rate limits

OpenAI measures usage with limiters including RPM, RPD, TPM and TPD, plus specialized limits for some image, audio, vector-store and long-context workloads. Limits are defined at organization and project level and vary by model. Models grouped under a shared limit draw from the same pool.

OpenAI automatically moves accounts through usage tiers as API spend increases, which usually raises limits for most models. The authoritative values for your account are on the organization Limits page and in the API's rate-limit response headers—not a static third-party table.

Anthropic Claude rate limits

Anthropic separates Messages API capacity into RPM, input tokens per minute (ITPM) and output tokens per minute (OTPM) for each model class. Limits are enforced at organization level, while administrators can set lower workspace controls.

For most Claude models, cache reads do not count toward ITPM; new uncached input and cache writes do. Anthropic uses a token-bucket model, so a short burst can trigger a 429 even when the minute-level average appears safe. Sharp increases can also hit acceleration limits, making gradual traffic ramp-up important.

Use the Claude Console limits, Usage charts or Rate Limits API for the values assigned to your organization.

Google Gemini rate limits

Gemini commonly evaluates RPM, input TPM and RPD, with additional dimensions for certain models and workloads. Limits apply per project rather than per API key. Exceeding any active dimension can produce a rate-limit error even when the other metrics have headroom.

Gemini ties quotas to model and usage tier. Billing enables Tier 1; later tiers depend on account qualifications and cumulative Google Cloud spending. Google says published limits are not guaranteed and directs developers to AI Studio for active quotas. Batch uses separate limits, including concurrent jobs and enqueued tokens per model.

Why an AI API returns HTTP 429

429 Too Many Requests does not always mean “too many requests.” It can indicate:

• RPM or a shorter burst window was exhausted;
• input, output or total token throughput was exhausted;
• a daily request/token quota or batch queue is full;
• an account, project or model-specific capacity pool was exhausted;
• a spend-rate, acceleration or billing-related control was reached.

Start with the structured error details and provider headers. A quota or billing failure that requires account action should not be retried like a temporary one-minute throttle.

Production-safe 429 handling

1. Identify the exhausted limiter. Log the provider, model, project, endpoint, request ID, status, error type and relevant response headers.
2. Respect Retry-After when supplied. Treat it as the minimum wait. Do not assume every provider or every 429 includes that header.
3. Use capped exponential backoff with jitter. Random delay prevents all workers from retrying simultaneously.
4. Limit attempts and total retry time. Infinite retries increase load, latency and cost. Remember that unsuccessful requests can still consume limit capacity.
5. Queue and shape traffic. Apply concurrency controls and per-provider/model queues before requests leave your application.
6. Reduce tokens when TPM is the bottleneck. Trim history, retrieve less context, cap output appropriately and use prompt caching where it changes quota accounting.
7. Move delay-tolerant work to batch or asynchronous endpoints. Evaluations and enrichment rarely need interactive capacity.
8. Alert on sustained saturation. A retry that succeeds still signals declining headroom.

Minimal provider-neutral retry pattern

async function withRateLimitRetry(send, maxAttempts = 5) {
  for (let attempt = 0; attempt < maxAttempts; attempt++) {
    const response = await send();
    if (response.status !== 429) return response;

    const retryAfter = Number(response.headers.get("retry-after"));
    const fallbackMs = Math.min(30_000, 500 * 2 ** attempt);
    const waitMs = Number.isFinite(retryAfter)
      ? retryAfter * 1000
      : fallbackMs + Math.random() * 500;

    await new Promise(resolve => setTimeout(resolve, waitMs));
  }
  throw new Error("Rate limit retry budget exhausted");
}

This deliberately avoids provider-specific error shapes. In production, retry only errors your provider identifies as transient, account for retries already performed by the SDK, and use an idempotency strategy for operations with side effects.

Queueing, concurrency and batch workloads

Backoff is a recovery mechanism, not a capacity plan. Use a queue or limiter to keep outbound traffic below the lowest relevant constraint. Separate interactive calls from background work so a bulk job cannot consume the quota needed by users.

• Interactive: reserve capacity, cap concurrency and degrade gracefully.
• Background: queue, batch and pace work against token—not just request—budgets.
• Multi-model: track quota pools before routing; providers may share limits across a model family.
• Streaming: include connection duration, output tokens and client disconnects in capacity planning.

How to unlock higher limits

OpenAI, Anthropic and Google all connect capacity to account standing, usage history or paid tiers, but none guarantees a requested increase. Before applying, collect peak RPM, input/output TPM, cache hit rate, concurrency, expected growth and the specific models you need.

Do not rotate multiple keys to bypass a project- or organization-level limit. Besides being ineffective for shared pools, intentional circumvention can conflict with provider policies. Scale through documented tier and quota-increase paths.

Metrics to monitor

Frequently asked questions

What are AI API rate limits?

They cap requests or tokens over time. Common dimensions include RPM, TPM or separate input/output TPM, RPD and batch queue size. Exact limits vary by provider, model and account tier.

Why does an AI API return HTTP 429?

A request, token, daily quota, batch queue, spend or burst limit may have been exceeded. Inspect the provider's error details, headers and dashboard before deciding whether to retry.

How should an application retry after a 429?

Follow Retry-After when available. Otherwise use capped exponential backoff with jitter and a strict retry budget. Do not blindly retry quota or billing errors that require intervention.

Are OpenAI, Claude and Gemini limits the same?

No. OpenAI uses model-dependent organization/project limits, Anthropic separately meters requests and input/output token throughput, and Gemini uses project-level model and usage-tier quotas.

Primary sources

• OpenAI API rate limits
• Anthropic Claude rate limits
• Google Gemini API rate limits