Does OpenRouter Have Rate Limits? What to Ask Any API

Short answer: yes, and so does everyone else

If you are asking does openrouter have rate limits, the answer is yes. So does every other hosted model API, because GPUs are finite and a provider that accepted unlimited traffic would fall over. We will not quote numbers for OpenRouter here, because they are set by that service and by the providers behind it, and they change. Read its current documentation for the figures that apply to your account and model.

What you can do right now is understand the shape of the limits. Once you know the categories, any provider's documentation becomes quick to evaluate.

Where rate limits come from

With a direct API there is one party: you, the key, and the provider's servers. With a router there are at least two. The router can limit your key, and the model provider behind the router can limit the router's traffic. A message that mentions an upstream provider is a hint that the second layer is the one that answered.

The deeper the stack, the more places a 429 can originate, and the harder it is to tell from the error text alone which layer produced it. That is not a flaw so much as a trade-off: you gain model choice and give up a single clear ceiling.

Questions to ask any provider before building

A rate-limit page that lists one number is incomplete. Put these questions to any API, router or direct, and find the answers in writing.

1. Requests per minute. Is it per key, per account or per IP?
2. Concurrent requests. How many at once? Does a streamed response hold a slot until it finishes?
3. Token limits. Is there a tokens-per-minute cap, or only a request count?
4. Daily or monthly caps. Do they exist, and what happens at the edge?
5. Error format. Do you get a machine-readable code, and a Retry-After header?
6. Tier changes. What do you do to raise the limits, and how long does it take?
7. Billing on failure. Are rejected or failed requests charged?
8. Visibility. Do response headers show your ceiling and balance?

If three of these have no clear answer, plan for surprises and build your retry logic accordingly. Our guide on OpenRouter API myths and facts covers a related set of assumptions people make about routers.

How limits work on our endpoint

To show what a complete answer looks like, here are ours. They are plain and fixed, and you can read them in the docs.

Go over the per-minute figure and you get HTTP 429 with the error code rate_limited. Open too many requests at once and the code is concurrency. If the service is briefly overloaded, you also get a 429, this time with Retry-After: 5. A streamed request keeps its concurrency slot until the stream ends.

Every response carries X-Request-Id, X-Balance-USD, X-RateLimit-Limit-Requests and X-RateLimit-Limit-Concurrency. This snippet prints them, so you can read your own ceilings instead of trusting a page:

Copyfrom openai import OpenAI

client = OpenAI(base_url="https://api.openrouterratelimit.com/v1", api_key="YOUR_KEY")

raw = client.chat.completions.with_raw_response.create(
    model="uncensored",
    messages=[{"role": "user", "content": "ping"}],
    max_tokens=5,
)
h = raw.headers
print("request id:      ", h.get("X-Request-Id"))
print("balance (USD):   ", h.get("X-Balance-USD"))
print("req/min ceiling: ", h.get("X-RateLimit-Limit-Requests"))
print("concurrency cap: ", h.get("X-RateLimit-Limit-Concurrency"))

Choosing between a router and a direct endpoint

Neither is better in the abstract. A router fits when you want to try many models behind one account, compare outputs and switch quickly. A direct endpoint fits when your workload is one kind of model and you want predictable ceilings and a short list of failure causes.

• If you are prototyping and do not know which model you need, a router saves time.
• If you are running a production feature on one model, fewer layers means fewer unknowns.
• If you need content that mainstream hosted models refuse, you need an endpoint built for that, whichever structure it has.

Our API is a single open-weight model, uncensored, tuned to answer without content refusals for lawful adult use. It is not a router and not the official API of any model vendor. Pricing is $0.15 per 1M input tokens and $0.50 per 1M output tokens from prepaid credit, with failed requests free. See pricing for top-up amounts and bonuses, or take the $0.50 trial from the API key page to measure the limits yourself.

Turn limits into a capacity plan

Limits only help when you convert them into a number you can design against. Two figures matter: how many requests you may start per minute, and how many may run at the same time. Whichever you hit first is your real ceiling.

The link between them is simple. Concurrency in use equals the arrival rate multiplied by the time each request takes. Suppose your calls average 10 seconds from start to finish, a plausible figure for a long completion, though yours will differ. With 8 concurrent slots, you can sustain 8 divided by 10, so 0.8 requests per second, which is 48 per minute. The 300 per minute figure is irrelevant at that duration, because the concurrency limit binds first. If your calls average 1 second, the opposite is true: 8 slots could serve 480 per minute, so the 300 per minute limit binds.

This explains a puzzling pattern people report, where they get errors well below the stated requests-per-minute figure. Long generations and long streams use slots for longer, so the concurrency cap arrives before the rate cap. Shorter outputs, set with max_tokens, raise your effective throughput without changing anything else.

Questions to settle with your own numbers

• What is your peak requests per minute, not your average?
• What is your average and 95th percentile request duration?
• Can the work wait, or must the user see an answer immediately?
• What should happen when the answer is no: queue, degrade or fail?

Write the answers down next to the provider's documented limits. If peak demand is more than about 70 percent of a limit, you either need a queue, a second key, a higher tier or a different provider. Accounts that have topped up can hold up to 5 keys on our service, which helps separate workloads, though you should check the docs before assuming that more keys means more total throughput.

What to do when you are already limited

Whatever you choose, build three habits. Log the full error body and request ID on every failure. Retry only on 429 and 5xx, with exponential backoff and jitter, and respect Retry-After. Cap your own parallelism a little under the documented ceiling so a spike never reaches the provider. These three steps turn most rate-limit incidents into a short delay that nobody notices.

More guides

• OpenRouter Rate Limited Upstream: Meaning and Fixes
• OpenRouter API: Myths vs Facts