Skip to main content
Making additional accounts or API keys will not affect your rate limits, as we govern capacity globally. We do however have different rate limits for different models, so you can share the load that way if you do run into issues.
OpenRouter enforces two kinds of limits:
Limit typeWhat it governsError on exceedingWhere to check
Credit limitsHow much you can spend (account balance and per-key credit caps)GET /api/v1/key → limit_remaining
Rate limitsHow many requests you can make (free-model request caps and DDoS protection)X-RateLimit-* headers on the error response

​
Checking Your Limits

To check the rate limit or credits left on an API key, make a GET request to https://openrouter.ai/api/v1/key. If you submit a valid API key, you should get a response of the form:
TypeScript
type Key = {
  data: {
    label: string;
    limit: number | null; // Credit limit for the key, or null if unlimited
    limit_reset: string | null; // Type of limit reset for the key, or null if never resets
    limit_remaining: number | null; // Remaining credits for the key, or null if unlimited
    include_byok_in_limit: boolean;  // Whether to include external BYOK usage in the credit limit

    usage: number; // Number of credits used (all time)
    usage_daily: number; // Number of credits used (current UTC day)
    usage_weekly: number; // ... (current UTC week, starting Monday)
    usage_monthly: number; // ... (current UTC month)

    byok_usage: number; // Same for external BYOK usage
    byok_usage_daily: number;
    byok_usage_weekly: number;
    byok_usage_monthly: number;

    is_free_tier: boolean; // Whether the user has paid for credits before
    // rate_limit: { ... } // A deprecated object in the response, safe to ignore
  };
};

​
Credit Limits

Credit limits govern how much you can spend. They come from two places:
  1. Account balance — your available credits across the account. If your account has a negative credit balance, you may see errors, including for free models. Adding credits to put your balance above zero allows you to use those models again.
  2. Per-key credit limits — an optional spending cap configured on an individual API key. The limit, limit_reset, and limit_remaining fields in the GET /api/v1/key response above describe this cap and how much of it remains.

​
Handling 402 errors

To resolve errors:
  • Add credits to bring your account balance above zero.
  • Check per-key limits. If limit_remaining on the key is exhausted, raise the key’s credit limit or wait for it to reset (see limit_reset).
  • Monitor proactively. Call GET /api/v1/key as shown above to track limit_remaining and usage before requests start failing.

​
Rate Limits

Rate limits govern how many requests you can make. There are a few rate limits that apply to certain types of requests, regardless of account status:
  1. Free usage limits: If you’re using a free model variant (with an ID ending in ), the following limits apply:
Credits purchased (all time)Requests per minuteRequests per day
Less than
At least
  1. DDoS protection: Cloudflare’s DDoS protection will block requests that dramatically exceed reasonable usage.

​
Handling 429 errors

Requests rejected with fail with a standard error response: 
{
  "error": {
    "code": 429,
    "message": "Rate limit exceeded",
    "metadata": {
      "error_type": "rate_limit_exceeded"
    }
  }
}
A error can come from two places:
  1. OpenRouter — you hit one of the platform limits above (free-model requests per minute or per day, or DDoS protection).
  2. The upstream provider — the provider serving your request is rate limiting or at capacity. In this case error.metadata.provider_code carries the provider’s original error code when available, and fallback routing retries other providers for the same model automatically before the error reaches you. You can also specify fallback models to try a different model when all providers for the first are exhausted.
Successful inference responses do not include X-RateLimit-* headers. When OpenRouter itself returns a error for a platform limit, the error response carries X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset headers describing the limit that was hit. When every attempted provider returned a retry hint, the error response also carries a Retry-After header. To monitor your remaining quota before hitting a limit, call GET /api/v1/key as shown above.
To resolve errors:
  • Retry with exponential backoff. Rate limits are transient; wait and retry rather than immediately re-sending. Honor the Retry-After header when present.
  • On free variants, purchase at least credits to raise your daily limit, or switch to the paid variant of the model, which has no platform-level request cap.
  • For provider-side limits, add fallback models or relax provider routing preferences so more providers are eligible to serve the request.

​
Mid-stream rate limits

If a rate limit is hit after streaming has started, the error arrives as an SSE event with finish_reason: "error" instead of an HTTP , since the status was already sent: 
data: {"id":"cmpl-abc123","object":"chat.completion.chunk","created":1234567890,"model":"openai/gpt-4o","provider":"openai","error":{"code":429,"message":"Rate limit exceeded"},"choices":[{"index":0,"delta":{"content":""},"finish_reason":"error"}]}
See Handling Errors During Streaming for details and code examples.