More than 100 providers sit behind one interface
The README lists more than 100 providers behind LiteLLM's common interface. The Python SDK lets an application call them directly. The proxy turns the same idea into a shared service with authentication, virtual keys, budgets, usage records, routing, caching, and guardrails. OpenAI, Anthropic, Gemini, Bedrock, Azure, and Vertex AI are among the named options. That breadth is the reason to adopt LiteLLM, and the source of most of its weight.
The common surface reaches beyond chat completions. LiteLLM documents responses, embeddings, images, audio, batches, reranking, Anthropic-style messages, A2A agents, and MCP tools. A team can route an MCP server or an agent through the gateway and keep the provider credentials away from the calling application. Compatibility still needs checking endpoint by endpoint. The provider table does not show every provider supporting every one of those operations.
What happened when we ran it
Our sandbox installed commit 61a73c5 through npm in 22 seconds. It pulled 379 packages and occupied 78 MB on disk. Npm audit found 0 known vulnerabilities across critical, high, moderate, and low severities. The checkout itself was much larger: 12,122 files, roughly 3,199,517 lines of source, and 190.7 MB before the install. This is a large software product, even though the npm dependency step was quick.
There was no root build script or target, so the lab skipped the build. There was also no root test script or target, so it skipped tests. That result does not say LiteLLM has no tests: our scan found a tests directory and 53 CI workflow files. It says the npm entry point available to our fresh Node 22 container did not expose either check. We cannot turn those skipped steps into a passing build or passing suite.
The container had 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. It did not call a model provider, start the Python proxy, apply database migrations, or open the dashboard. Our run establishes that the root npm dependencies resolved at this commit. It does not measure gateway latency, routing correctness, model compatibility, or the Python installation path. Those require a configured deployment and real provider calls.
A production proxy is a small platform, not one Python process
The shortest proxy example listens on port 4000, while the documented production architecture uses several services. Its AWS and GCP Terraform modules split the gateway, backend, and interface, then add managed Postgres, Redis, a versioned object store, secrets, and a one-off Prisma migration job. The local command is useful for trying the OpenAI-compatible endpoint. It is not a picture of the production operating cost.
Developer mode also reveals the moving parts. Docker Compose starts the database and Prometheus, make bootstrap prepares the project, the Python backend runs separately, and the dashboard starts from ui/litellm-dashboard. Each upstream provider needs its own credential and model configuration. Cloud deployments then add load balancers, certificates, secret managers, and provider-specific access such as AWS roles or Google project permissions. None of that is excessive for a central company gateway, but it is wasteful for one application calling one vendor.
The MIT license excludes the enterprise directory
The repository license grants MIT terms to content outside the enterprise/ directory and assigns that directory its own license. The README names single sign-on, feature prioritization, custom integrations, support, and service agreements under the enterprise offer. A team can run the core gateway without buying a commercial runtime license, but it should map required identity and support features before committing to the open-source edition.
Release handling has useful operational details. Version v1.103.2 was published on October 1, 2026, and the repository was pushed again the same day. The project publishes signed container images and documents verification with a pinned cosign public key. It also distinguishes stable image tags from ordinary releases. Pinning a tag and verifying its signature is safer than following a floating image while this repository changes several times a day.
5,487 open issues and pull requests mean constant motion
GitHub's combined counter showed 5,487 open issues and pull requests on October 1. Separate searches split that into 1,780 issues and 3,707 pull requests, so calling all 5,487 bugs would be wrong. The same snapshot showed 59,966 stars, a same-day push, and a same-day release. LiteLLM is plainly active. It also asks adopters to watch changes in routing, provider behavior, security, database migrations, and configuration.
That trade is reasonable when the gateway replaces provider code scattered across several applications. One platform team can own upgrades, credentials, budgets, and fallback rules while product teams use a familiar client. With a single model provider, LiteLLM moves complexity into a service that did not need to exist. Any-LLM is the smaller Python choice, Portkey is a more focused gateway comparison, and Helicone is worth considering when request analysis is the primary need.
Choose LiteLLM when central policy earns its operating cost
The 22-second install is the least important part of the decision. LiteLLM earns its place when virtual keys, multi-provider routing, spend controls, common logs, MCP access, and guardrails all need one owner. Its documentation and release activity support that role, while the 12,122-file checkout and stateful production stack show what ownership involves. Before rollout, prove the Python build, run the relevant suites, pin a signed image, and test only the providers and endpoints your applications will actually use.