Migrate from OpenRouter to self-hosted LiteLLM

How do you migrate from OpenRouter to LiteLLM without an outage?

The migration is a re-plumbing job: you move provider keys, accounts, model names and application base URLs from OpenRouter's hosted router to a LiteLLM gateway you run, and you can run both paths in parallel until traffic has moved. Platform or infrastructure engineering usually leads the work, with a security reviewer signing off on key handling, network paths and logging. LiteLLM is a self-hosted AI gateway that exposes one OpenAI-compatible endpoint and calls more than 100 providers, including OpenAI, Anthropic, Gemini, Bedrock and Azure, so most applications change only their base URL and model identifiers. The harder part is operational: your team opens its own accounts with each provider it uses, holds those keys and billing relationships, and runs the gateway's own infrastructure, including PostgreSQL as the primary supported database for virtual keys and spend tracking, and Redis 7.0 or newer once more than one proxy instance runs.

Start by inventorying what your applications actually call. List every OpenRouter model identifier in use, the providers behind each one, and any OpenRouter-specific settings such as provider preferences or fallback order. Then create a LiteLLM model group for each logical model your applications depend on, with deployments pointing at your direct provider accounts. Recreate fallbacks and retry behavior in the LiteLLM router, which supports priority ordering for failover, retries and cooldowns after repeated failures. Confirm the routing strategy you choose, for example simple-shuffle, which LiteLLM recommends, or a latency or cost-based option. Issue virtual keys per application or team with budgets, rate limits and model restrictions, and store the master key in a secret manager. Test each model group with production-like traffic before any base URL changes.

Cut over one application or one environment at a time. Point a non-critical service at the LiteLLM endpoint, compare response shape, latency, error rates and spend against OpenRouter for a defined window, then widen the rollout. Keep the OpenRouter key active until every caller has moved and you have confirmed that no scheduled job or forgotten service still uses it, because that is the most common source of surprise traffic during a migration. Plan the rollback path in writing: which base URL to restore, who can do it, and how long the team needs to act. The effort depends on how many applications, providers and model names you have, and on how much of your team already runs PostgreSQL and Redis. Ask your own engineers and any implementation partner for an estimate tied to that inventory rather than relying on a generic figure.

Which OpenRouter capabilities map cleanly to LiteLLM, and which need rework

This table maps each OpenRouter capability to its LiteLLM equivalent and labels the migration effort as clean, needs rework or gap. Read the migration note as the work you should plan for, and confirm any row marked for OpenRouter with the vendor before you cut over. The main takeaway is that the application-facing API and gateway controls move across cleanly, while billing, provider contracts and OpenRouter-specific routing syntax need manual work.

Capability	LiteLLM equivalent	Migration note
OpenAI-compatible endpoint	LiteLLM proxy exposes one OpenAI-format endpoint for 100+ providers	Clean. Applications change the base URL and API key; request format stays the same
Model access across providers	Model list in the proxy config, with each provider called through its own key	Needs rework. Map each OpenRouter model slug to a LiteLLM model group and add a direct provider key for each
Virtual keys with budgets	Virtual keys with per-key, per-user and per-team budgets, backed by PostgreSQL	Clean. Recreate keys per application or team; budgets must be set again because they do not transfer
TPM and RPM limits	Per-key and per-team TPM and RPM limits	Clean. Translate existing OpenRouter limits into LiteLLM values during pilot testing
Model restrictions per key	Keys restricted to specific models	Clean. Define allowed model groups for each key before issuing it to applications
Fallbacks and priority ordering	Fallback chains and priority ordering for failover, with retries and cooldowns	Needs rework. Rebuild each fallback chain by hand and test failover against the direct provider accounts
Routing strategies	Simple-shuffle, usage-based, latency-based, least-busy and cost-based routing	Needs rework. Choose the strategy per model group; behavior will differ from OpenRouter's hosted router
Provider preference syntax	Provider-specific settings in LiteLLM configuration	Needs rework. Confirm each OpenRouter provider preference with OpenRouter and rewrite it in LiteLLM config
Spend tracking and logging	Logging callbacks to Langfuse, OpenTelemetry and Prometheus	Needs rework. Set up the logging backend yourself; spend data is only as complete as the callbacks you enable
Hosted credit purchases and account billing	No equivalent. You pay each provider directly and track invoices yourself	Gap. Confirm with OpenRouter how credits and unused balances are handled before you stop funding the account

What data, keys and integrations move, and what you must recreate

Moving from OpenRouter is less a data transfer than a rebuild: provider relationships, application keys, model names and history each move differently. The cards below list what changes hands, what you reissue or recreate in LiteLLM, and what to confirm before you cut over.

Provider credentials

Your provider keys do not move out of OpenRouter. Each provider you use needs a direct account in your organization's name, with its own billing, rate limits and key rotation. Confirm which models you currently reach through OpenRouter's routing, check each provider's terms for API use by your own gateway, and store the new keys in a secret manager rather than in LiteLLM configuration files.

Application API keys

Application keys issued by OpenRouter cannot be carried over. Reissue each application, team or user access as a LiteLLM virtual key with its own model allow-list, budget and TPM or RPM limits. Virtual keys need a PostgreSQL database, so plan that database and its backups before the first application switches over.

Model name mappings

OpenRouter identifies models by its own slugs, which often include a provider prefix. Map each slug your applications send to a LiteLLM model group, then point that group at one or more provider deployments. Keep the application-facing names stable so that code changes are limited to the base URL and key, and test each mapping against the provider's current model list.

Usage and spend history

Do not promise historical spend or request data in LiteLLM until you have confirmed the export path for your OpenRouter account and plan. Ask OpenRouter which usage and activity records you can download, in what format, and for what period. Keep any exported records as a read-only archive, since LiteLLM spend tracking starts from the day it goes live.

Observability and SSO integrations

Logging, dashboards and admin sign-in do not follow the models. LiteLLM can send logs to Langfuse, OpenTelemetry and Prometheus, so decide where traces go before cutover. The admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC, and SSO is free for up to 5 users, with an Enterprise license needed beyond that. Confirm this limit against the current LiteLLM terms before you rely on it.

What happens at each step of the migration from OpenRouter

The sequence moves traffic from OpenRouter to a LiteLLM gateway you run in your own infrastructure in controlled stages, so each stage produces evidence before the next one starts. Every step closes with a named artifact that the next step depends on.

Inventory every model string and key
Your team lists every model identifier that applications send to OpenRouter, every API key and the service or team that owns it, each fallback chain, each provider preference and each integration that calls the endpoint, including batch jobs and evaluation scripts that are easy to forget. The output is a mapping sheet that pairs each OpenRouter model name with a LiteLLM model group, the direct provider account that will serve it, and the owner who signed off. The step is done when every production call path appears on the sheet and the owners have confirmed it.
Pilot one non-critical service
Deploy a LiteLLM instance in your environment, backed by PostgreSQL, and connect it to direct provider accounts that your organization has opened. Route one non-critical service through it, issue a virtual key with a budget and confirm that fallbacks, retries and logging behave as the mapping sheet says they should. Ask your provider contacts to confirm current rate limits and data handling terms for the accounts you open, since these vary by provider. The output is a test report listing each scenario, the result and any gap that needs a fix before the next step.
Run both paths in parallel
Keep OpenRouter and the LiteLLM gateway live at the same time, either by splitting a share of traffic between them or by shadowing requests to LiteLLM and discarding its responses. Compare response latency, error rates, token counts, cost per request and fallback behavior across both paths, and check that the spend recorded in LiteLLM matches what the provider invoices show. If you run more than one LiteLLM proxy instance, confirm that Redis 7.0 or newer is in place, because shared rate limits, router state and cache depend on it. The output is a set of parity metrics that the cutover owner reviews and signs off.
Cut over base URLs in stages
Switch application base URLs to the LiteLLM endpoint one service group at a time, starting with the lowest-risk groups and keeping the OpenRouter configuration in each service so it can be restored quickly. Keep LITELLM_MASTER_KEY in a secret manager, not in configuration files, and issue virtual keys to each application instead of sharing the master key. Record every change and the rollback command for it. The output is a runbook that names the order of services, the check after each switch and the person who can trigger a rollback.
Decommission OpenRouter access
After every service has run on LiteLLM for a period your change board agrees, revoke the OpenRouter API keys and remove any stored credentials for them from CI systems, scripts and secret stores. Export and archive the OpenRouter usage records and your LiteLLM spend and request logs under your retention policy, and confirm with your finance team that any open OpenRouter credit balance or billing dispute is closed. The output is a closure record that lists revoked keys, archived locations, the final parity result and the sign-off of each owner from step one.

What drives the cost and duration of moving off OpenRouter

This table lists the factors that change how much a move from OpenRouter to a self-hosted LiteLLM gateway costs and how long it takes, and how to keep each one under control. Read it as a checklist for scoping and for comparing written quotes. The main takeaway is that the number of teams, keys and fallback rules usually matters more than the raw server count.

Driver	Why it matters	How to keep it down
Models and providers in use	Each provider needs its own account, keys, terms and model name mapping, and each model may need its own fallback and test cases. Many OpenRouter routes can mean many direct contracts to manage.	Inventory the models your applications actually call and retire unused ones before migration. Start with a short list of providers and add others later.
Teams, applications and keys	Each team or application needs virtual keys with budgets and model restrictions, and each key is a control to test and document. Key sprawl adds design and admin work.	Group keys by team and use team-level budgets instead of one key per service. Ask the quote to state how many keys and teams are in scope.
Custom fallback and routing logic	LiteLLM supports simple-shuffle, usage-based, latency-based, least-busy and cost-based routing, plus priority failover and session affinity. Each custom rule must be designed, reproduced and tested against OpenRouter's current behavior.	Document the routing behavior your applications rely on today. Keep to the routing modes you need and test failover paths in a staging environment.
Compliance evidence needs	If you must show access control, logging and change records to an assessor, you need to build and retain that evidence. Audit logs and SSO are Enterprise features in LiteLLM beyond the free SSO user limit, which affects licensing cost.	Confirm early which controls your assessor expects. Ask the vendor which features need an Enterprise license and whether SSO user counts apply to your organization.
High availability components	Production LiteLLM uses PostgreSQL as the primary database and needs Redis 7.0 or newer once more than one proxy instance runs for shared rate limits, router state and cache. Each component adds hosting, backup and monitoring work.	Size PostgreSQL and Redis as managed or self-run services according to your own standards. Ask for the HA design, backup and restore tests in the written scope.
Proxy sizing and scaling	LiteLLM recommends one Uvicorn worker per pod on Kubernetes and scaling horizontally. The production guide suggests 1 vCPU and 4 GiB memory per worker as a starting point, so instance count grows with traffic and redundancy needs.	Load test with your real request profile before setting capacity. Treat the suggested sizing as a starting point, not a commitment, and confirm it in your environment.
Spend tracking at scale	LiteLLM batches spend updates to the database every 60 seconds at scale. Budgets and spend reports can therefore lag behind real usage, which matters for cost control and chargeback.	Agree on acceptable reporting lag with finance and budget teams. Set alerts on provider billing as well, since the gateway view is not the invoice.
Observability integration	Logging to Langfuse, Datadog, OpenTelemetry or Prometheus needs dashboards, alerts and retention decisions. Self-hosting Langfuse adds its own stack of web, worker, PostgreSQL, ClickHouse and Redis or Valkey services.	Reuse existing monitoring where possible and limit the first release to metrics and key request logs. Ask the quote to separate gateway observability from any LLM tracing platform.
Parallel-run window	Running OpenRouter and LiteLLM side by side keeps two spend streams, two sets of keys and two configurations active. The longer the window, the higher the recurring cost of both platforms and the on-call load.	Plan cutover by application and environment with clear rollback steps. Set an exit date for OpenRouter access in the statement of work.

What usually goes wrong when teams move LLM traffic off OpenRouter

OpenRouter hides several decisions behind one API key and one bill: model naming, provider accounts, fallbacks and spend limits. When traffic moves to a self-hosted LiteLLM gateway, each of those decisions becomes your team's job. The cards below cover the failure points we see most often and the check to run before cutover.

Model names drift between providers

OpenRouter identifiers such as vendor-prefixed slugs do not always match the model strings that Anthropic, OpenAI, Gemini or Bedrock expect. A LiteLLM config that maps a name incorrectly can send traffic to a different model version or fail only for one provider. Build a mapping table from every model your applications call, then send a fixed test prompt through each LiteLLM model group and compare the returned model field against the provider's documented identifier. Confirm the exact string against each provider's current model list before you commit the config.

Inherited budgets and limits disappear

On OpenRouter, credit balances and key limits set in the dashboard may have been the only spend control your teams relied on. LiteLLM does not copy those limits. Until you create virtual keys with per-key, per-user or per-team budgets and TPM or RPM limits, any application key can spend against your provider accounts without a ceiling. Inventory every OpenRouter key and its owner, then issue replacement virtual keys with explicit budgets and model restrictions before any application is switched over.

Fallbacks never tested under errors

Teams often assume that a fallback chain configured in LiteLLM will take over when a provider returns rate limit or server errors. Until you test it, you do not know whether retries, cooldowns and priority ordering behave as the config implies. Simulate failures by pointing a model group at an invalid key or a deliberately exhausted account in a staging environment, then confirm the request reaches the next provider and that the response reports which model served it. Repeat the test for each fallback path your applications depend on.

Single proxy instance with inconsistent limits

Running one LiteLLM proxy instance works for a pilot, but a second replica without shared state gives each instance its own view of rate limits, router state and cache. Budgets and TPM limits can then appear to apply inconsistently depending on which pod serves a request. LiteLLM's production guidance calls for PostgreSQL as the primary database and Redis 7.0 or newer once more than one proxy instance runs. Before scaling out, confirm both services are reachable from every replica and test a limit by sending traffic to each instance.

Master key stored in config files

The LiteLLM master key, which must start with sk-, grants administrative control over the proxy, including creating keys and changing budgets. Teams migrating quickly often place it in a YAML file or a Helm values file that is committed to Git or copied into container images. Store LITELLM_MASTER_KEY and provider API keys in a secret manager or Kubernetes secrets, restrict who can read them, and rotate the master key after the migration team hands off. Review the repository history for any key that was committed during testing.

Provider accounts not ready at cutover

OpenRouter let your team reach many providers through one billing relationship. After migration, each provider you call needs its own account, billing contact, spend cap and contract terms. Teams often discover at cutover that a provider requires organization verification, has no spend limit set, or has data processing terms that legal has not reviewed. Open and fund direct accounts for every model group before routing live traffic, set provider-side spend caps that match the LiteLLM budgets, and record which contract covers each provider's data handling.

How the migration changes by team size and starting point

A single team with a few models and one application usually has the smallest migration. One LiteLLM proxy with one PostgreSQL database can serve the application, and the team may only need a handful of virtual keys, often one per environment or per service. Because there is one owner, most routing and budget decisions can be made in a single configuration file and reviewed in one sitting. The main work is opening direct accounts with each provider the application uses, mapping the OpenRouter model names the code already sends to LiteLLM model groups, and switching the base URL once the proxy answers the same requests.

Virtual keys: Expect few keys, so budgets and model restrictions can be set by hand and tracked in a spreadsheet during the first weeks.
Enterprise features: SSO, audit logs and team management are usually not needed, and the open-source gateway covers routing, fallbacks and spend tracking.
Redis and PostgreSQL: A single proxy instance can run without a shared Redis for rate limits, since Redis becomes required once more than one proxy instance runs.
Fallbacks: Recreate the one or two fallback chains the application relies on, then test each one by forcing a provider error in a staging environment.
Cutover: A single base URL change, with a rollback to the OpenRouter key kept ready, keeps the switch short.

Before cutover, confirm that the provider accounts, billing limits and the LITELLM_MASTER_KEY storage are in place, since those are the items a single team most often forgets.

What do buyers ask before moving from OpenRouter to LiteLLM?

How much effort and cost does moving from OpenRouter to LiteLLM involve?

The move costs more in people and infrastructure than in software, because LiteLLM is MIT licensed outside its enterprise directory and the core gateway carries no license fee. The cost components are: direct accounts and billing with each provider you use, servers or a Kubernetes cluster to run the gateway, a PostgreSQL database for virtual keys and spend tracking, Redis 7.0 or newer once more than one proxy instance runs, and the engineering time to configure, test and operate it. Setup is largely one-time work, while infrastructure, provider usage and on-call effort recur. Ask any partner for a quote built from a written scope that lists each of these components separately, and ask whether LiteLLM Enterprise is priced into it.

How long does an OpenRouter to LiteLLM migration take?

The timeline depends on how many models, applications and teams sit behind OpenRouter today, how many provider accounts must be opened and approved, and how much logging, SSO and budget policy must be rebuilt. Provider account approval is often outside your control, so it is the first item to start and the most common source of delay. Application cutover is usually the shortest step, because it is a base URL change that can be staged per service. Confirm the duration with a fixed-scope plan that sets milestones and acceptance tests before any work begins, since DeployOpen engagements are scoped and timed in writing.

What does the migration require from our own engineering team?

Your team needs to own the decisions that OpenRouter currently makes for you. Expect to name a platform owner, provide a Kubernetes or VM environment, supply a PostgreSQL instance and Redis, and grant access to a secret manager for LITELLM_MASTER_KEY, which must start with sk-. Application teams must agree on model group names, budgets per key, team or user, and which fallback order is acceptable for each workload. Security and finance should review how provider keys are stored and how spend is reported. Your team also needs someone who can read gateway logs and respond when a provider rate limit or cooldown affects production.

Can one capable engineer move from OpenRouter to LiteLLM without outside help?

A capable engineer with Kubernetes, PostgreSQL and API gateway experience can run a small LiteLLM pilot alone, using the official proxy documentation and the production guidance on one Uvicorn worker per pod with horizontal scaling. Production readiness is harder. It requires shared state across instances, secret handling, key rotation, monitoring, upgrade planning under LiteLLM's support policy for the four most recent stable minor versions, and tested failover when a provider degrades. Most teams find the risk sits in the operating model, not the first deployment. Ask whether a partner can cover only the parts you lack, such as hardening, backup or upgrades, under a fixed scope.

Do we need LiteLLM Enterprise for SSO and audit logs?

Not for every case. The LiteLLM admin UI supports SSO with Google, Microsoft Entra ID, Okta and generic OIDC providers, and from v1.76.0 SSO is free for up to 5 users, with an Enterprise license required beyond that. Audit logs, SCIM, organization and team RBAC, IP allowlisting, JWT authentication for identity provider tokens and secret manager integrations sit in the Enterprise offering, and code under the enterprise directory carries its own license. Confirm the current user count, the license terms in the LiteLLM LICENSE file and the Enterprise feature list with LiteLLM before you decide, because a license decision belongs with your procurement and legal teams.

How do we keep request history and logs after we decommission OpenRouter?

Export and retain what you need before you cancel OpenRouter, because access to its dashboard history is not something you should assume after shutdown. Decide which records matter: request metadata, spend by key and team, error and fallback events, and any prompt content your policy allows you to keep. In LiteLLM, route logs to your own observability stack, such as Langfuse, Datadog, OpenTelemetry or Prometheus, and store spend data in your PostgreSQL database under your backup policy. Confirm the retention periods and data handling rules with your compliance lead, and check whether your audit requirements need an immutable archive for the history you migrate.

How DeployOpen scopes and runs a migration from OpenRouter

DeployOpen plans and runs the move from OpenRouter to a LiteLLM gateway inside your own cloud account or data center, starting from an inventory of the models and applications that call OpenRouter today. Work is agreed in a written, fixed scope before anything changes, and the cutover is staged so application base URLs move without a service gap.

How we scope

We inventory every application, script and team that calls OpenRouter, including the model names and provider preferences each one uses.
We map each OpenRouter model name to a LiteLLM model group and record which direct provider account will serve it.
The written scope lists the providers, virtual key structure, budgets, fallback rules and SSO requirements that the migration will cover.

How we build

We deploy the LiteLLM proxy with PostgreSQL as the primary database and Redis 7.0 or newer once more than one proxy instance runs.
We recreate fallbacks, retries, cooldowns and priority ordering in the router configuration and test each one against the provider failures you expect.
We keep LITELLM_MASTER_KEY in your secret manager and issue virtual keys with per-team budgets, rate limits and model restrictions.

How we hand over

We run parallel traffic through the gateway and OpenRouter, then move application base URLs in stages so each service can roll back independently.
We document the model group mapping, key ownership, budget settings, logging destinations and the runbook for adding a provider or rotating keys.
We confirm with your team which LiteLLM features need an Enterprise license, such as SSO beyond the free user limit or audit logs, before handover.

How we support

Ongoing support, upgrades and testing of the gateway are available as a retainer, which covers LiteLLM version upgrades within the supported minor versions.
We can review provider contracts, spend reports and budget alerts with your finance and security teams after cutover.
Engagements are fixed-scope, so any change to providers, models or deployment targets is agreed in writing and priced from the revised scope.

Migrate from OpenRouter to a self-hosted LiteLLM gateway