Fallbacks and resilience

In production a model or provider will fail; build a fallback chain, set timeouts and degrade gracefully.

June 3, 2026 6 slides 5 min read

OpenRouter · Producció

Fallbacks and resilience

When a model goes down, the app must keep answering.
Everything fails, it's a matter of when

A single model or provider will see outages, high latency or rate-limits. It's not pessimism — it's planning. If your app depends on one slug, it depends on luck.
The fallback chain

OpenRouter lets you send an array of models: it tries the first and, if it fails, moves to the next. Combine it with provider preferences to chain alternatives.
- Put the preferred model first and equivalent alternatives after.
- Leave a smaller, cheaper model as the last resort.
- Let OpenRouter try other providers of the same model.
OpenRouter · Production arlaf.dev

A resilient request body

{
  "models": [
    "openai/gpt-4o",
    "anthropic/claude-3.5-sonnet",
    "meta-llama/llama-3.1-8b-instruct"
  ],
  "provider": {
    "allow_fallbacks": true,
    "sort": "throughput"
  },
  "messages": [
    { "role": "user", "content": "Resumeix aquest text..." }
  ]
}

Your side counts too

Gateway fallbacks don't save you from everything. Set a sensible timeout on your call, retry with backoff and decide what to show the user if all fails — never a blank screen.
Don't couple the app to one slug. Couple it to a capability, with several models that cover it.

Read the full note

A producció les coses fallen, i has d’estar-hi preparat. Un proveïdor té una caiguda, un model et retorna un rate-limit en hora punta, la latència es dispara sense avís. Si tota la teva app penja d’un únic model, qualsevol d’aquests incidents la tomba sencera.

La cadena de fallbacks

OpenRouter resol bona part del problema deixant-te enviar un array de models en comptes d’un de sol. Prova el primer; si no respon, salta automàticament al següent, i així successivament. La idea és ordenar-los de millor a pitjor:

El model preferit primer — el que dóna la qualitat que vols.
Una o dues alternatives equivalents d’altres proveïdors.
Un model petit i barat com a últim recurs: pitjor resposta, però resposta.

A més, l’objecte provider controla com es trien proveïdors per a un mateix model. Amb allow_fallbacks actiu, si el proveïdor preferit no està disponible OpenRouter en prova un altre que serveixi el mateix model.

Nota: els noms exactes dels camps (models, provider, allow_fallbacks) i les opcions disponibles poden canviar. Contrasta’ls amb la documentació d’OpenRouter abans de fixar-los al codi.

El que has de fer tu

Els fallbacks del gateway són la meitat de la història; l’altra meitat és la teva. A la teva banda:

Posa un timeout raonable a cada crida perquè una petició penjada no bloquegi tot el flux.
Fes reintents amb backoff per als errors transitoris, però amb un sostre — reintentar infinitament només multiplica el cost.
Degrada amb elegància: si res respon, mostra un missatge clar o un resultat parcial, mai una pantalla en blanc ni una excepció crua.

La conclusió: no acoblis l’app a un slug concret. Acobla-la a una capacitat —“un model que sàpiga resumir”— i deixa diversos models darrere que la puguin cobrir. Així, quan un caigui, l’usuari ni se n’assabenta.