LiteLLM Alternatives After the Supply Chain Attack (PyPI 1.82.7/1.82.8)

If you run LiteLLM in production, you probably already know: PyPI versions 1.82.7 and 1.82.8 were compromised in a supply chain attack. 95M+ downloads. Malicious code in a dependency. The kind of incident that makes you audit your entire stack.

The immediate fix is obvious -- patch or pin to a clean version. But a lot of teams are using this as a trigger to reassess whether LiteLLM is the right tool for them in the first place. It's a heavy Python dependency tree. It requires a running server. And the security surface area is real.

If you're in that boat, here's a practical rundown of the alternatives.

What LiteLLM Actually Does

Before comparing, it's worth being precise about the problem LiteLLM solves:

• Unified API -- one interface to OpenAI, Anthropic, Gemini, etc.
• Request routing -- send traffic to different models based on rules
• Cost tracking -- log spend per model/team
• Fallbacks -- retry with a different provider on failure

Most alternatives solve some subset of these. The right one depends on which problems you actually care about.

The Alternatives

RelayPlane

The lightest-weight option. npm install -g @relayplane/proxy and you're running in under 30 seconds -- no Docker, no Python, no server setup. It drops into your existing stack as a local proxy that intercepts OpenAI-compatible requests.

RelayPlane handles model routing (complexity-based or explicit), cost tracking, and fallbacks. It runs as a single Node.js process and stores data in SQLite locally. No cloud required.

If you're already in a JS/Node environment and you don't need LiteLLM's full enterprise feature set, RelayPlane is the fastest path to a clean, auditable replacement.

Full comparison: RelayPlane vs LiteLLM →

Portkey

Cloud-hosted LLM gateway with a generous free tier. Strong observability story -- you get a dashboard for traces, costs, and errors out of the box. Good choice if you want something managed and don't want to run infrastructure.

The tradeoff: your requests go through Portkey's servers. For teams with data residency requirements, that matters.

OpenRouter

Not a self-hosted proxy -- it's a hosted API aggregator. You hit openrouter.ai/api/v1 and it routes to 100+ models. Zero setup, unified billing, good for prototyping and low-volume production use.

Doesn't replace LiteLLM's routing/fallback logic for self-hosted setups, but if you're just using LiteLLM as a model aggregator, OpenRouter removes the infrastructure entirely.

LiteLLM (patched)

Worth saying: if LiteLLM's feature set is genuinely what you need and your team is invested in it, patching is valid. Pin to a known-good version, audit your dependency tree, and add supply chain scanning to your CI. The project is actively maintained and the attack was in a transitive dependency, not core LiteLLM code.

The risk was real, but it wasn't a fundamental architectural flaw.

How to Pick

The Broader Point

Supply chain attacks on widely-used packages are becoming routine. LiteLLM was targeted because it's in a lot of production stacks. The same thing will happen to other popular AI infrastructure packages.

The mitigation isn't paranoia -- it's reducing attack surface. Smaller dependency trees, simpler processes, fewer moving parts. A proxy that's a single Node binary is harder to compromise than one with 300 transitive Python dependencies.

Worth factoring into your tooling decisions going forward.

RelayPlane is a lightweight LLM proxy that runs locally with npm install. See how it compares to LiteLLM →