LiteLLM is a free, MIT-licensed proxy you run yourself, giving one OpenAI-format API in front of 140+ model providers, with virtual keys, budgets, spend logging and an admin UI. Pick it when you want a single gateway you fully control, not a hosted one. Enterprise adds SSO, RBAC and support on request; the core gateway costs only the machine it runs on.
Other good fits
Setting spend limits and scoped virtual keys per project or per person against a shared pool of provider credentials.
+ Pros
Read pros
LiteLLM gives you a unified, OpenAI-format API in front of 140+ model providers and 1,800+ models, so your application code stays the same while you switch providers or models behind it. The proxy (a self-hosted gateway you run) adds virtual keys, per-key budgets, spend logging and an admin UI on top of that unified interface, letting you hand out scoped access instead of sharing one raw provider key.
Pick it when…
You want one API format across many providers, but need to run and control the gateway yourself rather than use someone else's hosted router.
You want to hand different teams or projects their own virtual key with its own spend budget, drawn from a shared pool of provider credentials.
You need spend logging and an admin view across every provider your application calls.
− Cons
Read cons
A common request format can't make every provider's features, model names, regions, quotas or error behaviour identical; expect to handle provider-specific quirks in your own code. Fallback and routing behaviour between providers needs its own explicit testing before you rely on it for anything user-facing. This review didn't assess any particular deployment's credential storage, retention, access controls or compliance posture; that's your responsibility to set up.
Pick something else when…
You'd rather not run the gateway yourself.OpenRouter is a hosted multi-provider router with no server for you to operate.
You only use one provider. Calling that provider's own SDK directly skips the extra layer.
You want application-level chains and broad integrations, not just a routing boundary.LangChain operates at that layer instead.
Avoid if
You only ever call one provider; a direct SDK call skips the extra layer entirely.
Workflow
Choose your approved providers and models → keep credentials outside source control → expose only the model names you want callers to see → issue a scoped virtual key → send a test request through the gateway → check usage and any provider-specific errors in the admin UI. The gateway doesn't remove your responsibility for each provider's own contract and data terms.
Cost
The core gateway is free and MIT-licensed; you pay only for the machine that runs it, plus whatever your configured providers charge per token. LiteLLM Enterprise adds SSO, RBAC, audit logs and vendor support, priced on request: check with LiteLLM directly for a quote before assuming a cost. Running effort includes protecting the master key (it grants full management access) and being careful with the salt key, since the docs warn that changing it affects stored credentials.
Restrictions
The quickstart requires a master key and a salt key for the gateway. The master key authorizes management access to the whole deployment, and the docs warn that changing the salt key affects already-stored credentials, so treat both as sensitive and plan key rotation carefully.
First project
Documentation-based suggestion — not run here.
Route one request through a single configured model.
Deploy the LiteLLM proxy with Docker, using the documented quick start, and set the required master key and salt key.
Configure one provider and one model name behind it.
Issue a scoped virtual key with a small budget.
Send a test classification prompt through that key and check the returned model identifier and usage fields in the response.
Done when the request succeeds through the gateway and the admin UI's spend log shows exactly that one request.
Links & evidence
Documentation-based · not hands-on · Sep 23, 2026
Rests on LiteLLM's documentation (getting started, proxy quick start, routing) and its product site, checked 23 September 2026. No proxy was deployed and no request was routed for this review.
LiteLLM getting started · Sep 23, 2026 — Unified OpenAI-format interface across providers.
LiteLLM proxy quickstart · Sep 23, 2026 — Docker deployment, master key and salt key requirements.
LiteLLM routing and load balancing · Sep 23, 2026 — Fallback and routing behaviour between providers.
LiteLLM site · Sep 23, 2026 — MIT license, 140+ providers/1,800+ models, Enterprise plan (SSO, RBAC, audit logs, request pricing).
Further review notes & alternatives
Alternatives and trade-offs
OpenRouter wins when you want multi-provider routing without running any infrastructure yourself.
LangChain wins when the need is application-level composition and integrations, not a routing gateway.
A provider's own SDK wins when you only ever call one provider and don't need a unified interface.
Give applications one interface across many model providers.
Route requests and track spending through a proxy.
Add guardrails and an admin UI to self-hosted deployments.
free-tier · cloud · self-host
llm gateway
openai-compatible proxy
spend tracking
routing
guardrails
write-code
open-source
View sourced imageAPI-key management screenshot from the official LiteLLM UI guide. Secret-key cells are blank in the original; appearance reflects the documented version.
LiteLLM documentation — Admin UI
Owner-approved use of public official interface screenshots, as recorded in public-visuals-batch-1.json, 13 September 2026. Copyright retained by BerriAI and LiteLLM contributors; attribution retained. Editorial product illustration; no open licence asserted.
