Coming from Portkey?One workflow instead of a config header.

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://api.portkey.ai/v1",
    api_key="unused",  # auth goes in x-portkey-api-key
    default_headers={
        "x-portkey-api-key": os.environ["PORTKEY_API_KEY"],
        "x-portkey-config": "pc-support-xxxx",
    },
)

resp = client.chat.completions.create(
    model="@openai-prod/gpt-4o",
    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://api.portkey.ai/v1",
  apiKey: "unused", // auth goes in x-portkey-api-key
  defaultHeaders: {
    "x-portkey-api-key": process.env.PORTKEY_API_KEY!,
    "x-portkey-config": "pc-support-xxxx",
  },
});

const resp = await client.chat.completions.create({
  model: "@openai-prod/gpt-4o",
  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://api.portkey.ai/v1/chat/completions \
  -H "x-portkey-api-key: $PORTKEY_API_KEY" \
  -H "x-portkey-config: pc-support-xxxx" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "@openai-prod/gpt-4o",
    "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

Portkey concepts and where they live in ModelRiver.

Map your config

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

{
  "strategy": { "mode": "fallback", "on_status_codes": [429, 500, 503] },
  "targets": [
    { "override_params": { "model": "@openai-prod/gpt-4o" } },
    { "override_params": { "model": "@anthropic-prod/claude-sonnet-5" } },
    { "override_params": { "model": "@google-prod/gemini-3.5-flash" } }
  ]
}

When to stay where you are

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

• You split traffic across targets with strategy.mode: "loadbalance".

• You rely on output guardrails, PII checks or prompt-injection checks. ModelRiver checks input only.

• You choose which status codes trigger fallback with on_status_codes.

• You manage prompt templates in your gateway, or need SSO, audit logs or OpenTelemetry export. ModelRiver does not offer these yet.

• You want to self-host the gateway. ModelRiver is hosted only.

What you gain, what you give up

Steps to move over

1. Step 1

   Add your provider keys

   Add a key for each provider behind the AI Providers your configs use, such as @openai-prod. Keys are encrypted at rest and masked once saved.

   Portkey docs (opens in a new tab)ModelRiver docs

2. Step 2

   Turn each config into a workflow

   For each config ID your app sends, create a workflow: the first target becomes the primary model, the next two become backups. Name it with letters, digits and underscores, such as support_bot.

   Portkey docs (opens in a new tab)ModelRiver docs

3. Step 3

   Compare the Draft with your config

   Run a few prompts you send through Portkey today in the Playground against the Draft. To wire up your app without provider calls, switch the workflow to Testing mode; switch back to Production before you publish.

   Portkey 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. The workflow name then does the job your config ID and @provider/model string did together.

   Portkey 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 with a ModelRiver API key, remove the x-portkey-* headers, and set model to the workflow name.

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

   Portkey docs (opens in a new tab)ModelRiver docs

6. Step 6

   Keep Portkey as a fallback for a while

   Keep your current gateway configured in your code as a fallback until you're confident, then remove it. Keep a second client with your Portkey headers and call it if a ModelRiver request fails.

   Portkey docs (opens in a new tab)ModelRiver docs

7. Step 7

   Edit the workflow, not the config

   Where you used to update a saved config, edit the workflow Draft, publish it, and roll back to an earlier revision if the change misbehaves.

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