Tre bug hanno fatto impazzire Claude per settimane
Anthropic ha documentato tre bug che hanno degradato Claude Code tra marzo e aprile 2025, causando amnesia e calo di qualità.
Tre bug distinti hanno degradato la qualità del codice generato per settimane
Il 26 marzo 2025, un ingegnere di Anthropic ha fatto girare un deploy che sembrava innocuo: cancellare il pensiero accumulato nelle sessioni di Claude rimaste inattive per più di un’ora, così da ridurre la latenza alla ripresa. Un’ottimizzazione ragionevole, in teoria. In pratica, il postmortem ufficiale di Anthropic documenta come un bug in quella modifica abbia trasformato Claude Code in qualcosa di molto simile a un paziente con amnesia anterograda: il ragionamento veniva azzerato non una volta sola, ma a ogni singolo turno di conversazione, per tutta la durata della sessione. Per quasi due settimane, gli sviluppatori che usavano Claude Code hanno visto deteriorarsi la coerenza del codice generato senza capirne la causa.
I tre bug che hanno fatto impazzire Claude
La storia inizia in realtà il 4 marzo 2025, con una modifica all’apparenza conservativa: Anthropic ha abbassato il livello di ragionamento predefinito di Claude Code da high a medium, con l’obiettivo dichiarato di ridurre le latenze elevate che affliggevano le sessioni più lunghe. Il ragionamento esteso — la catena interna di pensiero che Claude usa prima di produrre una risposta nei modelli con extended thinking — costa tempo. Passare da high a medium taglia il budget computazionale dedicato a quella fase, e con esso parte della profondità analitica. Una scelta discutibile già di per sé, ma almeno consapevole.
Il problema grave arriva tre settimane dopo. La logica del 26 marzo era questa: se una sessione è rimasta ferma per oltre un’ora, il contesto di ragionamento accumulato è probabilmente obsoleto, quindi conviene ripulirlo prima che l’utente riprenda. Pulire una volta, all’inizio della sessione ripresa, ha senso. Il bug ha fatto sì che quella pulizia avvenisse a ogni turno, continuamente, per tutta la sessione successiva. In pratica, ogni volta che Claude stava per rispondere, cancellava il proprio filo di pensiero e ricominciava da zero. Il risultato visibile: risposte progressivamente meno coerenti, codice che non teneva conto delle decisioni prese nei turni precedenti, una qualità che peggiorava in modo impercettibile ma costante. Anthropic ha corretto questo bug il 10 aprile, nella versione v2.1.101.
Ma prima che il fix venisse distribuito, il 16 aprile è entrata in gioco una terza modifica: un’istruzione aggiuntiva nel system prompt per ridurre la verbosità delle risposte. I system prompt sono istruzioni globali che condizionano il comportamento del modello prima ancora che arrivi il messaggio dell’utente — sono, di fatto, la personalità di fabbrica del sistema. L’intenzione era ridurre le risposte prolisse, un problema reale in certi contesti. Ma questa istruzione, combinata con altre modifiche al prompt già presenti, ha prodotto un effetto collaterale: la qualità del codice generato è calata sensibilmente. La modifica è stata revertita il 20 aprile, la stessa data in cui tutti e tre i problemi risultavano risolti nella versione v2.1.116.
Il postmortem: lezioni da un incidente evitabile
Anthropic ha documentato i tre problemi con una trasparenza che vale la pena riconoscere. Il postmortem descrive cause, timeline e fix con sufficiente dettaglio tecnico da permettere una diagnosi chiara. La root cause del bug più grave — la cache del ragionamento azzerata a ogni turno — è un classico errore di scope: una condizione pensata per essere applicata una volta è finita in un loop che si attivava continuamente. Il tipo di bug che nei code review passa perché il comportamento atteso e quello implementato divergono solo in edge case specifici (sessioni riprese dopo inattività prolungata). Non un errore grossolano, ma neanche invisibile a un test di integrazione ben scritto.
Il terzo bug — il system prompt troppo aggressivo sulla verbosità — è diverso per natura: non è un errore logico ma un’interazione inattesa tra componenti del prompt. In architetture dove il comportamento del modello dipende dalla composizione di più istruzioni di sistema, l’effetto combinato può essere molto diverso dalla somma delle parti. Questo tipo di regressione è notoriamente difficile da catturare con i test tradizionali, perché richiede benchmark qualitativi end-to-end, non semplici assertion binarie. Anche qui, Anthropic ha risposto con un revert tempestivo e con la compensazione dei limiti di utilizzo resettati per tutti gli abbonati.
Cosa significa per chi costruisce con LLM
Anthropic ha resettato i limiti di utilizzo per tutti gli abbonati come forma di compensazione, ma il vero takeaway per chi sviluppa applicazioni sopra questi modelli è un altro. I tre bug di Claude Code illustrano tre vettori di rischio distinti che ogni sviluppatore dovrebbe tenere sotto controllo nel proprio stack.
Il primo è la gestione della cache e del contesto. Se la tua applicazione mantiene sessioni di lunga durata, devi assumere che il provider possa modificare la logica di caching in qualsiasi momento — e quello che funzionava ieri potrebbe non funzionare dopo un aggiornamento silenzioso. Monitorare la coerenza delle risposte nel tempo, con metriche di qualità automatizzate, non è un lusso: è il modo per accorgersi di un bug come quello del 26 marzo prima che causi settimane di degrado silenzioso.
Il secondo è la fragilità dei system prompt. Se usi system prompt personalizzati, devi considerare che il provider potrebbe aggiungere istruzioni proprie che interagiscono con le tue in modi imprevedibili. Testare il comportamento del modello dopo ogni aggiornamento del provider — non solo dopo i tuoi deploy — è l’unico modo per rilevare regressioni di questo tipo. Il terzo vettore è più sottile: i parametri di reasoning come l’effort level non sono trasparenti per default. Se la tua applicazione dipende dalla profondità analitica del modello, dovresti verificare esplicitamente quale livello di reasoning è attivo, non darlo per scontato.
I bug di Claude Code ci ricordano che gli LLM in produzione sono sistemi complessi dove un singolo parametro fuori posto — una cache mal gestita, un system prompt troppo aggressivo, un budget di ragionamento ridotto senza comunicazione esplicita — può degradare l’intera esperienza in modo difficile da diagnosticare. La prossima volta che il tuo LLM “sembra peggiorato”, prima di concludere che il modello sia regredito nelle sue capacità, controlla il changelog del provider. Potrebbe essere un bug, non la deriva del modello. E fare questa distinzione fa tutta la differenza tra un debugging di trenta minuti e tre settimane di confusione.
