OpenRouter Free Model Limits in November 2026, Tested

Tested November 15, 2026. OpenRouter's free models allow 20 requests a minute and 50 requests a day. The daily number rises to 1,000 once you have bought 10 credits. Those are the documented limits, and we hit both on purpose to see how they behave.

Three things we measured that the docs don't spell out:

• Failed requests didn't count. We sent 55 requests. The 24 that were answered moved the daily counter by 24. The 31 that failed moved it by nothing.
• The limit you'll hit first usually isn't yours. In 19 days of daily tests we got 127 429 errors while staying well under both limits. They came from the providers behind the models, not from our account.
• The daily limit applies late. Our key was served 54 free requests before the first daily 429 arrived.

For the list of free models, see OpenRouter free models. For how each one does on real tasks, see the free models benchmark.

The documented limits

As of 2026-11-15 from OpenRouter's limits page.

What the same page says about them:

• They apply to any model ID ending in :free, across all free models together. The openrouter/free router draws from the same allowance.
• The tier depends on credits you have ever bought, not your current balance. The higher tier starts one credit below the threshold, to absorb rounding and top-up fees.
• The day is a UTC day.
• "Making additional accounts or API keys will not affect your rate limits, as we govern capacity globally."
• Requests that use your own provider key are not gated by the daily counter.
• A negative credit balance can cause errors on free models too.

The limits count requests. Nothing on the page caps tokens for free models, so a 200-token request and a 200,000-token request each cost one. Each model still has its own context window and output cap.

Which requests count toward the 50

You can read your counter at any time, and reading it is free:

curl -s https://openrouter.ai/api/v1/key \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" | jq '.data.free_model_daily_requests'

{ "used": 20, "limit": 50, "remaining": 30 }

We read it before and after each group of requests on November 15.

As of 2026-11-15, 12:38 to 12:43 UTC, one key with no credits purchased. How we computed it: used from /api/v1/key before and after each group, against the count of HTTP 200 responses.

The 31 requests that didn't count were 27 upstream 429s, one 403 for a model that isn't offered in our region, and three of OpenRouter's own per-minute 429s.

Two details matter if you're planning around the counter:

• An empty answer still counts. All 21 replies in the last row had no content, because we capped them at 20 tokens and the model spent those on reasoning. Each one used a request.
• The counter runs behind. It took between 20 seconds and a minute and a half to show new requests. Our free router test four days earlier came up two short, most likely because it read the counter too soon.

Most 429s come from the provider, not your limit

A daily benchmark has sent every free model two short tasks since October 28. It sends one request at a time, 3.5 seconds apart, and never more than 32 a day. That is under both documented limits, so every 429 in its log came from somewhere else.

As of 2026-11-15: 516 requests on 19 days, one run a day around midday UTC (16:16 UTC on day one), no retries. How we computed it: each request's HTTP status and error fields from our benchmark log. Of the 127 429s, 114 carried limit_source: upstream_provider_shared_pool. The other 13 are from day one, before we logged that field, and all read "Provider returned error".

Seven of the eight errors inside a 200 were upstream capacity limits too, so check the body for an error object even when the status is 200.

The upstream limit is a pool of free capacity that everyone calling that model shares. When it is empty, the model returns a 429 to all of them. It sits very unevenly across models:

As of 2026-11-15, for 13 of the 14 free models in OpenRouter's models API that day. The 14th, thinkingmachines/inkling-2-small:free, returned a region 403 on all 12 requests from our location in Europe. Models with fewer requests joined the catalog later. Models that have since left the catalog are in the totals above but not in this table.

Other failures show up in other ways. Recursive Flint returned a 503 on 10 requests between October 30 and November 3, and Nemotron 3 Nano Omni returned a capacity error inside a 200 three times.

An upstream 429 comes back fast, in a median of 0.2 seconds, and it didn't use any of our daily allowance. So trying a busy model costs you very little. Gemma 4 31B answered once in the 26 quick requests above, after failing all 38 benchmark requests.

How to tell which limit you hit

All three kinds of 429 have the same status code. The body and headers tell them apart. These are from our own responses on November 15:

None of them carried a Retry-After header. X-RateLimit-Reset is a Unix time in milliseconds. OpenRouter's docs say successful responses don't include the X-RateLimit-* headers, so /api/v1/key is the only way to see the daily count before you hit it.

How strict the limits are

Per minute. We sent 24 requests to one working model in 13 seconds. The first rejection came on the 13th request, and three were rejected in all. The other 21 were answered. Together with one answer from the Gemma group, that is 22 answered free requests in one clock minute against a limit of 20. The 25 upstream failures we had sent seconds earlier didn't trigger the limit at all.

So the per-minute limit didn't work as a clean count to 20 in our test. It started rejecting early and still let more through than the number suggests. We can't tell you the exact rule from one burst. The benchmark's spacing of 3.5 seconds never triggered it in 516 requests.

Per day. With the counter at 44 of 50, we sent one request every five or six seconds. Ten were answered before the first daily 429. The counter then read used: 54, limit: 50. Treat that as slack from a counter that lags, not as four extra requests you can plan on.

Getting the most from 50 requests a day

1. Name models that answer. Pick from the zero-429 rows above. You can't fix a busy shared pool by waiting a few seconds.
2. Send a fallback list. A models array of several :free IDs lets OpenRouter try the next one when the first fails. The free router post shows the request. Keep every entry a :free ID.
3. Leave room in max_tokens. A reply cut off before any content still uses a request.
4. Space requests three or more seconds apart in scripts and scheduled jobs.
5. Read /api/v1/key before a batch, and stop cleanly at zero. Remember it lags by up to a minute or so.
6. Check the model field in the response. In one of our requests, stray text after :free in the model ID got an answer from the paid nvidia/nemotron-3.5-lightning, and it was billed. Four such requests cost $0.00004 in total.
7. If 50 isn't enough, buy 10 credits once. That is the documented way to 1,000 a day. More keys or accounts won't do it.

OpenRouter's upstream error also suggests adding your own provider key, so the request uses your limits with that provider instead of the shared pool. We haven't tested that.

What this test doesn't show

• The counter and burst tests are one day, one key with no credits, from Europe. We haven't tested the 1,000-a-day tier.
• The benchmark samples once a day around midday UTC. A model that is busy then may answer at other hours.
• We didn't test whether the fallback attempts inside one models request count separately, or how streaming requests are counted.
• OpenRouter can change the limits and the way it enforces them at any time. The dates are on every table.

The raw rows are in the repo under docs/marketing/data/openrouter-free-model-limits-2026/.

Run a model you chose on real work in Teamday

No free OpenRouter model is in Teamday's model picker. Teamday's OpenRouter models are paid ones you pick by name, such as Kimi K3 and GLM-5.3 Flash, and they have no free-model request cap. Save your OpenRouter key in runner settings and usage bills to your own OpenRouter account. See current pricing.

Related guides

• OpenRouter free models: the full catalog
• Free OpenRouter models benchmarked
• openrouter/free: which model the free router picks
• Cheapest OpenRouter models by capability