OpenRouter: product and architecture
This OpenRouter review covers a hosted LLM gateway, and the whole product fits in one sentence: one API key, one bill, several hundred models across eighty-plus providers, with no markup on the tokens. Everything else — routing, failover, published per-model prices, data policies — follows from that. It is proprietary and there is no subscription; OpenRouter earns on the credits you buy. We evaluated it against its documentation, its published fee schedule, and the adoption signals we collect weekly.
Overview
OpenRouter is a commercial service with no public repository that is the product, so it has no core adoption signal of the kind an open-source project has. What we can measure is the vendor's own SDKs: our 14 September 2026 snapshot recorded roughly 2.6 million weekly npm downloads of @openrouter/ai-sdk-provider and about 376,000 weekly PyPI downloads of openrouter. Those are developer-adoption figures for client libraries, not platform usage, and we do not present them as the latter. The vendor's own site states 400T+ monthly tokens, 10M+ users, 500+ models, 80+ providers and 250k+ apps; those are unverified vendor figures, and the scale they describe is consistent with the Hacker News attention the product attracts.
Its market position is the frictionless middle of the model market. Where LiteLLM is infrastructure a platform team runs, OpenRouter is a URL and a key. The audience is teams that want optionality across models without operating anything, and application developers who want to ship against one interface and change their mind later.
Key Features and Architecture
The core is a unified OpenAI-compatible API. Adoption is a base-URL change and a key swap, and from there the model is a string. Text, image, video, and audio models are reachable through the same interface, which matters when a product grows a second modality and you would otherwise integrate a second vendor.
Provider routing and failover is the operational argument. Many models are served by more than one provider, and OpenRouter can fall back when one is degraded or down. For a product whose main dependency is a single model vendor's availability, that is a real reduction in exposure, and it is the part you cannot reproduce by holding several API keys yourself without building the routing.
Published price and performance per model is the commercial argument, and it is unusually transparent. Each model's rate and latency are listed openly, so comparing options is reading a table rather than running a procurement exercise.
Custom data policies let an organisation constrain which providers may receive its prompts — fine-grained enough to exclude a provider whose retention terms you have not accepted. This is the feature that decides whether OpenRouter is usable in a regulated setting, and it is worth reading the detail rather than the headline.
Bring your own keys lets you route through OpenRouter while paying a provider directly under your own contract, which preserves negotiated rates and existing commitments.
There is no self-hosted option. The gateway is the service.
Ideal Use Cases
Four situations favour OpenRouter. The first is model optionality without infrastructure. If you want to try a new model the week it ships, compare three on the same prompt, or switch when prices move, this removes every step between the decision and the request.
The second is availability through failover. A consumer product that goes down when one vendor has an incident has a single point of failure, and routing across providers is the cheapest way to remove it.
The third is early-stage and unpredictable volume. There is no subscription and no minimum, so the cost of keeping the option open is zero until you use it.
The fourth is agentic applications that call many models, where the per-model price table is itself a design input and one bill is materially simpler than eight.
Do not choose OpenRouter when your model contracts must stay yours — bring-your-own-keys covers part of this, but the default path buys tokens through an intermediary, and some procurement processes will not accept that. It is the wrong answer when the gateway must run inside your network, where LiteLLM self-hosted is the alternative. It is also not a governance platform: per-team budgets, virtual keys with RPM and TPM limits, and spend attribution across an organisation are what a self-hosted gateway is for. And it adds a hop, so a latency-critical path should be measured against calling the provider directly.
Pricing and Licensing
OpenRouter takes no markup on inference. Models are charged at each underlying provider's list price per million tokens, published openly per model, and there is no subscription.
The business model is the credit purchase. Buying credits costs 5.5% with a $0.80 minimum through Stripe, or 5% in cryptocurrency. That is the entire fee for normal use, and it is the number to compare against alternatives — a few per cent on top of list price in exchange for one integration, published prices, and failover.
Bringing your own provider keys is free up to $25,000 of monthly usage on the pay-as-you-go tier, or $200,000 on the enterprise tier, with 5% charged above those thresholds. That is the path for an organisation with negotiated provider rates that wants the routing without the resale.
The comparison worth making is against a self-hosted gateway. LiteLLM is free to self-host and takes no cut at all, so above a certain spend the 5.5% credit fee exceeds what running a proxy costs you in infrastructure and on-call. Below it, the fee is cheaper than the engineering. The crossover is not a token volume so much as an organisational one: it arrives when you have a platform team who would run the proxy anyway.
We recommend estimating the annual credit fee at your expected spend and comparing it against a realistic cost for operating LiteLLM, including the availability risk of putting your own service in the request path.
Strengths & Trade-offs
Pros
- No markup on inference. You pay list price for tokens, and the fee is a stated percentage on credit purchases rather than a hidden spread.
- Published per-model price and latency, which makes comparing models a reading exercise rather than a negotiation.
- Provider failover across eighty-plus providers, which removes a genuine single point of failure for a small integration cost.
- Nothing to operate: no proxy in your infrastructure, no on-call, no upgrade path.
- Custom data policies let you exclude providers whose terms you have not accepted, which is what makes it viable in a regulated setting.
Cons
- Proprietary and hosted only. There is no self-hosted build, so it cannot satisfy a requirement that the gateway run inside your network.
- Not a governance platform. Per-team budgets, virtual keys, and organisation-wide spend attribution are what a self-hosted gateway provides and this does not.
- The 5.5% credit fee is proportional to spend, so it grows with you while a self-hosted proxy's cost does not.
- Buying tokens through an intermediary is a procurement question for some organisations, and bring-your-own-keys only partly answers it.
- An extra network hop, which needs measuring on a latency-critical path.