Decision comparison
LiteLLM vs OpenRouter
The choice is not really between two gateways; it is between running one and buying one, and the answer follows from whether you have a platform team. OpenRouter is the cheapest way to keep your model choice open: one key, published prices, failover across eighty-plus providers, no markup on tokens and nothing to operate. LiteLLM is the answer when the questions are governance ones — who holds which key, whose budget stopped, which team spent the money — and when the model contracts or the gateway itself must stay inside your organisation. The crossover is organisational rather than a token volume: it arrives when somebody would be running the proxy anyway.
Direct comparison. These are reviewed substitutes bought for the same job, so the differences below are the ones that decide between them.
All 2 are LLM gateways.
Quick Comparison
| Decision factor | LiteLLM | OpenRouter |
|---|---|---|
| Best for | Platform teams with more than one model provider and more than one team calling them. LiteLLM is bought by the people who have to answer who is spending what on which model, not by the developer writing the prompt, and its feature list reflects that: most of it is governance rather than translation. NVIDIA, Netflix, Okta, Lemonade and AT&T all appear as named customers on the vendor's own site. | Teams that want optionality across models with nothing to operate, and application developers who want to ship against one interface and change their mind later. It is a URL and a key rather than infrastructure, which makes the cost of keeping your options open effectively zero until you use them. |
| Who operates it | You do. The SDK is a Python library, but the product is the proxy — a server you deploy on your own Postgres and Redis, scaling out with Kubernetes, in your own cloud or fully air-gapped. Teams that install only the SDK and conclude LiteLLM is a thin translation layer have seen half of it. | OpenRouter does. There is no self-hosted build, so a requirement that the gateway run inside your network rules it out entirely — that is a hard boundary rather than a configuration question. |
| What it costs | Free to self-host: everything outside the repository's enterprise/ directory is MIT-licensed, and the free build carries 140+ provider integrations, virtual keys, budgets and teams, load balancing, RPM and TPM limits, guardrails and logging to Langfuse, Arize Phoenix, LangSmith and OTEL. LiteLLM Enterprise is quoted per deployment with a 30-day trial. The gateway takes no cut of tokens. | No subscription and no markup on inference: models are billed at each provider's published list price per million tokens. OpenRouter earns on credit purchases instead, at 5.5% with a $0.80 minimum through Stripe or 5% in cryptocurrency. Bringing your own provider keys is free up to $25,000 of monthly usage on pay-as-you-go, or $200,000 on the enterprise tier, and 5% above that. |
| Governance and spend control | This is the substance of the product. Virtual keys issue per-team credentials mapped onto your real provider keys, so revoking an internal key does not mean rotating a provider secret. Budgets cap spend before it runs rather than reporting it afterwards. Spend is attributed by key, user, team and organisation. Audit logs, SSO with SCIM, OIDC and JWT auth and RBAC are enterprise-tier. | Thinner, and this is the honest gap. Its published account model is one organisation with API keys and prepaid credits, so spend is bounded by the balance rather than by a per-team budget that stops a request before it runs, and we find no documented per-team virtual keys with RPM and TPM limits. What it does have is custom data policies, which restrict which providers may receive a prompt — the feature that decides whether it is usable in a regulated setting at all — plus activity logs and export. |
| Provider relationship | Stays yours. You keep paying each model vendor directly at your own negotiated rates, and LiteLLM never sits in the commercial path. That also keeps the exit cheap: removing the gateway does not mean renegotiating anything. | Intermediated by default. You buy tokens through OpenRouter rather than from the vendors, which is a procurement question for some organisations. Bring-your-own-keys answers part of it by letting you pay a provider directly under your own contract while still routing through the service. |
| Failure mode to plan for | It is a service in your request path. A single-region deployment in front of a critical feature is a new availability dependency, which is precisely why the enterprise tier sells a multi-region control plane. Plan for on-call before you plan for the feature list. | An extra network hop you do not control, and a fee that scales with spend rather than staying flat. Measure the hop on a latency-critical path, and model the 5.5% against what running a proxy would cost you in infrastructure and on-call. |
LiteLLM
- Best for:
- Platform teams with more than one model provider and more than one team calling them. LiteLLM is bought by the people who have to answer who is spending what on which model, not by the developer writing the prompt, and its feature list reflects that: most of it is governance rather than translation. NVIDIA, Netflix, Okta, Lemonade and AT&T all appear as named customers on the vendor's own site.
- Who operates it:
- You do. The SDK is a Python library, but the product is the proxy — a server you deploy on your own Postgres and Redis, scaling out with Kubernetes, in your own cloud or fully air-gapped. Teams that install only the SDK and conclude LiteLLM is a thin translation layer have seen half of it.
- What it costs:
- Free to self-host: everything outside the repository's enterprise/ directory is MIT-licensed, and the free build carries 140+ provider integrations, virtual keys, budgets and teams, load balancing, RPM and TPM limits, guardrails and logging to Langfuse, Arize Phoenix, LangSmith and OTEL. LiteLLM Enterprise is quoted per deployment with a 30-day trial. The gateway takes no cut of tokens.
- Governance and spend control:
- This is the substance of the product. Virtual keys issue per-team credentials mapped onto your real provider keys, so revoking an internal key does not mean rotating a provider secret. Budgets cap spend before it runs rather than reporting it afterwards. Spend is attributed by key, user, team and organisation. Audit logs, SSO with SCIM, OIDC and JWT auth and RBAC are enterprise-tier.
- Provider relationship:
- Stays yours. You keep paying each model vendor directly at your own negotiated rates, and LiteLLM never sits in the commercial path. That also keeps the exit cheap: removing the gateway does not mean renegotiating anything.
- Failure mode to plan for:
- It is a service in your request path. A single-region deployment in front of a critical feature is a new availability dependency, which is precisely why the enterprise tier sells a multi-region control plane. Plan for on-call before you plan for the feature list.
OpenRouter
- Best for:
- Teams that want optionality across models with nothing to operate, and application developers who want to ship against one interface and change their mind later. It is a URL and a key rather than infrastructure, which makes the cost of keeping your options open effectively zero until you use them.
- Who operates it:
- OpenRouter does. There is no self-hosted build, so a requirement that the gateway run inside your network rules it out entirely — that is a hard boundary rather than a configuration question.
- What it costs:
- No subscription and no markup on inference: models are billed at each provider's published list price per million tokens. OpenRouter earns on credit purchases instead, at 5.5% with a $0.80 minimum through Stripe or 5% in cryptocurrency. Bringing your own provider keys is free up to $25,000 of monthly usage on pay-as-you-go, or $200,000 on the enterprise tier, and 5% above that.
- Governance and spend control:
- Thinner, and this is the honest gap. Its published account model is one organisation with API keys and prepaid credits, so spend is bounded by the balance rather than by a per-team budget that stops a request before it runs, and we find no documented per-team virtual keys with RPM and TPM limits. What it does have is custom data policies, which restrict which providers may receive a prompt — the feature that decides whether it is usable in a regulated setting at all — plus activity logs and export.
- Provider relationship:
- Intermediated by default. You buy tokens through OpenRouter rather than from the vendors, which is a procurement question for some organisations. Bring-your-own-keys answers part of it by letting you pay a provider directly under your own contract while still routing through the service.
- Failure mode to plan for:
- An extra network hop you do not control, and a fee that scales with spend rather than staying flat. Measure the hop on a latency-critical path, and model the 5.5% against what running a proxy would cost you in infrastructure and on-call.
Public signals
Verified factual signals only. Bars appear only for like-for-like metrics with five weekly assessments for every tool; missing evidence stays explicit. These signals do not establish enterprise adoption, product quality, or total cost.
| Metric | LiteLLM | OpenRouter |
|---|---|---|
| GitHub commits, 90d(Product adoption) | 12.0k | Not available |
| GitHub stars(Product adoption) | 59,000+ | Not available |
| Product Hunt comments(Community interest) | 12 | Not available |
| Product Hunt rating(Community interest) | 5.0/5 | Not available |
| Product Hunt reviews(Community interest) | 24 | Not available |
| Product Hunt votes(Community interest) | 120 | Not available |
| PyPI weekly downloads(Product adoption) | 22.4M | Not available |
| npm weekly downloads(Developer adoption) | Not available | 2.2M |
| PyPI weekly downloads(Developer adoption) | Not available | 361.1k |
As of September 21, 2026 — updated weekly.
Health & risk evidence
Observed public-source checks for mapped package versions and repositories.
LiteLLM
September 21, 2026Package vulnerabilities
PyPI · litellm@1.102.0
0 vulnerabilities
across 1 package
Repository security score
Not available
OpenRouter
September 21, 2026Package vulnerabilities
npm · @openrouter/ai-sdk-provider@3.1.0 · PyPI · openrouter@1.2.10
0 vulnerabilities
across 2 packages
Repository security score
Not available
Feature Comparison
| Feature | LiteLLM | OpenRouter |
|---|---|---|
| Deployment and control | ||
| Self-hosted deployment | Yes — the proxy runs on your own Postgres and Redis, in your cloud or fully air-gapped | Not available; hosted service only |
| Hosted option | Not offered by the vendor as a public service; you run it | The entire product |
| Licence | MIT outside the repository's enterprise/ directory, which is separately licensed | Proprietary; no public repository that is the product |
| Sits in the request path | Yes, inside your network — an availability dependency you operate | Yes, as a third party — an availability dependency you do not |
| Routing | ||
| Providers reachable | 100+ providers through one OpenAI-shaped API, native formats available | Several hundred models across eighty-plus providers |
| Failover between providers | Load balancing across providers, regions and keys | Automatic fallback when a provider is degraded or down |
| Routing policy | Load balancing across providers, regions and keys; routing by published rate; and auto-routing that matches a prompt to a model by rules you set | Published per-model price and latency, so the routing decision is made with the table in front of you |
| MCP tool servers | Acts as an MCP gateway, extending the same key and policy model to tool servers | Not described in its gateway documentation |
| Governance | ||
| Per-team virtual keys | Yes, in the free build — mapped onto your real provider keys | Its published account model is one organisation with API keys; no per-team virtual key is documented |
| Budgets that cap spend | Yes, in the free build — capped before the request runs | Credits are prepaid, so spend is bounded by the balance rather than by a per-team budget |
| Rate limits per key | RPM and TPM limits per key, in the free build | 50 requests/day on the free tier; no per-team limits |
| Spend attribution | By key, user, team and organisation | Activity logs and export |
| SSO, SCIM and RBAC | Enterprise tier | Enterprise tier |
| Data residency controls | Absolute — the gateway runs where you put it, including air-gapped | Custom data policies restrict which providers may receive a prompt |
| Commercial shape | ||
| Cut of token spend | None — you pay providers directly | None on inference; 5.5% on Stripe credit purchases, 5% in cryptocurrency |
| Cost as you grow | Flat: infrastructure and on-call, which do not scale with token spend | Proportional: the credit fee grows with what you spend |
| Observability | Logs outward to Langfuse, Arize Phoenix, LangSmith or plain OpenTelemetry | Activity logs and export within the service |
Deployment and control
Self-hosted deployment
Hosted option
Licence
Sits in the request path
Routing
Providers reachable
Failover between providers
Routing policy
MCP tool servers
Governance
Per-team virtual keys
Budgets that cap spend
Rate limits per key
Spend attribution
SSO, SCIM and RBAC
Data residency controls
Commercial shape
Cut of token spend
Cost as you grow
Observability
Which to choose
The choice is not really between two gateways; it is between running one and buying one, and the answer follows from whether you have a platform team. OpenRouter is the cheapest way to keep your model choice open: one key, published prices, failover across eighty-plus providers, no markup on tokens and nothing to operate. LiteLLM is the answer when the questions are governance ones — who holds which key, whose budget stopped, which team spent the money — and when the model contracts or the gateway itself must stay inside your organisation. The crossover is organisational rather than a token volume: it arrives when somebody would be running the proxy anyway.
Best-fit scenarios
Choose LiteLLM if:
Choose LiteLLM when more than one team calls more than one provider and somebody is accountable for the bill. The free self-hosted build carries what most vendors reserve for a paid tier: virtual keys so an internal credential can be revoked without rotating a provider secret, budgets that stop a request before it runs rather than reporting it afterwards, RPM and TPM limits per key, and spend attributed by key, user, team and organisation. It takes no cut of tokens, so your provider rates and negotiating position stay yours, and the cost does not grow as you do. It is also the only option if the gateway must run inside your network or air-gapped. Accept in exchange that you are running a service in your own request path, with the on-call that implies, and that enterprise pricing is not published so SSO, audit logs and support need a sales conversation.
Choose OpenRouter if:
Choose OpenRouter when you want optionality without infrastructure. There is no subscription and no minimum, so keeping the option open costs nothing until you use it; per-model price and latency are published openly, which turns model comparison into reading a table; and failover across eighty-plus providers removes a genuine single point of failure for a consumer product whose main dependency is one vendor's uptime. The fee is 5.5% on Stripe credit purchases with a $0.80 minimum, and bring-your-own-keys is free up to $25,000 of monthly usage if you have negotiated rates to protect. Accept that it is hosted only, that per-team budgets and virtual keys are simply not there, and that the fee grows with your spend while a proxy's cost does not — so model the annual fee against a realistic cost of operating LiteLLM before committing at volume.
These scenarios reflect the available product evidence. Your requirements, existing stack, and team expertise should guide the final decision.
Frequently Asked Questions
Can I use both?
Yes, and some teams do: LiteLLM self-hosted as the internal control point, with OpenRouter configured as one of the upstream providers behind it. That keeps virtual keys, budgets and spend attribution in your own gateway while borrowing OpenRouter's breadth and failover for models you have no direct contract with. You pay the 5.5% credit fee only on what flows that way.
Which is cheaper?
Neither takes a cut of inference, so the difference is the fee against the operating cost. OpenRouter charges 5.5% on Stripe credit purchases, which is proportional to spend. LiteLLM charges nothing and costs you infrastructure plus on-call, which is roughly flat. Below the point where those lines cross, the fee is cheaper than the engineering; above it, the proxy is. The crossover is usually organisational: it arrives when you already have a platform team.
Does either one let me keep my own provider contracts?
LiteLLM always does — it never sits in the commercial path, and you keep paying each vendor at your own rates. OpenRouter does through bring-your-own-keys, free up to $25,000 of monthly usage on pay-as-you-go or $200,000 on the enterprise tier, and 5% above that. The default OpenRouter path buys tokens through the intermediary, which some procurement processes will not accept.
Is either of them an observability tool?
No, and treating one as such is the common mistake. LiteLLM logs outward to Langfuse, Arize Phoenix, LangSmith or plain OpenTelemetry and expects one of those to exist; OpenRouter offers activity logs and export. Prompt-level tracing, evaluation and prompt management are a separate purchase in both cases.
What happens to my application if the gateway goes down?
Both put a hop in the request path, so both are an availability dependency — the difference is who owns it. With LiteLLM the outage is yours to prevent and to fix, which is why the enterprise tier sells a multi-region control plane. With OpenRouter it is the vendor's, and your compensation is that the service itself fails over across providers. Neither removes the risk; they relocate it.