Come far sopravvivere la tua app IA quando un modello sparisce all'improvviso

Ogni sviluppatore che costruisce sull'IA prima o poi impara la stessa lezione nel modo più duro: il modello da cui dipendi non è garantito che ci sia. Può essere soggetto a rate limit nei picchi di traffico, restituire un rifiuto, incappare in un errore di sovraccarico o — come è successo a Claude Fable 5 a giugno 2026 — essere spento del tutto per ragioni che non hanno nulla a che fare con il tuo codice. Le app che sopravvivono a questi momenti non sono quelle con il prompt migliore. Sono quelle che hanno pianificato l'assenza del modello.

Questa guida illustra un approccio pratico e a livelli alla resilienza, che funziona sia che tu chiami un singolo fornitore direttamente sia che instradi tramite un gateway.

Passo 1: non scrivere mai un singolo modello in modo fisso nel codice

La fragilità più comune è un nome di modello incorporato direttamente in una richiesta. Nel momento in cui quella stringa smette di funzionare, ogni chiamata fallisce. Definisci invece i tuoi modelli come configurazione — una piccola lista di priorità, non una costante:

MODEL_CHAIN = [
    "claude-opus-4-8",      # primary
    "claude-sonnet-4-6",    # same provider, cheaper/faster
    "gpt-5.5",              # different provider entirely
]

Questa singola modifica significa che cambiare fornitore durante un incidente è una modifica di configurazione, non un deploy di codice. Nota che la terza voce è un fornitore diverso. I fallback sullo stesso fornitore ti proteggono dalla caduta di un singolo modello; i fallback tra fornitori ti proteggono dalla caduta dell'intero fornitore — o dal suo spegnimento imposto.

Passo 2: usa una catena di fallback, non un singolo tentativo

Il pattern è semplice: prova ogni modello in ordine, passa al successivo in caso di fallimento e solleva un errore solo se l'intera catena è esaurita.

def call_with_fallback(messages):
    last_error = None
    for model in MODEL_CHAIN:
        try:
            return client.complete(model=model, messages=messages)
        except (RateLimitError, OverloadError, RefusalError) as e:
            last_error = e
            continue  # try the next model
    raise AllModelsFailedError(last_error)

Ciò su cui fai fallback conta. Riprovare lo stesso modello su un errore transitorio overloaded (HTTP 529) ha senso dopo un breve backoff. Ma un errore di autenticazione o una richiesta malformata falliranno in modo identico su ogni modello — questi dovrebbero emergere immediatamente invece di consumare l'intera catena.

Passo 3: appoggiati alla piattaforma quando offre fallback in modo nativo

Non devi sempre costruirlo a mano. Diverse piattaforme ora lo fanno lato server:

• L'API di Anthropic ha aggiunto un parametro beta fallbacks che riprova una richiesta rifiutata su un modello alternativo in un singolo round trip — Fable 5, per esempio, era configurato per fare fallback su Opus 4.8 quando i suoi classificatori rifiutavano una richiesta. La fatturazione segue il modello che ha effettivamente servito la risposta.
• OpenRouter ti permette di passare un array models in ordine di priorità; fa failover automaticamente su errori di lunghezza del contesto, flag di moderazione, rate limit e downtime, addebitandoti alla tariffa del modello che ha risposto.
• LiteLLM offre un Router con retry, fallback e load balancing integrati tra deployment e fornitori, che puoi self-hostare per il massimo controllo.

Un gateway come OpenRouter o LiteLLM ti dà un unico endpoint unificato su molti fornitori, così un fallback tra fornitori è solo un'altra voce in una lista invece di un secondo SDK da integrare.

Passo 4: aggiungi un circuit breaker per fallire in fretta

Se un modello è chiaramente down, non vuoi che ogni richiesta aspetti il suo timeout prima di passare oltre. Un circuit breaker tiene traccia dei fallimenti recenti e, una volta superata una soglia, salta del tutto il modello rotto per un periodo di raffreddamento. Nel 2026 i team in produzione si attestano comunemente su cinque fallimenti consecutivi per far scattare il breaker e un raffreddamento di ~60 secondi prima di testare il recupero. Mentre il breaker è aperto, il traffico va dritto al modello successivo nella catena — nessuna latenza sprecata.

Passo 5: decidi cosa significa "degradato" per il tuo prodotto

Fare fallback su un modello più economico non è gratis — la qualità cala e i tuoi prompt possono comportarsi diversamente. Pianificalo:

• Testa i tuoi prompt su ogni modello della catena. Un prompt messo a punto per un modello può produrre un output notevolmente peggiore sul suo fallback.
• Avvisa l'utente quando hai degradato se conta (es. "in esecuzione in modalità rapida"), invece di consegnare silenziosamente risultati di qualità inferiore.
• Registra quale modello ha effettivamente servito ogni richiesta così puoi vedere, dopo un incidente, quanto traffico hanno assorbito i fallback.

La conclusione

La resilienza non è una funzionalità che aggiungi dopo il lancio — è una piccola quantità di struttura che aggiungi presto: configurazione invece di costanti, una catena di priorità invece di una singola chiamata, un circuit breaker per fallire in fretta e prompt testati a ogni livello. I team le cui app sono rimaste in piedi durante lo spegnimento di Fable 5 a giugno non sono stati fortunati. Avevano semplicemente già risposto alla domanda che ogni costruttore IA dovrebbe porsi il primo giorno: cosa succede quando questo modello domani non c'è più?