Switching AI models used to mean a new account, a new SDK, a new billing relationship and a fresh set of rate limits to learn. Comparing GPT against Claude against Gemini on the same prompt meant writing three integrations and babysitting three dashboards.
OpenRouter collapses that into one thing. It is a gateway that sits between your code and dozens of model providers, exposing all of them through a single OpenAI-compatible API. One key, one balance, one request shape, and a model name you can change in a single line.
What OpenRouter actually is
It does not train models. OpenRouter is a routing layer, launched in 2023 by Alex Atallah, previously a co-founder of OpenSea. You send a chat completion to its base URL, and it forwards the request to whichever provider you asked for: OpenAI, Anthropic, Google, Meta, Mistral, DeepSeek, xAI, plus a long tail of smaller labs. The answer streams back in the same format you sent it.
The practical effect is that anything written against the OpenAI SDK keeps working. Change the base URL and the model string, and a surprising amount of the ecosystem plugs straight in, from Cursor and LibreChat to the Vercel AI SDK and most LangChain templates.
The catalogue runs into the hundreds of models and it moves fast. When a lab ships something big, the kind of generational jump people are expecting from GPT-6 Astra, it tends to show up on the platform within hours. The same goes for established families: Anthropic’s Claude line now covers everything from code review to designing proteins.
It is also where codenamed stealth models appear for quiet public testing before anyone knows who built them. That is the same game the community spent weeks playing with the Ox Alpha mystery, which is why a strange new model ID showing up on the AI frontier is worth a second look.
How the routing layer decides
The same model is often served by several hosts. A single Llama checkpoint might be available from four inference companies at four different prices and speeds. OpenRouter picks one for you, and you can nudge that choice.
Automatic failover
If a provider returns a 500 or stalls, the request is retried against another host. The default allows a few attempts before it gives up. For anything user-facing, this is the feature that matters most, because an upstream outage stops being your incident.
Cost and speed preferences
Two settings do most of the work. You can sort providers by price or by throughput, and set a maximum price per million tokens that quietly drops anything above your ceiling. If you would rather have a fast host than a cheap one, you can pin the order yourself and let the fallback list handle the rest.
The free models, and what they really cost
OpenRouter carries a rotating set of free endpoints, marked with a :free suffix. They are genuinely usable, but rate-limited to something like twenty requests a minute and a few hundred a day, and they tend to be smaller or older versions of a model. Fine for prototyping, evaluation and personal tools. Not a production plan.
Paid usage is billed at provider list price plus a small cut on credit purchases, roughly 5%, rather than a per-token markup. The headline numbers match what you would pay going direct. There is no subscription and unused credit does not expire.
Bringing your own keys
If you already have an OpenAI or Anthropic account with committed spend, you can attach your own API key instead of topping up credits. Requests then route through your provider account and OpenRouter takes a small fee on those calls.
The upside is that your enterprise discount or volume agreement still applies. The downside is that you are back to managing several billing relationships, which was part of the problem you set out to solve. Pick one approach per project and stick to it, rather than mixing both and losing track of where the money goes.
The settings nobody reads
This is where it pays to slow down. Account settings let you control which providers are allowed to see your prompts and whether your requests may be used for training. There is a zero-data-retention option, and a separate data policy covering free models that is worth reading before you paste anything sensitive into one.
The defaults are reasonable, but they are not the same as private. Free endpoints in particular often come with looser data terms. And no gateway protects you from a leaked key, a risk that keeps proving itself in stories like OpenAI going from hacker to hacked. Rotate keys, set spend limits, and check the logs.
Where it earns its place
- Model comparison: one prompt, one code path, five models, a single afternoon of evals.
- Prototypes and side projects: no procurement, no minimum spend, no waiting on an enterprise contract.
- Resilience without ops work: failover across hosts you would otherwise have to integrate yourself.
- Agent pipelines: send cheap summarisation and extraction steps to a small model, and the final reasoning step to a frontier one, all through the same client.
Where you should go direct instead
The extra network hop adds latency, usually tens of milliseconds, which matters if you are streaming responses to someone watching a cursor blink. Fine-tuned and private deployments are not on the menu at all, because OpenRouter only serves what labs expose publicly. Provider-specific features such as prompt caching, batch endpoints and extended thinking controls often arrive late or with caveats.
Volume changes the maths too. Once a single model accounts for most of your traffic, a direct contract usually beats any middle layer on both price and support. The sensible pattern for most teams is to keep the gateway as the default while you are still figuring out which model wins, then move your one proven workhorse to a direct integration and leave everything else routing through OpenRouter.

