Il contesto è un budget

C'è un momento, nelle sessioni lunghe con un agente di coding, in cui le risposte cambiano senza che cambi il tono. Ti ripropone una strada che avevate scartato un'ora prima. Perde un vincolo che era stato deciso a voce e mai scritto in un file. Comincia a dichiarare finito un lavoro che non è finito.

Nessuna di queste cose viene segnalata. Il modello non ti dice «da qui in poi ragiono peggio»: continua a rispondere con la stessa sicurezza di due ore prima, e sei tu che a un certo punto ti accorgi che stai correggendo più di quanto stai costruendo.

Il degrado non aspetta il milione

La finestra di contesto è una capienza, non una garanzia. Sono due cose diverse, e il marketing le tiene volutamente vicine.

Le due misure migliori che conosco hanno più di un anno, e conviene dirlo prima dei numeri: i modelli che ci compaiono sono in buona parte superati, alcuni deprecati. Non vanno letti come la fotografia di oggi. Servono a stabilire che il fenomeno esiste e come si comporta, e su quello nessuno dei lavori usciti dopo li ha smentiti.

NoLiMa (Adobe Research, febbraio 2025, poi ICML 2025) ha testato dodici modelli che dichiaravano almeno 128k token, con domande che non condividono parole con la risposta — quindi non risolvibili per corrispondenza letterale. A 32k token, dieci di quei dodici scendevano sotto la metà del punteggio ottenuto a contesto corto. GPT-4o, che oggi è vecchio e in via di pensionamento ma allora era fra i migliori del gruppo, passava da 99,3% a 69,7%. Trentaduemila token: in una sessione di lavoro vera li superi prima di pranzo.

Chroma (luglio 2025) ha ripetuto la misura su diciotto modelli — Claude, GPT, Gemini, Qwen, anche questi nelle versioni di allora — nel lavoro che ha reso popolare il termine context rot. Il risultato non è «oltre una certa soglia crolla»: è che le prestazioni non restano costanti a nessun incremento di lunghezza, nemmeno su compiti banali, e che il calo non è uniforme. Basta un solo distrattore nel contesto per scendere sotto la baseline. Sul benchmark conversazionale LongMemEval la differenza fra dare al modello i circa 300 token che servono e dargli i 113k della conversazione intera è netta su tutti.

Il controargomento è legittimo, ed è doppio: sono benchmark sintetici, e sono su modelli di ieri. Vale per i numeri precisi, non per la direzione — che è la stessa su trenta modelli e quattro famiglie diverse, e che Anthropic spiega in termini architetturali invece che empirici: il modello ha un budget di attenzione finito, ogni token che aggiungi lo consuma, e il transformer costruisce relazioni a coppie fra tutti i token — che a centomila token sono dieci miliardi. È una proprietà del meccanismo, non un difetto di una generazione. Un modello nuovo sposta la soglia; non la toglie.

Il compact non è la soluzione, è il sintomo

La risposta ovvia, quando il contesto si riempie, è compattare: riassumere la conversazione e continuare da lì. È anche quello che l'auto-compact fa da solo, e quasi sempre nel momento peggiore.

Il problema è cosa il riassunto si porta dietro. Se hai passato due ore su un bug che alla fine era una condizione invertita, nella sessione ci sono tutte le ipotesi sbagliate fatte per arrivarci. Il compact non le distingue dal resto: riassume anche quelle, e il modello se le ritrova come stato buono — riassunte, quindi senza più il contesto che permetteva di scartarle.

Su questo Anthropic ha scritto la cosa più utile che ho letto quest'anno. Nel pezzo sul design del harness per applicazioni long-running, di marzo 2026, distinguono compaction e context reset: la prima riassume nello stesso posto e lascia in piedi quella che chiamano context anxiety — l'agente comincia a chiudere il lavoro in anticipo perché crede di essere vicino al limite. Con Sonnet 4.5 il fenomeno era abbastanza forte che la sola compaction non bastava a reggere task lunghi. La soluzione che hanno adottato è azzerare la finestra e far ripartire un agente nuovo, con un artefatto di handoff che porta lo stato e i prossimi passi.

Un compact ti restituisce spazio, non qualità. Il rumore che avevi accumulato rientra riassunto, e il modello lo tratta come contesto buono.

L'handoff è il passaggio che decidi tu

La differenza fra un compact e un handoff non è tecnica, è di autorità. Il compact è una compressione che subisci: decide la macchina cosa sopravvive, e lo decide in base a quanto spazio serve. L'handoff è un documento che scrivi tu, su disco, prima di azzerare — e quello che ci metti dentro è una scelta.

La skill handoff di Matt Pocock è la versione più asciutta che conosco. Scrive il documento nella temp dir del sistema e non nel workspace, così non ti sporca il repo. Include una sezione «suggested skills», cioè dice all'agente successivo con cosa dovrebbe attaccare. E soprattutto vieta la duplicazione: quello che sta già in un piano, in un ADR, in un commit o in un diff non va riassunto, va referenziato per path. È la regola che tiene il documento piccolo, ed è la stessa ragione per cui funziona — un handoff lungo è un compact scritto a mano.

Poi /clear, e riparti con una finestra vuota e trecento righe di stato scelto. È lo stesso principio di cui ho già scritto a proposito di quando non automatizzare: la parte automatizzabile è il trasporto, non il giudizio su cosa valga la pena portarsi dietro.

Ma per decidere devi vedere il numero

Qui c'è il buco pratico. L'handoff va fatto prima che serva, e per farlo prima devi sapere a che punto sei. Claude Code il numero ce l'ha, ma te lo mostra tardi e di sfuggita: quando compare l'avviso, il degrado di cui parla NoLiMa è cominciato da un pezzo.

È il motivo per cui ho scritto imperStatusLine, una status line per Claude Code. L'idea di partenza è banale: la status line è l'unica superficie sempre visibile mentre lavori, ed è sprecata a mostrare la directory corrente.

Al centro c'è la barra del contesto: ◉ per la parte occupata, ◯ per quella libera, dimensionata sulla larghezza reale del terminale. Accanto, la percentuale e la dimensione vera della finestra — letta dal campo che Claude Code passa, non indovinata dal nome del modello. Nello scatto è al 15% di un milione: è il momento in cui non devi pensarci, ed è esattamente il momento in cui una status line deve saper stare zitta.

Il colore dice una cosa sola, e la dice ovunque

Una funzione, color_pct, colora la percentuale di contesto, la quota a cinque ore e quella a sette giorni: verde sotto il 60%, giallo fino al 79, rosso da 80 in su. Tre grandezze diverse, una scala unica, niente da ricordare.

Le due eccezioni sono volute, e sono il punto in cui il rosso cambia significato. L'effort è colorato al contrario del buon senso — low verde, medium giallo, high, xhigh e max rossi — perché lì il rosso non dice «male», dice «stai spendendo». Il permission mode segue la stessa logica: default verde, accept giallo, plan viola, bypass rosso. Non perché lavorare in bypass sia sbagliato, ma perché è l'unico stato in cui nessuno ti ferma, e vale la pena saperlo senza doverci pensare.

Il marcatore che riguarda proprio questo articolo

Sulla riga del contesto, quando la sessione supera i 200.000 token, compare un ⚠ 200k rosso. Non è una soglia che ho scelto io: è il campo exceeds_200k_tokens che Claude Code passa già e che quasi nessuna interfaccia mostra.

Serve perché su una finestra da un milione la barra resta verde fino al 60%, cioè fino a seicentomila token — tre volte oltre. Quel marcatore è l'unica cosa che ti ricorda che la capienza e la zona in cui il modello ragiona bene sono due numeri diversi, ed è tutto l'argomento di questo articolo compresso in cinque caratteri.

Le righe, una per una

Nello scatto la riga PWD non c'è, e non è un guasto: giro in Warp, che mostra già directory, branch e diff nella sua barra in basso, quindi lo script la sopprime — e per la stessa ragione toglie il Lines +/- dalla riga SESSION. Un'informazione duplicata a schermo costa attenzione quanto una nascosta.

Non è un cruscotto per curiosità. Ognuna di quelle righe è l'ingresso di una decisione: la percentuale dice se è ora di fare handoff, il permission mode dice quanto puoi lasciar correre, la quota a sette giorni dice se conviene bruciare il modello grosso adesso o fra due ore, i task in volo dicono se hai davvero finito. Sono le stesse informazioni che prima andavi a cercare in tre posti diversi, ognuna a un costo di attenzione che pagavi solo quando ti ricordavi di pagarlo.

Installarla

git clone https://github.com/imperugo/imperStatusLine.git
cd imperStatusLine
./install.sh

L'installer copia lo script in ~/.claude/imperStatusLine.sh, lo rende eseguibile e scrive la voce in ~/.claude/settings.json:

"statusLine": {
  "type": "command",
  "command": "bash $HOME/.claude/imperStatusLine.sh",
  "padding": 0
}

Se trova una versione precedente la mette da parte come .bak.<epoch> invece di sovrascriverla, ed è idempotente: rilanciarlo su una macchina già a posto non fa danni. ./install.sh --uninstall rimuove la voce dal settings e lo script.

L'unica dipendenza obbligatoria è jq. npx e ccusage servono solo come ripiego per la quota a cinque ore, quando Claude Code non passa i rate limit nativi. Su Windows lo script si cerca jq da solo nei percorsi di winget, perché la bash che Claude Code usa lì non eredita il PATH di sistema: senza quella ricerca ogni campo esce a zero, e non in modo evidente.

Cosa non fa

Non ti evita le allucinazioni e non ti gestisce il contesto. Non c'è nessuna intelligenza dentro: legge quello che Claude Code passa e lo dispone in modo che tu possa deciderci sopra. Il giudizio resta tuo, come nei sistemi di cui ho scritto a proposito dell'human-in-the-loop — con la differenza che qui la persona nel ciclo sei tu, e il ciclo è il tuo pomeriggio.

La parte che è costata più del previsto è quella che non si vede. Dalla versione 2.1 Claude Code passa il contesto, il costo, l'effort, i rate limit e lo stato della PR direttamente nel JSON su stdin; prima andavano ricostruiti leggendo il transcript e chiamando uno strumento esterno per le quote. Tenere in piedi i due percorsi è la maggior parte della complessità dello script, ed è la parte che si rompe quando un campo viene rinominato. È anche l'unica che vale la pena curare: una status line che mostra un numero sbagliato è peggio di una status line che non c'è, perché il numero sbagliato lo guardi e ci credi.

La regola che seguo

Guardo la barra prima di cominciare una cosa nuova, non quando sono in mezzo. Sopra il 60% non apro un fronte nuovo: chiudo quello aperto, scrivo l'handoff, /clear, e riparto. Sotto il 60% non ci penso.

Non è una soglia misurata, è una soglia comoda: sta abbastanza sotto la zona in cui i benchmark vedono il calo, e abbastanza sopra da non farti ricominciare ogni venti minuti. Il punto non è il numero. È che il numero sia sotto gli occhi, perché la decisione giusta al momento giusto la prendi solo se il momento lo vedi arrivare.

Fonti

• Adobe Research, NoLiMa: Long-Context Evaluation Beyond Literal Matching (febbraio 2025, ICML 2025) — https://arxiv.org/abs/2502.05167
• Chroma, Context Rot: How Increasing Input Tokens Impacts LLM Performance (luglio 2025) — https://www.trychroma.com/research/context-rot
• Anthropic, Effective context engineering for AI agents (settembre 2025) — https://www.anthropic.com/engineering/effective-context-engineering-for-ai-agents
• Anthropic, Harness design for long-running application development (marzo 2026) — https://www.anthropic.com/engineering/harness-design-long-running-apps
• Anthropic, Effective harnesses for long-running agents (novembre 2025) — https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Matt Pocock, la skill handoff — https://github.com/mattpocock/skills
• imperStatusLine — https://github.com/imperugo/imperStatusLine