Claude Code sessione lenta o costosa?

Come evitare che una sessione prolungata di Claude Code diventi lenta e costosa

Una sessione prolungata di Claude Code diventa lenta e costosa perché ogni turno invia nuovamente l'intero contesto, il quale aumenta progressivamente. La soluzione consiste nell'applicare una gestione ordinata della memoria. Esegui /context per identificare gli elementi che occupano la finestra, rimuovi gli elementi per i quali paghi ad ogni richiesta, quindi usa /clear tra attività non correlate e /compact con un'istruzione specifica all'interno di un'unica attività prolungata. Lavora in sessioni continue, poiché un prompt cache non aggiornato trasforma una lettura economica in una riscrittura completa di tutto il testo inviato.

Le cause del consumo di token sono spiegate in il contatore dei token dietro una sessione agent.

Leggi /context prima di apportare modifiche

Non tentare di indovinare il contenuto della finestra. Claude Code lo indicherà.

/context [all] visualizza l'utilizzo del contesto attuale come una griglia colorata, con suggerimenti di ottimizzazione per strumenti ad alto consumo di contesto e per l'eccesso di memoria; all espande il dettaglio per singolo elemento in modalità fullscreen. Interpreta il risultato come cinque categorie.

• Il system prompt. Le istruzioni interne di Claude Code. Fisse per l'intera sessione.
• Tool definitions. Lo schema di ogni tool che l'agent può chiamare, inclusi tutti i server MCP (Model Context Protocol) connessi.
• Memory files. CLAUDE.md e la memoria automatica, caricate all'inizio della sessione.
• Files e tool results. Ogni file letto e ogni output generato dai comandi.
• Message history. I tuoi input e le relative risposte.

Le prime tre categorie sono un costo fisso, applicato a ogni richiesta per tutta la durata della sessione. Le ultime due crescono progressivamente. Riduci il costo fisso una sola volta, all'inizio; gestisci la parte crescente in modo continuo.

Due stringhe indicano che la finestra è piena:

Context exceeds the 200k-token limit by 94k tokens — run /compact or /clear to continue.
Context is 94k tokens past the 200k-token compaction window — run /compact to reduce usage.

La prima indica un limite invalicabile e la richiesta viene rifiutata; l'errore dell'API corrispondente è Prompt is too long. La seconda indica una finestra di compattazione, che può trovarsi al di sotto della finestra di contesto reale del modello su un modello da 1 million token. Le richieste continuano ad avere successo oltre questo limite, quindi si tratta di un avviso e non di un rifiuto.

Su un piano a pagamento, /usage aggiunge la seconda parte, segnalando comportamenti come context prolungato o cache miss e attribuendo l'utilizzo recente a singole skill, subagent e server MCP.

CLAUDE.md è una tassa permanente, quindi mantienilo leggero

Il tuo CLAUDE.md viene caricato nel contesto all'inizio della sessione e rimane attivo. Se contiene una procedura di deployment dettagliata, quei token occupano spazio anche mentre correggi un errore in un file di test. La guida di Anthropic consiglia di includere solo l'essenziale e di mantenere il file sotto le 200 righe.

Sposta le procedure nelle skills. Una skill viene caricata solo quando invocata; un workflow eseguito due volte a settimana non ha costi nei giorni successivi. Le skills hanno un budget dedicato dopo la compattazione: i corpi vengono re-iniettati, con un limite di 5,000 token per skill e 25,000 totali; i più vecchi vengono rimossi per primi. La troncamento mantiene l'inizio del file, quindi posiziona le istruzioni più importanti all'inizio di SKILL.md.

Ciò che sopravvive alla compattazione determina dove deve essere collocata un'istruzione.

• Il system prompt e lo stile di output rimangono invariati, poiché non fanno parte della cronologia dei messaggi.
• Il CLAUDE.md nel project-root, le regole unscoped e l'auto memory vengono re-iniettati dal disco.
• Una regola con frontmatter paths: viene persa finché il file corrispondente non viene riletto.
• Una CLAUDE.md nidificata in una subdirectory viene persa finché non viene riletto un file in quella subdirectory.
• Gli hook non sono influenzati, poiché un hook viene eseguito come codice e non entra mai nel contesto.

Pertanto, una regola necessaria deve trovarsi nel CLAUDE.md del project-root: Claude Code rimuove prima i vecchi output degli strumenti e poi riassume, quindi le istruzioni fornite all'inizio della conversazione potrebbero andare perse. Modifica la memory con /memory. Claude Code mantiene la copia caricata all'inizio della sessione; un taglio a metà sessione mantiene la prompt cache e non si applica fino al prossimo /clear, /compact o restart.

/clear tra i task, /compact all'interno di uno

Questi due comandi sembrano intercambiabili ma hanno costi molto diversi.

/clear [name] avvia una nuova conversazione con contesto vuoto. Non invia alcuna richiesta, quindi non ha costi. Inserisci un nome per etichettare la conversazione precedente nel selettore /resume; /reset e /new sono alias. Usalo non appena passi a un task non correlato, altrimenti il vecchio task verrebbe inviato nuovamente e fatturato per ogni messaggio del nuovo task.

/compact [instructions] libera il contesto continuando la stessa conversazione: riassume la cronologia attuale e la sostituisce. Usalo all'interno di un singolo task prolungato dove è necessaria la continuità.

Fornisci sempre un'istruzione a /compact. Un comando /compact senza istruzioni riassume utilizzando un prompt predefinito che non sa quale parte del lavoro sia ancora necessaria. Un comando con istruzioni mantiene il focus:

/compact focus on the auth bug fix
/compact keep only the plan and the diff

Se esegui la compattazione per lo stesso motivo ogni volta, inserisci un'istruzione fissa nel CLAUDE.md del progetto sotto un'intestazione # Compact instructions. In una nuova sessione /compact stampa Not enough messages to compact., il che significa che non esiste ancora cronologia.

In questo punto si confondono due tipi di costi. La richiesta di riepilogo condivide il tuo prefisso, quindi legge la cache esistente invece di rielaborare la cronologia; la maggior parte del tempo viene impiegata per generare il riepilogo. Compattare un contesto ampio rimane una richiesta ingente, poiché la conversazione da riassumere costituisce l'input. Il passaggio successivo alla compattazione non è la parte lenta: ricostruisce la cache per un prompt molto più breve.

Esistono due comandi più economici. /rewind [description] riporta il codice e la conversazione a un checkpoint; per un percorso che si desidera abbandonare completamente è preferibile alla compattazione, poiché tronca la cronologia a un prefisso già in cache. /recap aggiunge un riepilogo come output del comando invece di sostituire la cronologia, mantenendo intatto il prefisso in cache.

L'esecuzione automatica ripetuta della compattazione stampa questo:

Autocompact is thrashing: the context refilled to the limit...

La compattazione è riuscita, ma l'output di un file o di uno strumento ha riempito la finestra diverse volte di seguito, quindi Claude Code ha smesso di tentare. Recupera leggendo il file sovradimensionato in intervalli di riga, eseguendo /compact con un focus che scarti l'output voluminoso, delegando quel lavoro a un subagent, oppure /clear se la conversazione precedente è conclusa.

I server MCP comportano un overhead fisso

Ogni server MCP connesso aumenta il carico di ogni richiesta per l'intera sessione. Il costo computazionale è presente anche se non si invoca il server.

Claude Code riduce questo impatto. Di default, le definizioni degli strumenti MCP sono differite; solo i nomi degli strumenti entrano nel contesto finché Claude non utilizza uno strumento specifico. Esegui /context per verificare il costo reale dei tuoi server, ed /mcp disable <name> per rimuovere un server che non utilizzerai oggi. Se esegui i tuoi server MCP su un VPS, lo stesso calcolo limita il numero di strumenti che un singolo server dovrebbe esporre.

Esegui questa operazione all'inizio della sessione. Se le definizioni rimangono differite, la connessione o la disconnessione di un server aggiunge solo dati alla conversazione e la cache viene mantenuta. Se invece le definizioni vengono caricate nel prefix (perché la ricerca degli strumenti è disattivata o un server è escluso dalla differimento), la stessa operazione costringe a rileggere tutto alla richiesta successiva.

Filtrare l'output verboso degli strumenti prima dell'inserimento nel context

Il risultato di uno strumento è un input, e l'input viene inviato nuovamente ad ogni turno successivo. Un test run che genera 20,000 token di output non è un costo unico: il costo si ripete ad ogni turno finché l'output rimane nella finestra di contesto.

Filtrare alla fonte. Un hook che riduce un test run ai soli errori prima che Claude lo legga trasforma quel blocco di output in poche centinaia di token, sia per il turno attuale che per ogni successivo invio:

npm test 2>&1 | grep -E "FAIL|Error:" | head -40

Gli hook non entrano mai nel context perché vengono eseguiti come codice. Utilizza questo metodo per qualsiasi strumento il cui output supera la dimensione dello schermo. La stessa logica si applica a un file di 3,000 righe: richiedi solo l'intervallo di righe necessario, poiché l'intero file rimane nella finestra di contesto una volta ricevuto.

Definire l'ambito di lettura dell'agent e delegare i compiti onerosi

Un prompt che specifica il nome del file ne legge il contenuto. Una richiesta generica di riordino del progetto legge tutto ciò che l'agent ritiene rilevante; ogni lettura rimane nella finestra di contesto.

Delega i compiti verbali a un subagent. L'esecuzione dei test e l'elaborazione dei log consumano entrambi contesto reale; un subagent mantiene l'output nella propria finestra e restituisce solo un riassunto. Il compromesso: un subagent crea un proprio cache senza hit alla prima chiamata e utilizza una durata del cache di cinque minuti anche con un abbonamento. La delega protegge in modo affidabile il contesto principale. Non riduce sempre il numero totale di token.

Il clock della cache: lavorare per sessioni

Il prompt caching rende il re-invio economico: il costo per leggere il prefix è 0.1x rispetto al tasso di input base, contro 1.25x per la scrittura, o 2x per la scrittura con lifetime di un'ora. Ogni utilizzo aggiorna l'entry senza costi aggiuntivi, quindi il timer parte dall'ultimo utilizzo.

Il lifetime dipende dal metodo di autenticazione; per questo l'affermazione generica "la cache scade dopo cinque minuti" è errata.

• Con un abbonamento Claude, Claude Code richiede automaticamente il lifetime di un'ora.
• Una volta superato il limite del piano e utilizzato il credito di consumo, la fatturazione avviene per l'utilizzo effettivo, quindi il limite scende a cinque minuti.
• Con una API key o un cloud provider, il limite rimane di cinque minuti. ENABLE_PROMPT_CACHING_1H=1 abilita il lifetime di un'ora, mentre FORCE_PROMPT_CACHING_5M=1 lo riporta a cinque minuti.

Il consiglio sul ritmo di lavoro è lo stesso in entrambi i casi: lavorare per sessioni continue. Un periodo di inattività superiore al lifetime costringe la sessione successiva a riscrivere l'intero prefix accumulato. Una sessione Claude Code detached in tmux non ha costi durante l'inattività, e il vantaggio della cache calda è ciò che si perde durante i periodi di stop.

Alcune azioni eliminano la cache anche mentre si sta lavorando: cambiare modello, cambiare il livello di effort, attivare la fast mode, connettere o disconnettere un server MCP, abilitare o disabilitare un plugin, negare l'uso di un tool, compattare o aggiornare Claude Code. /model è l'imprevisto più comune, poiché ogni modello ha la propria cache; la richiesta successiva leggerà l'intera cronologia senza hit della cache anche se il contenuto è identico.

L'editing di file, l'editing di CLAUDE.md, l'invocazione di skills e command, l'esecuzione di /recap, il rewind e l'avvio di un subagent mantengono la cache. La cache è limitata a una singola macchina e a una singola directory; due sessioni in directory diverse non condividono la cache.

Per verificare se il caching è attivo, leggi current_usage. cache_creation_input_tokens è stato scritto al tasso di scrittura della cache; cache_read_input_tokens è stato servito a circa un decimo del tasso di input standard. Un alto rapporto tra letture e creazioni indica un funzionamento corretto. Se il tasso di creazione rimane alto in ogni sessione, significa che qualcosa nel prefix continua a cambiare.

Un context window più ampio risolve il problema?

Parzialmente. Diversi modelli attuali supportano un context window di 1 milione di token, e la compattazione funziona allo stesso modo anche con limiti più elevati. L'aspetto economico non cambia, poiché il prompt completo viene comunque reinviato e fatturato ad ogni interazione. Un context window più ampio determina quando è necessario intervenire; l'igiene del prompt determina il costo. Se il problema è la fatturazione piuttosto che il limite massimo, quale piano Claude si adatta al tuo flusso di lavoro determina se stai consumando dollari o il limite del piano.

Context editing and compaction in the API are different things

If you are building your own agent on the Messages API, no slash commands exist and you implement this yourself. Two server-side features do the job, and they are not the same feature.

Context editing selectively clears specific content from conversation history as it grows, replacing each cleared result with placeholder text so Claude knows something was removed. It is a beta: send anthropic-beta: context-management-2025-06-27 and configure strategies under context_management.edits. clear_tool_uses_20250919 clears tool results, and clear_thinking_20251015 manages thinking blocks. Its trigger defaults to 100,000 input tokens, keep to the last 3 tool uses, and clear_tool_inputs to false, so inputs stay and only results go.

Compaction generates a summary and replaces the full conversation history with it. It is also a beta: send anthropic-beta: compact-2026-01-12 and use the edit type compact_20260112. The trigger defaults to {"type": "input_tokens", "value": 150000}, and the value must be at least 50,000.

Compaction has one handoff rule that quietly breaks agents. The response begins with a compaction content block holding the summary, followed by the normal text block. You must pass that block back on later requests, and the API then drops every content block before it. In practice: append the whole of response.content, not only the text.

Anthropic's documentation calls server-side compaction the primary strategy for managing context in long-running conversations, and context editing the option for finer control over what gets cleared. Check model support first. The current Opus, Sonnet and Fable models support compaction; claude-haiku-4-5 does not, and the compaction page carries the live list. Neither beta drives Claude Code's own /compact, which its documentation describes as a one-off summarization request the client sends.

FAQ

Perché la sessione di Claude Code diventa più lenta e costosa man mano che procede?

L'intera conversazione viene inviata nuovamente ad ogni turno. Una domanda di una riga in una sessione aperta da tutto il giorno include l'intero storico della giornata. Il prompt caching mantiene i costi bassi finché la cache è calda, al costo di 0.1x rispetto alla tariffa base di input per la lettura; quando un turno non trova la cache, lo stesso prefisso viene riscritto a 1.25x. Esegui /context per vedere cosa occupa la finestra, e leggi come viene fatturata una sessione di Claude Code per conoscere il meccanismo.

Qual è la differenza tra /clear e /compact in Claude Code?

/clear avvia una nuova conversazione con contesto vuoto. Non invia alcuna richiesta, quindi non ha costi; è la scelta corretta tra task non correlati. /compact mantiene la stessa conversazione e sostituisce la cronologia con un riassunto; è la scelta corretta all'interno di un singolo task prolungato. Fornisci un focus, come in /compact keep only the plan and the diff, poiché l'istruzione determina cosa viene conservato.

Come posso vedere cosa sta occupando la finestra di contesto di Claude Code?

Esegui /context, o /context all per il dettaglio completo per ogni elemento. Mostra il system prompt, le definizioni dei tool, i server MCP, i file di memoria e la cronologia in una griglia colorata, con suggerimenti per tool ad alto consumo di contesto e per l'eccesso di memoria. Su un piano a pagamento, /usage attribuisce inoltre l'utilizzo recente a singole skill, subagent e server MCP.

Dovrei usare una finestra di contesto da 1 milione di token invece di usare la funzione compact?

Una finestra più ampia posticipa il problema invece di risolverlo. Diversi modelli attuali supportano una finestra di contesto da 1 milione di token, tra cui Opus 4.8 e Sonnet 5, e la funzione di compaction si comporta allo stesso modo. Ogni turno invia comunque l'intero prompt e lo fattura; pertanto, una conversazione da 400,000 token è costosa a prescindere dalla capacità di contenimento.

Qual è la differenza tra context editing e compaction nelle API di Claude?

Il context editing cancella selettivamente i contenuti vecchi, principalmente i risultati dei tool, lasciando un testo segnaposto dove si trovava ogni elemento, così Claude sa che è stato rimosso. La compaction genera un riassunto e sostituisce l'intera cronologia con esso. La documentazione di Anthropic definisce la compaction come la strategia principale per le conversazioni prolungate e presenta il context editing come l'opzione di precisione. Entrambi sono in versione beta con i propri header, e entrambi sono separati dal /compact di Claude Code.