Fallbacks i resiliència

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.