API Rate Limits

• Rate Limit Tiers & Quotas

  OpenRouter structures rate limits across Free, Standard, and Enterprise account tiers with per-minute request quotas and per-minute token budgets that scale with your usage level and payment plan.

  Compare rate limit tiers →

• 429 Response Handling

  When your application exceeds its rate limit, the platform returns HTTP 429 with a Retry-After header. Proper handling of this response prevents cascading failures and unnecessary retry storms.

  Read 429 handling guide →

• Exponential Backoff Strategy

  Implementing exponential backoff with jitter distributes retry attempts across time and prevents the thundering herd problem that can occur when multiple clients retry simultaneously.

  Learn backoff strategies →

• Monitoring & Alerting

  Track rate limit proximity through response headers and usage API endpoints. Set up alerts before your application approaches its limit to avoid surprise 429 responses during peak traffic.

  Set up rate limit monitoring →

Rate Limit Tiers Explained

OpenRouter rate limits operate on two dimensions: requests per minute and tokens per minute. The request limit governs how many individual API calls your application can make in a sixty-second window. The token limit caps the total number of input and output tokens consumed across all requests within the same window, providing a cost-protection mechanism that prevents a misconfigured application from accumulating unexpected charges.

Free tier accounts receive 20 requests per minute and 40,000 tokens per minute — sufficient for prototyping, personal projects, and low-traffic integrations. The Standard tier increases these limits to 200 requests per minute and 400,000 tokens per minute, suitable for production applications with moderate user bases. Enterprise accounts negotiate custom limits based on projected workload, with many reaching thousands of requests per minute and token budgets in the millions. All tiers share the same underlying infrastructure, so the quality of model responses does not degrade at lower tiers — only the throughput ceiling changes.

Rate limits reset on a rolling sixty-second window rather than a fixed clock boundary. If your application sends 200 requests across a sixty-second period that starts at 10:03:27, the limit resets gradually — the request sent at 10:03:27 ages out at 10:04:27, making room for a new request. This rolling-window approach smooths traffic more effectively than fixed-window reset points, which can create burst patterns that stress infrastructure at the top of each minute.

Handling 429 Too Many Requests

A 429 response from the OpenRouter API signals that your application has exceeded its rate limit for the current window. The response includes a Retry-After header specifying the number of seconds to wait before sending another request. Your client code should respect this header exactly — sending requests before the specified duration elapses will result in additional 429 responses, wasting bandwidth and delaying recovery.

The 429 response body includes a JSON error object with a code field set to rate_limit_exceeded and a message field describing which limit was hit. If the request limit triggered the 429, the message identifies the requests-per-minute cap. If the token limit caused it, the message references the tokens-per-minute budget. Your application can parse this distinction to decide whether to reduce request frequency, switch to a model with shorter responses, or both.

Do not treat 429 responses as fatal errors. They are flow-control signals, not failures. A well-designed client handles them transparently — pausing, waiting, and resuming — while logging the event so operations teams can identify trends. If your application consistently hits rate limits, the correct response is not to retry more aggressively but to upgrade your account tier or optimize your request patterns to consume fewer resources per operation.

Distinguishing Rate Limits from Other 4xx Errors

Rate limit errors can be confused with authentication failures in poorly designed error handling. A 401 response means your API key is invalid or expired — retrying with the same key will never succeed. A 429 response means your key is valid but you have sent too many requests — retrying after a delay will succeed. Always check the HTTP status code before deciding on a retry strategy, and never retry 401 errors with the same credentials.

Implementing Exponential Backoff

Exponential backoff is the standard retry strategy for rate-limited APIs. When a request returns 429, your client waits for the duration specified in the Retry-After header, retries the request, and if another 429 arrives, doubles the wait time before the next attempt. Adding random jitter — a small, random variation in the wait time — prevents multiple client instances from synchronizing their retry attempts and creating a thundering herd that overwhelms the rate limiter again.

The OpenRouter SDKs implement backoff with jitter automatically. In the Python SDK, configure retry behavior through the client initialization options: max_retries=3, backoff_factor=0.5, and jitter=True. The JavaScript SDK accepts similar configuration via retryConfig. The Go SDK uses the standard retry package pattern with functional options. If you are writing a custom HTTP client rather than using an SDK, implement backoff manually using the algorithm: wait = min(retry_after * (2 ^ attempt) + random_jitter, max_wait_seconds).

For guidance on building resilient API integrations, the NIST Artificial Intelligence standards program includes resources on reliable system design patterns that apply broadly to AI service integrations. The Consumer Financial Protection Bureau's technical documentation provides additional context on designing consumer-facing services with appropriate rate management and error transparency.

Monitoring Rate Limit Usage

Every API response from OpenRouter includes rate limit headers that your application can use to track proximity to its limits without querying a separate endpoint. The X-RateLimit-Remaining header shows how many requests remain in the current sixty-second window. X-RateLimit-Reset provides a Unix timestamp indicating when the window resets. Monitoring these headers in your application's observability stack — whether Prometheus, Datadog, or CloudWatch — gives operations teams visibility into rate limit consumption trends before they cause 429 responses.

For programmatic access to historical usage data, the /api/v1/usage endpoint returns token consumption and request counts filtered by time range. Build a dashboard query that compares recent usage against your tier's limits as a percentage. Set an alert threshold at 80% of your limit so your team can investigate or request a tier upgrade before the application starts receiving 429 responses during production traffic.

Frequently Asked Questions About Rate Limits