Fallbacks y resiliencia

En producción un modelo o proveedor fallará; monta una cadena de fallbacks, pon timeouts y degrada con elegancia.

3 de junio de 2026 6 slides 5 min de lectura

OpenRouter · Producció

Fallbacks y resiliencia

Cuando un modelo cae, la app debe seguir respondiendo.
Todo fallará, es cuestión de cuándo

Un solo modelo o proveedor sufrirá caídas, latencia alta o rate-limits. No es pesimismo — es planificación. Si tu app depende de un único slug, depende de la suerte.
La cadena de fallbacks

OpenRouter te deja enviar un array de modelos: prueba el primero y, si falla, salta al siguiente. Combínalo con las preferencias de proveedor para encadenar alternativas.
- Pon el modelo preferido primero y alternativas equivalentes después.
- Deja un modelo más pequeño y barato como último recurso.
- Permite que OpenRouter pruebe otros proveedores del mismo modelo.
OpenRouter · Producción arlaf.dev

Un body de petición resiliente

{
  "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..." }
  ]
}

Tu lado también cuenta

Los fallbacks del gateway no te salvan de todo. Pon un timeout razonable en tu llamada, haz algún reintento con backoff y decide qué muestras al usuario si todo falla — nunca una pantalla en blanco.
No acoples la app a un solo slug. Acóplala a una capacidad, con varios modelos que la cubran.

Leer la nota completa

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.