OpenRouter Free Models: Limits, Privacy and Fallbacks Explained

TL;DR: OpenRouter's published free-model policy allows 50 requests per day, rising to 1,000 after $10 in purchased credits, with a 20-request-per-minute limit in both cases.^[1] Buying credits does not make every model free or settle its privacy policy: free and paid training permissions are separate, and a paid fallback is billed at the model actually used.^[5][8]

Union Alpha brought readers to OpenRouter to try a mysterious model. Its identity is now known. The useful next question is operational: what happens to your allowance, data and bill when the endpoint you liked becomes unavailable?

The real story isn't the zero on a model's price card. It is the set of decisions behind each request. A prototype can survive a queued answer. A customer-facing application needs predictable behavior when a quota runs out, a provider rejects traffic or a fallback changes the model.

Cover: generated editorial artwork illustrating request controls, not a screenshot of OpenRouter or measured infrastructure.

Free Quotas: Count Requests, Not Conversations

OpenRouter publishes these limits for ordinary free-model use. They describe an allowance, not guaranteed successful completions.^[1]

The limits reference specifies all-time credits purchased, rather than the balance currently left. It also documents a small threshold allowance for rounding and top-up fees. Use the account's reported ceiling instead of reverse-engineering eligibility from a receipt.^[2]

Check GET /api/v1/key: free_model_daily_requests reports used, limit and remaining for the current UTC day. usage_daily measures credits, not free requests. The is_free_tier flag alone does not establish which request ceiling applies.^[2]

An illustrative agent that makes five model calls per task would consume a 50-request allowance in ten tasks, assuming no other traffic or failures. OpenRouter's cost guide says failed free requests also consume quota. Repeatedly retrying a broken endpoint can therefore exhaust a daily allowance without completing the work.^[1]

Capacity Planning: Reserve Attempts Before Starting Work

Consider a hypothetical workflow requiring four model requests per completed task. Give each task one additional request for recovery, and reserve ten of a 50-request daily allowance for manual diagnosis. The remaining 40 requests fund eight task budgets of five attempts, not a promise of eight successful tasks. A task needing a second retry stops or waits instead of consuming another task's allocation.

With a 1,000-request allowance, reserving 200 leaves 800 requests, enough for 160 identical task budgets. These are planning scenarios, not measured throughput. They assume all requests are subject to the same quota and include no other application traffic.

The minute limit remains a separate constraint. An illustrative scheduler could admit 16 planned calls per minute and reserve four for recovery, within the published ceiling of 20. Four planned calls per task gives four task-equivalents per minute on paper, but slow responses, upstream capacity and dependency order can reduce completions. Queue length is a better overload signal than a green account-balance indicator.

Count attempts centrally across workers. If every worker independently sees remaining capacity and starts work, a shared allowance can be oversubscribed. Reserve the task's budget before dispatch, release unused reservations on completion, and reconcile your estimate with the account counter. A local reservation system is your application control, not an extra quota granted by OpenRouter.

Credits: A Deposit Does Not Buy Unlimited Inference

The $10 threshold is a purchase condition for a higher free allowance. It does not convert paid models into free ones. OpenRouter deducts paid usage from a US-dollar credit balance; purchasing credits also carries a platform fee. Check checkout for the actual total.^[3]

Do not confuse eligibility with the life of the money. OpenRouter's cost guide says the deposit never expires, while its FAQ reserves the right to expire unused credits after one year. Those statements conflict. Do not buy credit on a promise of permanent stored value; consult the current terms before purchasing.^[1][3]

Keep three budgets separate: free requests, paid spending and application retries. A $0 token price addresses only the first layer of inference billing. Paid tools or a paid fallback need their own review. Our recommendation is to make the application's spending policy explicit before increasing its throughput.

Model Selection: Free Router Is Not a Quality Ranking

openrouter/free randomly selects among available free models after filtering for needed capabilities, including tools, image understanding and structured output. OpenRouter does not describe it as choosing the best model for your task. The response's model field identifies what actually answered.^[4]

That makes it useful for exploratory work where variability is acceptable. It is a poor basis for declaring that a particular model passed a regression test unless you record the returned identity. Pin a listed free variant when evaluating that model, and confirm its supported parameters and context window.

The :free suffix is a catalog variant, not a magic switch that works on every paid model. OpenRouter's FAQ says catalog variants need their own listing. Free availability can also change.^[3][4] A saved model name is not a long-term availability contract.

Capability Matching: A Response Is Not an Accepted Result

Before approving a fallback, define the job's minimum contract: input modality, required tool interface, output schema, context size, permitted providers and spending ceiling. A model that can summarize text is not automatically a replacement for one extracting a validated object from an image.

OpenRouter documents provider.require_parameters: true to restrict routing to providers supporting all supplied parameters.^[10] Treat that as a routing filter, not proof of task accuracy. Validate the returned schema and tool arguments in your application. Test a missing field, an oversized input, a refusal and an interrupted stream before accepting the replacement.

For deterministic evaluation, keep a small set of inputs with known acceptance criteria. Record the requested model and the served model separately. If the replacement fails a requirement, return a clear degraded result or stop; do not silently turn a required structured answer into prose because the fallback happened to respond.

Privacy: Training and Retention Are Different Decisions

OpenRouter documents separate training permissions for free and paid models. Check both. Opting out of provider training and opting into OpenRouter's own logging are different controls.^[5]

At OpenRouter itself, prompt and response storage is opt-in. Private debugging logs and permission for product-improvement use are separate settings, both off by default. Request metadata is still retained; the documentation also describes anonymous prompt categorization.^[6] “No prompt logging by default” does not mean nothing is processed or recorded anywhere.

For inference providers, a no-training promise does not automatically mean no retention. OpenRouter's dedicated ZDR documentation describes provider.zdr: true as restricting requests to endpoints with zero-data-retention policies. It excludes enabled plugins and tools from that guarantee.^[7]

There is a documentation inconsistency: the provider-logging overview says OpenRouter has no routing rules based on retention, while the dedicated ZDR page explicitly documents them. We rely on the specific ZDR reference for the described control, but have not independently tested its enforcement. Confirm eligible endpoints before sending sensitive material.^[5][7]

Data Decisions: Set the Boundary Before the Retry

The following matrix is our suggested review process, not a legal determination or provider certification. Apply your organization's actual data rules to every eligible destination.

Review tools separately: approving an inference endpoint does not approve every search service or tool attached to the workflow. Also inspect what your own error tracker stores. A carefully configured provider cannot undo a prompt copied into unrestricted application logs.

Keep a dated policy record next to the fallback configuration, with the reason each destination is permitted. Revisit it when a route, model or service term changes. “It was free when we tried it” is neither a data classification nor approval for the next request.

Fallbacks: Decide What Failure Is Allowed to Cost

Provider failover tries another provider for a model. Model fallback can change the model itself. OpenRouter's models array defines alternatives in priority order; errors including rate limits, downtime, context failures and moderation flags can trigger fallback. Billing follows the model that ultimately served the request.^[8]

A practical policy is to approve the entire fallback list before enabling it. A free-only experiment should contain only verified free destinations. An application permitted to spend should use an explicit paid allowance and evaluate the replacement model's behavior. Successful fallback does not prove identical output quality, tool behavior or data handling.

These checks follow OpenRouter's limits, error and fallback references. A negative balance can affect even free requests; a positive balance does not rule out a spending-cap rejection.^[2][8][9]

A Bounded Recovery Runbook

Write the fallback policy in application terms before encoding it into a request. For example: try the approved free primary; allow one approved alternate for a transient failure; do not use paid destinations; do not relax privacy or schema requirements; stop when the task's attempt budget is exhausted. This is a proposed policy, not the default behavior of the platform.

For an application allowed to pay, add an explicit branch with a task-level spending allowance and reviewed model list. Estimate the remaining work before taking that branch, and reconcile actual usage afterward. A token-price ceiling alone does not cap the bill if the application keeps issuing requests.

1. Pause new dispatch when failures spike. Preserve the first useful error and the last successful route. Avoid hundreds of copies of the same failing attempt.
2. Classify the failure. Separate quota exhaustion, provider overload, insufficient spending allowance, malformed input and incomplete streamed output. Changing models does not repair every category.
3. Choose one permitted recovery. Wait for a retry hint, reduce an unnecessarily oversized request, or use the approved alternate. Keep the original task ID and account for the extra attempt.
4. Validate and reconcile. Check the replacement's result, record its identity and cost, then release or close the task reservation. Never mark a partial answer complete merely because the HTTP connection succeeded.

If a tool action may already have changed external state, reconcile that action before replaying the whole agent loop. Retrying a model response and repeating a purchase, email or database write are different operations. An application-level operation identifier can help distinguish recovery from duplicate work.

The uncomfortable truth is that free inference still requires operational discipline. Use it to learn which tasks are worth paying for. Record which model answered, stop wasteful retries, and treat data policy as part of routing. The strongest prototype is the one whose failure behavior you already understand.

Last updated: September 20, 2026