In this article
openrouter/free selects among eligible free models; save the returned identity when reproducibility matters.
openrouter/free is OpenRouter’s router for available free models. It can suit small experiments where testing a workflow matters more than fixing a particular model. For reproducible comparison, save which model actually answered every request. Repeating the same prompt does not necessarily mean the same model will run again.
Understand the selection you requested
The documented router chooses from available free models while considering required capabilities. Treat its identifier as a selection mechanism, not as the name of a single set of weights. A successful answer establishes one observed execution, not permanent access to that exact configuration.
Begin with a short, non-sensitive input and a small output limit. Save the requested router, returned model identity, finish state, errors and usage when available. This is more useful than collecting only the displayed text, which can conceal a change of model between attempts.
Test the feature your application needs
First confirm an ordinary text request. Then test a mandatory feature, such as structured output or tools, as its own controlled case. Keep the operation and output contract explicit. A model selected for one request may not represent all feature combinations your application expects.
Do not use an unlabelled sequence of router responses as a model benchmark. Group results by the returned identity and record the actual parameters. If the application needs stable behavior, compare the router with a specific eligible free catalog entry under the same task conditions.
Compare selection modes
| Mode | What the application fixes | What still needs checking |
|---|---|---|
openrouter/free | A free selection mechanism | Actual answering model and capabilities |
A specific :free entry | Desired model entry | Its current endpoints and availability |
| An application fallback list | A set and ordering of targets | Cost and compatibility of every transition |
A fixed free entry does not guarantee uninterrupted capacity either. It simply fixes a different part of the request. An application’s own fallback can introduce paid targets, so preserve its financial and feature requirements separately from the router setting.
Keep failures and conclusions bounded
Check the account’s current free-model restrictions before scheduling a dataset. Use a finite queue, deadline and attempt count. Save partial, rejected and completed tasks separately rather than reporting only successful examples. Do not treat a new key as an expansion of shared account limits.
The result should describe a small workflow test with observed identities and quality. It is not proof of reserved compute or ongoing demand for an equivalent local model. That supports a distinct local pilot with explicit model and capacity assumptions.
Official references: openrouter.ai — free router, openrouter.ai — free.
Related guides: Free model limits on OpenRouter: planning a bounded test, Free OpenRouter API keys: what is free and what costs money.