Skip to content

Architecture and migrationComparison

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

They are often compared because both give you one OpenAI-compatible endpoint for many models. They are almost opposites. OpenRouter is a hosted service that sells model access; LiteLLM is software you run on your own keys. Here is how to choose, and when neither is the right fit.

By INFRO Editorial

Published

5 min read

Two glass structures on a dark ground, one a single large hosted hub and one a compact self-contained node, both with amber lines fanning out to many providers

In short

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.
On this page
  1. The comparison
  2. How OpenRouter routes your request
  3. What running LiteLLM involves
  4. Which to choose
  5. When neither fits
  6. Summary

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 keys1. 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 tracking23. Choose OpenRouter for the broadest catalog with nothing to operate; choose LiteLLM to keep keys and traffic inside your infrastructure.

The comparison

OpenRouterLiteLLM
What it isHosted router and model accessPython SDK and self-hosted proxy
Who runs itOpenRouterYou
Provider accountsOpenRouter's, or yours (BYOK)Yours
CatalogHundreds of models100+ providers you connect
Default routingLoad-balanced across providers, weighted by inverse square of price; fallbacks onYour configured model groups, fallbacks and load balancing
BYOK cost5% of the equivalent OpenRouter cost after a monthly allowanceNo fee; you pay for infrastructure
When your key failsFalls back to shared capacity by default; per-key setting turns it offYour configured fallbacks, on your keys
BudgetsWorkspace and guardrail budgets; BYOK counted only if switched onPer virtual key, team, user and tag
Data controlsdata_collection: "deny", zdr routing optionsYour deployment, your network
Operating burdenNonePostgres, scaling, upgrades, security
Ownership newsStripe announced on 19 Aug 2026 that it agreed to acquire OpenRouterOpen source; commercial license for some features
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 unavailable4.

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 endpoints4. 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 enabled5. 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 OpenRouter6; 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 guide2. Some organization features sit under LiteLLM's commercial license3.

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 affected7. The lesson applies to any self-hosted gateway: pin by hash, isolate the proxy, and scope the keys it holds. LiteLLM alternatives 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 readers ask

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.

From the team that builds it

Where this shows up in INFRO

INFRO is a control plane in front of the provider accounts you already hold. The capabilities below are the parts of it this article touches, each with the documentation that defines its behaviour.

INFRO accounts are self-serve. Provider usage is billed to you by your providers; INFRO charges a software subscription and takes 0% of model spend. See plans.

Sources

Numbered in order of first citation. Each was opened and checked against the claim on the date shown.

  1. 1.Quickstart (opens in a new tab) — OpenRouter. Accessed Oct 20, 2026.
  2. 2.LiteLLM AI Gateway (proxy server) (opens in a new tab) — LiteLLM. Accessed Oct 20, 2026.
  3. 3.BerriAI/litellm (opens in a new tab) — GitHub. Accessed Oct 20, 2026.
  4. 4.Provider selection (opens in a new tab) — OpenRouter. Accessed Oct 20, 2026.
  5. 5.BYOK (opens in a new tab) — OpenRouter. Accessed Oct 20, 2026.
  6. 6.Stripe agrees to acquire OpenRouter (opens in a new tab) — Stripe. Accessed Oct 20, 2026.
  7. 7.Security Update: Suspected Supply Chain Incident (opens in a new tab) — LiteLLM. Accessed Oct 19, 2026.

About this article

Every statement comes from OpenRouter's and LiteLLM's own documentation and repositories, opened on 2026-10-20, and is limited to what those pages say. No benchmark was run and no price beyond the vendors' own published BYOK terms is quoted. Written by the team that builds INFRO, which competes with both; it appears only in its own section.

Last checked against its sources on . The next review is due by . No separate named reviewer is recorded for this article.

How articles are written, sourced and corrected is set out in the editorial standards.

Read next