litellm - 💡(How to fix) Fix [Feature]: Scope proxy_cli.py Click envvars under the LITELLM_* prefix used elsewhere in the codebase

Check for existing issues

• I have searched the existing issues and checked that my issue is not a duplicate.

The Feature

Rename the ten unprefixed Click envvar= arguments in litellm/proxy/proxy_cli.py to use the LITELLM_* prefix that the rest of the codebase uses. Keep the existing unprefixed names working as a non-breaking fallback via Click's list-of-envvars feature, and optionally emit a deprecation warning when an unprefixed name is the one that resolved.

Concretely, for --host:

-    "--host", default="0.0.0.0", help="Host for the server to listen on.", envvar="HOST"
+    "--host", default="0.0.0.0", help="Host for the server to listen on.",
+    envvar=["LITELLM_HOST", "HOST"]

Same shape for the other nine options listed below. Click resolves the first matched env var, so LITELLM_HOST takes precedence while HOST remains a working fallback for any existing deployment relying on it.

Version

Observed in litellm v1.83.14, file litellm/proxy/proxy_cli.py.

Motivation, pitch

LiteLLM already has a de-facto LITELLM_* env-var naming convention. A grep across litellm 1.83.14 finds ~130 distinct LITELLM_* env vars read by the package (LITELLM_MASTER_KEY, LITELLM_LOG, LITELLM_API_BASE, LITELLM_CORS_ORIGINS, LITELLM_MODE, LITELLM_ASYNCIO_QUEUE_MAXSIZE, and so on). That's clearly the convention for new functionality.

proxy_cli.py is the outlier. Every envvar= declared on a Click option in that file uses an unprefixed name:

DEBUG is the most likely to collide silently — half the Python and Node ecosystem reads it for their own log-verbosity switches. HOST and PORT are also widely touched by webserver-adjacent tooling. The current naming makes these CLI flags difficult to configure cleanly via env in any environment that hosts more than one service (12-factor deployments, direnv-managed dev workstations, multi-process orchestration).

The problem this solves for me: I deploy litellm-proxy as a local OpenAI-compatible router on a developer machine in front of other model servers. I want to set --host 127.0.0.1 as a project-wide default via the envvar= path rather than relying on every operator remembering the CLI flag — but exporting HOST=127.0.0.1 repo-wide is unsafe because HOST is touched by enough other tooling that an unrelated process can end up surprised by it.

Currently working around this with a small wrapper script that scopes HOST to the LiteLLM subprocess, but it seems to me worth filing as a ticket because it looks like an inconsistency. A LITELLM_HOST=127.0.0.1 alias would let me put the value in a LITELLM_*-scoped env source and be done.

Why this is non-breaking: Click's envvar argument accepts a list; the first matched wins. Adding LITELLM_HOST ahead of HOST in the list means existing deployments that rely on HOST keep working unchanged. If we wanted to add a deprecation warning that would require more work. Happy to build a patch for it but I figure the non-intrusive option is more likely to land

Related: Why do I want to set HOST? The proxy defaults to --host 0.0.0.0, which is the right call for container/server deployment but kinda dangerous on direct-host deployments where the proxy ends up reachable on the LAN. Out of scope for this issue; happy to file separately if useful.

What part of LiteLLM is this about?

SDK (litellm Python package)

LiteLLM is hiring a founding backend engineer, are you interested in joining us and shipping to all our users?

No

Twitter / LinkedIn details

https://www.linkedin.com/in/danmackinlay/