LiteLLM Alternatives in 2026: What to Use After Two Supply Chain Attacks

The right LiteLLM alternative depends on which LiteLLM you run. If you import the Python library, the replacements are the providers' official SDKs or Mozilla.ai's any-llm. If you run the LiteLLM proxy, the self-hosted alternatives are Bifrost, MLflow AI Gateway and Portkey's open-source gateway. If you would rather not run a gateway at all, managed ones such as OpenRouter, Vercel AI Gateway and Cloudflare AI Gateway do the routing for you. Most teams looking right now are reacting to LiteLLM's two supply chain attacks this year, so we also checked something the comparisons leave out: whether each option's releases can be verified as coming from its own pipeline. Facts and prices below were checked on 4 November 2026.

---

First: which LiteLLM do you use?

LiteLLM is three things, and each has different replacements:

• The Python library (import litellm): one function call for every provider, inside your own code. You hold the provider keys.
• The proxy (the LiteLLM Docker image): a server your apps call instead of the providers, with virtual keys, budgets, logging and fallbacks. It holds every provider key your company uses, which is what made the October attack so costly for teams running it.
• A dependency of something else: many coding agents, AI review bots and frameworks install LiteLLM without you choosing it. Replacing your own use does not remove those.

Check all three before you decide. Teams often discover they run the proxy for one product and the library in three others.

LiteLLM alternatives at a glance

"Release provenance" means the package carries a signed attestation, published by PyPI or npm, linking it to the project's own build workflow. We checked the latest release of each through PyPI's integrity API and npm's registry on 4 November 2026. It would not have stopped October's attack on its own, because that attacker controlled LiteLLM's real pipeline. But it does stop the most common case, a package uploaded with a stolen token from somewhere else, which is how the March attack worked.

Replacing the LiteLLM library

The official SDKs. If you call two or three providers, the simplest alternative is no abstraction at all: OpenAI's SDK, Anthropic's SDK, Google's. You lose one-line model switching and gain smaller dependencies maintained by the companies whose APIs they call, and new features the day they ship. The cost is a thin adapter of your own, usually a few hundred lines. Note that provenance varies even here: OpenAI's Python SDK carries PyPI attestations and Anthropic's did not when we checked.

any-llm. Mozilla.ai's library keeps LiteLLM's one-interface idea but, in its own words, uses the providers' official SDKs where they exist instead of reimplementing their APIs, as LiteLLM does. Apache 2.0, Python 3.11 or newer, attested releases on PyPI. A separate project, Otari, adds gateway features (budgets, API keys, usage analytics) if you later want a proxy. It is the closest drop-in for teams that like LiteLLM's library and distrust its release process.

Replacing the LiteLLM proxy (self-hosted)

Bifrost. A gateway written in Go by Maxim, Apache 2.0, about 9,400 GitHub stars. One OpenAI-compatible API in front of 23+ providers, with fallbacks, load balancing, virtual keys, budgets, rate limits, semantic caching, a web UI and an MCP gateway. It runs with npx -y @maximhq/bifrost or one Docker command. Its maintainers report under 200 µs of added overhead at 5,000 requests per second (a vendor benchmark). The most active of the self-hosted options: more than 100 commits in the month to 4 November.

MLflow AI Gateway. Part of MLflow, Apache 2.0 and governed by the Linux Foundation, which is the strongest governance story on this list. Routing, fallbacks, rate limiting, cost tracking and guardrails, and every request is logged as an MLflow trace. MLflow's own benchmark puts its median overhead at 28.6 ms against LiteLLM's 56.7 ms. Natural if you already use MLflow for tracing or evaluation; heavy if you don't.

Portkey's open-source gateway. MIT, TypeScript, about 13,300 stars, runs with npx @portkey-ai/gateway, with routing, fallbacks, retries, guardrails and caching. One caution: the open-source repository's latest release is from January 2026 and its main branch was last pushed in May. Portkey says a 2.0 that merges its enterprise gateway into open source is coming, and its hosted Portkey Cloud is actively developed. Check the repository's activity before you adopt the self-hosted version.

Not running a gateway at all (managed)

OpenRouter. One API and one bill for hundreds of models. No markup on inference ("billed at the provider's list price on every plan"), a 5.5% fee on credit purchases on the Standard plan (8% on Business), and $25,000 a month of bring-your-own-key usage with no fee, then 5%. Prompts and completions are not logged by default, and zero data retention can be enforced in settings. The trade: a third party sees every request.

Vercel AI Gateway. Managed routing, provider fallbacks, budgets, request logs and bring-your-own-key, with "zero markup to provider token prices, including with BYOK". Your app doesn't need to run on Vercel.

Cloudflare AI Gateway. Caching, rate limiting, analytics, fallbacks and retries at Cloudflare's edge. Core features are free on all plans; free accounts keep 100,000 logs in total, paid ones 10 million per gateway. Its unified billing passes provider rates through with no markup and a 5% fee on credit purchases.

Managed gateways remove the thing that hurt in October, a self-hosted server holding every key, but you trust their operations instead. For regulated data, read each one's retention terms against yours.

LiteLLM vs OpenRouter: not either-or

The most searched comparison isn't really a choice. LiteLLM is software that turns one API into many using your keys; OpenRouter is a service that routes your requests and bills you. We use both together: our AI service calls models through the LiteLLM library, and every one of those calls goes to OpenRouter. LiteLLM is pinned at 1.90.2 in a lockfile, so neither attack reached us.

One lesson from running that setup, whichever route you pick: model names retire. A retired OpenRouter model name returns an error on every call, and twice one reached our production unnoticed because the code path using it had not run yet. We now ping every configured model once at startup and alert if any is gone. A gateway's fallbacks can paper over this; a check at boot tells you before a customer does.

How to choose

• You use the library and call two or three providers: official SDKs. Fewest moving parts.
• You use the library and want one interface for many models: any-llm, or stay on a pinned LiteLLM.
• You run the proxy for budgets, keys and logging across teams: Bifrost if you want the active, fast one; MLflow AI Gateway if you value foundation governance or already run MLflow.
• You don't want to host anything: OpenRouter for the widest model catalog and one bill; Vercel or Cloudflare if you already live there.
• You are fine on LiteLLM and just shaken: staying can be right. Pin exact versions, pin the proxy image by digest, keep provider keys scoped and rotatable, and wait a few days before upgrading. That is what kept us safe both times.

Whatever you pick, verify what you install

The attacks were a release problem, so the defence is the same for every option on this list:

1. Pin exact versions in a lockfile, and container images by digest, never latest.
2. Check provenance where it exists. For npm: npm audit signatures. For PyPI, the pypi-attestations tool verifies a file against the repository it should come from, and PyPI shows an attestation on each file's page.
3. Delay upgrades by a few days. Both LiteLLM compromises were pulled within hours.
4. Scope the keys a gateway holds, per provider and per environment, so a compromise means a rotation, not an incident.
5. Inventory indirect installs: coding agents, review bots and frameworks that bring LiteLLM along.

Related: the LiteLLM supply chain attack (1.107.0), the LiteLLM MCP vulnerability, MCP gateway explained, and Claude API pricing.