Migrate from OpenRouter.
Keep your code.

How the migration works

FreeRouter speaks your existing request format — models, tools, streaming, provider preferences — so your code barely changes. Steps 1–3 happen in the dashboard with zero downtime: your app keeps calling OpenRouter directly until steps 4–5 cut it over.

1. Create a FreeRouter account at app.freerouter.com (Google or email + one-time passcode).
2. Move your OpenRouter key into FreeRouter as a backend provider (Providers → Add provider → OpenRouter). You are copying it, not deleting it — your app still needs it until the cutover.
3. Create a FreeRouter API key with its API shape set to openrouter, and attach a routing rule that sends 100% of traffic to OpenRouter.
4. Swap the key in your app — replace the OpenRouter secret with your fr_live_... secret (keep the old variable set until verified, so rollback is a one-line revert).
5. Swap the base URL — from https://openrouter.ai/api/v1 to https://api.freerouter.com/v1. Endpoints, bodies, and streaming stay identical.

Verify: send one request and check the X-FreeRouter-Provider response header reads openrouter, then watch the request land on the Logs screen in the FreeRouter dashboard — proof your traffic now flows through your own routing rules. If anything looks wrong, point the app back at OpenRouter while you investigate.

Day one, nothing behaves differently — and that is the point. But the router now sits between your app and the gateway: add a second provider later and flip the rule to priority-with-failover or a percentage split with no code deploy. The full migration guide walks through every step with dashboard click-paths.

Let your coding agent do the legwork

Paste the prompt below into your coding agent. It tells the agent to read the FreeRouter documentation at https://docs.freerouter.com, study your code, and come back with a migration plan for your review — including the account setup, provider key, FreeRouter key, base-URL swap, end-to-end test, and Logs-screen check. No code changes until you approve.

I am currently using OpenRouter as my LLM gateway and would like to replace it with FreeRouter, with my existing OpenRouter account serving as a backend provider through FreeRouter (bring-your-own-key).

Explore the technical documentation at https://docs.freerouter.com as well as my code, then put together a well-thought-out migration plan for this objective so I can review and approve it. Do NOT make any code changes yet — present the plan first and wait for my approval.

Useful context for the plan:
- Current gateway: OpenRouter. Identify every place in my code that calls OpenRouter today and keep the diff minimal (the openrouter API shape accepts existing request bodies verbatim — models, tools, streaming, provider preferences).
- FreeRouter essentials: base URL https://api.freerouter.com/v1; auth with a fr_live_... key; model ids look like provider/model (e.g. openai/gpt-4o-mini); each key has an API shape (use openrouter to match my client) and a routing rule (priority with 100% to OpenRouter, failover later).
- Setup the plan must cover: (1) creating a FreeRouter account, (2) adding my OpenRouter key as a BYOK provider (Providers → Add provider → OpenRouter), (3) creating a FreeRouter key with the openrouter shape and a routing rule sending 100% to OpenRouter, (4) swapping my app's base URL from https://openrouter.ai/api/v1 to https://api.freerouter.com/v1 and the key to the fr_live_... key, (5) end-to-end testing plus witnessing the routing on the Logs screen in the FreeRouter dashboard.

The plan should include: (1) every place in my code that calls OpenRouter today, (2) the exact config and code changes (base URL, key, model ids, API shape), (3) how to validate (the dashboard Test key button, the X-FreeRouter-Provider response header, GET /v1/models, the Logs screen), and (4) how to roll back if something breaks (point the app back at OpenRouter — the old key still works).