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:
  1. Credit limits — how much you can spend, based on your credit balance and any per-key credit limits. Exceeding these returns .
  2. Rate limits — how many requests you can make in a given window, such as free-model request caps and DDoS protection. Exceeding these returns 429 Too Many Requests.

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 Payment Required

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 ), you can make up to requests per minute. The following per-day limits apply:
  • If you have purchased less than credits, you’re limited to model requests per day.
  • If you purchase at least credits, your daily limit is increased to model requests per day.
  1. DDoS protection: Cloudflare’s DDoS protection will block requests that dramatically exceed reasonable usage.

Handling 429 Too Many Requests

Rate-limited requests fail with a standard error response:
{
  "error": {
    "code": 429,
    "message": "Rate limit exceeded",
    "metadata": {
      "error_type": "rate_limit_exceeded"
    }
  }
}
A 429 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 429 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. To monitor your remaining quota before hitting a limit, call GET /api/v1/key as shown above.
To resolve 429 errors:
  • Retry with exponential backoff. Rate limits are transient; wait and retry rather than immediately re-sending. When every attempted provider returned a retry hint, the response carries a Retry-After header — honor it 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.
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 429, since the 200 status was already sent. See Handling Errors During Streaming.