Blog

Switching from OpenRouter: the whole migration, mapped

The code change is famously small; the OpenAI-compatible surface makes leaving a base-URL swap. The real migration is credits, routing rules, and choosing the right destination for the reason you are leaving.

By the Unbiased Team · published August 9, 2026 · fees and prices verified July 28, 2026; measured data dated in place

Switching from OpenRouter is a base-URL and API-key change for code, plus two real tasks: draw down credit balances before you go, and re-express routing rules at the destination. Pick the destination by your reason for leaving: fees past ~$900/month (flat fee), governance (control plane), data locality (self-hosted), or selection fatigue (blended model).

The easy part, honestly easy

Everything serious in this category speaks the OpenAI-compatible surface, OpenRouter included. Your application migration is a base URL and a key, and if you built anything reasonable, model names live in config. Budget an hour for the code and a day for the testing you should do anyway.

Two things do not travel. Credit balances: stop topping up ahead of the move and draw the balance down, because accumulated credits, not code, are the aggregator's real lock-in. Routing rules: fallbacks, provider preferences, and per-route choices are expressed in OpenRouter's dialect and need re-writing in the destination's; budget an afternoon.

Choose the destination by the leaving-reason

Leaving over fees (spend cleared the ~$900/month crossover): a flat-fee control plane like Portkey at $49/month, or direct APIs if your model set has stabilized to one or two providers. Leaving over governance: the control plane, which is the product built for SSO, audit, and spend control. Leaving over data locality: self-hosted LiteLLM, free plus the ops line we price honestly at ~$1,000/month unless your platform team has real spare capacity.

Leaving because model selection became a chore: that is not solved by any of the above, they all hand the choosing back to you. The blended-model category exists for it: Pareto, several LLMs per request, one answer, billed at cost, receipts published. Ours, so verify before believing.

The migration checklist

Meter before and after: run your top three tasks through both stacks and compare metered bills, not rate-card math; verbosity makes paper math lie. Confirm streaming and tool calling on the destination for your exact models. Re-run your eval set against the new route (provider variance means the same model name can behave differently through a different path). Keep the OpenRouter key alive for a week of fallback. Then close the loop: whatever you learned about your traffic during the move, write it down; it is the selection homework most teams never get receipts on.

Questions, answered