# OpenRouter vs LiteLLM: hosted router or self-hosted gateway?

URL: https://infro.io/blog/openrouter-vs-litellm
Author: INFRO Editorial (https://infro.io/blog/editorial)
Publisher: INFRO
Published: 2026-10-20
Last modified: 2026-10-20
Last reviewed: 2026-10-20 (next review due 2026-11-19)
Topic: Architecture and migration
Format: Comparison

> OpenRouter is a hosted, OpenAI-compatible router to hundreds of models that sells access on its own balance and also accepts your keys; by default it load-balances across providers weighted by price and falls back to other providers and, for BYOK, to its shared capacity. LiteLLM is open-source software you deploy yourself, available as a Python SDK and a self-hosted proxy for more than 100 providers on your own keys, with virtual keys, budgets and spend tracking. Choose OpenRouter for the broadest catalog with nothing to run; choose LiteLLM to keep keys and traffic in your infrastructure.

Key takeaways:
- OpenRouter is a hosted service with its own provider accounts; LiteLLM is software you run with your keys.
- OpenRouter load-balances across providers weighted by price by default, with fallbacks on; set order, only or sort to control it.
- OpenRouter BYOK costs 5% of the equivalent OpenRouter price after a monthly allowance and falls back to shared capacity by default.
- LiteLLM gives virtual keys, budgets and spend tracking by key, team, user and tag, but you operate Postgres, upgrades and security.
- Neither answers spend governance across teams on your own accounts out of the box without configuration or operation; compare that explicitly.

**OpenRouter or LiteLLM?** They solve the same surface problem — one OpenAI-compatible endpoint for many models — in opposite ways. **OpenRouter** is a hosted service: you call `https://openrouter.ai/api/v1`, and it serves hundreds of models through its own provider accounts or your keys[1]. **LiteLLM** is open-source software you run: a Python SDK and a self-hosted proxy for more than 100 providers on your own keys, with virtual keys, budgets and spend tracking[2][3]. Choose OpenRouter for the broadest catalog with nothing to operate; choose LiteLLM to keep keys and traffic inside your infrastructure.

## The comparison

|  | OpenRouter | LiteLLM |
| --- | --- | --- |
| What it is | Hosted router and model access | Python SDK and self-hosted proxy |
| Who runs it | OpenRouter | You |
| Provider accounts | OpenRouter's, or yours (BYOK) | Yours |
| Catalog | Hundreds of models | 100+ providers you connect |
| Default routing | Load-balanced across providers, weighted by inverse square of price; fallbacks on | Your configured model groups, fallbacks and load balancing |
| BYOK cost | 5% of the equivalent OpenRouter cost after a monthly allowance | No fee; you pay for infrastructure |
| When your key fails | Falls back to shared capacity by default; per-key setting turns it off | Your configured fallbacks, on your keys |
| Budgets | Workspace and guardrail budgets; BYOK counted only if switched on | Per virtual key, team, user and tag |
| Data controls | `data_collection: "deny"`, `zdr` routing options | Your deployment, your network |
| Operating burden | None | Postgres, scaling, upgrades, security |
| Ownership news | Stripe announced on 19 Aug 2026 that it agreed to acquire OpenRouter | Open source; commercial license for some features |

Table: From each project's own documentation and announcements, 2026-10-20.

## How OpenRouter routes your request

OpenRouter's defaults favour availability and price. Requests are load-balanced across the top providers for a model "to maximize uptime", and among stable providers, cheaper ones are chosen more often, weighted by the inverse square of the price. `allow_fallbacks` is true by default, so a backup provider is used when the primary is unavailable[4].

You can take control per request: `order` lists providers to try in sequence, `only` and `ignore` restrict the set, `sort` ranks by price, throughput or latency and disables load balancing, `data_collection: "deny"` limits routing to providers that do not collect user data, and `zdr` restricts it to zero-data-retention endpoints[4]. If one specific provider matters to you — for a data agreement or consistent behaviour — set it explicitly; the default will not hold you to one.

### BYOK on OpenRouter

You can bring your own provider keys. The fee is "5% of what the same model/provider would cost normally on OpenRouter", after a monthly allowance measured in list-price inference cost — $25,000 on pay-as-you-go, custom on Enterprise. By default, if your keys are rate limited or fail, OpenRouter falls back to its shared endpoints; a per-key setting, "Never use shared capacity", prevents that. BYOK spend does not count toward guardrail or workspace budgets unless "Include BYOK spend" is enabled[5]. Read those three behaviours together before relying on BYOK for contract or data reasons.

Stripe announced on 19 August 2026 that it has agreed to acquire OpenRouter[6]; consider what that means for your supplier relationships if you route most of your traffic through it.

## What running LiteLLM involves

LiteLLM's proxy gives you one OpenAI-compatible endpoint with virtual keys that carry their own models, budgets and rate limits, spend tracking by key, team, user and tag, load balancing, fallbacks and retries, guardrails, logging to tools such as Langfuse, Datadog and Prometheus, and an admin UI. It is deployed with Docker, Helm or Terraform against a Postgres database, with Redis sizing covered in the production guide[2]. Some organization features sit under LiteLLM's commercial license[3].

The cost of that control is operation. You patch it, scale it, back it up and secure it — including its supply chain. In March 2026, two LiteLLM releases on PyPI were published with credential-stealing code after attackers obtained publishing access through a compromised scanner in LiteLLM's CI; LiteLLM removed them, rotated credentials and shipped a clean release through a rebuilt pipeline, and states that its official Docker image, which pins dependencies, was not affected[7]. The lesson applies to any self-hosted gateway: pin by hash, isolate the proxy, and scope the keys it holds. [LiteLLM alternatives](https://infro.io/blog/litellm-alternatives-2026) covers the controls.

## Which to choose

**Choose OpenRouter when:**

- You want the widest catalog, including models you have no account with, on one balance.
- You do not want to run infrastructure.
- Price-weighted routing across providers suits the workload, and data controls via `data_collection` and `zdr` are enough.

**Choose LiteLLM when:**

- Keys and prompts must stay in your network.
- You already operate services of this kind and have the people to run one more.
- You want routing in-process as a Python library, with no gateway hop.

**Use both** when you want direct provider keys under your own control for most traffic and OpenRouter for long-tail models: LiteLLM can call OpenRouter as one of its providers.

## When neither fits

Both are strong at routing. The question they leave to you is organizational: budgets that refuse before the call for every team on your own accounts, cost estimated at your negotiated rates and checked against the provider's bill, and an audit trail of who changed what. OpenRouter's budgets count BYOK only when you turn that on; LiteLLM gives you the pieces to build it and the job of running them.

INFRO is a hosted BYOK control plane for that case: it runs only on provider accounts you connect, with 0% markup on model spend, budgets at organization, project, member and key level checked before the provider is called, cost estimates at list or negotiated rates, an audit log on every plan, and reconciliation against OpenAI's and Anthropic's cost APIs on the Business plan. It is not a catalog of models you do not hold accounts for, and it is not self-hosted without an enterprise agreement; for those, OpenRouter and LiteLLM respectively are the better answers. A LiteLLM proxy you already run speaks the OpenAI API, so it can also sit behind INFRO as one connection.

## Summary

OpenRouter rents you a router and, by default, its provider capacity. LiteLLM gives you the router to run on your own keys. Pick by who should operate the gateway and whose accounts should carry the traffic, then check the defaults — fallback, routing and budget behaviour — before you trust either with production spend.

## Questions

### What is the difference between OpenRouter and LiteLLM?

OpenRouter is a hosted service: you call its endpoint, and it serves models through its own provider accounts or your keys. LiteLLM is open-source software: you run its Python SDK or proxy yourself, with your own provider keys, and operate it. Both expose an OpenAI-compatible API.

### Is LiteLLM free?

The open-source SDK and proxy are free to use; some organization features sit under a commercial license, and you pay for the infrastructure and engineering time to run the proxy, including its Postgres database.

### Does OpenRouter charge for BYOK?

Yes. OpenRouter's BYOK page says the fee is 5% of what the same model and provider would cost on OpenRouter, deducted from your balance, after a monthly allowance measured in list-price inference cost ($25,000 on pay-as-you-go; custom on Enterprise).

### Can I use OpenRouter and LiteLLM together?

Yes. LiteLLM can call OpenRouter as one of its providers, so a self-hosted LiteLLM proxy can hold your direct provider keys and send long-tail models to OpenRouter.

## Sources

1. Quickstart — OpenRouter. https://openrouter.ai/docs/quickstart (accessed 2026-10-20)
2. LiteLLM AI Gateway (proxy server) — LiteLLM. https://docs.litellm.ai/docs/simple_proxy (accessed 2026-10-20)
3. BerriAI/litellm — GitHub. https://github.com/BerriAI/litellm (accessed 2026-10-20)
4. Provider selection — OpenRouter. https://openrouter.ai/docs/guides/routing/provider-selection (accessed 2026-10-20)
5. BYOK — OpenRouter. https://openrouter.ai/docs/guides/overview/auth/byok (accessed 2026-10-20)
6. Stripe agrees to acquire OpenRouter — Stripe. https://stripe.com/newsroom/news/stripe-agrees-to-acquire-openrouter (accessed 2026-10-20)
7. Security Update: Suspected Supply Chain Incident — LiteLLM. https://docs.litellm.ai/blog/security-update-march-2026 (accessed 2026-10-19)