OpenRouter vs LiteLLM for Agent Model Routing
Teams building agent orgs eventually hit the same fork: OpenRouter (hosted marketplace + one key) or LiteLLM (self-hosted proxy you operate). Both normalize model APIs. They are not interchangeable products.
This comparison is from running both in production — OpenRouter for Cursor and agent routing tables, LiteLLM on a €4/mo Hetzner stack behind n8n. No affiliate links; pricing notes point to public pages only.
Part of the Agent Cost & Model Selection series. Positioning context: Operating Note 002.
One-line distinction
OpenRouter — you buy access to a hosted router and model catalog; ops and provider negotiation are abstracted away.
LiteLLM — you deploy a router you control; provider keys, budgets, and fallbacks live on your infra.
The routing ideas (task classes, promote/demote, failure-priced ROI) are the same either way. The gateway choice is an ops and policy question.
Quick comparison
| Dimension | OpenRouter | LiteLLM |
|---|---|---|
| Deployment | Hosted SaaS | Self-hosted (Docker/K8s) or LiteLLM Cloud |
| Provider keys | OpenRouter account | Your OpenAI, Anthropic, Groq, etc. keys |
| Model catalog | Curated marketplace incl. free tiers | Whatever your keys unlock + community model list |
| Cost visibility | Dashboard per key / model | Per-request logging, budgets, spend limits you configure |
| Time to first route | Minutes (API key + base URL) | Hours (container, env, provider keys, HTTPS) |
| Data residency | Traffic via OpenRouter | Stays on your network if self-hosted |
| Best fit | Solo/small team, IDE routing, fast experiments | n8n/automation stacks, strict budgets, multi-tenant proxy |
| Ops burden | Low | You own uptime, upgrades, key rotation |
Public pricing: OpenRouter passes through model rates plus platform fees; LiteLLM is OSS — you pay your cloud + provider usage.
When to use OpenRouter
Choose OpenRouter when speed and catalog breadth matter more than running your own gateway.
Good signals:
- You route Cursor, Cloud Agents, or small Python agents and want one
https://openrouter.ai/api/v1base URL. - You rely on free or cheap tiers in the marketplace for class A/B tasks (task classes in Note 002).
- You promote/demote models weekly without redeploying infra (automatic model watch).
- Ops headcount for a proxy is zero — you want spend dashboards, not Prometheus rules.
Watch-outs:
- Egress and residency follow OpenRouter’s terms, not yours.
- Vendor lock-in is soft (OpenAI-compatible API) but catalog IDs and pricing are platform-specific.
- Heavy production traffic may be cheaper direct-to-provider — compare your actual mix, do not guess.
My IDE setup documents the pattern: Cut Cursor costs with OpenRouter.
When to use LiteLLM
Choose LiteLLM when you already run agents on your own metal and need a policy layer you own.
Good signals:
- n8n, Temporal, or cron workflows call models from a VPC and must not leak prompts to a third-party router.
- You need hard budgets per workflow, team, or API key — LiteLLM’s spend limits and logging hooks are the point.
- You swap providers (Groq → OpenAI → Anthropic) without touching workflow code — same proxy, different
model=string. - You operate in the ~€35/mo infra band and accept gateway ops as part of the stack (self-hosted stack write-up).
Watch-outs:
- You maintain the container, TLS, and key rotation.
- No built-in “free model marketplace” — free means a provider you configured, not OpenRouter’s catalog.
- Misconfigured fallbacks can mask failures; pair with eval fixtures (eval fixture pack).
Agent-org lens: same routing discipline, different control plane
Neither tool replaces right agent, right model:
- Classify tasks (A cheap → D irreversible) before picking a gateway.
- Separate agent role from model — researcher vs critic may use different routes on the same proxy.
- Price failure — a free OpenRouter model that retries three times loses to a paid LiteLLM route with one clean pass (when cheap models get expensive).
OpenRouter optimizes experiment velocity. LiteLLM optimizes policy enforcement on your turf. Agent orgs often need both capabilities but should standardize on one primary gateway per environment to keep routing tables honest.
Decision shortcut
| Your bottleneck | Start with |
|---|---|
| “I need routing this afternoon in Cursor” | OpenRouter |
| “n8n on Hetzner must call models with caps” | LiteLLM |
| “Compliance: prompts cannot leave EU VPC” | LiteLLM (self-hosted) |
| “I want free tiers without managing keys” | OpenRouter |
| “Multi-team spend limits + audit log” | LiteLLM |
| “Still picking models vs building agents” | Fix task classes first — gateway second |
Can they stack?
Possible but rarely necessary on day one:
- Dev on OpenRouter, prod on LiteLLM — different keys and route tables; document both in your routing table so agents do not drift.
- LiteLLM → OpenRouter as a provider — LiteLLM can proxy to OpenRouter as one backend; adds latency and double billing; use only if policy requires LiteLLM in front.
Default: pick one, encode it in agent skills and CI, measure ROI weekly.
What I run today
- OpenRouter — Cursor, Cloud Agents, content-agent promote/demote loops, Note 002 posture.
- LiteLLM — self-hosted automation stack behind n8n when workflows need provider keys on-box.
Same ROI ledger either way: infra band, model spend per accepted outcome, human cleanup minutes.
If you are sorting gateway choice for an agent org — contact me with your stack (IDE vs n8n vs custom runtime) and where spend or failures hurt most. Start from the cost hub if you need the full series map.