Moving from OpenRouter?Keep your SDK. Bring your own keys.

2 lines of code + 1 workflow

Keep your OpenAI SDK. On the client line, change the base URL and key. On the request line, set model to the name of a workflow.

Step 0: create a workflow in the console with your primary model and backups. Its name is what you send as model.

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://openrouter.ai/api/v1",
    api_key=os.environ["OPENROUTER_API_KEY"],
)

resp = client.chat.completions.create(
    model="openai/gpt-4o",
    extra_body={"models": ["anthropic/claude-sonnet-5", "google/gemini-3.5-flash"]},
    messages=[{"role": "user", "content": "Summarize this ticket."}],
)
print(resp.choices[0].message.content)

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.modelriver.com/v1",
    api_key=os.environ["MODELRIVER_API_KEY"],
)

resp = client.chat.completions.create(
    model="support_bot",  # workflow: gpt-4o + 2 backups
    messages=[{"role": "user", "content": "Summarize this ticket."}],
)
print(resp.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://openrouter.ai/api/v1",
  apiKey: process.env.OPENROUTER_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "openai/gpt-4o",
  // OpenRouter extension, not in the OpenAI SDK types
  ...{ models: ["anthropic/claude-sonnet-5", "google/gemini-3.5-flash"] },
  messages: [{ role: "user", content: "Summarize this ticket." }],
});
console.log(resp.choices[0].message.content);

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.modelriver.com/v1",
  apiKey: process.env.MODELRIVER_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "support_bot", // workflow: gpt-4o + 2 backups
  messages: [{ role: "user", content: "Summarize this ticket." }],
});
console.log(resp.choices[0].message.content);

curl https://openrouter.ai/api/v1/chat/completions \
  -H "Authorization: Bearer $OPENROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o",
    "models": ["anthropic/claude-sonnet-5", "google/gemini-3.5-flash"],
    "messages": [{"role": "user", "content": "Summarize this ticket."}]
  }'

curl https://api.modelriver.com/v1/chat/completions \
  -H "Authorization: Bearer $MODELRIVER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "support_bot",
    "messages": [{"role": "user", "content": "Summarize this ticket."}]
  }'

What maps to what

OpenRouter concepts and where they live in ModelRiver.

Map your config

Your fallbacks, output shape and budget move into one named workflow.

{
  "model": "openai/gpt-4o",
  "models": ["anthropic/claude-sonnet-5", "google/gemini-3.5-flash"],
  "response_format": { "type": "json_schema", "json_schema": { "name": "ticket", "schema": { "...": "..." } } },
  "messages": [{ "role": "user", "content": "Summarize this ticket." }]
}

When to stay where you are

OpenRouter may suit you better if any of these matter most.

• You want one balance that pays for every model, without opening an account with each provider.

• You pick models per request, use openrouter/auto, or switch between many models often. ModelRiver needs a workflow created for each setup first.

• You rely on provider routing: sorting by price, latency or throughput, only/ignore lists, or routing only to zero-data-retention endpoints.

• You use free model variants, image or audio models, or the Responses API.

• You need SSO, audit logs, OpenTelemetry export. ModelRiver does not offer these yet.

What you gain, what you give up

Steps to move over

1. Step 1

   Add your provider keys

   Add an API key for each provider your current models[] list uses, for example OpenAI, Anthropic and Google. Keys are encrypted at rest and used only for your requests.

   OpenRouter docs (opens in a new tab)ModelRiver docs

2. Step 2

   Create one workflow per model setup

   Name it with letters, digits and underscores, such as support_bot. Set the first model of your models[] list as primary and the next two as backups. Attach your JSON schema as a structured output and add a budget if you want one.

   OpenRouter docs (opens in a new tab)ModelRiver docs

3. Step 3

   Compare the Draft with what you get today

   Run a few prompts you already send to OpenRouter in the Playground, against the Draft, and compare the answers. To wire up your app without provider calls, switch the workflow to Testing mode; switch back to Production before you publish.

   OpenRouter docs (opens in a new tab)ModelRiver docs

4. Step 4

   Publish the workflow Live

   API requests run the Live version, so publish before you switch code. After that, support_bot in model behaves the way a preset name does today.

   OpenRouter docs (opens in a new tab)ModelRiver docs

5. Step 5

   Swap base URL, key and model

   Point your OpenAI SDK at https://api.modelriver.com/v1, use your ModelRiver API key, set model to the workflow name and remove models, provider and response_format from the request.

   base_url="https://api.modelriver.com/v1"
   api_key=os.environ["MODELRIVER_API_KEY"]
   model="support_bot"

   OpenRouter docs (opens in a new tab)ModelRiver docs

6. Step 6

   Keep OpenRouter as a fallback for a while

   Keep your current gateway configured in your code as a fallback until you're confident, then remove it. A simple pattern: if the ModelRiver call raises, send the same messages to OpenRouter with your old models[] list.

   OpenRouter docs (opens in a new tab)ModelRiver docs

7. Step 7

   Edit the workflow, not the request

   Where you used to edit a models[] array or a preset, edit the workflow Draft, publish it, and roll back to an earlier revision if the change misbehaves.

   OpenRouter docs (opens in a new tab)ModelRiver docs

Related

• Moving from LiteLLMMigrate from a self-hosted LiteLLM proxy to ModelRiver: hosted, OpenAI-compatible, your own provider keys. Map config.yaml fallbacks to one
• Moving from PortkeyMigrate from Portkey to ModelRiver: move the fallbacks in your x-portkey-config header into one named workflow. Your own keys, flat per-requ
• Moving from Vercel AI GatewayMigrate from Vercel AI Gateway to ModelRiver: bring your own provider keys with no credits to buy, from any framework. Map vmc/ models to wo
• All migration guidesWhat moves and what doesn’t, for each gateway.
• Gateway migration docsConcept mapping, snippets and first errors.