LiteLLM CLI Cheatsheet - Unified LLM Gateway & Proxy Server
The moment one application must talk to OpenAI, Anthropic, Gemini and a couple of self-hosted endpoints, the code is not what breaks - the cross-cutting concerns do: scattered credentials, retry and rate-limit policy, cost attribution, and graceful degradation when one vendor degrades. LiteLLM collapses all four into a single proxy process so the application only ever sees one OpenAI-compatible endpoint and switching vendors is a base_url change. The rule for whether to adopt it is vendor count: with exactly one provider the official SDK is one less moving part; as soon as you need failover or budget-based routing, the cost visibility the proxy provides pays for itself. This sheet covers installation, the one-line CLI proxy, config.yaml-driven production setup, routing and operations. What matters most is learning how routing and budgets are declared, and then running the built-in connectivity check after every config edit instead of discovering a dead backend in production.
Install 5
uv tool install 'litellm[proxy]'pip install "litellm[proxy]"litellm --versionlitellm --helppython -c "import litellm; print(litellm.__version__)"Start Proxy (one-liner) 5
litellm --model gpt-3.5-turbolitellm --model anthropic/claude-...litellm --model ollama/ litellm --model bedrock/anthropic.claude-v2litellm --model vllm/<model>Config-driven (prod) 5
litellm --config config.yamllitellm --config config.yaml --detailed_debuglitellm --testlitellm --test <model>export OPENAI_API_KEY=...Routing & Ops 5
openai_api_base=http://0.0.0.0:4000curl http://0.0.0.0:4000/v1/modelslitellm --model <provider>/ --api_base <url>litellm --drop_paramslitellm --telemetry FalseTips 5
One-liner suits local validationUse --config in prod, not one-linersprovider/ prefix is the key--test after config changesProxy unifies the OpenAI protocolTips
- LiteLLM uses the
provider/prefix to route 100+ models to one OpenAI-compatible interface — the de-facto gateway for multi-provider fallback, cost, and rate-limiting. - For quick local validation use a one-liner
litellm --model <provider/model>; in production always use--config config.yamlto centralize keys, routing, and budgets. - The proxy listens on :4000 by default; legacy OpenAI clients switch providers by just changing
base_url— near-zero migration cost. - After config changes, run
litellm --testto self-check connectivity before shipping.
FAQ
What is the difference between the one-liner and a config file?
The one-liner litellm --model gpt-3.5-turbo is ideal for local verification — a proxy is up in seconds and you can try different providers quickly. Production should use --config config.yaml, centralizing model lists, keys, routing and budgets in a file that can be version controlled and permission restricted, and which keeps secrets out of your shell history.
What role do provider prefixes play in LiteLLM?
They route the request: openai/ to OpenAI, anthropic/ to Claude, ollama/ to a local Ollama, bedrock/ to AWS Bedrock, vllm/ to a local vLLM. With these prefixes, switching backends means changing only the model name rather than the client code. The proxy exposes the OpenAI protocol externally, so existing clients just need a different base_url.
How do I confirm connectivity after changing config?
Run litellm --test, which issues a test request against the current configuration and reports the result; litellm --test <model> checks one specific model. Once the proxy is up, curl http://0.0.0.0:4000/v1/models confirms the exposed model list is what you expect. Add --detailed_debug for verbose logs while troubleshooting.
What if the backend rejects an unsupported parameter?
Add --drop_params, which discards parameters the backend does not understand to improve compatibility. It lets a newer SDK work against an older provider without code changes. The trade-off is that the dropped parameter has no effect — if it mattered to your logic, switch to a backend that supports it rather than silently discarding it.
How do I disable telemetry in LiteLLM?
Use litellm --telemetry False. Telemetry reports usage upstream, so it should be disabled in privacy-sensitive or offline environments; it also makes outbound requests, which slows startup or fails outright on an air-gapped network. Production deployments normally declare this alongside logging settings in the config file.
Official References
Each command links to its official documentation below, so you can verify the latest usage and read deeper.
Maintained by LaoHand
Publicly updated on Aug 23, 2026, continuously proofread against official docs.
Contact Us
Wrong command or description? Send us corrections, business inquiries or product feedback by email.
Contact Us