LiteLLM vs OpenRouter

Choose LiteLLM when you need to run the gateway and keep provider credentials in your infrastructure. Choose OpenRouter when you want hosted routing and consolidated model billing: its Standard credit purchases carry a 5.5% fee, while LiteLLM's open-source software has a $0 license fee. The LiteLLM vs OpenRouter decision turns on who operates the gateway, which account pays for inference, and whether the saved fees cover your operating cost.

LiteLLM vs OpenRouter: which should you choose?

OpenRouter wins for a builder who wants multi-provider access without operating another service. LiteLLM wins for a builder whose gateway, credentials and traffic policies must run in infrastructure they control. High usage alone does not settle it: OpenRouter's bring-your-own-key option has different economics from buying inference credits.

A gateway sits between your product and the model providers. This comparison covers LiteLLM's self-hosted Proxy Server, not just its Python SDK, and OpenRouter's hosted service, with both credit-funded and bring-your-own-key (BYOK) billing.

Pricing and documentation verified on 12 October 2026, including LiteLLM's live pricing and OpenRouter's live pricing. The bill below is calculated from those published fees. No signed-in trial or latency benchmark was performed.

The feature rows follow the LiteLLM architecture, OpenRouter key schema and the specific routing, logging and caching docs cited below. Provider integrations and purchasable models are different counts; neither number proves that your exact model, region and feature combination is available.

For a small product with no platform owner, start with OpenRouter unless the hosted request path violates a concrete requirement. For a product already running shared infrastructure and requiring centrally enforced per-key rate limits, choose LiteLLM. For a growing product with negotiated provider contracts, compare OpenRouter BYOK against LiteLLM, rather than applying the credit-purchase fee to both.

Who holds the keys, bills you, and forwards the request?

LiteLLM gives you the gateway boundary; OpenRouter gives you a managed intermediary. BYOK changes the upstream credential and payer, not the existence of that intermediary.

LiteLLM: your gateway, your provider accounts

LiteLLM is an open-source gateway you deploy between your application and its model providers. Its documented path checks a virtual key, applies budgets and rate limits, routes the request, then translates it into the provider's API format. A virtual key is an application credential issued by the gateway, so the application does not need each upstream provider secret. LiteLLM request architecture.

Your configured provider accounts pay for inference. Your gateway needs its own operating budget: compute, the database that supports keys and spend, and any cache or shared rate-limit infrastructure you deploy. The production deployment documentation describes those components; it does not supply a universal hosting bill.

Winner for credential and deployment control: LiteLLM. Skip it if nobody owns upgrades, database availability and failed requests. Free software does not supply that owner.

OpenRouter: hosted routing, with a choice of payer

OpenRouter is a hosted gateway and model catalogue. With purchased credits, your application uses an OpenRouter key and usage draws from that balance. With BYOK, you supply provider credentials; OpenRouter says those keys are encrypted and used for requests to the specified provider. The provider account bears the inference usage, and applicable routing fees come from OpenRouter credits. OpenRouter BYOK documentation.

The consequential default is shared-capacity fallback. When a prioritized BYOK key cannot serve a request, OpenRouter can use its own capacity and spend your OpenRouter credits. Its strongest provider-level setting is Never use shared capacity for any model on this provider. Other providers may still serve the request unless you also constrain the allowed providers. That is a payer policy, not merely an availability setting.

Winner for ready catalogue access, consolidated purchasing and gateway operations: OpenRouter. Choose BYOK when retaining provider accounts matters, but decide explicitly whether fallback may move a charge onto OpenRouter.

OpenRouter pricing: credit purchases and BYOK

OpenRouter charges for funding credits and, above an allowance, for BYOK routing. These are separate charges. Its FAQ states a 5.5% fee with a $0.80 minimum per credit purchase, and a 5% fee for crypto payments. Underlying provider inference prices pass through without markup. OpenRouter fee FAQ.

The live plan matrix labels Standard at 5.5% and Business at 8%. Both list $25,000 of list-price inference per month with no BYOK fee, then a 5% fee. Enterprise terms are custom. The worked bill uses Standard; do not apply its percentage to Business. Current plan matrix.

BYOK's fee base is what the same model and provider would normally cost on OpenRouter. It is not necessarily your discounted provider invoice. The allowance is measured in inference value, not request count, and the fee is deducted from OpenRouter credits. BYOK fee definition.

For a broader treatment of funding and usage charges, see our OpenRouter pricing guide.

LiteLLM Open Source and Enterprise

LiteLLM Open Source has no license fee, including for production. The pricing page includes virtual keys, spend tracking, budgets, rate limits, fallbacks, request/response logging and Prometheus metrics. Those are not all Enterprise-only features. LiteLLM plans.

Enterprise adds identity and organizational controls such as SSO/SCIM, OIDC/JWT authentication, audit logs, secret managers and key rotation, plus support and deployment options. Pricing is annual and depends on gateway request capacity, architecture and support needs, rather than token spend. There is no public dollar amount to insert into a fair monthly comparison; use your quote.

One monthly bill, at small and growing usage

At an illustrative $50,000 of monthly list-price inference, Standard credits cost $52,750; pure Standard BYOK costs $51,318.75 under the funding assumptions below. LiteLLM Open Source costs $50,000 plus your operating cost. These are calculations, not quoted bundles or measured workloads.

Normalize the same models, providers and token mix to a monthly inference value B. The small case uses $100; the growing case uses $50,000, twice the published BYOK allowance. Assume provider invoices equal list prices, no cache savings or negotiated discounts, no shared-capacity fallback, and a single non-crypto Standard top-up whose credits are fully consumed. Taxes and optional extras are outside this comparison.

Let H be your actual monthly LiteLLM hosting and maintenance cost. Do not replace it with an invented server estimate.

The calculation uses the credit-purchase fee and the current BYOK allowance. It assumes a pure BYOK month needs no credit purchase when no routing fee is due.

For the growing credit-funded workload, buy $50,000 of credits and add $50,000 × 5.5% = $2,750. Total cash cost: $52,750.

For the same workload through BYOK, the provider invoice is $50,000. The routing fee applies to inference above the allowance: ($50,000 − $25,000) × 5% = $1,250. Funding that fee with a Standard credit purchase adds $1,250 × 5.5% = $68.75. Total: $50,000 + $1,250 + $68.75 = $51,318.75. The funding fee is a derived consequence of paying BYOK fees from purchased credits; it is not a second fee on the provider invoice.

The crossover depends on which OpenRouter route you would use

Against Standard credits, LiteLLM saves money when H is smaller than the avoided credit-purchase fee. Above the minimum-fee range, break-even is B = H ÷ 0.055. At the small workload, only $5.50 is available to cover H; at the growing workload, $2,750 is available.

Against pure Standard BYOK, there is no routing-fee saving below the allowance. Above it, where the percentage top-up fee exceeds the minimum, break-even is B = $25,000 + H ÷ 0.05275. At the growing workload, LiteLLM must operate for less than $1,318.75 per month to win on these costs alone. An Enterprise license changes H to H plus the monthly allocation of your actual quote.

Different provider discounts, model prices, credit purchase sizes or fallback usage change the bill. Request count alone cannot locate this crossover because requests have different token costs.

Fallbacks, budgets and caching: which wins each job?

LiteLLM wins for controls you operate inside your gateway; OpenRouter wins for routing you can use without maintaining that gateway. The deciding differences are configuration and scope, not a checkmark beside “fallbacks.”

Routing and fallbacks: OpenRouter for a managed default

OpenRouter's provider router supports provider ordering, an allowlist and an allow_fallbacks control. Its separate models array tries alternative models when the primary cannot serve the request. That distinction matters: changing the provider for the same model and changing the model itself are different product decisions. Provider routing, model fallbacks.

LiteLLM documents retries within a configured model group and fallbacks to another group. You own those deployments and rules. LiteLLM routing architecture.

Winner: OpenRouter for a builder seeking managed failover. Choose LiteLLM when the approved fallback destinations are deployments you already manage. Neither a fallback list nor this comparison establishes a latency advantage.

Budgets and per-key rate limits: LiteLLM for traffic governance

LiteLLM exposes budget controls and requests-per-minute (RPM) and tokens-per-minute (TPM) limits for virtual keys. A spending cap controls accumulated cost; a rate limit controls how quickly an application can consume capacity. A customer can remain under a monthly budget while still creating an unwanted burst. LiteLLM budget and rate controls.

The named limitation is database dependence. LiteLLM's docs explicitly say budgets do not cap usage on a deployment without a database: the global budget check fails open, and key, user and team budgets are unavailable. A budget value in a configuration file is insufficient if its required backing service is absent.

OpenRouter documents per-key dollar limits, reset periods and an include_byok_in_limit setting. Its key-creation schema does not list user-configurable per-key RPM/TPM fields, while its limits page describes platform and provider capacity controls. Do not equate a key spending limit with an application-specific throughput cap. Key controls, rate and budget limits.

Winner: LiteLLM when per-key spend and throughput rules are requirements. OpenRouter supplies spending controls, but match the documented scope to the account that pays.

Logging and caching: LiteLLM for storage control

LiteLLM supports logging destinations and message redaction while retaining spend metadata. Its response cache supports local, Redis and other documented backends; exact-match caching reuses an answer for an identical request. Logging controls, cache backends.

OpenRouter offers private input/output logging as an opt-in. It also documents gateway response caching, where an identical request can return a saved response without a provider call, separately from provider prompt caching, which reuses prompt processing inside a provider. Response caching is off unless enabled and scoped to the API key. Private logging, response caching, prompt caching.

Winner: LiteLLM for choosing where gateway logs and caches live. OpenRouter is the simpler hosted option. Its specific cache limitation is worth deciding before adoption: account-level zero data retention disables response caching, while per-request provider.zdr does not change cache eligibility. Requiring a non-retaining provider does not itself disable retention in the gateway's response cache.

Data handling: ownership is not a no-egress guarantee

LiteLLM removes a hosted gateway vendor from the path; it does not make remote inference local. Its security page says: “No data or telemetry is stored on LiteLLM Servers when you self-host.” Its architecture still forwards requests to your selected model providers. LiteLLM security, request path.

That gives you control over the proxy, its logs and its configured destinations. It does not waive the upstream provider's policy or the policy of an external logging service you enable.

OpenRouter's statement is: “Any prompt retention on OpenRouter is always opt-in.” It distinguishes private debugging logs from permission to use inputs and outputs to improve its product; both switches are off by default. It stores request metadata and describes sampling a small number of prompts for categorization using a model with a zero-data-retention policy. Without the use-of-inputs/outputs opt-in, it says the categories are stored anonymously and are not tied to your account or user ID. OpenRouter data collection.

The upstream provider is another boundary. OpenRouter documents separate retention and training policies and supports endpoint filtering for zero data retention, or ZDR. Not training on data and not retaining data are different promises. Its ZDR documentation also warns that enabled plugins and tools may have their own retention policies. Provider policies, ZDR controls.

Winner for owning the gateway's data handling: LiteLLM. OpenRouter can fit a hosted-service policy, but evaluate the gateway, provider, cache and any enabled tools separately. “BYOK” alone answers none of those retention questions.

Switching from OpenRouter to LiteLLM, or back

The migration cost is rebuilding policy and accounting around the API, not just changing its address. A compatible request format does not move provider contracts, budgets, historical logs or fallback rules.

1. 1

   Map the payer and credential for every route

   For a move to LiteLLM, identify the provider credentials and accounts that replace credit-funded access. For a move to OpenRouter, choose purchased credits or BYOK and specify whether shared capacity may pay for fallback requests.

2. 2

   Map models and behavior

   Record the model identifiers or aliases your product uses, the allowed providers, supported request parameters and fallback destinations. Preserve an application's intended model behavior instead of treating every catalogue entry as interchangeable.

3. 3

   Rebuild budgets, rates and retention deliberately

   Carry over each key's spending policy, reset period and required throughput control. For LiteLLM, include the database that budgets require. For OpenRouter, decide which budgets include BYOK. Document logging and cache retention separately from provider retention.

4. 4

   Keep an accounting and rollback boundary

   Retain the old usage records according to your policy, record the cutover point and keep the previous routing configuration available. Assign ownership for reconciling provider invoices and gateway credits after the move.

Do not switch a small, working OpenRouter product to LiteLLM solely to avoid a fee smaller than the cost of owning another service. Do not move a working LiteLLM deployment to a hosted router if gateway custody is a firm requirement. And do not switch purely because a catalogue is larger without verifying the specific models and features your product needs.

Using both is supported: LiteLLM documents OpenRouter as an upstream provider. That can retain a local control point while using OpenRouter's catalogue, but it also retains OpenRouter's request path and applicable fees. It is not a way to turn hosted inference into a fully local system.

OpenRouter alternatives: Vercel and Cloudflare

Vercel AI Gateway is the first hosted fee comparison to make; Cloudflare AI Gateway is relevant when its gateway controls fit your existing infrastructure. Neither removes the need to understand which credential pays.

Vercel AI Gateway lists no token markup or platform fee, and no gateway fee for BYOK. BYOK requires purchased credits; failed BYOK requests can retry with system credentials and charge the gateway balance. Its free tier includes $5 monthly for eligible models, but buying credits ends that monthly free allowance. Payment processing fees and optional add-ons can still apply. Vercel's own pricing.

Cloudflare AI Gateway offers core analytics, caching and rate limiting free. Unified Billing adds 5% to credit purchases: its example is $100 of credits for a $105 charge, with provider inference prices passed through. New customers whose first gateway was created on or after 24 September 2026 use Workers Logs pricing, so free gateway features do not imply unlimited free logging. Cloudflare's own pricing.

For those new logging accounts, Workers Paid includes 20 million logs per month, then $0.60 per additional million; the Free plan lists 200,000 logs per day. Workers Logs pricing. Our Cloudflare payer-control article explains credential rules, and our OpenRouter alternatives comparison covers the wider shortlist.

Questions builders ask before choosing

OpenRouter vs LiteLLM: who holds my provider keys?

With self-hosted LiteLLM, you control the gateway's provider credentials. With OpenRouter BYOK, you supply provider keys to the hosted service, which says it encrypts them. Credit-funded OpenRouter usage does not require you to supply each provider's key.

Can I keep my provider contracts with OpenRouter?

BYOK lets requests use your provider accounts. The provider's invoice, OpenRouter's list-price-based BYOK fee and any shared-capacity fallback are separate billing considerations. The fee-free allowance does not make the provider's inference free.

Is LiteLLM cheaper as usage grows?

Only when its operating cost, plus any Enterprise license, is smaller than the OpenRouter fees you would avoid. Compare against the BYOK fee when that is your alternative; applying the credit-purchase percentage to the entire BYOK provider invoice overstates the saving.

Can I use LiteLLM with OpenRouter?

Yes. LiteLLM documents an OpenRouter provider integration. You keep both routing layers, so you also keep the relevant operating costs, OpenRouter fees and hosted data path.

Get the AI Business Workflow Audit Checklist through the newsletter to map your provider keys, model spend and fallback owner before changing gateways.