How to migrate from OpenRouter or LiteLLM

Start from facts, not from memory. Search the code for the gateway's base URL and for any code that adds gateway-specific fields to requests. Then pull a month of usage from the gateway or provider and group it by model, by application and by feature: streaming, tool calls, JSON output, image input, long prompts.

Write the result in a table with one row per model and application. The columns that matter most are request volume, whether the call streams, whether it uses tools, whether it relies on JSON output, and whether it uses any routing preference. Volume tells you where a saving or a mistake is large. The feature columns tell you where the destination might behave differently.

Also list the non-code dependencies: dashboards that read the gateway's activity logs, budget alerts, and any contract or data processing terms. A migration that forgets the finance dashboard fails in month two.

Model names are the first thing to break. OpenRouter model ids are of the form provider/model, for example the ~openai/gpt-sol-latest style alias its quickstart uses, or a specific identifier from its model catalogue. LiteLLM also names models provider/model, but there that string goes in litellm_params.model, while clients use the model_name alias you defined. Direct provider APIs use their own native names. The Swfte gateway uses provider:model, and the model directory shows the id for each model.

Then map the request fields. OpenRouter accepts a provider object (order, allow_fallbacks, only, ignore, sort, zdr, data_collection, require_parameters) and a models array for fallbacks. These are OpenRouter features. They do not exist on a direct provider API, and on a LiteLLM or Swfte route you re-express them as gateway configuration. Make a row for each one you use.

Optional OpenRouter headers (HTTP-Referer and X-OpenRouter-Title) only attribute your app on its leaderboards. Remove them when you leave unless the destination asks for something similar.

The only honest answer to "does it behave the same?" is to send the same requests down both routes. Export requests from your logs, sample across applications and features, and make sure the sample includes your hard cases: the longest prompts, requests with tools, requests that expect JSON, requests in each language you serve, and a handful that currently fail.

Remove or replace personal data before you save the file, and treat the file as sensitive anyway. Keep one JSON object per line with the messages, the options you send (tools, response format, temperature), and a label for the feature it comes from. Do not store the old route's answers as the truth: they are one sample of a non-deterministic system. You compare behaviour, not exact text.

If you do not log request bodies today, you will have to write representative requests by hand. That is slower and less honest, and it is a good reason to add logging with redaction as part of this project.

Write a small script that sends every replay request to the old route and the new route and records what you care about: whether the call succeeded, the HTTP error if not, the finish_reason, whether tool calls came back, whether JSON output parses, the token counts the route reports, and the time taken. The script below does that with the OpenAI SDK pointed at two base URLs. Run it with identical settings and at temperature 0 where the destination allows it.

Read the differences, not the average. The failures that hurt are specific: a tool call that comes back malformed, a JSON answer wrapped in prose, a request rejected because the destination does not support a parameter, a missing usage field that breaks your cost tracking. Fix each one or decide it is acceptable, and write the decision down.

Expect some differences in wording. They are not failures unless a downstream rule depends on the exact text. If it does, that rule is fragile and now is a good time to fix it.

With the parity results in hand, change the client. For any OpenAI-compatible destination the change is three values: the base URL, the API key and the model identifier. Put them in configuration, not in code, so the same build can talk to either route. OpenRouter's base URL is https://openrouter.ai/api/v1. A LiteLLM proxy is whatever address you deployed it at, and uses your key and your model_name aliases. Swfte's gateway endpoint is https://api.swfte.com/agents/v2/gateway, with provider:model ids.

If your destination is a direct provider, read its compatibility notes first. Anthropic documents an OpenAI SDK compatibility layer at https://api.anthropic.com/v1/, and says it is mainly intended for testing and comparing models, not as a long-term production solution for most use cases. It lists differences that matter: the strict parameter for function calling is ignored, so tool-call JSON is not guaranteed to follow your schema; response_format is ignored; prompt caching is not supported through it; system and developer messages are hoisted and joined into one; n must be 1; temperature above 1 is capped at 1; and many unsupported fields are silently ignored rather than rejected. For production use of Claude directly, use Anthropic's own SDK and API.

Silent ignoring is the dangerous part. A request that used to enforce a JSON schema through the gateway may now return free text with no error. Your parity test should have caught it; if it did not, add a case for it now.

List what the old route did for you without being asked. On OpenRouter, a models array falls back to the next model when the first fails, with the documented triggers of context-length errors, moderation flags on filtered models, rate limiting and downtime, and the request is priced at the model actually used, reported in the model field of the response. The provider object can restrict providers, set an order, prefer low price, throughput or latency, or send only to zero-data-retention endpoints. In-region routing for the EU or US is described as available on its Business and Enterprise plans.

On a LiteLLM proxy the equivalents are fallbacks, num_retries, allowed_fails and cooldown_time in the config file, and per-key model allow-lists. On other gateways the setting names differ. For every rule, write the destination's equivalent or write "dropped, because ...". Privacy rules need extra care: if you relied on zdr or data_collection: deny, confirm the destination can give you the same guarantee in writing, not only a similar setting name.

If you move to a single provider, cross-provider fallback and price-based routing are gone. If you move to a self-hosted gateway, you inherit the operation of those features; see how to set up an LLM gateway.

Streaming is where hand-written parsers break. OpenRouter documents that it periodically sends Server-Sent Events comments such as : OPENROUTER PROCESSING to prevent timeouts, tells clients to skip lines that start with a colon before parsing JSON, ends every Chat Completions stream with an extra chunk that carries usage, and, once headers are sent, reports mid-stream errors as events with an error object and finish_reason: "error". If your parser handles those, check that the destination does not need different handling. If you used the official SDK, you are likely fine, but test.

For tools, test a call that must use a tool, a call that must not, and a call with several tools. Compare the shape of tool_calls, argument JSON validity and how your code handles a refusal. For structured output, check whether the destination enforces your schema or only asks for it, using a case that tempts the model to add commentary.

Turn each of these into a permanent test that runs against whichever route is live. You will need them again at the next migration.

Compare the parity run's usage fields. Some routes fill details such as cached tokens and reasoning tokens, and some leave them empty: Anthropic's compatibility layer documents usage.prompt_tokens_details and usage.completion_tokens_details as always empty. If your cost model reads those fields, it will under-report on the new route until you change it.

Then compare price. Hosted gateways typically pass provider list prices through and add a fee. Our OpenRouter alternatives page records a percentage fee on credit purchases that depends on the plan, so check the current figures on OpenRouter's pricing page against your volume before you decide the migration saves money. A direct route removes that fee but also removes the single invoice and the cross-provider fallback. Work out the monthly difference from your own inventory, with the arithmetic shown, rather than from a comparison page. Our cost reduction guide shows how.

Finally, logging and audit. Move the alerts, budgets and dashboards that depended on the old gateway's activity data, and decide how long you keep the old data. Switch off the old billing last, and only after the final invoice has matched your records.

Send a small share of real traffic, such as 1 per cent, to the new route, and raise it in steps while you watch. Make the choice sticky per user or session so one conversation does not switch route halfway. Keep the old route configured and warm until the end. A configuration flag that flips back in one step is your rollback; test it before the canary starts, not during an incident.

Decide the numbers that stop the rollout before you start: for example error rate above the old route's by a set margin, p95 latency above a limit, a drop in your task pass rate, or spend per request above your estimate. Watch them at each step for long enough to cover a full cycle of your traffic, such as a weekday and a weekend if usage differs.

When you reach 100 per cent, leave the old route in place for a defined period, then remove it, delete unused keys, and close the old account or plan. Update the documents that name the old gateway. Record the migration, the evidence and the date, so the next person can see why the decision was made.