Route LLM calls across GPT, Claude & Gemini via one API

RouterBase Model Gateway helps agents migrate existing OpenAI SDK integrations to RouterBase, a single OpenAI-compatible API surface for model routing across GPT, Claude, Gemini, image, video, audio, and embedding workloads. It documents a four-step approach: classify the workload first (modality, quality target, runtime constraints such as latency budget, context length, streaming, JSON mode, tool calling, and retry tolerance, plus business constraints like price ceiling or provider preference); configure an OpenAI-compatible client with the RouterBase API key kept server-side in an environment variable and the base URL pointed at https://routerbase.com/v1:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["ROUTERBASE_API_KEY"],
    base_url="https://routerbase.com/v1",
)

response = client.chat.completions.create(
    model="google/gemini-2.5-flash",
    messages=[{"role": "user", "content": "Write one sentence about model routing."}],
)

print(response.choices[0].message.content)

validate model IDs and capabilities against the live catalog before locking in a price-sensitive recommendation, with curl "https://routerbase.com/api/v1/models?task=chat" -H "Authorization: Bearer $ROUTERBASE_API_KEY", confirming streaming, tool-calling schema, JSON-mode parseability, and vision/media payload shape with a small test request; and design conservative, explicit application-level fallbacks unless the account already has a smart-routing policy configured, retrying only transient network errors, timeouts, rate limits, and server errors while failing fast on authentication failures, invalid model IDs, validation errors, or policy refusals. Because RouterBase model availability, pricing, and provider capabilities can change, the skill explicitly treats every example as a starting point to be re-verified against the live catalog rather than a permanent fact.

Use it when migrating an OpenAI-compatible client to RouterBase by changing the base URL and model ID; when selecting primary and fallback models for chat, reasoning, vision, media generation, audio, or embeddings; when debugging RouterBase request setup, such as headers, environment variables, streaming, tool calls, JSON mode, or multimodal payloads; or when documenting an internal model-routing plan balancing cost, latency, quality, and provider redundancy. It names two related, separate skills for adjacent needs: @api-analyzer for validating a single API request shape only, and @langfuse for production LLM observability, tracing, and evaluation - neither is duplicated here. It explicitly does not replace RouterBase account configuration, live model catalog checks, or production observability, and high-stakes outputs still require human review and domain-specific evaluation.

A five-step migration checklist for converting an existing OpenAI SDK integration: change the base URL to https://routerbase.com/v1, read ROUTERBASE_API_KEY from server-side environment configuration, replace the model name with a matching RouterBase model ID, preserve standard OpenAI request fields unless RouterBase documentation says otherwise, and run one minimal smoke test before shipping. A documented routing-plan table format records use case, primary model, fallback model, the reason for that choice, and how it was validated. A fallback-loop pattern tries each model in an ordered plan and re-throws only non-retryable errors:

const modelPlan = [
  "anthropic/claude-sonnet-4-6",
  "google/gemini-2.5-flash",
];

for (const model of modelPlan) {
  try {
    return await client.chat.completions.create({ model, messages });
  } catch (error) {
    if (!isRetryableRouterBaseError(error)) throw error;
  }
}

Built on the standard OpenAI SDK, Python and JavaScript, pointed at RouterBase's OpenAI-compatible endpoint and REST catalog API, so any code already written against the OpenAI client library needs only a base URL, API key, and model ID change to route through RouterBase's GPT, Claude, Gemini, image, video, audio, and embedding coverage.

Developers migrating an OpenAI SDK integration to a multi-provider router, or documenting a model-selection plan that needs explicit primary and fallback choices, cost and latency tradeoffs, and provider redundancy - who want the credential-handling and retry-classification mistakes, such as leaking a key client-side or retrying a non-retryable error, caught before they ship.