Switchboard

Overview

The classic problem: you hard-code a model like openai/gpt-4o in your code, deploy, and everything works. A month later a newer model lands and you want to switch — which means editing code and redeploying from scratch. Switchboard fixes that.

Set model to mizan/switchboard once. Then, from the Switchboard page, assign each key its primary model and ordered fallbacks — and change them anytime without touching your code. Each key resolves independently, so different deployments can use different models off the same codebase.

How it works

• Per-key assignment. A mizan/switchboardrequest resolves against the requesting API key's configuration — primary model plus up to 3 fallbacks, each a full provider/model slug.
• Auto fallback when unset. A key with no configuration behaves exactly like Auto Router until you assign one — nothing ever breaks because you forgot to configure it.
• Ordered fallback chain. If the primary fails before the response starts (network error, upstream 4xx/5xx, or a removed/unpriced model), the router retries the next model automatically.
• Billing mode per key. Choose Mizan billing or BYOK billing when you configure the key (see below).

The response echoes the model that actually served the call in the model field, so you always know which one handled a request.

Usage

Use mizan/switchboard exactly like any other model value — the only change vs. today is that you stop hard-coding a specific model. Any OpenAI SDK works as a client.

curl https://api.app-mizan.com/v1/chat/completions \
  -H "Authorization: Bearer mizan_rt_..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "mizan/switchboard",
    "messages": [{ "role": "user", "content": "Explain quantum entanglement in simple terms" }]
  }'

The response echoes the resolved model:

{
  "id": "chatcmpl-...",
  "model": "openai/gpt-4o",
  "choices": [
    { "message": { "role": "assistant", "content": "..." } }
  ],
  "usage": { "prompt_tokens": 15, "completion_tokens": 150, "total_tokens": 165 }
}

Configuring in the dashboard

Open the Switchboard page, find your key, and click Configure. Pick:

• Primary model. The model your key uses by default.
• Fallback models. Up to 3, tried in order if the primary is unavailable.
• Billing. Which billing path Switchboard calls take.

Models you pick but that aren't currently in the catalog are flagged in the UI — they still save (the router falls through to the next model at request time), but you get a warning so a typo or a since-removed model doesn't silently degrade traffic.

Billing

Switchboard is the only Mizan routing mode that lets you choose the billing path, per key:

• Mizan billing (default). Requests are served with Mizan's platform keys and billed from your wallet — one pay-as-you-go bill, no setup.
• BYOK billing. Requests use your own connected provider account for each chosen provider and are billed directly to it. Requires a connection for the provider; a provider without one falls back to Mizan billing rather than failing.

Fallbacks

The primary plus fallbacks form an ordered chain, exactly like Auto Router candidates: if a model fails before the response has started streaming — an upstream 4xx/5xx, a network error, or a model that's no longer priced in Mizan's catalog — the router retries the next one automatically. Once response bytes have reached the client, no fallback happens: an in-flight stream either succeeds or fails as-is. Every attempt is logged individually on Audit Logs.

Limitations

• Switchboard is per API key — it does not change how fixed-model or mizan/auto requests behave.
• No session stickiness or per-prompt classification: every request for a key uses its assigned chain.
• A model that's removed from the catalog falls back at request time — it isn't blocked from being saved in the UI, only flagged.
• Streaming is supported; the response still echoes the resolved model slug.