LiteLLM vs OpenRouter: which LLM gateway fits your stack?

As of November 2, 2026, pick LiteLLM if you can run a gateway yourself: it is free MIT software with no token fee, but you operate PostgreSQL and Redis and pin versions after the 1.107.0 compromise. Pick OpenRouter for zero operations: 5.5% on credit purchases (8% on Business), no markup on tokens. You can also run both, since LiteLLM lists OpenRouter as a provider.

The 1.107.0 part is new. On October 21, 2026, a compromised LiteLLM release was published to PyPI and shipped through the official container images (Microsoft). Per ClickPy data cited by Wiz, it was downloaded roughly 49,000 times.

The real choice is who runs the gateway

In our view, the decision comes down to one question: do you want to operate a piece of infrastructure that holds every provider key you own? Everything else (fees, latency, security exposure) follows from the answer. We cover the wider version of this choice in open source vs managed AI gateways.

Sources: LiteLLM, OpenRouter's comparison post, OpenRouter pricing, OpenRouter Business, fees as checked on November 2, 2026.

The OpenRouter catalog number depends on how you count. OpenRouter's own routing post says 400+ models across 70+ providers, and an independent reviewer counted 464 entries across 67 publishers on the live API on October 28, 2026, with batch and free aliases counted separately (iadecider). If a specific model is the reason you are choosing, check it is listed before you commit.

Free software still has a bill

The LiteLLM gateway and SDK are MIT-licensed and free in production (LiteLLM). LiteLLM Enterprise is a paid annual license for SSO, SCIM, audit logs and support, and LiteLLM says its price depends on request capacity, installation architecture and support, never on tokens.

LiteLLM does not publish the Enterprise price. Third-party estimates circulate, some of them from competing gateway vendors, and a separate review notes LiteLLM's own pricing page does not list them. We would not budget on any of them; ask LiteLLM for a quote.

The bigger cost is operations. OpenRouter's own comparison puts it plainly: no platform fee, but you run PostgreSQL, Redis and Docker yourself.

Redis is not optional for long. LiteLLM's docs say it is highly recommended for any proxy running more than one worker process (LiteLLM Redis requirements). Without it, a 100 requests per minute limit across 4 workers lets through up to 400, and a revoked key stays usable on workers that did not process the revocation.

OpenRouter's fee is the opposite shape: no ops, a percentage of what you spend. The 5.5% is charged when you buy credits, and it rises to 8% on the Business tier. The extra 2.5 points buys EU or US in-region routing, with no cross-region fallback (OpenRouter pricing).

BYOK changes the math. On Standard and Business, OpenRouter includes $25,000 per month of list-price BYOK inference with no fee, then charges 5% above that (OpenRouter pricing). A team that routes its own provider keys through OpenRouter pays nothing until spend passes $25k a month.

Worked example: where self-hosting breaks even

Take a team deciding between the two. The question: at what monthly model spend does OpenRouter's fee cost more than running LiteLLM?

Our assumptions (Requesty calculations, change them to your numbers):

• A loaded engineer costs $180k per year, and LiteLLM takes a quarter of one engineer's time across deploys, upgrades, Redis and PostgreSQL care, key rotation and incident response. That is $3,750 per month.
• Hosting for the gateway, PostgreSQL and Redis costs ~$300 per month.
• Total self-hosting cost: ~$4,050 per month.

If all spend goes through credits at 5.5%, OpenRouter's fee matches that $4,050 at $4,050 / 0.055, or about $73,600 per month. At the 8% Business rate, break-even drops to about $50,600 per month. If instead all spend runs on your own keys, the fee is 5% of spend minus $25k, so break-even is $4,050 / 0.05 + $25,000, or about $106,000 per month.

The ops estimate is the weakest input, so stress-test it. Even if we halve it to an eighth of an engineer ($1,875 plus $300 hosting), break-even on credits at 5.5% is still about $39,500 per month. If you double it (a half-time owner, for a security team that wants someone watching every release after October 21), it climbs to about $141,800 per month on credits.

At our base case, OpenRouter's 5.5% credit fee costs less than running LiteLLM until model spend passes about $73,600 a month, and a leaner or heavier ops estimate moves that line to anywhere between ~$39,500 and ~$141,800. Below the line, a percentage fee is cheaper than the people needed to run a gateway safely; above it, self-hosting pays for itself, if you have someone who wants the job.

What the 1.107.0 compromise changes

Running LiteLLM means you inherit its supply chain, and in 2026 that supply chain broke twice.

The March sources do not agree: Snyk puts the exposure at about 3 hours, so use LiteLLM's wider 10:39 to 16:00 UTC window when you check your own logs. Datadog ties the March release to a broader campaign against developer tooling.

For October, LiteLLM lists the affected Docker tags as v1.107.0, latest, main-latest and main-stable. It says all previous versions are safe and that customers on its private enterprise release were not hit. It had not yet confirmed how the attacker got into the internal deployment in the first place.

Two details from Microsoft's analysis should shape your view. First, your code did not need to import LiteLLM: starting Python in an affected environment could be enough to run the payload. Second, a separate module tried to read credential and model-configuration records from the LiteLLM proxy database. A gateway holds every provider key you have, which is exactly why it is worth attacking.

Scale makes this bigger than one project. Datadog puts litellm at about 23 million weekly downloads. Exposed admin panels are a separate risk on top of this one, which we covered in one in ten exposed LiteLLM gateways still answers to sk-1234.

Does this mean you should drop LiteLLM? We think not. For most teams the fix is version discipline, and LiteLLM's own response was clear about what to pin. What it does mean is that the ops line in the worked example above has a security component you cannot skip.

Latency: who measured what

Both options add a hop. With LiteLLM the hop is inside your network, then the request goes out to the provider. With OpenRouter the request goes to OpenRouter's edge first, then to the provider. Either way, the provider call leaves your network, so a self-hosted gateway does not keep traffic strictly inside it.

Every overhead number we could trace to a named tester comes from a vendor, ourselves included, and no two of them use the same test.

Read LiteLLM's 8 ms as a best case. The test used 4 instances of 4 vCPUs and 8 GB, 4 workers per instance, Locust with 1,000 users and a mock backend, with overhead read from the x-litellm-overhead-duration-ms header. The page gives no test date, and the same table shows total request latency of 150 ms at p95, so 8 ms is not what a client sees (effloow makes the same point).

Do not set the 8 ms next to TrueFoundry's 120 to 200 ms as if they were one test: one is proxy overhead against a mock, the other is added time to first token on real traffic. TrueFoundry also saw answers stream about 17% slower on credits (94 and 95 tokens per second against 115 direct), and its best explanation is less capacity on OpenRouter's account, which is the author's inference. OpenRouter's docs add that edge caches can be cold for the first 1 to 2 minutes in a new region.

We found no independent head-to-head test.

You can run both

LiteLLM's docs list OpenRouter as a provider and say LiteLLM supports OpenRouter's text, chat, vision and embedding models (LiteLLM docs). You set OPENROUTER_API_KEY and call models as openrouter/<model>; the base URL defaults to https://openrouter.ai/api/v1. That lets you keep LiteLLM as the control point inside your infrastructure (keys, budgets, logging) and send some traffic to OpenRouter's catalog behind it.

Two limits apply. LiteLLM only sends your OpenRouter key, so BYOK for the underlying providers is set up in your OpenRouter account, not in LiteLLM. Some OpenRouter features are version-specific too: the Decisions API pass-through is in v1.104.0 and later (and patches of v1.101.1 and v1.102.1), but in no v1.103 release, which is one more reason to pin.

You still carry LiteLLM's ops and pinning work, and OpenRouter's fee applies to whatever you route through it.

Where Requesty fits

Requesty is a third option on the hosted side: one OpenAI-compatible API in front of 600+ models from 30+ providers, priced at 5% on top of model costs with all features included (pricing). It has failover chains across providers, latency and cost-based routing, per-user spend limits, and dashboards for cost, latency, TTFT and P50 to P99. You can bring your own provider keys or use one Requesty key, and there is an EU endpoint for data residency.

The scope limit: Requesty is hosted only. If your requirement is that the gateway runs inside your own VPC, LiteLLM is the option that does that. If you want a gateway without a self-hosted proxy or admin panel to patch and expose, switching is a base URL change. We compare the wider field in our routing platforms comparison, and explain why we built ours in Go in this language audit.

from openai import OpenAI
 
client = OpenAI(
    base_url="https://router.requesty.ai/v1",
    api_key="YOUR_REQUESTY_KEY",
)

import OpenAI from "openai";
 
const client = new OpenAI({
  baseURL: "https://router.requesty.ai/v1",
  apiKey: process.env.REQUESTY_API_KEY,
});

Which one to pick

Before you decide, plug your own monthly spend, your split between credits and your own keys, and a realistic ops estimate into the break-even table above. If you already run LiteLLM, work through the pinning checklist today.