Migrating from OpenRouter

Should you migrate?

The three-line change

# Before (OpenRouter)
OPENAI_BASE_URL = "https://openrouter.ai/api/v1"
OPENAI_API_KEY  = "sk-or-..."

# After (FreeModel)
OPENAI_BASE_URL = "https://freemodel.online/v1"
OPENAI_API_KEY  = "sk-..."        # from the console

For Anthropic-format clients, the base URL is different:

ANTHROPIC_BASE_URL = "https://freemodel.online/api/gateway"
ANTHROPIC_API_KEY  = "sk-..."

The part that takes longer: model names

OpenRouter names models vendor/model: openai/gpt-4o, anthropic/claude-sonnet-4. FreeModel does not use that scheme, and it also exposes modality routes like auto/image and tier aliases like fm-v1-lite that have no OpenRouter equivalent. So this is a mapping pass, not a find-and-replace.

# Pull the live list before mapping anything: do not hard-code from memory
curl https://freemodel.online/v1/models

# No key required. If a model you depend on is not in the list,
# that is your answer about whether to migrate.

Two things to check while you map:

• Drop the :free suffix. On OpenRouter it selects a free model; here routing is free-first by default, so the suffix is meaningless and may not resolve.
• Some OpenRouter models are simply not here. We serve 200+ models against their 460. If your workload depends on a specific one, verify it before you start.

What changes in behaviour

The routing change is the one that surprises people. If your code depended on a specific model answering (because you tuned prompts against it, or you are benchmarking), name a model explicitly rather than relying on routing. Otherwise the same request can land on a different model tomorrow.

Migration checklist

[ ] Pull https://freemodel.online/v1/models and diff it against what you use
[ ] Confirm every model you depend on is present
[ ] Get a key from the console
[ ] Point base_url at https://freemodel.online/v1 (or /api/gateway for Anthropic format)
[ ] Strip :free suffixes
[ ] Pin model names anywhere the specific model matters
[ ] Run one request per model you actually use, not just one smoke test
[ ] Check latency: routing adds a decision step

If you decide not to migrate

That is a reasonable outcome, and worth saying plainly. OpenRouter has more models, a longer track record, and integrations everywhere. The honest summary:

Stay on OpenRouter   if you need a specific model, a paid path you can
                     budget against, or you are following someone else's
                     setup guide
Switch to FreeModel  if you want Anthropic-format endpoints directly,
                     free-first routing by default, or the agent layer
                     above it

If you are still weighing it, the two direct comparisons go deeper on each: vs OpenRouter covers the feature differences, alternatives covers what else exists if neither of us is right.

The migration, step by step

Five steps, in the order that avoids rework. The order matters: if you remap model names before you have pulled the live list, you are mapping against a list you remembered.

1. Step 1: change the base URL and the key. For an OpenAI-format client that is two environment variables: OPENAI_BASE_URL="https://freemodel.online/v1" and OPENAI_API_KEY from the console. For an Anthropic-format client the URL is different: ANTHROPIC_BASE_URL="https://freemodel.online/api/gateway", which is the one clients like Claude Code read. If your SDK takes the URL as a constructor argument rather than an environment variable, the same value goes into base_url in code.
2. Step 2: pull the live model list and diff it. curl https://freemodel.online/v1/models needs no key. Diff those ids against the ones your code calls before you touch anything else, and keep the output — it is the version you verified against, not the one on this page.
3. Step 3: remap the model names. This is the pass that takes the time. OpenRouter ids are vendor/model, so the vendor prefix is the first thing to deal with; the :free suffix is the second, and it goes away entirely. Where a specific model has no counterpart, a tier alias such as fm-v1-lite or a modality route such as auto/image is usually the honest substitute: it describes a tier or a modality instead of pretending to pin a model.
4. Step 4: run one request per model you actually use. Not one smoke test. A model can answer a hello-world prompt and still fail the JSON shape or the word limit your pipeline depends on, and that failure only shows up on a real task.
5. Step 5: pin anything you benchmark against. If prompts were tuned against one model, name that model explicitly instead of relying on routing, or the same request can land on something else tomorrow and your benchmark stops being a benchmark.

Migration FAQ