OpenRouter did something worth being clear-eyed about: it made a hundred models reachable through one OpenAI-shaped API, with one account, one bill, and fallbacks when a provider is down.
That is not a small thing. Provider APIs differ in tokenisation, streaming semantics, tool-call formats, error taxonomies and rate-limit behaviour, and normalising them is unglamorous work that everybody would otherwise redo.
If you want access, that problem is solved and you should not solve it again.
What it leaves to you
Which model, for this request, and on what grounds.
OpenRouter gives you excellent mechanisms for expressing an answer — model lists, fallback orders, provider preferences, price and latency routing. What it does not do, because it is not its job, is hold an opinion about your traffic. The policy is yours, and it lives in your application code as a string or a list, next to the call.
For a lot of products that is exactly right. If you have one prompt and one model, a router is ceremony.
It stops being right when three things are true at once: several distinct kinds of work, real cost differences between models, and a rule that must never be broken for one of those kinds.
The third thing is the one
Cost and quality routing is well served. Score the request, pick a tier, done — and there are several good tools for it, OpenRouter among them.
A constraint is different in kind. "This request touches money and must not leave our infrastructure" is not a preference to be weighed against price; it is a gate that runs before anything is weighed. And the difficulty is not expressing it once — it is that it has to survive every other feature you add.
Stickiness wants to keep a conversation on its model. Fallback wants the next model when one errors. Both are correct features, and both will happily select a model your constraint excluded, unless the thing they read from is the filtered list rather than the pool.
That is a property of where the code draws its data, not of the routing table. Expressing it as configuration in someone else's system means expressing it once, in a place that the next feature does not have to go through.
What we built instead, and honestly
Requests are classified into concepts — kinds of work, authored as files with
example sentences. Each concept carries constraints, and the constraints gate
before anything ranks. /v1/explain returns the whole decision without calling
a provider.
Costs: somebody has to write the concepts, we support far fewer models, and there is no marketplace of providers behind it. If your problem is access, this is strictly worse.
Gains: the routing policy is a reviewable artifact, every decision is explainable in terms of the concept and the eliminations, and a constraint holds structurally rather than by everyone remembering.
The honest position
These are not competitors so much as different layers with an overlap. OpenRouter answers how do I reach any model. This answers which model should this kind of work go to, and can I prove the rule held.
You could reasonably run both — a concept router in front, OpenRouter as the provider behind it — and for anyone who wants breadth of access plus a policy they can review, that is probably the right shape.
What you should not do is pick one because a comparison table said so. The question that decides it is whether you have a rule that must never be broken. If you do not, you want access and everything here is overhead. If you do, the important question is not which models you can reach but whether anyone can tell you the rule held on Tuesday.