File the two together and you'd think you were choosing between competitors. Both lead with the same sentence: one OpenAI-compatible API for every model. Both list a wall of provider logos. Both talk about routing and fallbacks. The search query that brought you here — "openrouter vs litellm" — assumes they sit on a shelf next to each other and you pick one.

They aren't on the same shelf. They're barely in the same store.

One is a marketplace, the other is plumbing

OpenRouter is a hosted aggregator. You send requests to https://openrouter.ai/api/v1, exactly the way you'd call OpenAI, and it fans out behind the scenes to 400+ models across 70+ providers. One account, one key, one invoice. It does provider failover automatically — if the provider serving a model 5xxes or rate-limits you, it falls through to another provider serving the same model, and it doesn't bill you for the run that didn't complete. The money model is clean: it passes through provider token pricing without a markup, then takes a fee on credit purchases (around 5.5%), or a small per-request fee on bring-your-own-key traffic after a free monthly allowance. You are buying from someone.

LiteLLM is something you run. It's an open-source Python SDK and a self-hostable proxy — the BerriAI repo sits north of 50k GitHub stars — that gives you one OpenAI-format interface to 100+ providers using your keys. It has its own router (retries, fallbacks, load balancing), but the reason teams actually stand it up is the control plane: virtual keys scoped per team or app, budgets and rate limits on those keys, caching, and logging piped to Langfuse or MLflow or wherever you already look. You are operating something.

That's the whole distinction, and it's not a feature-count distinction. It's a where does the thing live distinction.

OpenRouter answers "I want one account and one bill for every model." LiteLLM answers "I want budgets, keys, and audit logs over the provider accounts I already have." Those are different questions, and most stacks have both.

Where the control plane lives is the actual decision

Stop counting models. OpenRouter lists more, LiteLLM reaches plenty, and the number was never the constraint. The two real questions are: where does your control plane live, and who owns the billing relationship.

If you want to not think about either — no provider contracts, no proxy to deploy, no Postgres to back the key store — OpenRouter is the short path. You hand over the billing relationship and the routing, you get a single endpoint, and you ship. The cost is that the control plane is theirs. Your spend caps, your key rotation, your fallback policy, your activity log: all of it lives in their dashboard, on their terms. For a solo build or an early prototype, that's a feature, not a compromise.

If you have providers you already pay — an Azure commit, a Bedrock account, a direct Anthropic key — and you need to put governance over your own accounts, that's LiteLLM. You're not buying access; you already have access. What you're missing is a layer that says this team's key has a $200/month ceiling, that app routes to a cheaper model on overflow, and every call lands in our logs. That layer is the product. OpenRouter can't give it to you over your own provider contracts, because the contracts aren't with OpenRouter.

The stack that's actually common: both

Here's the part the comparison framing hides. LiteLLM treats OpenRouter as just another upstream provider. You add a line to the proxy's model list — model: openrouter/<some-model>, api_base: https://openrouter.ai/api/v1, your OpenRouter key — and now OpenRouter's whole catalog sits underneath LiteLLM's governance. People wire this up to give Claude Code or an internal agent access to models OpenRouter aggregates, while keeping LiteLLM's virtual keys and spend tracking out front.

That setup tells you exactly what each tool is for. OpenRouter becomes the breadth-and-billing layer: one account that reaches the long tail of models without you signing seventy contracts. LiteLLM stays the control plane: your apps point at your proxy, your keys and budgets and logs live with you, and OpenRouter is simply one of the providers being governed — sitting next to your direct Anthropic and Bedrock keys, not replacing them.

You lose nothing by combining them because they were never solving the same problem. OpenRouter abstracts accounts. LiteLLM abstracts control. Run one inside the other and each does the job it's good at.

How to actually choose

Ask where you want the control plane to live, and whose name is on the billing relationship.

The "vs" was a category error. One's a place you buy models; the other's a thing you run to keep models in line. The honest decision isn't which wins — it's which problem you have, and the answer is frequently "yes, both." For the adjacent fight among self-hosted gateways, see LiteLLM vs Portkey vs TensorZero; for routing models by cost and quality, RouteLLM vs NotDiamond vs Martian.