Does self-hosting LiteLLM cost less than OpenRouter's fees?
Self-hosting LiteLLM tends to cost less only when your monthly model spend is high enough that OpenRouter's platform fee exceeds the fixed cost of running the gateway. OpenRouter charges a 5.5% or 8% fee on credit purchases, and a 5% fee on bring-your-own-key (BYOK) usage above the monthly allowance. Where your spend crosses that line depends on your own numbers, not on a universal threshold. The license line is usually zero for the core gateway, because LiteLLM is MIT licensed outside its enterprise directory. Enterprise features such as SSO beyond 5 users, SCIM and audit logs are a separate cost.
The recurring costs sit in infrastructure and people. LiteLLM's production guide names PostgreSQL as the primary database, and virtual keys with budgets depend on it. Redis 7.0 or newer becomes necessary once more than one proxy instance runs, for shared rate limits and router state. The guide suggests 1 vCPU and 4 GiB of memory per worker as a starting point. Your staff pays for upgrades, backups, monitoring and on-call coverage. Provider charges still apply in both models, so confirm the rates you would pay each provider directly and whether any BYOK fee applies to your traffic.
Build a simple comparison with your last twelve months of spend: the fee at your credit purchase volume, against cloud compute, PostgreSQL, Redis, storage, and the share of engineering time you expect to spend. Ask any implementation partner for a fixed-scope written quote that lists setup, hardening and support separately, and ask LiteLLM whether your enterprise feature needs require a license. DeployOpen implements and supports self-hosted gateways in your own cloud or data center, and a written scope gives you a basis for that comparison.
Which cost components sit on each side
This table sets out which cost components fall on the OpenRouter side and which fall on the self-hosted LiteLLM side, and whether each recurs or is paid once. Use it as a checklist when you request a like-for-like quote. The main takeaway is that OpenRouter's fee is a single line, while self-hosting moves cost into infrastructure, operations and staff time.
| Cost component | OpenRouter side | Self-hosted LiteLLM side | One-time or recurring |
|---|---|---|---|
| Platform or license fee | Platform fee on credit purchases (5.5% or 8%, per OpenRouter's stated terms); 5% BYOK fee above the monthly allowance | LiteLLM core is MIT licensed with no license fee; Enterprise license needed for SSO beyond five users and for audit logs | OpenRouter fee recurring; LiteLLM core none, Enterprise recurring if chosen |
| Model usage billing | Provider usage billed through OpenRouter, with the platform fee applied on top | Paid directly to each provider under your own accounts; the gateway does not bill for tokens | Recurring, scales with request volume |
| Infrastructure (compute, PostgreSQL, Redis, log storage) | None on your side | Gateway hosts, PostgreSQL as the primary supported database, Redis 7.0 or newer once several instances run, and log storage | Recurring, sized by traffic and retention |
| Implementation and configuration | Account setup and model selection | Virtual keys, budgets, routing, fallbacks, logging and deployment to your Kubernetes cluster | One-time build, with ongoing changes |
| Migration of base URLs and keys | Applications use one OpenRouter key and endpoint | Open direct provider accounts, reissue keys as virtual keys and switch application base URLs | One-time, per application |
| Support and on-call | Covered by the vendor under your plan's support terms; confirm the terms in writing | Your team or a retained partner covers gateway, database, Redis and provider incidents | Recurring |
| Upgrades | Handled by the vendor | Track LiteLLM releases; it supports the four most recent stable minor versions, so plan upgrades within that window | Recurring |
| Internal skills | Minimal platform knowledge needed | Kubernetes, PostgreSQL, Redis, secret management and provider billing, held in-house or contracted | Staffing recurring; ramp-up one-time |
What moves the comparison up or down
Self-hosting LiteLLM trades a per-spend platform fee for fixed infrastructure and staff time. Six drivers decide which side of that trade wins for a given organization, and most of them interact, so check them together rather than one at a time.
Monthly model spend
OpenRouter's fee grows with every dollar you route through it, so the fee is the component that scales fastest. Self-hosting costs grow more slowly, mostly with servers and operations, not with tokens. Your own spend is the main input: pull twelve months of invoices, split them by provider, and model the fee at your current and expected volume. Ask whether any routed spend is credit purchases versus bring-your-own-key traffic, since the two carry different fees.
Number of teams and virtual keys
LiteLLM virtual keys support per-key, per-user and per-team budgets, rate limits and model restrictions, and each team you add means more keys to issue, rotate and reconcile. The more teams share one gateway, the more the chargeback and budget work is worth automating and the more the gateway's fixed cost is spread out. Count the teams that need separate budgets today and in the next year, and decide who owns key lifecycle.
Availability requirements
A single LiteLLM proxy instance is simple, but once you run more than one for high availability, shared rate limits, router state and cache need a shared store. LiteLLM's production guide asks for Redis 7.0 or newer at that point, and PostgreSQL is the primary supported database. Each added instance, replica and failover path adds servers, monitoring and on-call load. Ask whether an outage of the gateway is acceptable for your workloads, and what uptime your internal users expect.
Logging and retention volume
Logging is where self-hosting costs hide. Request and response logs, spend records and traces can grow quickly, and you own their storage, backup, access control and deletion. LiteLLM can send logs to Langfuse, Datadog, OpenTelemetry and Prometheus, and each destination carries its own bill or operating burden. Decide which prompts may be stored at all, how long they are kept, and who may read them before choosing a logging stack.
Identity requirements that push toward Enterprise
The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC, and from v1.76.0 SSO is free for up to 5 users. Beyond that, SCIM, JWT authentication, audit logs, organization and team RBAC, and secret manager integrations sit in the Enterprise license. If your auditors expect audit logs, SCIM deprovisioning or vault-backed keys, budget for the license and confirm its terms in writing before treating the gateway as free to run.
Skills already on staff
Running a gateway means someone must upgrade it, patch PostgreSQL and Redis, tune workers and rotate the master key, which must start with sk- and live in a secret manager. Teams that already run Kubernetes, managed databases and secret stores absorb this quickly, while others pay for it in hiring, training or outside support. Inventory who would carry the pager, how often LiteLLM's releases are taken, and whether a retainer or internal rota is the cheaper way to cover it.
What the self-hosted stack needs from your infrastructure
LiteLLM runs as a Python proxy server that your applications call through one OpenAI-compatible endpoint, so the stack you operate is the proxy plus its data stores. The production guide names PostgreSQL as the primary supported database, and it is not optional for the controls that matter most here: virtual keys, per-key, per-user and per-team budgets, and spend tracking all depend on it. Plan for a managed or self-managed PostgreSQL instance with backups, restore testing and access controls in your own environment, and confirm with your database team how it will be patched and monitored.
Redis becomes required once you move beyond a single proxy instance. The guide asks for Redis 7.0 or newer for shared rate limits, router state and cache, so that every replica enforces the same limits and failover decisions. Each proxy worker is sized in the guide at a starting point of 1 vCPU and 4 GiB of memory. Treat those figures as a baseline to validate with your own traffic, not as a capacity promise. On Kubernetes, LiteLLM recommends one Uvicorn worker per pod and scaling horizontally by adding pods, and it recommends keeping the LITELLM_MASTER_KEY (which must start with sk-) in a secret manager rather than a plain environment file.
Two operational details decide whether the database holds up at volume. First, spend is written to PostgreSQL in batches, and the production guide describes batching spend updates every 60 seconds at scale. Expect spend figures in the admin views and budget checks to lag by up to that interval, and confirm with your finance team whether that lag is acceptable for chargeback. Second, the stack adds recurring work: database and Redis upgrades, LiteLLM version upgrades (the project supports the four most recent stable minor versions), and on-call coverage for the proxy. Ask any implementation partner to price these as ongoing responsibilities in the written scope, because they are the largest share of cost that a platform fee otherwise hides.
How to build the comparison with your own numbers
This sequence turns OpenRouter invoices and your own infrastructure rates into a side-by-side monthly total, so the decision rests on your spend and not on a generic estimate.
Export twelve months of OpenRouter spend
Finance or the platform owner downloads your OpenRouter usage and billing records for the last twelve months and breaks spend down by model and by API key. Keep the export in a spreadsheet with one row per month, model and key. You know this step is done when the monthly totals in the sheet reconcile with the invoices or credit receipts for each month.
Separate credit purchases from BYOK usage
Split the export into two groups: spend that came through credit purchases, which carries OpenRouter's platform fee of 5.5% or 8% depending on the purchase, and usage routed through your own provider keys (BYOK), which carries a 5% fee only above the monthly allowance. Confirm the current fee terms in writing with OpenRouter, because the rate and allowance that applied last year may not apply to next year. Done when each row is tagged as credit or BYOK and the fee you would have paid is calculated per group.
List the direct provider accounts you would open
Engineering and procurement list every model provider you would contract with directly, such as the vendors behind the models in your export, and note each provider's billing terms, minimum commitments, rate limits, data processing terms and regional endpoints. Ask each provider for its current published pricing and written terms rather than assuming they match what OpenRouter passes through. Done when each provider has a row with its pricing source, payment terms and the contract owner named.
Price your compute, PostgreSQL and Redis
The platform team prices the infrastructure LiteLLM needs from your cloud or data center rate card: proxy compute sized for at least two instances for availability, managed PostgreSQL for virtual keys and spend records, and Redis 7.0 or newer once more than one proxy instance runs for shared rate limits and router state. Add egress, backup storage and any logging backend you choose. Confirm sizing against LiteLLM's production guidance, which suggests 1 vCPU and 4 GiB memory per worker. Done when you have a monthly infrastructure line for each component, with the rate card and region noted.
Estimate engineering hours for operations
Engineering leadership estimates the hours needed for initial deployment, configuration of keys, budgets and routing, upgrades, security patching, monitoring and on-call coverage. Count one-time work separately from recurring work, and note which tasks would stay with an implementation partner under a fixed-scope engagement or retainer. Your hours estimate is your own assumption, so label it as such in the model. Done when each activity has an hour range, an owner and a one-time or recurring tag.
Add Enterprise license cost only when required
Add a LiteLLM Enterprise line only if your requirements call for it. Per the supplied facts, SSO is free for up to 5 users from v1.76.0, and an Enterprise license is needed beyond that, while audit logs, organization and team RBAC, and SCIM sit in the Enterprise tier. Request a written quote from LiteLLM covering the user count and features you need, and confirm whether the license is priced per year or per seat. Done when the line is either set to zero with the reason recorded or filled with the quoted amount and its term.
Compare monthly totals at current and projected spend
Build a sheet with two columns, one for the OpenRouter path including fees and one for the self-hosted path including provider invoices, infrastructure, engineering time and any license. Run the comparison at your current monthly spend and at a projected figure you state as an assumption. Look for the spend level where the self-hosted total falls below the hosted total, and identify which inputs move that point most. Done when both totals are on one page, every number has a named source, and vendor quotes are attached in writing.
Questions buyers ask before comparing costs
How much effort does self-hosting LiteLLM take, and can our team do it alone?
Your team can run it alone if it already operates containers, a PostgreSQL database and a secrets store, and has someone who owns the gateway. The effort comes from the supporting services rather than the proxy itself: PostgreSQL is the primary supported database for LiteLLM, Redis 7.0 or newer is required once more than one proxy instance runs, and the production guide suggests 1 vCPU and 4 GiB memory per worker as a starting point. Confirm with your platform team how many instances you need, whether Kubernetes is available, and who is on call for an outage. Ask any implementation partner for a written scope that names each of these components before comparing hours.
What recurring work follows a LiteLLM deployment?
The recurring work is upgrades, security patches, monitoring and key management, and it continues for as long as the gateway serves production traffic. LiteLLM maintains support for the four most recent stable minor versions, so you need a schedule to move forward before older versions drop out of support. Plan for dashboards and alerts on the proxy, PostgreSQL and Redis, rotation of the master key stored in a secret manager, review of virtual keys and budgets, and provider credential changes. If you run LiteLLM Enterprise, add license renewal to the list. Ask any partner to state whether patching, upgrades and testing are one-time or a retainer, and what each covers.
How long does a migration from OpenRouter take, and what changes the duration?
Migration length depends on how many applications and model names you have, how many provider accounts you must open, and how much fallback and routing behavior you need to recreate. Teams with a small model list and one application usually move faster than teams with many services, each with its own keys and retry logic. Other drivers include procurement for direct provider contracts, legal review of data processing terms, and testing of responses across providers. This page does not give a figure because the inputs differ by organization. Ask for a timeline in the written scope, tied to a named inventory of applications and models.
Does the free LiteLLM SSO tier cover our team size?
The free SSO tier covers up to 5 users, and it applies from LiteLLM v1.76.0 onward. Beyond that limit, SSO requires an Enterprise license. Count the people who will sign in to the admin UI, not the number of applications or API keys, because virtual keys do not consume SSO seats. If your identity provider is Google, Microsoft Entra ID, Okta or a generic OIDC provider, the admin UI supports it, but confirm the exact setup with LiteLLM's current documentation. Enterprise also adds SCIM, audit logs and team RBAC, so a team that needs those features should price them together.
What happens to the cost comparison if only one team uses the gateway?
With one team, the fixed costs of running the gateway are spread across fewer requests, so the monthly spend needed to justify self-hosting rises. The gateway still needs PostgreSQL, Redis once you run multiple instances, compute, storage for logs, and someone to maintain it. Those costs do not shrink much when a single team uses them. Compare the platform fee you pay OpenRouter on your actual monthly credit purchases against your own infrastructure and staff time, and include direct provider billing as a separate line. For a single team, the answer often depends on whether you also need the governance features, not on the traffic alone.
When does outside help change the cost math?
Outside help changes the math when internal staff cannot cover the setup, the upgrade cycle or the on-call load, or when the team needs a fixed-scope delivery with written deliverables. DeployOpen plans, implements, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not publish a price list, so ask for a quote based on the written scope and compare it with the recurring internal effort you would otherwise carry.
Which costs stay the same after we move off OpenRouter?
Model provider charges stay. Under a self-hosted gateway you pay each provider directly for tokens, so the usage charges move from OpenRouter's billing to your provider accounts rather than disappearing. What changes is the platform fee and the infrastructure you take on. Ask your providers about committed-use discounts, rate limits and invoicing terms, because those depend on your account, not on the gateway. Keep a line item for logging storage and observability tools, since LiteLLM sends logs to Langfuse, Datadog, OpenTelemetry or Prometheus and those tools carry their own costs.
When the monthly spend justifies running the gateway
Self-hosting pays off when the platform fee you avoid is larger than the recurring cost of running the gateway, which includes infrastructure and a share of engineering time. The fee to model is OpenRouter's 5.5% or 8% on credit purchases, plus the 5% BYOK fee above the monthly allowance, applied to the spend you would route through it. Direct provider billing removes that fee but adds the servers, PostgreSQL, Redis and the people who patch, back up and monitor them. LiteLLM's production guide names PostgreSQL as the primary supported database and requires Redis 7.0 or newer once more than one proxy instance runs, so a team starting from zero takes on both as new services. Separate one-time setup from the recurring run cost before comparing totals.
The break-even moves quickly with the platform you already operate. If your organization already runs PostgreSQL, Redis and Kubernetes with monitoring and on-call coverage, the added infrastructure cost is mostly a few more workloads, and the main expense becomes upgrade and maintenance time. Low monthly spend changes the result sharply, because the fee you save may be smaller than the hours spent on upgrades, key rotation, provider account administration and incident response. LiteLLM maintains support for the four most recent stable minor versions, so staying supported means upgrading on a regular schedule. A single-developer team or an organization without operations capacity often keeps the hosted service, and that is a reasonable result of the calculation.
The threshold is your own calculation, and this page does not set one. Start with monthly routed spend per provider, apply each fee that would disappear, then subtract the recurring infrastructure cost and the engineering hours you expect to spend each month on upgrades, on-call and key management. Ask your DeployOpen or internal team to estimate those hours from your own environment, and confirm current OpenRouter fee terms directly with the provider before deciding. Include a risk line in the model: a self-hosted gateway becomes a shared dependency for every application that calls a model, so its availability, failover and recovery targets need to be planned and funded, not assumed. Re-run the calculation when spend, provider count or team size changes.
How DeployOpen scopes a fixed-scope LiteLLM cost and implementation review
DeployOpen is a Chainscore Labs company that plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For OpenRouter cost vs self-hosted LiteLLM, we start with your actual provider bills, traffic and data constraints, then agree the scope in writing before any build work begins.
How we scope
- We inventory the OpenRouter fees, provider accounts and models your applications call today.
- We size the LiteLLM deployment for your traffic, including PostgreSQL, Redis and the servers that run the proxy.
- The written scope lists deliverables, timelines and the cost model you will receive before work starts.
- Engagements are fixed-scope, and the quote follows directly from that written scope.
How we build
- We deploy LiteLLM in your infrastructure with PostgreSQL and Redis configured for multiple proxy instances.
- We set up virtual keys, per-team budgets and rate limits to match the spend approvals you already have.
- We configure fallbacks and routing, then test failover against the providers you have contracted.
- We connect logging to your monitoring stack and secure the master key in your secret manager.
How we hand over
- You receive architecture notes, configuration documentation and a runbook for keys, budgets and provider changes.
- We document the monthly cost model so your finance and engineering teams can track provider and infrastructure spend.
- We walk your platform team through operations, upgrades and the process for moving applications off OpenRouter base URLs.
- We prepare the evidence your compliance reviewers need, while independent auditors issue any formal assessment.
How we support
- Ongoing support, version upgrades and continuous testing are available as a retainer.
- We can review spend reports and routing settings on a schedule agreed in the retainer scope.
- Security testing of the gateway and its integrations can be added to the scope as a separate written engagement.
- Any change to scope, deliverables or timelines is documented in writing before it takes effect.
