OpenRouter caps every free :free model at 20 requests per minute, account-wide.
An account with no purchased credits gets 50 requests a day, a ceiling reached in 2.5 minutes at that pace.
One lifetime purchase of $10 in credits, confirmed against the documentation OpenRouter publishes on 2026-08-27, raises the daily cap to 1,000.
Read the table below and stop.
Account state | Requests per minute | Requests per day | Basis for the cap | Beyond the cap |
|---|---|---|---|---|
No credits purchased | 20 | 50 | Default free-tier setting | 429 rate-limit error until the daily window resets |
$10 or more in credits, lifetime | 20 | 1,000 | One-time purchase total, not a maintained balance | 429 rate-limit error until the daily window resets |
Negative credit balance | 20 (unaffected) | 0 in practice | Balance fell below $0 | 402 credit error, including on free models |
Table note: figures are vendor-documented (Reported tier), not independently tested. Source, URL, and retrieval date for every cell are recorded in the raw data file and on the methodology page.
OpenRouter's documentation names two thresholds, not a sliding scale: 20 requests per minute in both states, and either 50 or 1,000 requests a day depending on lifetime credit purchases.
Falling to a negative balance blocks free models with a 402 error, a separate failure mode from the 429 rate-limit response the per-minute and per-day caps produce.
Both daily figures reset on a 24-hour cycle; OpenRouter's documentation does not name the reset timezone, a detail this article did not confirm.
Basis and method
This article uses Basis 2, aggregated. Every figure below comes from documentation OpenRouter itself publishes: its API reference on credit and rate limits, its FAQ, its pricing page, its support article on rate limits, and its BYOK pricing announcement, all retrieved 2026-08-27, with each claim linked to its specific source at the point it is made below.
LLM Waves Research did not send requests against the OpenRouter API to trigger a rate-limit or credit error and confirm enforcement first-hand. Two figures are LLM Waves Research's own arithmetic applied to OpenRouter's published constants: minutes to exhaustion equals the daily cap divided by the 20-requests-per-minute limit, and the 30-day request ceiling equals the daily cap multiplied by 30.
No figure in this article was produced by testing. Full method, including the complete dated source list: methodology.
This article checks OpenRouter's free tier on three axes: the fixed per-minute cap, the two-setting per-day cap, and the one-time purchase that moves an account between them.
Every free-tier request still counts against a fixed ceiling before any daily total matters.
Fifty requests a day sounds workable until the per-minute cap sets the real pace.
The :free suffix and what it buys
A model slug ending in :free on OpenRouter routes a request to a zero-cost variant instead of the standard, billed endpoint. OpenRouter's pricing page lists 25+ models available this way across 4 free providers, retrieved 2026-08-27. The catalog changes without a public changelog.
A separate LLM Waves Research article tracks which models carry the :free suffix on a given day, since that roster shifts far more often than the caps around it.
This piece covers the limits that apply no matter which :free model gets called, because those limits outlast any single model's place in the free catalog.
The per-minute cap holds at 20 in every state
OpenRouter's API reference names the free-model per-minute limit as a fixed constant, 20 requests per minute, unchanged by credit balance on the account.
At that pace, the 50-request no-credit daily cap is reachable in 2.5 minutes of continuous calls; the 1,000-request funded cap takes 50 minutes at the same rate. Neither minute figure appears in OpenRouter's own documentation.
Both are LLM Waves Research's arithmetic: the daily cap divided by 20. A burst of parallel requests hits the per-minute ceiling first, before either daily number becomes relevant, since 20 requests can arrive in under a second on a fast connection.
The daily number is the one most people plan around. It is also the one with a second setting hidden behind it.
The daily cap has exactly two settings
OpenRouter's FAQ states the rule in one sentence: purchase at least $10 in credits, lifetime, and the daily cap for free models moves from 50 to 1,000 requests.
The purchase is cumulative, not a balance an account has to maintain.
OpenRouter's support article on rate limits confirms the higher cap continues even if the account balance later drops back under $10, since the $10 figure counts total historical credits purchased rather than funds on hand at any given moment. Not a subscription tier.
What $10 actually buys
Projected across 30 days, the two caps produce 1,500 requests a month unfunded against 30,000 requests a month funded, a formula this article states outright: daily cap times 30.
That gap is 28,500 extra monthly requests for a single $10 purchase, close to $0.0004 per additional request unlocked. A twentyfold jump, for $10. Compare that to the 5.5% platform fee OpenRouter's pricing page lists on pay-as-you-go paid usage, and the $10 credit purchase reads less like a fee and more like a one-time key.
Nothing about the purchase changes the per-minute ceiling; 20 requests per minute still caps how fast either monthly total can be drawn down.
A negative balance blocks free models too
A negative credit balance produces a 402 error on OpenRouter, and that applies to free models as well as paid ones. OpenRouter's API reference states this directly: an account with a negative credit balance may see 402 errors, including for free models. Restoring a positive balance restores access immediately, according to the same page.
This failure mode is separate from the 429 responses the per-minute and per-day caps produce.
Rate limit headers only appear after a request fails
OpenRouter's API reference documents three rate-limit response headers, X-RateLimit-Limit, X-RateLimit-Remaining, and X-RateLimit-Reset, and states that all three appear only on error responses tied to platform-level 429s, never on a successful call. A client polling a successful response for remaining quota will find nothing there.
This is a narrow, technical detail. It matters most to anyone building retry logic against the free tier, since the usual pattern of reading headroom off a successful response does not work here.
The free tier is not BYOK, and the BYOK number changed
Bring-your-own-key routing, BYOK, is a separate program from the free :free models this article covers. A BYOK request uses an account's own provider API key, billed at that provider's own rate plus a 5% OpenRouter fee past an allowance. OpenRouter's own announcement page still carries an October 2025 headline offering 1,000,000 free BYOK requests a month, but an update logged on the same page states plainly that the policy changed in August 2026 to a plan-dependent allowance measured by list-price inference cost: $25,000 a month on pay-as-you-go, $200,000 a month on enterprise.
Content built against the older figure has not caught up. Confusing BYOK's cost-based allowance with the free tier's request-based caps produces the wrong number for both.
What we did not measure
We did not send requests against the OpenRouter API to trigger a 429 or 402 response and confirm enforcement first-hand. We did not independently count the free models live on OpenRouter's catalog on the retrieval date; the pricing page's "25+" figure is quoted as published.
The reset timezone for the daily windows is not named in OpenRouter's public documentation and was not confirmed elsewhere. Per-model exceptions inside the free catalog, since some individual models may carry tighter limits than the account-wide figures reported here, were not checked model by model. Paid-tier behavior is described only from OpenRouter's own statement that it sets no hard platform limit; upstream provider limits and BYOK-key limits were not tested.
Use-case verdicts
For developers
The unfunded pairing of 20 requests a minute and 50 a day covers testing a prompt across a handful of calls. A coding agent making dozens of calls in one session crosses it inside that same sitting.
For startups
The funded tier's 1,000 requests a day covers a few hundred manual test sessions a month, for the price of one $10 purchase, before a startup needs to commit to paid infrastructure.
For high-volume traffic
Both free-tier daily caps function as a hard ceiling enforced with a 429 response, not a soft target. Sustained volume past a few hundred requests a day calls for the paid tier's usage-based pricing instead.
For low-latency workloads
The free tier adds no queueing behavior beyond the 20-requests-per-minute cap itself. A burst past that cap returns an error rather than a delay, so latency-sensitive calls need pacing under 20 a minute rather than a queue to wait on.
For self-hosted or on-device deployments
OpenRouter's free-tier caps do not apply at all, since neither route runs through OpenRouter's API, and this article does not have the data to compare the two paths directly.
How is OpenRouter's free tier free?
OpenRouter's :free models route requests to providers offering inference at no cost to OpenRouter, subject to the platform's own 20-requests-per-minute and 50-or-1,000-requests-per-day caps. No payment method is required to start. A card or crypto payment is required only to purchase the $10 in credits that raises the daily cap.
What free models are available on OpenRouter?
OpenRouter's pricing page lists 25+ free models across 4 free providers, retrieved 2026-08-27, and the specific roster changes without a public changelog. A separate article on this site tracks which models carry the :free suffix on a given day.
What happens when the free tier limit is reached?
Exceeding either the 20-per-minute or the daily 50-or-1,000 cap returns a 429 rate-limit error until the relevant window resets. A negative credit balance produces a different error, a 402, that blocks free models until the balance turns positive again.
Does OpenRouter's free tier require a credit card?
No. OpenRouter's free :free models are reachable with an API key and no payment method on file, capped at 20 requests per minute and 50 requests a day. A card or crypto payment becomes necessary only when purchasing credits, including the $10 purchase that raises the daily cap to 1,000.
Is the $10 credit threshold a one-time payment?
Yes. OpenRouter's documentation defines the threshold as credits purchased all time, not a balance that has to stay above $10. A funded account keeps the 1,000-request daily cap even if its balance later falls, including to zero, as long as a negative balance is not reached.
The two numbers outlast the model list
Free models rotate through OpenRouter's catalog without notice; the caps around them do not.
Anyone building against the free tier can treat 20 requests a minute, and either 50 or 1,000 a day, as the stable part of the arrangement, worth checking again only when OpenRouter's own documentation changes.
This article reflects a single retrieval window. OpenRouter's rate-limit and pricing pages remain the definitive source going forward.
Raw data: the full constant values, arithmetic, and dated source list behind every figure in this article live on the OpenRouter Rate Limit Data page.
Changelog: 2026-08-27: Published. Figures collected from OpenRouter's API reference, FAQ, pricing page, rate-limit support article, and BYOK announcement page, all retrieved the same day.
Published: 2026-08-27 Last updated: 2026-08-27 Data collected: 2026-08-27 (UTC)