LiteLLM’s most revealing number is not its star count. It is the gap between code movement and release activity. In the ToolVitals snapshot, the BerriAI/litellm repository records 2,934 GitHub commits in 30 days and 48 active contributors. The same snapshot records 30 GitHub releases in 90 days, yet 0 release events in the last 30 days. That pattern points to heavy engineering behind a quiet current release window, not a project whose health can be read from tags alone.

LiteLLM is a gateway and SDK for a fragmented model stack

The GitHub repository describes LiteLLM as an OSI-approved open-source AI gateway for more than 100 LLM providers. It offers two related ways to use the product. Developers can import the Python SDK directly into an application, or teams can deploy the Proxy Server as a centralized service. Both paths aim to hide provider-specific SDKs, authentication schemes, request formats, and error types behind an OpenAI-compatible interface.

The supplied ToolVitals description names providers including Bedrock, Azure, OpenAI, Vertex AI, Cohere, Anthropic, SageMaker, Hugging Face, vLLM, and NVIDIA NIM. The repository also lists supported endpoints such as chat completions, responses, embeddings, images, audio, batches, reranking, messages, and agent-to-agent requests. That scope makes LiteLLM more than a thin client wrapper. It is positioned as an integration boundary between applications and a changing collection of model APIs.

The official site frames the product more broadly as an AI gateway for platform teams. Its supplied excerpt describes one OpenAI-compatible key for 140-plus providers and 1,892 models, along with access to agents and MCP servers. It also presents controls for team and project access, usage and spend tracking, hard budgets, rate limits, guardrails, load balancing, caching, model routing, and self-hosted deployment.

The provider and model counts differ between the site and repository. The repository says 100-plus LLM providers, while the site says 140-plus providers and 1,892 models. The supplied context does not explain whether those numbers use different snapshots, counting rules, or product scopes. Treat them as directional first-party positioning, not as one exact normalized inventory.

Performance is also part of the positioning. The repository excerpt reports 8 ms p95 latency at 1,000 requests per second in its benchmark material. The official site reports 0.66 ms at p99 for its Rust AI Gateway benchmark and says that result was 3.5 times lower than the next gateway tested. Those figures are not interchangeable. They use different percentile and benchmark descriptions, so an engineering team should reproduce the workload rather than combine them into one performance claim.

What the ToolVitals metrics say

ToolVitals gives LiteLLM a hot score of 206.6, a health score of 99, a shipping score of 99, and an overall ToolVitals score of 99. The repository has 61,607 GitHub stars. The data confidence value is 90. These are strong signals within the ToolVitals system, but they are not service-level guarantees, user counts, or independent measurements of production reliability.

The star count establishes attention and project reach. It does not establish how many teams run LiteLLM in production, how often those deployments are used, or how satisfied their operators are. A project can accumulate stars through broad developer interest without becoming the right operational choice for a specific workload.

The 2,934 commits in 30 days are a stronger signal of engineering motion than stars alone. The release excerpts show that this activity includes proxy fixes, provider compatibility work, router changes, UI migrations, tests, typing cleanup, security-related dependency updates, and infrastructure behavior. That breadth is useful for a gateway that sits across many providers. It also means commit volume is not the same thing as feature volume. A large share of the work may improve maintenance, correctness, or internal structure without changing the user-facing product.

The 48 active contributors indicate that LiteLLM is not being changed by one visible maintainer working in isolation. They do not show how contribution ownership is distributed, whether critical components have backups, or how much review each change receives. Those questions matter for a service that can sit on the request path for many applications.

The release numbers require careful reading. Thirty GitHub releases in 90 days and zero release events in 30 days can both be true because the measurement windows differ. The supplied event records run from August 11 through August 21, 2026, while the ToolVitals snapshot was generated on October 21, 2026. The data therefore shows a release burst earlier in the measured 90-day period and no qualifying release event in the shorter current window. ToolVitals cannot identify from these figures alone whether that gap reflects stabilization, release-channel policy, delayed tagging, or another process choice.

On licensing, the payload classifies LiteLLM as OSI-approved open source and gives MIT as the license label. Based on the supplied data, LiteLLM should be described as open source, not fair-code, source-available, or open-core. That distinction matters to teams evaluating whether they can inspect, modify, and self-host the gateway under the stated license signal.

The release notes show a control-plane product taking shape

The v1.99.0-dev.2 release makes container supply-chain verification unusually visible. It says LiteLLM Docker images are signed with cosign and that releases use the same signing key introduced in commit 0112e53. The release instructions recommend verification against a pinned commit hash, with tag-based verification presented as a convenience path. That does not prove every deployment is secure, but it gives operators a concrete way to check image provenance before running a gateway.

The same release page lists fixes for spend logging on OpenAI passthrough embeddings, router fallbacks, estimated input tokens for failed requests, and a boolean thinking parameter that previously caused an attribute error. It also includes work on MCP forms, guardrail inputs, registry reads across sibling replicas, UI form migrations, and test-suite organization. The pattern is operational. The team is working on the details that determine whether a centralized gateway behaves predictably when requests fail, replicas disagree, or administrators change configuration.

The v1.99.0-dev.1 release continues that direction. Its notes include WebSocket passthrough for OpenAI prefixes, AWS Bedrock batch cancellation, a mixed-provider auto-router preset, MCP guardrail recording, provider-specific compatibility fixes, and changes to migration resolution. It also includes fixes for request metadata, authentication, batch errors, and rate-limit behavior.

The v1.98.0-rc.1 release shows the routing work becoming more deliberate. The notes describe a complexity router calibrated with worked examples, pre-adoption shadow evaluations for the auto-router, a mixed-provider auto-router preset, and a dashboard view for routing results. They also show continued work on authorization boundaries, model allow lists, guardrail behavior, Responses API compatibility, and the dashboard migration to a newer UI component system.

The v1.98.0-dev.2 release adds more evidence that the gateway is being built for operations rather than only API translation. Its changes include optional session and trace identifiers in JSON logs, per-deployment failure and cooldown controls, configurable estimated output tokens for rate limiting, guardrail load isolation, and fixes for caller-scoped file pagination. The release also includes work for provisioned-throughput accounting and request attribution, which fits LiteLLM’s stated role in usage visibility and organizational control.

The v1.97.0 release includes credential-header redaction in request logging, cache client cleanup, router settings, guardrail moderation, and stronger handling of role and access boundaries in the dashboard. Those changes are less visible than a new provider announcement, but they matter more to a platform team that has to explain what happened during a failed or blocked request.

The stable patch pages for v1.88.6, v1.89.7, and v1.90.7 describe backported proxy fixes and runtime dependency refreshes. The presence of development, release-candidate, stable, and stable-patch tags suggests parallel release tracks rather than one simple version line. That can help teams choose a risk profile, but it also raises the importance of clear support and upgrade guidance.

Taken together, the release notes point to a gateway that is becoming a policy and operations layer. Provider adapters still matter, but the recent work also covers routing decisions, guardrails, identity, request logs, replica behavior, UI administration, MCP access, and image verification. LiteLLM is trying to control how an organization uses models, not only how an application calls one.

What the data does not tell you

ToolVitals sees repository activity, contributors, releases, license signals, and public project evidence. It does not see code quality, user satisfaction, revenue, support responsiveness, production incident rates, or whether LiteLLM works well for your particular provider mix. A 99 health score cannot answer whether a provider adapter handles your structured-output, streaming, batch, or tool-calling workload correctly.

The release pages demonstrate that many fixes are being made. They do not tell you how often regressions reach production, how long a breaking behavior remains in a development channel, or whether your application is covered by the project’s tests. The cosign instructions establish a verification mechanism for images. They do not establish that a verified image has a safe configuration, correct database permissions, or acceptable data handling for your environment.

The official performance figures have the same boundary. They are useful evidence that latency is a stated design target and that the team has published benchmark conditions. They are not a substitute for measuring queueing, retries, provider latency, database access, logging overhead, and failover behavior in your deployment.

A skeptical buyer should test the gateway, not the star count

An engineering lead evaluating LiteLLM should start with the exact operating model the team needs. Run the Python SDK and Proxy Server paths separately if both are candidates. Pin a stable release for the first evaluation, then compare it with a development or release-candidate build only when a required capability is absent from the stable path.

Build a provider matrix around the endpoints your applications actually use. Test chat completions, the Responses API, embeddings, streaming, image or audio requests, batches, tool calls, and agent-to-agent requests where relevant. Exercise provider failure, router fallback, rate limits, guardrail rejection, malformed metadata, replica lag, cache loss, and database interruption. Measure p95 and p99 latency with and without logs, guardrails, caching, and routing enabled.

The security path should be part of that test. Verify the Docker image using the pinned cosign key described in the v1.99.0-dev.2 release notes, inspect the Helm or Terraform deployment path you intend to use, and document which credentials, request content, and usage records pass through the gateway. A gateway that sits between every application and every model deserves a threat model, not just a successful quickstart.

LiteLLM is active, but not the category’s largest attention signal

The related-tool data puts LiteLLM below several neighboring developer tools on raw attention. Unsloth has 78,273 GitHub stars and a hot score of 232.9, compared with LiteLLM’s 61,607 stars and 206.6 hot score. Hermes Agent has 255,187 stars and a 234.5 hot score. LiteLLM, Unsloth, and Hermes Agent all have a shipping score of 99 and 0 release events in the last 30 days.

These are category comparisons, not feature comparisons. Unsloth and Hermes Agent are not direct replacements for a model gateway. The useful conclusion is narrower: LiteLLM has substantial reach and strong ToolVitals health and shipping signals, but it is not winning the related list through star count alone. Its case rests on the operational problem it solves and the breadth of its provider and control-plane work.

What maintainers should make clearer

The metrics give LiteLLM’s maintainers a communication problem as well as an engineering signal. A project with 2,934 commits in 30 days and 30 releases in 90 days can still look quiet to a user who sees 0 release events in the current 30-day window. The development, release-candidate, stable, and patch streams make that distinction more important.

The release pages already contain useful technical detail. A concise release-channel matrix would make the information easier to act on. It should identify which tags are recommended for production, which changes affect migrations or provider compatibility, how long each stable line receives fixes, and whether image-signing instructions apply identically across every published channel. That would turn high shipping activity into clearer adoption guidance without requiring users to reconstruct the policy from individual release notes.

Recommendation

If your team needs one API boundary across several LLM providers and wants self-hosted control over routing, budgets, guardrails, logs, and model access, evaluate LiteLLM as a gateway first. Its repository and official site support that use case, and the release history shows active work on the operational features that make a gateway useful beyond request translation.

Do not choose it solely because ToolVitals reports a 99 health score, 61,607 stars, or 2,934 recent commits. Choose it after a workload-specific test proves that the providers, endpoints, fallbacks, authentication rules, logging behavior, and deployment model fit your applications. If your system uses one provider and needs only a thin client, a direct provider SDK may be simpler. If your organization needs a common control layer across changing models, LiteLLM is a credible candidate, provided you pin the release, verify the image, and own the gateway’s operational testing.

Sources