Finestra di contesto Claude: come funzionano i token nelle chat

Ogni volta che si preme «Invia» in una chat con Claude succede qualcosa di controintuitivo. Il modello non legge solo l’ultimo messaggio. Rilegge l’intera conversazione dall’inizio, compresi tutti i file caricati, le istruzioni di sistema e le risposte precedenti, e poi genera la risposta successiva. Questo comportamento è conseguenza di un limite tecnico dei modelli linguistici attuali, che non possiedono una memoria nel senso in cui la intendiamo noi. La finestra di contesto è la soluzione che usano come memoria della conversazione in atto.

Il meccanismo ha conseguenze dirette sulla qualità delle risposte, sulla velocità e sui limiti che si incontrano durante l’uso. Capire come funziona permette di ottenere risultati migliori e di evitare situazioni in cui l’assistente sembra «dimenticare» quello che gli è stato detto pochi minuti prima. Spiega anche perché chi ha un account free può ritrovarsi ad esaurire velocemente i tokern a disposizione se usa male le chat.

L’articolo è centrato su Claude (claude.ai e Claude Desktop). I concetti di base (token, finestra di contesto, accumulo progressivo) valgono per tutti i chatbot basati su modelli linguistici, con differenze nell’implementazione.

Che cos’è un token

Un token è l’unità di misura del testo per un modello linguistico. Non coincide con una parola né con un carattere, ma con un frammento di testo che il tokenizzatore del modello riconosce come unità autonoma. In inglese una parola comune corrisponde in genere a un singolo token. Una parola lunga o poco frequente può richiederne due o tre.

Per l’italiano il rapporto è meno favorevole. I tokenizzatori usati dai modelli attuali sono stati addestrati prevalentemente su testi inglesi, e le parole italiane tendono a essere più lunghe e morfologicamente più ricche. Lo studio Language Model Tokenizers Introduce Unfairness Between Languages (Petrov et al., ACL 2023) lo quantifica con precisione, “the tokenizer employed by ChatGPT and GPT-4 uses about 1.6 times more tokens to encode the same text in Italian as it does in English.” Questo rapporto è simile per i tokenizzatori di Claude e degli altri modelli. Come ordine di grandezza, 1.000 token corrispondono a circa 750 parole inglesi ma solo a circa 500 parole italiane. Per altre lingue il rapporto può essere anche molto peggiore, ad esempio è 2.6 per il bulgaro, 3 per l’arabo, arriva a 15 per lo shan, una della lingue parlate nel Myanmar. L’articolo è reperibile qui.

La conseguenza pratica è che chi usa Claude in lingue diverse dall’inglese ha una finestra di contesto effettivamente più piccola a parità di contenuto.

La finestra di contesto, ovvero la memoria di lavoro

La finestra di contesto è lo spazio in cui il modello tiene tutto ciò che gli serve per generare una risposta. Si misura in token e ha una dimensione fissa. Per i modelli Claude attuali (Opus 4.6, Sonnet 4.6) la finestra standard è di 200.000 token, con la possibilità di estenderla a 1 milione di token per i piani di livello più alto (secondo la documentazione ufficiale Anthropic).

L’analogia più immediata è quella dello schermo del computer. La finestra di contesto è la superficie dello schermo su cui il modello visualizza tutto il materiale necessario per lavorare. Ci stanno le istruzioni di sistema, la conversazione in corso (domande e risposte), i file caricati e la risposta che sta generando. Quello che è sullo schermo esiste per il modello. Quello che non ci sta non esiste.

A ogni turno della conversazione il nuovo messaggio dell’utente si aggiunge in fondo, insieme alla nuova risposta del modello. Il contenuto si accumula progressivamente, scorrendo verso l’alto come in un documento che si allunga. Quando lo schermo si riempie, il contenuto più vecchio esce dal margine superiore e il modello non lo «vede» più.

Quello che c’è sullo schermo prima di iniziare

Questo è l’aspetto meno visibile e forse più importante. Quando si apre una nuova conversazione in claude.ai la finestra di contesto non è vuota. Contiene già le istruzioni di sistema (il system prompt) che definiscono il comportamento del modello, le regole di sicurezza, le istruzioni per gli strumenti disponibili e altre direttive operative.

Con tutti gli strumenti e i connettori attivi (ricerca web, Google Drive, Gmail, Calendar, server MCP) il system prompt di Claude occupa circa 24.000 token, un valore documentato da analisi indipendenti pubblicate nel maggio 2025 sulla versione 3.7 Sonnet e probabilmente cresciuto nelle versioni successive con l’aggiunta di nuove funzionalità. Questo vuol dire che una buona parte della finestra da 200.000 token è già occupato prima che l’utente scriva una sola parola.

Si può ridurre questo overhead disattivando gli strumenti e i connettori che non servono per la conversazione in corso. L’operazione si effettua dalle impostazioni «Ricerca e strumenti» nell’interfaccia di claude.ai, dove è possibile disconnettere i singoli connettori (Google Drive, Gmail, Calendar, ecc.) e disabilitare la ricerca web. Disconnettere un connettore non cancella le credenziali di accesso, per cui è possibile riconnetterlo quando serve. Questa gestione è consigliata dalla stessa documentazione dell’Help Center di Claude, che indica esplicitamente di «disabilitare temporaneamente strumenti e connettori non necessari» perché sono particolarmente costosi in termini di token.

A questa base fissa si aggiungono altri elementi. Se si lavora all’interno di un Progetto di Claude, le istruzioni personalizzate del progetto occupano ulteriore spazio nella finestra. Anthropic raccomanda di mantenerle concise, proprio perché vengono caricate in ogni conversazione del progetto.

Quanto pesano i file caricati

Caricare un documento in una conversazione è comodo, ma ha un costo significativo in termini di token. Il costo dipende dal tipo di file e da come viene caricato.

PDF caricati direttamente in chat

Quando si allega un PDF in una singola conversazione il file entra per intero nella finestra di contesto. La documentazione dell’Help Center distingue due modalità di elaborazione in base alla lunghezza del documento. Per i PDF sotto le 100 pagine Claude analizza sia il testo sia gli elementi visivi (grafici, tabelle, immagini), convertendo ogni pagina anche in un’immagine. Il costo è di 1.500-3.000 token per pagina, secondo la documentazione sul supporto PDF. Per i PDF oltre le 1.000 pagine Claude estrae solo il testo, senza la conversione in immagine. Per i documenti tra le 100 e le 1.000 pagine la documentazione ufficiale non specifica quale modalità si applichi.

Con l’approccio duale (testo + immagine) un documento di 50 pagine può consumare tra 75.000 e 150.000 token, dal 37% al 75% di una finestra standard da 200.000 token. I limiti attuali sono 32 MB e 100 pagine per i modelli con finestra a 200.000 token.

Il punto da non sottovalutare è che il contenuto del file resta nella finestra per tutta la durata della conversazione, riletto insieme a tutto il resto a ogni turno.

PDF nei Progetti (RAG)

I documenti caricati nella knowledge base di un Progetto vengono gestiti in modo completamente diverso. Secondo la documentazione ufficiale i Progetti usano la retrieval augmented generation (RAG), una tecnologia che indicizza i documenti e recupera solo le porzioni pertinenti alla domanda, invece di caricare l’intero contenuto nella finestra di contesto.

Questo significa che lo stesso documento di 50 pagine caricato come riferimento di un Progetto non occupa stabilmente 75.000-150.000 token nella finestra. A ogni domanda Claude cerca nella knowledge base, recupera i frammenti rilevanti e carica solo quelli nel contesto. Il risparmio rispetto al caricamento diretto in chat è significativo.

Il compromesso è che la RAG, lavorando su frammenti, potrebbe non cogliere connessioni tra sezioni distanti del documento che sarebbero visibili con il caricamento integrale. Quando l’analisi richiede una visione d’insieme dell’intero documento è preferibile il caricamento diretto in chat.

Un test indipendente sulla knowledge base dei Progetti ha rilevato un dato interessante, lo stesso documento caricato in formato PDF, Word o markdown occupa lo stesso spazio nell’indice (circa il 3% della capacità nel test specifico). Questo suggerisce che Claude preprocessa il contenuto durante l’indicizzazione, rendendo il formato originale poco rilevante per i documenti di Progetto.

L’alternativa markdown per i caricamenti in chat

Dove il formato conta molto, invece, è nel caricamento diretto in chat. La maggior parte dei PDF che si usano nelle conversazioni con i modelli linguistici sono documenti prevalentemente testuali, come report, manuali, articoli e contratti. Per questo tipo di file il costo in token del formato PDF è in larga misura uno spreco, perché il modello dedica risorse a processare informazioni di layout, font, posizionamento e metadati che non gli servono per comprendere il contenuto.

Lo stesso testo convertito in markdown conserva la struttura logica (titoli, paragrafi, elenchi, tabelle) ma elimina il sovraccarico visivo. Il risparmio è notevole, perché il testo puro con la sola formattazione strutturale pesa molto meno della doppia elaborazione testo-più-immagine che Claude applica ai PDF. Un documento testuale di 50 pagine che in formato PDF può consumare 75.000-150.000 token si riduce a una frazione di quel valore in markdown.

La conversione non è solo una questione di risparmio. Un file markdown è anche più facile da elaborare per il modello, perché la struttura logica del documento è esplicita e non va ricostruita dall’analisi del layout visivo.

Per chi volesse provare questo approccio senza usare il terminale, esiste PyMuPDF4LLM GUI, un’applicazione open source con interfaccia grafica che converte i PDF in markdown ottimizzato per i modelli linguistici. Funziona in locale (nessun dato lascia il computer), supporta la selezione di pagine specifiche, l’estrazione delle immagini e il riconoscimento ottico dei caratteri per i PDF scansionati. L’app è liberamente scaricabile da GitHub.

Immagini

Il costo in token di un’immagine dipende dalla risoluzione, non dal contenuto. Un’immagine bianca costa esattamente quanto una fotografia dettagliata alla stessa risoluzione. Secondo la documentazione Vision di Anthropic la formula approssimativa è (larghezza × altezza) / 750. Un’immagine di 1.092×1.092 pixel consuma circa 1.600 token. Claude ridimensiona automaticamente le immagini il cui lato più lungo supera 1.568 pixel.

Come cresce il consumo durante la conversazione

Il meccanismo di accumulo è semplice ma le sue conseguenze sono spesso sottovalutate. A ogni turno il nuovo messaggio dell’utente e la nuova risposta del modello si aggiungono a tutto il contenuto già presente nella finestra, senza eliminare nulla finché c’è spazio.

Un esempio, si carica un PDF di 30 pagine (circa 60.000 token) in una chat e si pone una domanda (200 token). L’input del primo turno è di circa 84.000 token (24.000 di system prompt + 60.000 di PDF + 200 di domanda). Claude risponde con circa 800 token. Al secondo turno l’input sale a circa 85.000 token, perché include anche la risposta precedente. Al decimo turno, ipotizzando risposte di 800 token e domande di 200, l’input ha raggiunto circa 93.000 token. Se quello stesso documento fosse stato convertito in markdown prima del caricamento, il peso iniziale sarebbe stato sensibilmente inferiore e la conversazione avrebbe avuto molto più spazio per svilupparsi.

In questo scenario si raggiunge il limite della finestra dopo circa 40-50 scambi, supponendo risposte di lunghezza media. Con risposte più lunghe, o caricando altri file durante la conversazione, il limite arriva molto prima.

La conseguenza pratica è che le conversazioni lunghe diventano progressivamente più pesanti, e a un certo punto la qualità delle risposte può degradare perché il modello deve gestire una quantità di contesto molto grande.

Questo degrado ha un nome tecnico, context rot. La stessa documentazione Anthropic riconosce che al crescere del numero di token nel contesto l’accuratezza e la capacità di recupero delle informazioni calano. La ricerca ha identificato un pattern specifico, noto come lost in the middle, le informazioni collocate nella parte centrale della finestra vengono richiamate con minore precisione rispetto a quelle che si trovano all’inizio o alla fine. In pratica, se si carica un documento lungo e si pone una domanda su un dettaglio che si trova a metà, il modello potrebbe rispondere meno bene rispetto a quando lo stesso dettaglio si trova nelle prime o nelle ultime pagine. Anche senza raggiungere il limite della finestra, una conversazione con molto contesto accumulato tende a produrre risposte meno precise rispetto a una conversazione con poco contesto e domande mirate.

Cosa succede quando la finestra si riempie

Quando la conversazione raggiunge circa il 95% della capacità della finestra, Claude attiva un processo chiamato compattazione automatica (descritto nella documentazione ufficiale). Il modello condensa i messaggi più vecchi in un riassunto strutturato che preserva le decisioni prese, lo stato del lavoro e le informazioni essenziali. L’utente vede una barra di avanzamento (in genere la procedura dura uno o due minuti). Il rapporto di compressione varia molto a seconda del tipo di conversazione. In un test documentato nel cookbook ufficiale Anthropic la compattazione ha ridotto il consumo complessivo di token del 59% in un workflow con 5 cicli di lavoro sequenziali. Dopo la compattazione il modello lavora con il riassunto compresso più i messaggi recenti.

In Chat esistono due livelli separati, il primo è la cronologia visibile, l’intera conversazione originale resta conservata e l’utente può continuare a scorrere tutti i messaggi nell’interfaccia. Il secondo è il contesto attivo del modello, dopo la compattazione contiene solo il riassunto più i messaggi recenti. Quello che l’utente vede e quello che il modello «vede» non coincidono più.

La conversazione originale completa viene conservata in un file di trascrizione (transcript). All’occorrenza il modello può accedere a questo file per recuperare dettagli specifici che il riassunto compattato non conserva. In Cowork e Claude Code questo meccanismo è particolarmente visibile, perché il transcript è un file JSONL su disco che Claude può leggere con i propri strumenti.

La compattazione è disponibile per gli utenti con piano a pagamento e permette di continuare la conversazione a tempo indeterminato. Gli utenti del piano gratuito non ne dispongono e devono aprire una nuova conversazione quando raggiungono il limite.

Come stimare il consumo di token

Anche senza strumenti tecnici è possibile fare stime ragionevoli. Ecco alcuni valori indicativi per l’uso quotidiano.

Una pagina di testo italiano (circa 300 parole) corrisponde a circa 600 token. Una pagina di PDF caricata in Claude (con l’approccio duale testo + immagine) consuma tra 1.500 e 3.000 token. Un’email media in italiano (250 parole) equivale a circa 500 token. Un’immagine di circa 1000px di lato consuma approssimativamente 1.600 token.

Per conteggi precisi esistono diversi strumenti online gratuiti. Il Tokenizer di GPT for Work supporta i modelli Claude, GPT e Gemini, mostrando conteggio token, parole e caratteri, mentre Token Calculator copre i modelli principali senza richiedere registrazione. Anthropic offre un endpoint API per il conteggio dei token ma non uno strumento web pubblico.

Strategie pratiche

Sulla base di quanto descritto fin qui si possono adottare alcune abitudini che fanno una differenza concreta nell’uso quotidiano.

Iniziare nuove conversazioni con regolarità. Dopo 15-20 scambi la conversazione ha accumulato una quantità significativa di contesto. La tecnica più efficace è chiedere al modello un riassunto delle decisioni prese e dei punti chiave, copiarlo, aprire una nuova chat e incollarlo come primo messaggio. Una cronologia di 10.000-50.000 token si comprime in un riassunto di 500-2.000 token, liberando spazio per nuovo lavoro.

Usare i Progetti di Claude per i documenti di riferimento. I Progetti sono il posto giusto per i documenti che servono stabilmente, come manuali, specifiche e linee guida. La RAG recupera solo le porzioni pertinenti a ogni domanda, con un consumo di token per turno molto inferiore rispetto al caricamento diretto in chat. Conviene creare progetti separati per flussi di lavoro diversi e mantenere le istruzioni di progetto concise, perché vengono caricate in ogni conversazione.

Convertire i PDF in markdown prima di caricarli in chat. Quando un documento deve essere analizzato nella sua interezza all’interno di una singola conversazione (non attraverso la RAG del Progetto), convertirlo in markdown riduce sensibilmente il consumo di token. Questo vale per i PDF prevalentemente testuali, che sono la grande maggioranza dei documenti usati nel lavoro professionale.

Essere selettivi con i file. Caricare un intero documento di 100 pagine quando la domanda riguarda un singolo paragrafo è uno spreco significativo di contesto. Quando possibile è preferibile copiare e incollare solo la sezione rilevante.

Scegliere il modello appropriato. Per domande rapide e compiti semplici Haiku è più che sufficiente e lascia più budget di contesto disponibile. Sonnet è adatto al lavoro standard. Opus va riservato ai compiti che richiedono ragionamento complesso o elaborazione di grandi quantità di informazioni.

Gestire i connettori con consapevolezza. Ogni connettore attivo aggiunge le proprie definizioni al system prompt. Se per una conversazione non servono ricerche web o accesso al calendario, disconnetterli temporaneamente dalle impostazioni «Ricerca e strumenti» libera spazio nella finestra. In caso di necessità la riconnessione è immediata e non richiede di reinserire le credenziali.

In sintesi

La finestra di contesto funziona come uno schermo a dimensione fissa. Tutto quello che il modello usa per rispondere (istruzioni di sistema, conversazione, file, risposta in generazione) deve starci. I messaggi si accumulano progressivamente e quando lo spazio finisce i contenuti più vecchi escono dal contesto attivo. I file caricati in chat pesano molto e continuano a pesare per tutta la durata della conversazione. L’italiano costa circa il 50% in più dell’inglese in termini di token.

Claude gestisce l’esaurimento del contesto con la compattazione automatica, che produce un riassunto strutturato e conserva la conversazione originale come trascrizione accessibile. I Progetti con la RAG offrono un’alternativa molto più efficiente per i documenti di riferimento stabile. Per i file caricati direttamente in chat la conversione da PDF a markdown è la strategia con il miglior rapporto tra semplicità e risparmio.

La strategia più efficace resta in ogni caso la prevenzione, ovvero gestire consapevolmente quello che si mette sullo schermo del modello e non aspettare che si riempia.