AI providers 2026-10-23 · updated 2026-10-23 · Dracon Research Team

OpenRouter vs LiteLLM: hosted gateway or self-hosted proxy

They are not substitutes

Almost every search for this pair frames it as a choice: OpenRouter or LiteLLM, pick one. That framing is wrong, and it is wrong in a way that costs money. They solve the same job from opposite directions. LiteLLM is software you install and run; OpenRouter is a hosted service you call. One is a component you operate, the other is a vendor you pay. The useful question is not which is better but what you are actually buying: a gateway you rent, or a gateway you own.

What each one is, side by side

LiteLLM and OpenRouter compared on the eight dimensions that decide the choice: what each one is, where it runs, who holds the keys, what it costs, how the bill arrives, what the free tier is, who writes the routing rules, and what data leaves your infrastructure. LiteLLM facts from the project documentation read on 2026-10-23 and from our own comparison page; OpenRouter facts from our provider catalog entry.
Dimension	LiteLLM	OpenRouter
What it is	A free, MIT-licensed proxy that you run yourself	A hosted gateway that meters your use in credits
Where you run it	Wherever you put it: a laptop, a VPS, a container	On their servers, so there is no process for you to run
Who holds the keys	You do, in your own environment variables, on your own machine	Optional: bring your own provider keys, or draw on the shared pool
What it costs	Nothing for the software. You pay each provider its own list price for tokens	Provider list price plus a spread on top-ups, billed in credits
How the bill arrives	One line per provider, in that provider's own currency	One credit balance, across models and providers
The free tier	Whatever free tier the provider you call publishes, under your control	50 requests a day on the base free tier; $10 in pay-as-you-go credits unlocks 1,000 requests a day of free models
Who writes the routing rules	You do: retries, fallbacks and load balancing in a config file you own	The gateway's own routing, plus published uptime stats
What leaves your infrastructure	Only the calls you send to each provider	Your prompts transit their servers

Read the free-tier row carefully, because it is the one that most often gets misquoted. OpenRouter's base free tier is 50 requests a day. Adding $10 in pay-as-you-go credits lifts that to 1,000 requests a day of free models, and the free model pool rotates. LiteLLM has no free tier of its own, because it is not a service: it inherits whatever the provider you call publishes, and it inherits the decision as well, because you choose which provider sits behind the route.

The cost difference is not the software

Both routes end up paying the provider's list price for tokens. The software cost of LiteLLM is zero, and the marginal cost of OpenRouter's software is also effectively zero, because it is folded into the spread. The real difference is what happens above the token. With OpenRouter, per model, you pay the provider list price plus a spread on top-ups, and the whole thing is drawn against one credit balance. Credits never convert to a flat rate, so your cost scales with use forever. With LiteLLM, you pay the provider directly, in the provider's currency, on the provider's invoice, at the provider's list price. For light use the difference is a rounding error. At sustained volume it compounds, and the compounding is entirely in the layer you chose not to run yourself.

What LiteLLM costs you when you get it wrong

Self-hosting is not free in the only currency that matters when something breaks at 2am. A LiteLLM deployment is a process that has to be running, on a machine you pay for, with a config you maintain. The historical friction was config authoring: model_list entries, api_base URLs, environment variable wiring, and the assumption that all of it stays in step as providers change their base URLs. That friction is why people end up back on a hosted gateway. The other failure mode is quieter: a routing layer that nobody owns quietly routes your production traffic to a fallback provider nobody checked the price of. Self-hosting moves trust from a vendor's infrastructure to your own, and that is a trade you should make deliberately rather than by default.

How to pick

Pick OpenRouter when you want a working gateway today, you have no process you want to own, and one credit balance is worth more to you than provider-direct pricing. It is the right default for prototypes and for teams who have decided not to run infrastructure.
Pick LiteLLM when the routing layer is load-bearing: you need provider-direct pricing at volume, your prompts should not transit a third party's servers, or you need fallback rules that are yours to change without asking anyone.
Pick both, deliberately. Point a self-hosted LiteLLM at OpenRouter and you get the hosted catalogue with your own routing rules on top. This is the arrangement most teams reach for first, because it lets them learn the routing behaviour before they own the whole stack.
Check the unit economics against the provider list, not against each other. Both roads end at the same token price, so the question is only what the layer between you and that price costs in spread, in egress of your prompts, and in operational attention.

If you do self-host the routing layer, the configuration step is the part worth automating. Our router builder turns a provider list into LiteLLM YAML: order your providers, export the config, run `litellm --config litellm.config.yaml`. The exported config references environment variables for the keys, so the secrets stay on your machine rather than inside the config. Each provider in the chain has a setup guide in the AI Hub if you need the key first, and the full comparison with the config walkthrough sits next to this article. If you want a second opinion on a specific routing setup, ask the assistant.