LiteLLM alternatives (2026) — hosted gateways, BYO-key control planes, and when to stay put

LiteLLM is an open-source, OpenAI-compatible proxy you run yourself: it sits in front of your own provider accounts and gives your code one endpoint and one key shape across them (its docs). Teams look for alternatives for two unrelated reasons. Operational: a self-hosted proxy is one more service to patch, scale and be paged about. Supply chain: on March 24, 2026 an attacker published two backdoored LiteLLM releases to PyPI, and the incident put the attack surface of "a package in your build" in front of a lot of teams that had not priced it. This roundup maps each motivation to the tool that actually answers it — including the case for staying put, which is stronger than the seven vendor listicles on this search suggest.

Bias declared up front: Kunavo is our product, and it is listed first. Every other tool below gets a genuine recommendation, the details we have vetted live on the comparison pages, and the two occupants we have not evaluated are described only at the level their own sites state.

The short list

The distinction that does most of the work

LiteLLM does two jobs at once, and most replacements do only one of them. It is a proxy (one endpoint over many providers) and it is a BYO-key tool (the provider accounts stay yours). A hosted inference gateway — Kunavo, OpenRouter — replaces both: there is no proxy to run and no provider account to hold, because the gateway holds the upstream credentials and bills you for usage. A hosted control plane — Portkey, TrueFoundry — replaces only the first: you stop operating the proxy, you keep the accounts. Knowing which half you are replacing settles most of this list. The pattern itself is unpacked in the LLM gateway guide.

What actually sent people looking

The top result on this search is not a listicle — it is a Reddit thread about the supply chain attack. Here is what happened, from LiteLLM's own security update: on March 24, 2026, an attacker published litellm==1.82.7 and litellm==1.82.8 to PyPI with malicious code injected into the distributed wheels. They were live from 10:39 UTC for roughly 40 minutes before PyPI quarantined them. The compromise was traced to the Trivy dependency in LiteLLM's CI/CD security-scanning workflow; the attacker bypassed the official release workflow and uploaded to PyPI directly. Per SecurityWeek, over 2,500 organizations were affected.

LiteLLM's remediation is on the record and it is substantial: compromised packages pulled, maintainer credentials rotated, Mandiant engaged for forensics, and v1.83.0 released through a rebuilt CI/CD pipeline with isolated build environments, stronger release gates and cosign-signed Docker images. If you are on 1.83.0 or later and you were not running a poisoned version during that 40-minute window, this incident is closed for you.

The reason it still moves people to this search is structural rather than about LiteLLM specifically. A self-hosted proxy is a package in your build, which makes your CI/CD and your cluster part of its blast radius. That is the sentence worth sitting with — it is equally true of every self-hosted alternative on this page, MLflow AI Gateway included, and it is the one thing a hosted endpoint removes: you call an HTTPS URL, so there is no package to poison and nothing of the gateway's running inside your network.

The honest other half: a hosted gateway is not safer, it is differently exposed. Your API key and your prompt text transit someone else's infrastructure, and you inherit their breach risk in place of your own patching risk. If prompt text cannot leave your infrastructure, self-hosting is the correct answer and the rest of this page is about a trade you should not make.

1. Kunavo — no proxy, no provider accounts

Kunavo is a hosted inference gateway: one OpenAI-compatible base URL, one sk-kn- key, one pay-as-you-go balance, and we hold the upstream provider credentials rather than you. Against LiteLLM that is a different division of labour — you are not running a proxy and you are not maintaining accounts at Anthropic, Google and OpenAI separately.

Price: most of the catalog is listed under the providers' official rates — Claude Sonnet 4.6 at $1.20 / $6.00 per 1M tokens against Anthropic's $3.00 / $15.00, though a few models, Claude Sonnet 5 among them, sit at list. LiteLLM has no markup because it resells nothing; what you pay is your own provider deal, so the comparison is our rate against your direct rate, not against zero. Coverage: chat, image, video and music models on the same key and balance. What it does not do: route your own provider keys — that is the BYO-key half LiteLLM keeps and we do not replace. Details: Kunavo vs LiteLLM.

2. OpenRouter — the longest model tail

The other hosted inference gateway, and the one to pick when catalog breadth matters more than unit price: hundreds of models from a large provider set on one wallet, plus free tiers and bring-your-own-key routing that Kunavo does not offer. If you are leaving LiteLLM because you want to stop holding accounts, OpenRouter and Kunavo are the two realistic shapes. Kunavo vs OpenRouter puts the two side by side, and the OpenRouter roundup covers the rest of that field.

3. Portkey — keep your keys, drop the ops

A hosted control plane over provider accounts you already have: routing, fallbacks, guardrails and observability, without a proxy of your own to run. This is the closest replacement if you chose LiteLLM for its routing and budget features and the only thing you actually want to give up is operating it. Details: Kunavo vs Portkey.

4. Helicone — if observability was the whole reason

A lot of LiteLLM deployments exist because someone needed request logs and per-team cost attribution, and the proxy was how they got them. If that describes yours, an observability layer over your existing provider calls is a much smaller thing to run than a gateway. Details: Kunavo vs Helicone.

5. TrueFoundry — when procurement needs a vendor

Occupies position 2 on this search with its own LiteLLM comparison. It is an enterprise AI gateway sold on latency overhead, deployment flexibility, SLAs, governance and audit-ready controls (its product page). We have not evaluated it, so this entry is a pointer rather than a recommendation: if your blocker is that an open-source proxy has no support contract, this is the category that solves that, and the comparison is worth reading with the knowledge that they wrote it.

6. MLflow AI Gateway — the like-for-like open-source swap

Position 3, and the closest thing on this page to LiteLLM itself: an open-source, self-hosted gateway that fronts your own provider keys, maintained as part of the MLflow project. Worth naming plainly: swapping one self-hosted proxy for another keeps the deployment model and therefore keeps the attack surface described above. That is a legitimate choice — it is what you want if the thing you disliked was the project, not the model.

7. Cloudflare AI Gateway — caching and limits at the edge

A thin proxy in front of provider accounts you already have: response caching, rate limiting, retries and analytics, with no inference resold. It composes with any inference source rather than replacing one, including Kunavo or OpenRouter. Details: Kunavo vs Cloudflare AI Gateway.

When LiteLLM is still the right call

• Prompt text cannot leave your infrastructure. Regulated data, air-gapped environments, or a policy that a hosted gateway simply cannot satisfy. Self-hosting is the answer and the only question is which self-hosted proxy.
• You have negotiated provider contracts. Committed spend or enterprise rates at Anthropic, OpenAI or Google are worth more than anything a reseller lists, and BYO-key tools are how you keep using them.
• You use its per-key budgets and team routing. Those features are the reason many LiteLLM deployments exist; check your replacement covers them before assuming a base-URL swap is the whole migration.
• You want source you can read and patch. An open-source proxy you control is a real property, and the March 2026 incident does not take it away — that was a release-pipeline compromise, since remediated, not a flaw in the proxy itself.

Switching is two lines

Every alternative here that resells inference speaks the OpenAI wire protocol, so moving off a LiteLLM proxy is a base_url and key swap — request and response shapes are unchanged:

# Before: your own LiteLLM proxy, your own provider keys,
# your own container to patch.
client = OpenAI(
    api_key=os.environ["LITELLM_MASTER_KEY"],
    base_url="http://litellm.internal:4000",
)

# After: a hosted endpoint. No package in your build, no proxy to run.
client = OpenAI(
    api_key=os.environ["KUNAVO_API_KEY"],
    base_url="https://api.kunavo.com/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-6",
    messages=[{"role": "user", "content": "Hello"}],
)
print(resp.choices[0].message.content)

The part that is not two lines is whatever LiteLLM was doing beyond routing: per-key budgets, team fan-out, custom callbacks. Inventory those first. The wire-level details are in the OpenAI-compatible API guide, and what a gateway should handle for you covers the feature set to check a replacement against.

FAQ