Il 27 luglio Claude Opus 5 ha registrato un picco di errori di inferenza su tutti i suoi canali: API, Claude Code e Claude Cowork. Anthropic ha aperto l’incidente alle 11:27 UTC e ha chiuso alle 12:30 UTC, confermando il ritorno ai livelli normali di funzionamento.

Per chi usa Opus 5 in produzione, un’ora di errori intermittenti non è un dettaglio. Un agente che lavora in autonomia su decine di chiamate sequenziali o orchestrate si blocca a metà del task, lascia stati inconsistenti e produce output parziali che qualcuno deve poi pulire a mano. I frontier model sono la dipendenza più fragile dello stack: quando sbagliano loro, lo strumento che hai costruito sopra ha come unico piano di fallback l’attesa.

Tre giorni prima raccontavamo l’arrivo di Opus 5 come default nei piani enterprise di Anthropic, presentato per raddoppiare le prestazioni a parità di costo. Un incidente operativo di questo tipo, risolto in fretta, è normale per un servizio cloud. Il punto è un altro: chi automatizza processi su questi modelli deve trattare la loro disponibilità come una variabile aleatoria, con monitoraggi attivi sui tassi di errore e logica di retry, non dare nulla per scontato.

Il playbook giusto per gestire questa fallibilità esiste già ed è il controllo qualità quando l’AI fa molto lavoro: campionare gli output, intercettare i problemi presto e non affidarsi ciecamente alla risposta del modello.

Nel dettaglio

La pagina di stato di Anthropic descrive l’incidente in modo stringato: il picco di errori ha colpito claude.ai, l’API, Claude Code e Claude Cowork in blocco. È stato un problema sistemico che ha coinvolto il modello frontier nel momento in cui elaborava le richieste, non un degrado selettivo di un endpoint minore.

Non conosciamo la causa tecnica del bug. Anthropic non ha fornito dettagli sul post-mortem, e la pagina di stato si limita a confermare la risoluzione. Il thread su Hacker News (101 punti, 73 commenti) raccoglie segnalazioni di utenti che hanno visto fallire chiamate API ripetutamente, con errori intermittenti che rendevano difficile capire se il problema fosse nel proprio codice o nel servizio upstream. Questo è un pattern classico degli incidenti cloud: il consumatore perde tempo a debuggare la propria integrazione prima di accorgersi che la piattaforma è degradata.

Il contesto operativo conta. Opus 5 è diventato in pochi giorni il modello di default per molti workflow agentici, spingendo Anthropic a tagliare l’80% del system prompt di Claude Code perché il modello ha bisogno di meno istruzioni difensive. Quando un modello passa da novità a infrastruttura di produzione in così poco tempo, la tolleranza ai suoi difetti si abbassa drasticamente. Un team che ha migrato i propri agenti su Opus 5 la scorsa settimana si trova oggi a dover aggiungere strati di resilienza che non aveva previsto.

L’implicazione pratica è costruire sistemi che non si rompono quando il modello si rompe, senza abbandonare i frontier model. Questo significa monitorare i tassi di errore delle API con soglie di allerta, avere retry con backoff esponenziale per gli errori transitori, e prevedere un meccanismo di fallback su un modello secondario per i task non bloccanti. Significa anche tracciare ogni output in modo da poter ricostruire cosa è andato a buon fine e cosa è rimasto incompleto dopo un fallimento a metà chain.

Il limite di quello che sappiamo è netto: l’incidente è durato un’ora e non ci sono indicazioni di corruzione silenziosa dei risultati. I frontier model hanno una fragilità operativa paragonabile a un database gestito, con un anno di vita sulla scena operativa contro i decenni di hardening di una RDS. Chi ci costruisce sopra deve mettere in conto la curva di maturità.