Introduzione

Nella parte precedente abbiamo definito cosa è un token, a cosa corrisponde in termini di elaborazione di componenti di testo e perché il consumo di token sia ben superiore al testo che viene immesso in input e alla risposta prodotta in output. In questo secondo articolo, completiamo il discorso andando a vedere una serie di semplici suggerimenti per ottimizzare l’utilizzo dei token vale a dire dei consigli da mettere in pratica per ridurre al minimo il consumo non necessario di token.

Mantenere il controllo: monitorare contesto, costi e stato

Tre comandi importanti possono aiutare gli sviluppatori a comprendere lo stato attuale di una sessione.

/context

/context consente agli sviluppatori di ispezionare ciò che è attualmente caricato nel contesto del modello. Questo “contesto” può essere considerato come la memoria a breve termine di Claude per la sessione. Poiché esiste un limite alla quantità di informazioni che il modello può mantenere, il comando /context offre visibilità su quanta parte e come tale capacità è correntemente usata.

/statusline

/statusline permette di configurare una piccola barra informativa che rimane permanentemente nella parte inferiore dell’interfaccia terminale di Claude Code. Si tratta di una barra personalizzabile che esegue qualsiasi script shell configurato, ricevendo dati della sessione e mostrando ciò che lo script restituisce. Ciò offre una vista persistente e immediata sull’utilizzo del contesto, sui costi, sullo stato di Git o su qualsiasi altro elemento che si desidera monitorare. La si può immaginare come il cruscotto di un’auto: si può dare un’occhiata in qualsiasi momento e vedere subito cosa sta succedendo.

/cost

/cost funge da strumento di monitoraggio della spesa, mostrando l’utilizzo dei token della sessione corrente e il costo associato (quando si utilizza la fatturazione tramite API). I token rappresentano le unità di lavoro consumate dal modello durante l’elaborazione degli input e la generazione delle risposte.

Nel loro insieme, questi comandi forniscono una preziosa visibilità e un maggiore controllo sia sull’uso del contesto sia sui costi.

Il peso del passato

Come discusso nei paragrafi precedenti, le conversazioni lunghe non solo consumano un elevato numero di token, ma possono anche portare a risultati meno accurati e affidabili. Per questo motivo, è importante mantenere le interazioni il più concise possibile. Ciò richiede spesso un attento equilibrio: fornire abbastanza contesto affinché il modello funzioni bene, evitando al contempo un accumulo inutile di informazioni. In molti casi, questo è semplice da ottenere. Ad esempio, dopo aver completato un’attività, come la correzione di una GUI, e passando a un’attività diversa, come l’implementazione di un calcolo, è consigliabile avviare una nuova conversazione. Ciò si può ottenere reimpostando il contesto, ad esempio utilizzando il comando /clear. Questo permette di evitare conversazioni eccessivamente lunghe che trascinano con sé da attività precedenti informazioni ormai irrilevanti.

In altre situazioni, anziché reagire immediatamente all’ultimo output generato dal modello, è possibile migliorare l’efficienza prendendosi un momento per rivedere e perfezionare attentamente il prompt successivo prima di inviarlo. A tal fine può essere utile anche utilizzare altri LLM, come ChatGPT, Google Gemini, DeepSeek o Claude, per rivedere, migliorare i propri prompt ed individuare eventuali lacune. Questo approccio può migliorare la qualità dei prompt e quindi ridurre la necessità di interazioni prolungate avanti e indietro, portando in definitiva a un uso più efficiente dei token.

Ottimizzare l’uso dei token con il batching dei prompt

Come discusso nella sezione precedente, ogni volta che viene inviata una nuova richiesta a Claude Code, il modello legge ed elabora non solo il nuovo prompt, ma anche una quantità significativa di contesto aggiuntivo, inclusi la cronologia della conversazione, CLAUDE.md, i server MCP, i file e altri dati rilevanti. Questo contesto accumulato crea un “overhead” che consuma token, spesso in quantità rilevanti.

Quando non è possibile reimpostare la conversazione, perché rimane una parte fondamentale del ciclo di implementazione in corso, una strategia efficace consiste nel raggruppare più richieste in un unico prompt (prompt batching). La logica è ridurre l’impatto dell’overhead. Tuttavia, questo approccio deve essere applicato con attenzione. Sebbene il batching possa migliorare l’efficienza, deve essere bilanciato con altre considerazioni importanti, in particolare:

1. mantenere un obiettivo del prompt chiaro e ben definito, che rappresenta una linea guida fondamentale per un prompting efficace;
2. mantenere i prompt il più concisi possibile, per evitare problemi come l’effetto “lost in the middle”.

In pratica, il batching funziona bene quando si combinano attività strettamente correlate. Ad esempio, un singolo prompt potrebbe includere sia la correzione di un attributo in una specifica GUI sia la validazione di un altro attributo correlato all’interno della stessa interfaccia. Al contrario, combinare attività non correlate, come modificare un elemento della GUI e validare messaggio non collegato, può portare alla riduzione della chiarezza e influire negativamente sulla qualità dell’output.

Porre attenzione ai server MCP

Come discusso in precedenza, i server MCP consentono alle applicazioni di intelligenza artificiale di connettersi a sistemi esterni. Tuttavia, questo comporta un costo: Claude Code carica in anticipo nel contesto le definizioni degli strumenti, operazione che può risultare molto onerosa in termini di risorse. Come illustrato nella tabella seguente, l’integrazione dei server MCP può aumentare significativamente il consumo di token, e questo overhead si applica a ogni interazione. La tabella mostra il consumo reale di token utilizzati dai server MCP.

Esistono diversi modi per mitigare questo impatto. In primo luogo, i server MCP possono essere disconnessi quando non strettamente necessari, riducendo così il caricamento inutile di contesto.

In secondo luogo, Claude Code offre una funzionalità chiamata MCP Tool Search, che consente la scoperta dinamica degli strumenti: invece di caricare tutte le definizioni degli strumenti in anticipo, il sistema recupera solo quelli necessari per uno specifico compito, riducendo così l’utilizzo di token.

Un altro approccio pratico consiste nel privilegiare le interfacce a riga di comando (CLI) rispetto alle integrazioni MCP quando appropriato. I server MCP possono infatti introdurre un notevole overhead di token a ogni iterazione. Come osservato da Ravi Madabhushi, “MCP può essere fino a 32 volte più costoso della CLI”, evidenziando l’importanza di valutare attentamente quando e come utilizzare MCP.

Plan Mode (modalità pianificazione)

Claude Code può operare in tre principali modalità di autorizzazione che controllano quanto autonomamente può interagire con il codebase del progetto durante lo sviluppo: default mode, auto-accept edits mode, plan mode.

Modalità predefinita

In default mode, Claude richiede conferma prima di modificare qualsiasi file o eseguire comandi. È l’impostazione più conservativa e offre agli sviluppatori un controllo completo su ogni azione, a scapito della velocità di sviluppo, che risulta ridotto.

Modalità con accettazione automatica delle modifiche

In auto-accept edits mode, Claude può creare e modificare file all’interno della directory di lavoro senza richiedere conferma e può eseguire automaticamente comuni comandi del filesystem (ad esempio mkdir, touch, rm, mv, cp). L’approvazione automatica si applica solo ai percorsi all’interno della directory di lavoro. Questa modalità consente uno sviluppo più rapido, ma riduce il controllo diretto. Inoltre, poiché Claude non si ferma per chiedere approvazione, può eseguire più azioni per ogni attività, aumentando sia il numero di chiamate agli strumenti sia la durata complessiva della sessione.

Modalità pianificazione

In plan mode Claude analizza il codebase, esegue comandi esplorativi e propone un piano strutturato senza apportare modifiche, utilizzando in genere un numero limitato di token. L’implementazione inizia solo dopo che il piano è stato revisionato e approvato.

Dal punto di vista dei costi e dell’efficienza, la modalità Plan è spesso vantaggiosa per attività complesse. Generare un piano richiede generalmente poche centinaia di token e consente agli sviluppatori di validare l’approccio proposto prima della sua esecuzione. Questo riduce l’impatto di eventuali errori specialmente considerando che un’implementazione errata può consumare migliaia di token sia per il tentativo iniziale, sia per le successive correzioni. Inoltre, non richiede tempo per diagnosticare e risolvere i problemi. Per questo motivo, la modalità Plan può rappresentare un punto di partenza più economico e affidabile per modifiche non banali. Tuttavia, come visto, anche il Plan mode ha un suo costo e quindi non conviene usarlo per modifiche banali.

Claude, non apportare modifiche finché non sei sicuro al 90%

Una pratica comunemente raccomandata consiste nell’includere dei guardrail nel file CLAUDE.md, ad esempio istruendo il modello a raggiungere un alto livello di confidenza prima di apportare modifiche. Per esempio:

“Non apportare alcuna modifica finché non sei sufficientemente sicuro della soluzione. Poni domande di chiarimento quando necessario per comprendere meglio i requisiti”.

(“Do not make any changes until you are sufficiently confident in the solution. Ask follow-up questions as needed to clarify requirements”).

Sebbene varianti di questa linea guida siano ampiamente diffuse nelle comunità di sviluppatori e nelle pratiche di prompt engineering, non esiste una fonte formale o autorevole che definisca una soglia specifica come “90%” o “95% di confidenza”.

Usa Opus per il ragionamento, Sonnet per l’esecuzione

Claude Code supporta tre modelli, ciascuno adatto a diversi tipi di attività, ed è possibile passare dall’uno all’altro in qualsiasi momento utilizzando il comando /model senza perdere il contesto della conversazione.

Sonnet

Sonnet è il modello predefinito e la scelta migliore per la maggior parte delle attività di programmazione, poiché è veloce, potente ed efficiente in termini di costi.

Opus

Opus offre capacità di ragionamento più approfondite per problemi complessi, come refactoring estesi e trasversali, debugging difficili o decisioni architetturali. Tuttavia, consuma significativamente più token, quindi è preferibile utilizzarlo in modo selettivo piuttosto che come impostazione predefinita.

Haiku

Haiku è l’opzione più veloce ed economica (in genere circa tre volte più economica di Sonnet), ed è quindi particolarmente adatta per ricerche rapide, modifiche semplici o attività automatizzate ad alto volume.

Una strategia di ottimizzazione molto efficace consiste nel combinare la scelta del modello con il tipo di attività. Un approccio comune è utilizzare Opus per la pianificazione e Sonnet per l’esecuzione.

La pianificazione richiede capacità di ragionamento: analizzare codebase complesso, identificare dipendenze, anticipare potenziali problemi e progettare un approccio robusto, ed è qui che Opus offre il massimo valore.

Al contrario, l’esecuzione è in gran parte meccanica. Una volta definito un piano solido, implementare le modifiche richieste implica principalmente seguire istruzioni chiare, un compito che Sonnet può gestire in modo efficiente.

Da notare che questo approccio è consigliato a prescindere dall’utilizzo di modelli LLM. Il vantaggio in termini di costi di questo approccio è significativo. Se una parte consistente dei token viene spesa in attività di esecuzione che Sonnet può svolgere altrettanto bene, spostare tali attività da Opus a Sonnet può ridurre sensibilmente il consumo complessivo di token mantenendo al contempo risultati di alta qualità.

Poni attenzione a documenti aggiuntivi

È prassi abbastanza comune che gli sviluppatori, durante un ciclo di sviluppo assistito, carichino documenti aggiuntivi per farli esaminare a Claude Code. Un esempio classico è il caricamento di file di log per individuare errori o diagnosticare comportamenti imprevisti. Tuttavia, prima di caricare qualsiasi file, è importante valutare se sia davvero necessario l’intero contenuto dello stesso. In molti casi, è sufficiente fornire solo un estratto rilevante.

Fornire input più piccoli e mirati non solo riduce il consumo di token, ma migliora anche la capacità del modello di concentrarsi sulle informazioni più importanti. Ad esempio, durante il debug di un errore tramite un file di log, spesso è sufficiente includere solo le righe intorno all’errore (ad esempio 10/30 righe prima e dopo il problema), anziché l’intero file. I file di log possono essere molto estesi. Questo approccio mirato porta a risposte più precise ed efficienti.

Detto ciò, esistono situazioni in cui caricare l’intero documento è giustificato. Ad esempio, quando si cercano pattern ricorrenti all’interno di un log di grandi dimensioni, un contesto più ampio può essere necessario per ottenere risultati accurati.

Come linea guida generale, gli sviluppatori dovrebbero fornire la quantità minima di contesto necessaria per risolvere efficacemente il problema. È consigliabile partire con un sottoinsieme mirato e ampliare il contesto solo se necessario. Questo approccio iterativo aiuta a ottimizzare sia l’uso dei token sia la qualità dell’output.

Allo stesso modo, quando si richiede un’attività a Claude, è importante essere il più specifici possibile. Ad esempio, se c’è un problema in una particolare GUI, una validazione o un modulo di calcolo, è possibile indirizzare Claude verso file specifici, ad esempio @nomefile, invece di analizzare l’intero repository, operazione che richiederebbe molto più tempo e un numero maggiore di token.

Monitorare le attività di lunga durata per evitare sprechi

Quando chiediamo a Claude Clode di eseguire attività complesse, il modello può impiegare diversi minuti per completarle. È quindi naturale sfruttare questo tempo per svolgere altre attività, lavorare su altro o semplicemente fare una pausa. Sebbene questo comportamento sia comprensibile, non è sempre ottimale. In particolare, è spesso utile monitorare l’avanzamento del modello per assicurarsi che stia procedendo nella direzione corretta, che non stia facendo assunzioni errate e che non rimanga bloccato in cicli inefficienti. Anche se può sembrare un’attività tediosa, può evitare sprechi di tempo e consumo inutile di token, consentendo di intervenire tempestivamente quando qualcosa va fuori strada.

Less Is More: ottimizzare il file CLAUDE.md

Come descritto in precedenza, CLAUDE.md è un file di configurazione speciale che Claude Code legge all’inizio di ogni sessione per comprendere il progetto. Può includere convenzioni di codifica, decisioni architetturali, librerie preferite, vincoli e qualsiasi altra indicazione utile a far sì che il modello si comporti come desiderato e che il software evolva in maniera coerente. Poiché questo file viene anteposto a ogni interazione, Claude lo rielabora di fatto a ogni messaggio che si invia.

Questo comporta due implicazioni importanti: occupa permanentemente spazio nel contesto del modello e quindi contribuisce al consumo di token a ogni interazione.

Per questo motivo, è essenziale mantenere CLAUDE.md il più conciso possibile, idealmente entro poche centinaia di righe. Quando si aggiungono nuovi contenuti, è buona pratica seguire la regola del “uno dentro, uno fuori”: le istruzioni obsolete o meno rilevanti dovrebbero essere rimosse per mantenere chiarezza ed efficienza. Nel tempo, indicazioni superate o eccessivamente verbose possono recare più danni che benefici, poiché possono indirizzare il modello in modo errato aumentando continuamente il consumo di token. Quindi si consiglia di considerare CLAUDE.md come un documento in continua evoluzione, da rivedere, aggiornare e snellire regolarmente. Si tratta di uno dei modi più semplici ed efficaci per migliorare sia le prestazioni sia l’efficienza dei costi.

Non arrivare al limite: usare il comando /compact in anticipo

Il comando /compact riassume l’intera cronologia della conversazione in una sintesi concisa, liberando spazio nel contesto di Claude pur mantenendo il filo essenziale della conversazione e quindi del lavoro. È particolarmente utile a metà attività, quando si desidera continuare a lavorare senza perdere continuità. Si differenzia da /clear, che elimina completamente il contesto ed è quindi più adatto quando si intende iniziare un’attività del tutto nuova. Claude Code può anche attivare automaticamente /compact quando ci si avvicina al limite di contesto, riducendo la probabilità di raggiungere un limite di utilizzo.

Come linea guida pratica, è consigliabile eseguire /compact in modo proattivo dopo sessioni prolungate che includono la lettura di più file, iterazioni complesse o attività di debugging estese, tipicamente dopo 20-30 minuti di lavoro intensivo. Questo aiuta a evitare che il contesto si sovraccarichi prima che le prestazioni inizino a degradare.

Man mano che la finestra di contesto si riempie, il modello diventa meno efficace nel ricordare le parti precedenti della conversazione e comincia a manifestare con maggiore evidenza il fenomeno di “lost in the middle”. In pratica, ciò può manifestarsi con suggerimenti ripetuti, decisioni dimenticate o perdita di vincoli precedentemente definiti. Questi sono segnali chiari che è il momento di utilizzare /compact. Puoi considerarlo come una funzione di “salva e riassumi” per la tua sessione: preserva la continuità riducendo al contempo l’overhead inutile del contesto.

Evitare le ore di punta: ottimizzare i tempi di utilizzo

Anthropic ha dichiarato che le ore di punta sono tra le 13:00 e le 19:00 GMT nei giorni feriali. Durante questi periodi, gli utenti di Claude tendono a consumare i limiti di cinque ore di utilizzo più rapidamente rispetto al normale. Sebbene i limiti settimanali complessivi rimangano invariati, l’utilizzo effettivo per sessione può sembrare ridotto a causa della maggiore domanda.

Al contrario, i fine settimana (sabato e domenica) sono considerati periodi di bassa attività (off-peak), con un consumo delle sessioni normale indipendentemente dall’ora del giorno.

La conclusione pratica, soprattutto per gli utenti di Claude Code che eseguono carichi di lavoro intensivi in termini di risorse, è quella di pianificare le attività più pesanti e ad alto consumo di token durante le ore non di punta, quando possibile. Questo può aiutare a massimizzare l’efficienza delle sessioni e a prolungarne l’utilizzo effettivo. Per gli utenti in Europa, ciò è particolarmente vantaggioso, poiché le ore lavorative del mattino ricadono generalmente al di fuori dei periodi di maggiore domanda, offrendo una finestra naturale per sessioni più intensive.

Conclusioni

In conclusione, lavorare in modo efficace con Claude Code, e con altri modelli LLM, non significa solo scrivere prompt migliori, controllare e validare sempre il codice generato, ma richiede anche un’attenta gestione delle limitate risorse computazionali: tempo e token. Una corretta gestione dei token influisce direttamente sia sui costi, sia sull’accuratezza del modello. Ad esempio, contesti di dimensioni eccessive non solo consumano più token e tempo, ma possono anche portare a risultati meno precisi.

Un fenomeno ben documentato è l’effetto “lost in the middle”, in cui i modelli LLM tendono a concentrarsi maggiormente sulle informazioni presenti all’inizio e alla fine di un prompt, mentre i contenuti centrali tendono ad aver maggiore probabilità di essere trascurati. Per questo motivo, gli sviluppatori dovrebbero considerare ogni interazione come cumulativa, con conseguenze su efficienza, accuratezza ed esperienza complessiva di sviluppo. Come mostrato in questo articolo, piccole abitudini ed attenzioni, come mantenere il contesto essenziale, limitare input non necessari e selezionare strumenti e modalità appropriati, possono avere un impatto significativo sulle prestazioni.

Gli sviluppatori più efficienti non sono quelli che utilizzano il modello in modo indiscriminato, ma quelli che lo usano in modo consapevole: minimizzando gli sprechi, massimizzando i risultati e mantenendo il controllo sul contesto. L’obiettivo dovrebbe essere quello di diventare “power user”, operando entro i vincoli esistenti e massimizzando il valore delle risorse disponibili.

Con la continua evoluzione dello sviluppo assistito dall’intelligenza artificiale, la gestione dei token diventerà una competenza ingegneristica sempre più importante: una competenza che influisce direttamente sulla produttività, sui costi e sulla capacità di mantenere il flusso di lavoro, contribuendo al contempo a un utilizzo più efficiente delle risorse ambientali

Riferimenti

[OpenAI 2026] What are tokens and how to count them?
https://help.openai.com/en/articles/4936856-what-are-tokens-and-how-to-count-them

[Lee 2025] Timothy B. Lee, Context rot: the emerging challenge that could hold back LLM progress.
https://www.understandingai.org/p/context-rot-the-emerging-challenge

[Liu et al. 2023] Nelson F. Liu – Kevin Lin – John Hewitt – Ashwin Paranjape – Michele Bevilacqua – Fabio Petroni – Percy Liang, Lost in the Middle: How Language Models Use Long Contexts.
https://arxiv.org/abs/2307.03172

[Madabhushi 2026] Ravi Madabhushi, MCP is up to 32× more expensive than CLI. Here’s why we still use it.
https://www.scalekit.com/blog/mcp-vs-cli-use

[Turland 2026] Connor Turland, What is MCP Tool Search? The Claude Code feature that fixes context pollution. Cyrus,
https://t.ly/o_3zr