Context Rot

Thariq, ingegnere di Anthropic, colloca l'esordio del fenomeno intorno ai 300-400k token sul modello da 1M di token, a seconda del compito. Superata quella soglia le prestazioni calano perché l'attenzione si diluisce su troppi token: è questa la definizione meccanica di context rot. Chris Williams descrive lo stesso fenomeno a livello di giudizio, catalogandolo come F3 tra le otto modalità di fallimento da cui un ciclo di sviluppo agentico deve difendersi. Il giudizio del modello si degrada man mano che la finestra si riempie, e il modello finisce per ancorarsi ai propri output precedenti.

Il motivo per cui il problema continua a riemergere è che vincola la progettazione del processo, non la scelta del modello. Vivek Trivedy di LangChain lo considera una delle sfide a cui l'harness dell'agente deve rispondere, tramite la compaction, lo scarico dei risultati ingombranti degli strumenti sul filesystem, e le Skills come progressive disclosure. Williams costruisce un'intera fase attorno a questo: P2 (Decompose) suddivide la specifica in ticket atomici dimensionati per agenti "freschi", con contratti espliciti ai confini. Nessuno dei due rimedi elimina il degrado; entrambi si limitano ad aggirarlo.

La risposta pratica di Thariq è il rewind. Invece di correggere all'interno di una sessione ormai inquinata, si torna al punto subito successivo alle letture dei file e si riformula il prompt con quanto appreso nel frattempo. La sua cautela riguardo alla compaction è più marcata: è un processo lossy, e il modello si trova nel suo momento di minore intelligenza proprio quando deve decidere cosa conservare.

Thariq si aspetta che «Claude Code» arrivi col tempo a gestire questi meccanismi da solo. Fino ad allora, la gestione della sessione resta una competenza dell'utente.