La compattazione inattiva di Claude Code preserva la cache, ma riprende da un riepilogo

La compattazione inattiva di Claude Code può ora riassumere una sessione di grandi dimensioni prima che la cache del prompt scada, anche quando la finestra di contesto non è piena. Per impostazione predefinita, la funzionalità è rivolta alle sessioni che contengono almeno 200.000 token. Il compromesso centrale è netto: Claude torna a un contesto più economico e più breve, ma prosegue da un riepilogo generato anziché da ogni turno originale.

Lydia Hallie, ingegnera di Anthropic, ha descritto questo comportamento in un post sulla compattazione inattiva dell'ottobre 2026. Gli utenti possono disattivare la funzione aggiungendo "idleCompaction": false a un file delle impostazioni di Claude Code. Possono inoltre modificare la soglia minima di contesto con CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS.

Questo controllo è arrivato dopo che gli sviluppatori avevano segnalato compattazioni inattese in sessioni di lunga durata. La loro preoccupazione non era l'esistenza della compattazione. Claude Code riassumeva già le conversazioni vicine ai limiti di contesto. Il punto di conflitto era se un timer di inattività dovesse sostituire una trascrizione ancora utilizzabile per ridurre il costo del ritorno dopo la scadenza della cache.

La compattazione inattiva di Claude Code cambia il significato della ripresa

Una sessione ripresa può mantenere la propria identità pur perdendo la cronologia letterale che l'aveva originariamente definita.

Claude Code archivia localmente i messaggi delle sessioni e supporta la loro riapertura con --continue o --resume. Questa persistenza può far sembrare una sessione uno spazio di lavoro duraturo. Tuttavia, il modello ragiona solo sul contesto inviato nella richiesta corrente, non su ogni artefatto archiviato sul disco.

La guida alla finestra di contesto di Anthropic spiega che il contesto attivo contiene cronologia della conversazione, contenuti dei file, output dei comandi, istruzioni del progetto, memorie, skill e istruzioni di sistema. Man mano che questi materiali si accumulano, Claude Code elimina gli output degli strumenti più vecchi e infine riassume la conversazione.

La compattazione consiste nel sostituire il materiale conversazionale più vecchio con un riepilogo più breve. La sessione resta disponibile e Claude può continuare a lavorare. Tuttavia, il modello non riceve più parola per parola ogni turno sostituito.

Il nuovo percorso inattivo cambia quando può avvenire tale sostituzione. La tradizionale compattazione automatica risponde a un budget di contesto in diminuzione. La compattazione inattiva risponde invece all'inattività e alla tempistica della cache del prompt, a condizione che la sessione sia sufficientemente grande.

Gli utenti hanno iniziato a segnalare il messaggio “Compacted while idle, before the prompt cache expired,” dopo aver lasciato le sessioni incustodite. Le segnalazioni hanno associato il rollout a Claude Code 2.1.286, sebbene il comportamento fosse controllato in parte da un gate lato server. Ciò significa che l'installazione di una specifica versione client non rivelava necessariamente lo stato completo del rollout.

La soglia minima predefinita riportata da Hallie e discussa nel repository pubblico di Anthropic è di 200.000 token. Quel numero è una soglia di idoneità, non la promessa che la compattazione avvenga esattamente quando la conversazione raggiunge 200.000 token.

Una sessione idonea richiede anche le condizioni di cache pertinenti e un tempo di inattività sufficiente. L'indagine della community nella segnalazione sulla compattazione inattiva ha rilevato che il timer si avvicinava alla fine di un periodo di cache del prompt di un'ora. Gli utenti hanno osservato l'evento visibile circa 54-56 minuti dopo l'ultima attività.

Questi dettagli temporali provengono da partecipanti alla segnalazione che hanno esaminato il comportamento del client ed eseguito test locali. La documentazione pubblica di Claude Code di Anthropic inizialmente non forniva una specifica completa della compattazione inattiva. I lettori dovrebbero quindi distinguere tre livelli di evidenza: la descrizione della compattazione di Anthropic, l'annuncio dell'ingegnera e l'analisi della community sui dettagli di implementazione.

La conseguenza verificata sul prodotto resta chiara in tutte queste fonti. Dopo la compattazione inattiva, Claude riprende da uno stato conversazionale compresso. La trascrizione originale può ancora esistere localmente, ma il suo contenuto completo non è più automaticamente presente nel contesto di lavoro del modello.

Questa distinzione conta perché la persistenza locale e l'attenzione del modello risolvono problemi diversi. Una trascrizione archiviata supporta audit e recupero. Il contesto attivo determina ciò che Claude può prendere in considerazione durante la risposta successiva.

La funzionalità scambia fedeltà del contesto con efficienza della cache

La compattazione inattiva sposta il lavoro da un ritorno potenzialmente a freddo all'ultima finestra con cache calda, accettando la perdita del riepilogo per ridurre l'elaborazione ripetuta del contesto.

La cache del prompt consente alle richieste ripetute di riutilizzare prefissi di input corrispondenti. Un cache hit richiede in genere meno elaborazione dell'input rispetto alla ricostruzione dello stesso grande prefisso dopo la scadenza della sua voce in cache. Le lunghe sessioni di Claude Code creano prefissi riutilizzabili insolitamente grandi perché ogni turno può includere messaggi precedenti, attività degli strumenti e materiale del progetto.

La documentazione sulla cache del prompt di Anthropic descrive la durata della cache e il diverso trattamento delle scritture e delle letture della cache. Una lunga sessione che si raffredda può richiedere a Claude Code di elaborare di nuovo un prefisso sostanziale quando l'utente torna.

La compattazione inattiva cerca di intervenire prima di quel momento. Mentre il grande prefisso resta nella cache, Claude Code può chiedere al modello di riassumerlo. Una richiesta successiva inizia con il riepilogo più breve e con tutte le istruzioni o i materiali del progetto che Claude Code ripristina.

Questo meccanismo privilegia l'efficienza quando un utente intende riprendere una grande sessione dopo una pausa. Invece di tornare con l'intero vecchio contesto, l'utente torna con una rappresentazione compressa che richiede meno token da elaborare.

Il costo è la fedeltà delle informazioni. I riepiloghi preservano fatti e decisioni selezionati, ma non garantiscono la conservazione esatta di ogni vincolo, opzione scartata, osservazione dei test o correzione conversazionale.

Anthropic riconosce questa limitazione generale nella propria documentazione sul contesto. Afferma che le richieste e gli snippet di codice fondamentali vengono preservati durante la compattazione, mentre le istruzioni dettagliate delle conversazioni precedenti possono andare perse.

Questo avvertimento diventa più rilevante in una sessione di coding agentico. Un'istruzione sottile può determinare quale percorso di migrazione sia consentito. Un'ipotesi respinta può impedire a Claude di ripetere un'indagine costosa. Una piccola anomalia nei test può spiegare perché una correzione apparentemente ovvia non sia sicura.

Questi dettagli possono sembrare secondari a un sistema di riepilogo, pur restando decisivi per il successivo passaggio di coding. Un riepilogo può descrivere accuratamente l'obiettivo generale del progetto e comunque omettere le evidenze che ne hanno vincolato l'implementazione.

Il rischio aumenta nelle sessioni lunghe ed esplorative. Uno sviluppatore potrebbe chiedere a Claude di esaminare diversi moduli, confrontare progetti concorrenti, eseguire test e abbandonare due approcci. La direzione finale potrebbe dipendere da risultati negativi sparsi tra output dei comandi e brevi correzioni.

Dopo la compattazione, Claude può ricordare che è stato scelto un approccio senza conservare tutte le ragioni per cui le alternative sono fallite. Può quindi ricostruire una spiegazione plausibile che differisce dall'indagine effettiva.

Questo non rende la compattazione intrinsecamente difettosa. Nessun sistema finito di gestione del contesto può mantenere una cronologia illimitata parola per parola. La disputa riguarda tempistiche e intenzione dell'utente.

Vicino a un limite rigido di contesto, il riepilogo impedisce alla sessione di interrompersi. Prima della scadenza della cache, il prodotto sceglie l'efficienza anche se la sessione potrebbe ancora avere una capacità di contesto residua sostanziale.

Questo è il principale antagonista di questa storia: efficienza della cache contro fedeltà del contesto. Non è Claude Code contro un altro assistente di coding. Ogni agente di lunga durata deve infine gestire un contesto finito, ma il trigger di inattività rende insolitamente visibile l'equilibrio scelto da Anthropic.

Perché gli sviluppatori hanno contestato un riepilogo automatico

La reazione negativa si è concentrata su un cambiamento di stato non annunciato, non sull'esistenza stessa della compressione del contesto.

Uno sviluppatore che inserisce manualmente /compact sa che Claude riepilogherà la conversazione precedente. Il comando può includere un focus, come preservare le decisioni API o i fallimenti dei test non risolti. Quel momento crea un naturale confine di revisione.

La compattazione inattiva elimina quella scelta immediata. Un utente può allontanarsi per pranzo, partecipare a una riunione o attendere feedback esterni, per poi tornare a una sessione la cui cronologia attiva è cambiata.

La segnalazione GitHub originale descriveva più sessioni di lavoro compattate durante l'inattività. Il segnalante ha affermato che i riepiloghi omettevano istruzioni esatte, ragionamenti decisionali e metodi concordati in precedenza. Altri utenti hanno riferito di aver visto la stessa notifica pur non essendo vicini alla soglia di contesto configurata.

Si tratta di segnalazioni degli utenti, non di misurazioni controllate dell'accuratezza dei riepiloghi. Tuttavia, identificano un rischio credibile per il prodotto perché la documentazione di Anthropic afferma già che i dettagli iniziali possono andare persi durante la compattazione.

Anche l'implementazione iniziale ha complicato il monitoraggio. Secondo i test documentati nella segnalazione, le prime compattazioni inattive apparivano nei metadati degli hook come manual, nonostante nessun utente avesse inserito /compact.

Gli hook di Claude Code consentono ai team di eseguire automazioni prima o dopo eventi definiti. Un'etichetta di trigger fuorviante rende più difficile distinguere un'azione deliberata dell'utente da una transizione guidata dal timer.

Claude Code 2.1.290 ha modificato quel trigger in auto, secondo un collaboratore di Anthropic nel repository. Ciò separa la compattazione inattiva da /compact invocato esplicitamente, ma non distingue pienamente la compattazione inattiva dalla normale compattazione automatica basata sulla soglia.

Questa ambiguità è importante per i team che usano gli hook per preservare lo stato di lavoro. Un hook potrebbe volere una politica prima di una compattazione di emergenza al limite del contesto e un'altra prima di una compattazione inattiva guidata dalla cache.

La discussione sulla segnalazione ha richiesto un trigger idle distinto. In base al comportamento riportato della versione 2.1.290, sia gli eventi di inattività sia quelli legati alla soglia di contesto potevano apparire come auto. La notifica del terminale identificava l'evento inattivo per l'utente, ma tale avviso non era necessariamente incluso nell'input dell'hook.

La lezione più ampia sul prodotto riguarda l'ottimizzazione invisibile. Gli sviluppatori di solito accettano un'ottimizzazione quando modifica latenza o uso delle risorse senza cambiare la semantica. Il riepilogo può modificare la semantica perché la richiesta successiva al modello riceve evidenze diverse.

Questo rende la compattazione inattiva più simile a una migrazione automatica dello stato che a un'attività di pulizia in background. L'identificatore della sessione resta stabile, mentre il substrato del ragionamento cambia.

I team che gestiscono migrazioni ad alto rischio, risposta agli incidenti o revisioni di codice estese hanno motivo di trattare questa transizione con cautela. Le loro sessioni spesso accumulano vincoli individualmente piccoli ma collettivamente importanti.

Le sessioni più brevi sono meno esposte perché rimangono al di sotto della soglia minima. Anche i flussi di lavoro già costruiti attorno a passaggi di consegne espliciti riducono il costo, poiché lo stato critico esiste al di fuori della trascrizione della chat.

La pressione ricade quindi soprattutto sugli sviluppatori che trattano una lunga sessione di Claude Code come un partner di progetto persistente. Sono quelli che guadagnano di più dalla continuità, ma perdono anche di più quando la continuità diventa dipendente da un riepilogo senza un confine intenzionale.

L'impostazione idleCompaction separa due diverse protezioni

Gli utenti possono disattivare la compattazione inattiva senza disattivare la compattazione automatica che protegge le sessioni vicine al limite di contesto.

Claude Code 2.1.290 ha introdotto un'impostazione dedicata, secondo un collaboratore di Anthropic che ha risposto nella segnalazione pubblica. Un utente ha poi confermato che l'opzione funzionava nella versione 2.1.291.

La configurazione di base è la seguente:

Claude Code supporta impostazioni a diversi livelli di ambito, inclusi utente, progetto, progetto locale e policy gestite. Il riferimento delle impostazioni di Anthropic ne spiega posizione e precedenza.

Una preferenza valida per l’intero utente può essere inserita nel file delle impostazioni personali. Un team che lavora su un repository può inserire le impostazioni del progetto nel controllo di versione quando tutti devono condividere lo stesso comportamento. Un’impostazione di progetto locale può sovrascrivere il comportamento senza modificare la configurazione condivisa del repository.

La distinzione importante è tra idleCompaction e autoCompactEnabled. La prima riguarda il nuovo percorso basato su timer. La seconda governa il comportamento più ampio della compattazione automatica.

Disattivare "idleCompaction": false preserva la normale compattazione alla soglia, in base al comportamento descritto per la versione 2.1.290. È utile agli sviluppatori che desiderano protezione in prossimità di una finestra di contesto piena, ma rifiutano la sintesi guidata dalla cache durante le pause.

Questa separazione ha risposto direttamente alla richiesta più forte degli utenti. Prima che apparisse l’interruttore dedicato, disabilitare la compattazione automatica in senso più ampio poteva anche rimuovere la protezione che impedisce a una sessione di raggiungere il proprio limite di contesto.

Gli utenti dovrebbero verificare la versione installata prima di presumere che la chiave funzioni. Eseguire:

Il problema pubblico colloca l’impostazione nella versione 2.1.290, mentre un utente ne ha confermato esplicitamente il funzionamento nella 2.1.291. Le organizzazioni con installazioni gestite potrebbero inoltre ricevere aggiornamenti secondo una pianificazione controllata.

Il gate lato server della funzionalità offre un’ulteriore ragione di cautela. Impostare idleCompaction su true non obbliga necessariamente Anthropic ad abilitare la funzionalità per ogni account o ambiente. Consente il comportamento del client quando si applicano altre condizioni di idoneità.

Impostarlo su false è il controllo pertinente per gli utenti che necessitano di un opt-out. I team dovrebbero comunque testare il comportamento nella propria installazione, con il proprio tipo di account e la propria gerarchia di policy.

Un’impostazione gestita può avere la precedenza su una scelta dell’utente. È appropriato per le organizzazioni con configurazione centralizzata, ma significa che modificare un singolo file locale potrebbe non produrre il risultato previsto.

Il metodo di verifica più sicuro è comportamentale. Confermare la versione del client, ispezionare le impostazioni effettive e testare con una sessione non critica prima di fare affidamento sull’opzione durante un lavoro importante.

Gli utenti dovrebbero inoltre conservare istruzioni durature al di fuori della cronologia conversazionale. Anthropic raccomanda di inserire le regole persistenti in CLAUDE.md, che Claude Code carica come contesto del progetto. Il consiglio vale sia che la compattazione inattiva sia abilitata sia che sia disabilitata, perché può comunque verificarsi la normale compattazione vicino al limite.

Una base di conoscenza ingegneristica ricercabile può svolgere uno scopo analogo per i team umani. Decisioni, vincoli e risultati delle indagini diventano artefatti recuperabili anziché dipendere interamente da una singola sessione agente.

La soglia di 200K è regolabile, ma non è un limite di contesto

`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` modifica il momento in cui una sessione è idonea alla compattazione inattiva, non la dimensione della finestra di contesto del modello.

Hallie ha dichiarato che il minimo predefinito è di 200.000 token. Gli utenti possono fornire un diverso valore intero tramite la configurazione dell’ambiente nelle impostazioni di Claude Code.

Per esempio:

Questo esempio aumenta la soglia di idoneità a 400.000 token. Non concede una finestra di contesto più ampia, non riserva 400.000 token alla cronologia della conversazione e non garantisce che la compattazione si attivi immediatamente a quel punto.

L’analisi del problema pubblico ha riportato un limite inferiore di 100.000 token. I valori inferiori a tale soglia sono stati descritti come elevati a 100.000. Quando si è svolta la discussione, Anthropic non aveva documentato pienamente la variabile d’ambiente nel riferimento pubblico delle impostazioni, quindi gli utenti dovrebbero considerare i dettagli di implementazione sensibili alla versione.

Aumentare la soglia favorisce la fedeltà. Più sessioni di grandi dimensioni possono rimanere inattive senza essere sintetizzate, anche se il ritorno dopo la scadenza della cache può richiedere più elaborazione dell’input.

Ridurre la soglia favorisce l’efficienza della cache. Più sessioni diventano idonee alla compattazione prima della scadenza, aumentando la probabilità che gli utenti tornino a dei riepiloghi anziché alla cronologia conversazionale completa.

Il valore corretto dipende dalla forma del flusso di lavoro, non semplicemente dalla capacità del modello. Una lunga sessione con output di strumenti ripetitivo può essere sintetizzata bene. Una discussione architetturale più breve può contenere decisioni dense e interdipendenti che resistono alla compressione.

Il conteggio dei token misura la dimensione, non l’importanza semantica. Una sessione di debugging da 300.000 token potrebbe includere migliaia di righe di log eliminabili. Una revisione della sicurezza da 120.000 token potrebbe contenere numerose e precise ipotesi sulle minacce che dovrebbero restare testuali.

Ecco perché un minimo configurabile aiuta senza risolvere la tensione fondamentale. Consente ai team di scegliere dove inizia il compromesso, ma una soglia numerica non può riconoscere se la conversazione corrente sia sicura da sintetizzare.

Gli sviluppatori possono ridurre il rischio creando checkpoint espliciti prima di lasciare una sessione. Chiedete a Claude di registrare l’obiettivo attivo, le conclusioni confermate, gli approcci scartati, i file modificati, lo stato dei test e il comando successivo in una nota del repository.

Quella nota non dovrebbe limitarsi a riaffermare l’attività. Dovrebbe acquisire le prove necessarie per riprendere senza ricostruire l’intera conversazione.

I vincoli persistenti appartengono a CLAUDE.md o a un altro file di progetto autorevole. Le scoperte temporanee appartengono a un issue, un registro di lavoro o un documento di passaggio di consegne. I riepiloghi generati possono quindi favorire la continuità senza diventare l’unica registrazione.

I team possono anche usare /context per ispezionare cosa sta consumando la finestra attiva. Se prevale un output di comandi voluminoso, cancellare o ristrutturare quel materiale può essere più sicuro che lasciare a un riepilogo generale la decisione su ciò che conta.

La compattazione manuale con /compact rimane utile ai confini naturali. Anthropic afferma che gli utenti possono aggiungere istruzioni di focalizzazione, offrendo al sintetizzatore un obiettivo di conservazione migliore rispetto a un evento di inattività non presidiato.

Il principio più ampio è semplice: quando possibile, scegliere la compattazione in base ai confini dell’attività. Le soglie di token prevengono il fallimento, ma i confini definiti dagli esseri umani riflettono meglio la struttura del lavoro ingegneristico.

Cosa preserva la compattazione di Claude Code e cosa non può promettere

La compattazione preserva una rappresentazione operativa della sessione, non una copia senza perdite della sua cronologia di ragionamento.

La documentazione di Claude Platform di Anthropic definisce la compattazione come la sostituzione dei turni di conversazione più vecchi con un riepilogo scritto dal modello. La sua panoramica della compattazione spiega che le applicazioni continuano inserendo il blocco compattato restituito nel punto in cui in precedenza comparivano i messaggi sintetizzati.

Claude Code gestisce questo flusso di lavoro all’interno del prodotto. L’implementazione precisa differisce da quella di un’applicazione che usa direttamente l’API Claude, ma il risultato concettuale è simile: l’input precedente è rappresentato da testo generato.

Un buon riepilogo può mantenere la richiesta dell’utente, lo stato attuale dell’implementazione, i percorsi di file importanti, i risultati dei test e le attività rimanenti. Può ridurre drasticamente la quantità di materiale precedente inviata nei turni successivi.

Non può garantire la conservazione letterale di ogni scambio. Il sintetizzatore deve selezionare informazioni, organizzarle ed esprimerle entro un budget di token più ridotto.

La cronologia di ragionamento pone una sfida particolare. Una sessione di coding contiene spesso una catena di eliminazioni. Claude esamina un file, formula un’ipotesi, vede un output contraddittorio e cambia direzione.

Il riepilogo finale può registrare la spiegazione accettata comprimendo il percorso che l’ha convalidata. Spesso è sufficiente, ma indebolisce la capacità del modello successivo di verificare la conclusione.

L’output degli strumenti crea un altro problema. Log, errori del compilatore, piani di database e tracce dei test possono contenere piccoli dettagli la cui importanza diventa evidente solo in seguito. Un riepilogo prodotto prima di tale scoperta successiva non può sapere quale riga risulterà importante.

Anche le correzioni dell’utente possono perdere forza. “Non modificare lo schema” può comparire una sola volta, seguito da centinaia di turni. Se non viene promosso a istruzioni persistenti, la compattazione può ridurne o ometterne l’importanza.

La documentazione di Claude Code raccomanda esplicitamente CLAUDE.md per le regole che devono sopravvivere. Supporta inoltre una sezione “Compact Instructions”, che indica al sintetizzatore cosa conservare durante la compattazione.

Questi meccanismi riducono il rischio, ma non rendono i riepiloghi privi di perdite. Un’istruzione di compattazione è comunque una guida per un modello che effettua una selezione. Un file di istruzioni del progetto è più forte perché Claude Code può caricarlo di nuovo come contesto autorevole.

Gli sviluppatori dovrebbero quindi dividere la conoscenza della sessione in tre classi. Le regole operative permanenti appartengono alle istruzioni del progetto. Lo stato ingegneristico verificato appartiene ai file o ai registri di lavoro tracciati. L’esplorazione conversazionale può rimanere nella trascrizione e accettare un’eventuale compressione.

Questo approccio migliora anche la collaborazione. Un altro ingegnere non può ereditare in modo affidabile la sfumatura non documentata di una conversazione privata con un agente. Un file di passaggio di consegne conciso offre a esseri umani e agenti un punto di recupero condiviso.

La domanda pratica non è se i riepiloghi siano buoni o cattivi. È se un dato particolare possa esistere in sicurezza solo all’interno di un riepilogo.

Se la perdita di un dettaglio causerebbe una migrazione non sicura, un incidente ripetuto o un risultato non valido, registratelo al di fuori della conversazione prima di lasciare la sessione.

Tre segnali mostreranno se la compattazione inattiva merita fiducia

Il prossimo test è capire se Anthropic riuscirà a rendere osservabile il beneficio in termini di efficienza senza rendere imprevedibile la continuità della sessione.

Il primo segnale è la documentazione ufficiale. Gli utenti hanno bisogno di una descrizione stabile di idoneità, tempistiche, versioni supportate, limiti di soglia, precedenza delle impostazioni e interazioni con le policy della cache dei prompt.

La documentazione chiarirebbe inoltre se il valore predefinito di 200.000 token si applica in modo uniforme a modelli e account. Se Anthropic documenta la variabile d’ambiente e il suo limite inferiore, i team potranno configurarla senza fare affidamento sull’archeologia degli issue.

Questo risultato rafforzerebbe la fiducia nella funzionalità. La continua dipendenza da post sui social e dall’ispezione dei binari la indebolirebbe, poiché i controlli non documentati possono cambiare senza un percorso di migrazione evidente.

Il secondo segnale è costituito da metadati distinti per gli hook. Un trigger idle dedicato consentirebbe ai team di trattare la compattazione guidata dal timer in modo diverso sia dai comandi manuali /compact sia dalla compattazione automatica vicino al limite.

Le organizzazioni potrebbero acquisire un’istantanea dello stato prima di un evento di inattività, allegare istruzioni di compattazione personalizzate o registrare telemetria sulla frequenza di attivazione della funzionalità. Un’identità chiara dell’evento renderebbe inoltre più semplice l’analisi degli incidenti.

Se Anthropic manterrà entrambi i percorsi automatici sotto la stessa etichetta auto, gli amministratori avranno visibilità limitata sul motivo per cui una sessione è cambiata. Ciò conserverebbe un divario tra l’esperienza nel terminale e le interfacce di automazione.

Il terzo segnale è costituito dalle prove sulla qualità dei riepiloghi nelle lunghe sessioni di coding. Le segnalazioni degli utenti identificano sfumature mancanti, ma la discussione pubblica non stabilisce un tasso generale di fallimento.

Una valutazione utile misurerebbe se i riepiloghi preservano vincoli espliciti, ipotesi scartate, attività in sospeso, fallimenti dei test, riferimenti ai file e regole di sicurezza. Dovrebbe inoltre testare la compattazione ripetuta, perché gli errori possono accumularsi quando uno stato compresso diventa input per un altro.

Un risultato positivo sosterrebbe l’argomentazione di Anthropic sull’efficienza. Dimostrerebbe che la maggior parte delle sessioni idonee riprende con precisione sufficiente a giustificare la compressione automatica prima della scadenza della cache.

Un risultato negativo rafforzerebbe la tesi a favore di un comportamento opt-in o di soglie predefinite più elevate. Potrebbe inoltre spingere Claude Code verso una compattazione parziale che mantenga letterali i turni recenti sintetizzando al contempo il materiale più vecchio.

Per ora, gli sviluppatori hanno una scelta praticabile. Mantieni attiva la compattazione per inattività di Claude Code quando un minor sovraccarico alla ripresa conta più della continuità letterale. Aumenta la soglia dei token quando il compromesso è giustificato solo da sessioni molto grandi.

Disattivala con "idleCompaction": false quando una sessione in pausa deve riprendere mantenendo intatta la cronologia attiva esistente. La normale compattazione al limite di contesto può restare abilitata come salvaguardia separata.

Qualunque politica tu scelga, non fare di una lunga chat l'unico registro dello stato critico dell'ingegneria. Inserisci i vincoli duraturi nelle istruzioni del progetto, conserva le evidenze verificate nei file e crea un passaggio di consegne prima di allontanarti.

La compattazione per inattività di Claude Code mette in luce una verità fondamentale sugli agenti di programmazione: la continuità della sessione non equivale a una memoria perfetta. Prima della tua prossima lunga pausa, decidi quale delle due sia davvero necessaria al tuo flusso di lavoro.