Migrating from LiteLLM?Keep the API. Stop running the proxy yourself.

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="http://0.0.0.0:4000",
    api_key=os.environ["LITELLM_MASTER_KEY"],
)

resp = client.chat.completions.create(
    model="support-model",  # alias from config.yaml
    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_model",  # workflow name
    messages=[{"role": "user", "content": "Summarize this ticket."}],
)
print(resp.choices[0].message.content)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "http://0.0.0.0:4000",
  apiKey: process.env.LITELLM_MASTER_KEY,
});

const resp = await client.chat.completions.create({
  model: "support-model", // alias from config.yaml
  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_model", // workflow name
  messages: [{ role: "user", content: "Summarize this ticket." }],
});
console.log(resp.choices[0].message.content);

curl http://0.0.0.0:4000/chat/completions \
  -H "Authorization: Bearer $LITELLM_MASTER_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "support-model",
    "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_model",
    "messages": [{"role": "user", "content": "Summarize this ticket."}]
  }'

What maps to what

LiteLLM concepts and where they live in ModelRiver.

Map your config

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

model_list:
  - model_name: support-model
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY
  - model_name: support-backup
    litellm_params:
      model: anthropic/claude-sonnet-5
      api_key: os.environ/ANTHROPIC_API_KEY

router_settings:
  fallbacks: [{"support-model": ["support-backup"]}]

When to stay where you are

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

• You need the gateway on your own infrastructure or in your VPC, or prompts must not leave your network. ModelRiver is hosted only and is not self-hostable.

• You load-balance across several deployments of one model, or use latency-based or usage-based routing strategies.

• You tune retries, cooldowns, timeouts, or separate context-window and content-policy fallback chains.

• You call providers outside ModelRiver's 13, or image, audio or Responses API endpoints.

• You want to read and change the gateway's source code.

What you gain, what you give up

Steps to move over

1. Step 1

   Add your provider keys

   Add each key your config.yaml reads with os.environ/.... Keys are encrypted at rest and masked once saved, so there are no environment variables to manage.

   LiteLLM docs (opens in a new tab)ModelRiver docs

2. Step 2

   Create one workflow per alias your app calls

   Primary: the litellm_params.model behind the alias. Backups: the first two models in that alias's fallbacks list. Name it with underscores, such as support_model.

   LiteLLM docs (opens in a new tab)ModelRiver docs

3. Step 3

   Replay a few proxy requests against the Draft

   Take requests your app sends to the proxy today and run them through the Draft in the Playground. To wire up your app without provider calls, switch the workflow to Testing mode; switch back to Production before you publish.

   LiteLLM 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. support_model then plays the role your model_name alias plays in the proxy.

   LiteLLM docs (opens in a new tab)ModelRiver docs

5. Step 5

   Swap base URL, key and model

   Replace the proxy URL with https://api.modelriver.com/v1, the master key with a ModelRiver API key, and the alias with the workflow name.

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

   LiteLLM docs (opens in a new tab)ModelRiver docs

6. Step 6

   Keep the proxy as a fallback for a while

   Keep your current gateway configured in your code as a fallback until you're confident, then remove it. Leave the proxy running with its current config.yaml and send to it with the old alias if a ModelRiver call fails.

   LiteLLM docs (opens in a new tab)ModelRiver docs

7. Step 7

   Edit the workflow, not the config file

   Where you used to change config.yaml, edit the workflow Draft in the Console, publish it, and roll back to an earlier revision if needed.

   LiteLLM docs (opens in a new tab)ModelRiver docs

Related

• Moving from OpenRouterMigrate from OpenRouter to ModelRiver: OpenAI-compatible, your own provider keys, no token markup. Turn your models[] fallbacks into a versi
• 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.