OpenRouter Free Models: 20 RPM and the $10 Daily Cap Explained

OpenRouter's free model variants are one of the busiest "free" surfaces in the AI API market: a large catalogue of models with a :free suffix, reachable through a single OpenAI-compatible endpoint with one key and nothing to pay. The catch is that the free tier has three moving parts that most users never read, and each one fails differently.

This is the arithmetic of those three parts: a per-minute cap, a per-day cap that depends on a purchase you may not remember making, and a billing state that can block free models entirely.

What are OpenRouter's free model rate limits?

OpenRouter documents two kinds of limits, and they produce different errors. Credit limits govern how much you can spend and produce payment-required errors. Rate limits govern how many requests you can make and produce rate-limit errors.

For free model variants — any model whose ID ends in :free — the platform rate limits are:

Source: OpenRouter limits documentation↗.

Three details from that page matter as much as the table:

1. The tier is set by lifetime credits purchased, independently of whether you currently hold a balance or qualify as a free-tier account. Spending the credits does not downgrade the ceiling; the purchase happened, so the ceiling stays.
2. The higher ceiling is granted slightly early. OpenRouter states that, to absorb rounding and top-up fees, the higher daily ceiling begins one credit below the nominal threshold — currently at 9 credits — and that an account which has purchased fewer than that reports itself as not on the free tier together with the lower daily ceiling.
3. Extra keys and extra accounts do not help. OpenRouter's documentation is direct: capacity is governed globally, so making additional accounts or API keys will not affect your rate limits. What does vary is the per-model limit, so the legitimate lever is spreading load across different models rather than across keys.

Paid, non-:free variants are not subject to the platform request cap described above. The 20-per-minute and daily ceilings described here belong to the free suffix.

How we verified this

We read OpenRouter's limits documentation↗ directly on 2026-09-17 and transcribed the free-tier table, the credit-limit behaviour, the global-capacity statement, the key-endpoint response schema and the fallback-routing notes from that single page. We also re-confirmed the payment-required behaviour for negative balances, because it is the single most misdiagnosed error in the free tier. We did not add model-count figures or per-model free quotas: OpenRouter's free catalogue and its per-model limits change regularly, and the authoritative values appear in your own key response and in the models catalogue at the time you read it.

The 10-credit hinge nobody talks about

The most consequential number in OpenRouter's free tier is not a rate. It is 10 credits, and the threshold is lifetime, not recurring.

Cross it once — with any top-up, on any day, for any model — and your daily free allowance rises from 50 requests to 1,000, permanently. That is a twenty-fold increase in daily capacity for a one-time purchase, and it does not decay when the credits are spent, because the tier is keyed to total credits purchased rather than to the balance you are holding.

Think of it as an onboarding cost rather than a spend. If your project makes more than a few dozen free requests a day — and anything with real users does — the alternative to buying credits is living with a 50-request ceiling that a single debugging session can exhaust. The comparison is not "10 credits versus free"; it is "10 credits versus a hard cap that will interrupt your work tomorrow".

There is one caveat worth stating plainly: the threshold depends on credits purchased, so a project running entirely on granted or promotional credit without a purchase may still sit below the threshold. Check the actual tier your account reports rather than assuming.

Why 20 requests per minute is the real constraint

The daily ceilings sound restrictive, but they are daily. The per-minute cap is what most projects actually collide with, for three reasons.

One user turn is several requests. A conversational agent issuing a planning call, one or two tool calls, an observation step and a final response can easily consume three to six model calls for a single turn from a single user. At 20 requests per minute, that is roughly five user turns per minute before the platform starts rejecting requests — and that assumes only one user is active.

Concurrency multiplies instantly. Two users acting simultaneously, each triggering four calls, pass 20 requests in a few seconds. Three parallel background jobs will do it without any user involvement at all.

The cap is platform-wide across free variants. Because the free limits apply to your account across free models, switching from one :free model to another does not create new per-minute headroom. Your account has twenty requests a minute, whatever model serves them.

The practical consequence: 20 requests per minute comfortably supports one interactive user working sequentially, or a small batch process run in controlled bursts. Anything genuinely concurrent needs a paid variant, or an architecture that spreads work across a longer time window.

The payment error that looks like a rate limit

This is the failure mode that costs people entire afternoons. Two different conditions produce two different errors, and only one of them is worth retrying.

• When you exceed a rate limit, you receive a rate-limit error. The request may succeed later. Backoff is the correct response.
• When your account balance is negative, you receive a payment-required error — and it applies to free models too. OpenRouter's documentation states this explicitly: a negative account balance may produce payment-required errors including for free models, and the resolution is to add credits so the balance is above zero.

The reason this is confusing is that it contradicts the mental model of "free means no money involved". It does not: the free path inherits the account's billing state, because the platform will not serve requests on an account that cannot spend. The signature question — "I'm only using free models, why is this a payment error?" — has a single answer, and the answer is not in your request.

There is a second, subtler source of the same error: per-key credit limits. A key can carry an optional spending cap described by three fields in the key response — the limit itself, its reset behaviour, and the remaining amount. If the remaining amount on the key is exhausted, requests fail with a payment error even when the account balance is healthy. The documented resolutions are to raise the key's credit limit, wait for its reset, or monitor the remaining amount proactively.

Operationally, the rule is simple: log payment errors separately from rate-limit errors, route them to a billing alert, and never put them in a backoff queue. A retry loop on a payment error is a loop that can never succeed.

How to check your remaining free quota before you hit the wall

OpenRouter exposes your quota through the key endpoint, which is the cheapest piece of monitoring you can add to a free-tier project:

[object Object]

Three fields do the work. The remaining-credit figure catches the balance problem before it becomes a payment error. The free-tier flag tells you how the platform classifies the account. And the daily free request object gives you used, limit and remaining counts for the current UTC day — which is the number you want on a dashboard if you run batch work.

Two limitations to design around. First, the per-minute limit is not reported by that endpoint, so short-window pacing has to be tracked client-side. Second, successful inference responses do not carry rate-limit headers; the platform's rate-limit headers appear on the error response when a platform limit is rejected, which is useful for diagnosis but not for prevention. Prevention means counting your own requests per minute.

Worked example: how many users can a free model serve?

Assume a chat assistant where one user turn costs four model calls. Reading the two ceilings together:

The first row is the honest reason to buy the credits. Twelve turns a day is a demo, not a product. The second row is a real working budget — eight users a day, or one power user with 250 turns — bounded not by requests but by the five-turn-per-minute pacing ceiling.

If your workload is batch rather than interactive, the calculation inverts: the daily ceiling governs, and the per-minute cap is irrelevant as long as your scheduler paces submissions. A batch job that submits one request every four seconds sits comfortably under 20 per minute and simply consumes its daily budget in a predictable number of hours.

Does fallback routing change the math?

OpenRouter's fallback routing is often mistaken for extra free capacity. It is not, but it is genuinely useful.

When a provider serving your model is down or rate limited, fallback routing retries other providers for the same model before the error reaches you. The practical implications for a free-tier build:

• Upstream congestion is partly absorbed. A rate-limit error can originate at the platform or at the upstream provider. When it comes from upstream, the platform's own retry may resolve it before you ever see an error.
• Read the metadata before declaring a route dead. The error metadata carries the upstream provider's original code when available, which is how you distinguish "my account hit its cap" from "this provider is having a bad minute".
• Your account caps are unchanged. Fallback improves the success rate of requests that the platform accepts. It does not raise the 20-per-minute or daily ceilings, because those are applied to your account regardless of which upstream ultimately served the request.
• Fallback models are a separate lever. You can configure a list of fallback models to try when every provider for the first choice is exhausted. That is the mechanism that helps when the constraint is upstream capacity rather than your own quota.

There is one more edge case worth knowing if you stream responses: if a limit is hit after streaming has begun, the platform cannot return a status code, because the response has already started. The error arrives as a server-sent event carrying an error finish reason instead. Clients that only check HTTP status codes will treat a failed stream as a successful empty completion, which is a subtle and expensive bug. Handle the in-stream error path explicitly.

Limitations and things that surprise people

• A fresh account defaults to 50 requests per day. That is not a soft launch allowance; it is the ceiling until a lifetime purchase threshold is crossed.
• The free catalogue is not stable. Free variants are added, renamed and retired, and the models behind a given :free ID can change upstream capacity without notice. Never hard-code a large list of free model IDs into production logic without a fallback.
• Some requests are exempt from free-model gating. OpenRouter notes that accounts and endpoints exempt from free-model limits, and requests using your own provider keys, are not gated by the daily counter. The remaining figure in the key response reflects the tier policy rather than an enforced ceiling for those accounts — useful to know before you build alerting on it.
• A separate protection layer exists. The platform also relies on DDoS protection that blocks requests dramatically exceeding reasonable usage. That is not a quota you can plan against; it is a signal that you have misconfigured a loop.
• Quality and capacity vary by upstream. A free variant served by a less-provisioned provider may be slower or more frequently congested than the paid route for the same model, and that variability is not a billing problem.

FAQ

Does buying 10 credits cost me anything per month? No. It is a lifetime purchase threshold, not a subscription. Once crossed, the higher free-model daily ceiling applies to the account permanently, even after the credits themselves are spent.

Can I combine the free tier with paid variants for overflow? Yes, and it is the standard pattern. Free variants handle the work they can absorb; paid variants have no platform request cap, so overflow traffic simply bills per token.

Why does the daily counter reset at a different time than my day starts? The free-model daily counter is tracked for the current UTC day. If your usage reporting is in local time, the reset will appear to land mid-shift.

Do free models support the same features as paid ones? Not necessarily. Upstream providers differ in what they support, and features such as tool calling, structured output and long context depend on the model and the provider serving it at that moment. Test the specific free variant you depend on.

What is the fastest way to diagnose an unexpected failure? Check the key endpoint for remaining credit and free-request quota first, then read the error metadata for an upstream provider code. Between those two, almost every free-tier failure is identifiable in under a minute.

Where this sits in the directory

The free tier is genuinely usable for exactly one workload shape: single-user, sequential, cache-friendly, with a one-time credit purchase to unlock the 1,000-request daily budget. Outside that shape, you are on the paid variants, which carry no platform request cap.

The OpenRouter entry in the directory carries the limits documentation, the free-variant catalogue and the key endpoint that reports your exact remaining free budget — plus the same shape-of-limit treatment we apply to every other provider, so you can pair it with a fallback that fails in a different place.