Token LLM: cosa entra nella finestra di contesto

Quando si parla di token LLM, la finestra di contesto (context window) indica lo spazio totale che un modello linguistico di grandi dimensioni (LLM) può usare per una richiesta: l’input che legge e l’output che genera. In una finestra da 1M di token, istruzioni, documenti e conversazione devono condividere questo spazio con la risposta, compreso il ragionamento nei modelli che lo prevedono. Riempire la finestra non significa che il modello saprà usare correttamente ogni dettaglio.

Token LLM: che cos’è la finestra di contesto nell’IA?

La finestra di contesto si può immaginare come un banco da lavoro. Documenti, istruzioni e attività in corso ne occupano la superficie. Un banco più grande permette di disporre più materiale, ma serve comunque spazio per lavorare. E avere tutti i documenti davanti non garantisce di notare la clausola che conta.

Un token è un’unità elaborata dal modello: spesso un frammento di parola, anziché una parola intera. Testo, codice e altri input vengono convertiti in token secondo le regole del singolo modello. Conviene contare i token della richiesta effettiva, senza stimare la capacità dal numero di pagine o dalle dimensioni dei file. La guida di Google ai token chiarisce questa distinzione.

L’input può contenere anche materiale che non è mai stato digitato nella chat:

• Istruzioni di sistema che definiscono il comportamento dell’assistente.
• Il messaggio corrente e la cronologia della conversazione conservata.
• Definizioni degli strumenti, che descrivono le azioni a disposizione del modello.
• Risultati degli strumenti, brani recuperati dalle fonti, immagini e documenti.

Anthropic include esplicitamente questi elementi nel conteggio del contesto. Una domanda breve può quindi far parte di una richiesta molto estesa.

Finestra di contesto e limite di token: qual è la differenza?

La finestra di contesto pone un limite alla richiesta complessiva; il limite di output riguarda soltanto la parte generata. I modelli di ragionamento possono usare una parte di quel budget per ragionare prima di produrre la risposta visibile. OpenAI documenta come input, output e ragionamento occupino la stessa finestra.

Quando la finestra è condivisa, la regola per pianificare lo spazio è questa:

I token di input più i token riservati alla generazione devono rientrare nella finestra di contesto.

Se il modello conteggia il ragionamento in quel budget, occorre includerlo nella quota riservata. Va rispettato anche il limite massimo di output del modello, che è distinto. Impostare un limite di output elevato non crea spazio aggiuntivo.

Che cosa determina la finestra di contesto di uno strumento IA?

Determina quanto materiale il modello può considerare insieme per quella richiesta. Non indica con quale precisione lo userà, che cosa l’applicazione conserverà tra una sessione e l’altra o quali informazioni archiviate invierà di nuovo al modello nella richiesta successiva.

Per chi lavora nell’assistenza clienti, la differenza è concreta: un ticket può essere salvato nel sistema di help desk senza essere presente nell’input corrente dell’assistente. Per chi sviluppa, salvare una trascrizione e comporre la richiesta successiva al modello sono due responsabilità distinte.

Quanto è grande la finestra di contesto di Claude, GPT-6 e Gemini 4?

I principali modelli API riportati qui sotto offrono finestre di circa un milione di token, ma le regole sull’output contano quanto la capacità dichiarata. Dati verificati sulle pagine ufficiali dei modelli il 16 ottobre 2026. Ogni riga rimanda direttamente al produttore: sono specifiche delle API, non garanzie sui piani delle chat per il pubblico o sui limiti imposti dalle singole applicazioni.

La pagina attuale dei modelli Claude riporta la stessa finestra e lo stesso tetto di output per tutti quelli elencati. La dimensione della finestra serve quindi poco per scegliere tra questi modelli: è più utile confrontare le risposte sul proprio compito.

GPT-6 Astra, GPT-6.1 Sol e GPT-6 Luna condividono a loro volta la capacità indicata. Modelli con la stessa finestra possono comunque comportarsi diversamente nell’estrazione di informazioni, nella pianificazione o nella scrittura di codice. La specifica dice quanto materiale entra, non stabilisce una graduatoria di qualità.

Anche il margine di long decode di Gemini 4 Argon rientra nella finestra condivisa. Secondo Google, l’API limita l’output richiesto allo spazio rimasto dopo l’input; il ragionamento consuma lo stesso budget. Un’impostazione di output elevata non si somma a una finestra già piena di input. Il conteggio dei token di Gemini descrive la regola precisa.

Un esempio concreto: il prompt entra, la risposta no

Un prompt da un milione di token lascia meno spazio alla risposta di quanto il limite massimo di output del modello possa far pensare.

Prendiamo i limiti documentati di GPT-6 Astra. Supponiamo che la richiesta completa contenga 1,000,000 token di input, tra istruzioni, strumenti, cronologia e documenti di riferimento. È un esempio di ripartizione del budget, non un carico di lavoro misurato. Vogliamo riservare tutti i 128,000 token generati consentiti dal modello.

Il calcolo è questo:

• Finestra: 1,050,000 token.
• Spazio rimasto dopo l’input: 1,050,000 − 1,000,000 = 50,000 token.
• Input più output previsti: 1,000,000 + 128,000 = 1,128,000 token.
• Spazio mancante: 78,000 token.

L’input entra. Il budget previsto per la risposta no. Lo spazio rimasto deve bastare sia per il ragionamento sia per la risposta visibile.

Per riservare l’intero output consentito, l’input deve contenere al massimo 922,000 token, cioè 1,050,000 − 128,000, prima di sottrarre l’eventuale margine aggiuntivo necessario al flusso di lavoro. Non occorre riservare sempre il massimo: la quota va scelta in base all’output richiesto dal compito.

Perché una finestra più grande non garantisce di recuperare meglio le informazioni?

Una richiesta può rientrare nei limiti e produrre comunque una risposta che ignora informazioni presenti al suo interno. È un problema di qualità, anche se l’API accetta il prompt.

Nelle sue indicazioni sul context engineering, Anthropic descrive come la capacità di recuperare le informazioni possa peggiorare all’aumentare del contesto. Il problema non si manifesta necessariamente con un rifiuto evidente: l’assistente potrebbe trascurare un’eccezione, confondere una vecchia procedura con quella che l’ha sostituita o rispondere basandosi su un passaggio vicino che sembra pertinente.

Lo studio Lost in the Middle, di Nelson F. Liu e colleghi, ha rilevato che le prestazioni nelle risposte a domande sui documenti e nel recupero di coppie chiave-valore dipendevano dalla posizione delle informazioni rilevanti. I passaggi al centro potevano essere più difficili da usare rispetto a quelli vicini alle estremità. È una ricerca precedente, non un benchmark dei modelli attuali elencati nella tabella.

La qualità su contesti lunghi va misurata sul proprio carico di lavoro. Non esiste qui un numero universale di token oltre il quale tutti i modelli diventino improvvisamente inaffidabili.

Per un assistente di supporto, si può costruire un piccolo insieme di test sulle eccezioni alle procedure, scegliendo casi di cui si conosce già la risposta corretta. Si confronta una richiesta mirata, che contiene la procedura applicabile, con una più lunga che include anche procedure estranee al caso. Poi si sposta il passaggio decisivo all’inizio, al centro e verso la fine. La verifica è se la risposta applica l’eccezione giusta e cita la fonte corretta.

Per un assistente di programmazione, si può porre una domanda la cui risposta dipenda da un file di implementazione e dal codice che lo richiama. I file non pertinenti vanno aggiunti solo dopo aver verificato la risposta con il contesto mirato. Se la versione più lunga peggiora, acquistare più capacità non aiuta a diagnosticare l’errore.

Trovare correttamente una frase distintiva è un indizio utile sulla capacità di recupero delle informazioni. Non dimostra però che il modello sappia conciliare documenti in conflitto o rispettare tutti i vincoli durante un’attività lunga.

Che cosa fare quando il contesto è troppo lungo?

Chi sviluppa deve esaminare la richiesta completa inviata al modello. Chi usa lo strumento deve salvare lo stato dell’attività prima di proseguire la sessione. In entrambi i casi occorre distinguere un input rifiutato da una risposta interrotta perché ha esaurito lo spazio.

Per gli attuali modelli Claude, Anthropic documenta un errore di prompt troppo lungo quando il solo input supera la finestra. Se l’input entra ma la generazione raggiunge il confine, la risposta può invece fermarsi con model_context_window_exceeded. Conviene controllare l’errore o il motivo effettivo dell’interruzione, senza presumere che il sistema abbia eliminato in silenzio i vecchi messaggi. Si veda il comportamento di Claude quando supera il contesto.

1. 1

   Contare tutto ciò che l’applicazione invia

   Esaminare insieme istruzioni, messaggi della conversazione, definizioni degli strumenti, brani recuperati e risultati degli strumenti. Usare il sistema di conteggio dei token del fornitore, se supporta la struttura della richiesta, e confrontarne la stima con i dati di utilizzo restituiti nella risposta. L’endpoint di conteggio di Anthropic accetta messaggi strutturati e molti tipi di input, ma prevede restrizioni per gli strumenti lato server e alcune fonti di file.

2. 2

   Riservare spazio alla generazione

   Annotare la finestra del modello, il suo tetto di output e la quota da riservare all’output necessario. Includere il ragionamento quando previsto. Ridurre di conseguenza il budget di input, senza considerare ogni token rimasto come spazio per un altro documento.

3. 3

   Individuare il materiale che continua a crescere

   Cercare risultati di ricerca ripetuti, log integrali, documenti duplicati e rami abbandonati della conversazione. A un agente di programmazione possono servire il test che fallisce e la funzione coinvolta; raramente gli serve, a ogni turno, l’output completo di tutti i comandi precedenti riusciti. Vanno conservati gli elementi necessari a verificare l’azione successiva.

4. 4

   Preparare una nota per riprendere il lavoro

   Prima di riavviare o compattare, salvare l’obiettivo, le decisioni confermate, i problemi aperti, i riferimenti alle fonti pertinenti e la prossima azione. Per chi segue un caso di assistenza clienti, occorre conservare la richiesta corrente e l’eccezione applicabile alla procedura. Quando conta la formulazione esatta, riaprire la fonte originale.

5. 5

   Verificare la correttezza dopo la modifica

   Ripetere il compito che non era riuscito con la richiesta più piccola. Controllare che contenga gli elementi necessari e che la risposta sia corretta. Se il prompt ora entra ma continua a ignorare il dettaglio decisivo, indagare la selezione e il recupero delle informazioni, anziché proseguire con tagli alla cieca.

Se un flusso di lavoro breve e stabile risponde già correttamente e resta entro i limiti, non serve cambiarne il modello. Una finestra dichiarata più grande, da sola, non giustifica una migrazione.

Recupero delle fonti, sintesi, compattazione o cache: quale soluzione scegliere?

L’intervento dipende da ciò che occupa spazio. Queste tecniche risolvono problemi diversi e possono essere usate insieme.

Il recupero delle fonti serve quando la raccolta di documenti è molto più ampia del materiale necessario per rispondere. La generazione aumentata dal recupero, o retrieval-augmented generation (RAG), fornisce al modello materiale selezionato dalle fonti prima della risposta. Un assistente di supporto dovrebbe recuperare la politica di reso applicabile e i dati dell’ordine, anziché leggere l’intera base di conoscenza. La guida all’agentic RAG spiega come un agente possa cercare di nuovo quando i primi elementi raccolti non bastano.

Il limite sta nella selezione: se il recupero tralascia l’eccezione decisiva, il modello non può usarla. Quando il compito richiede davvero di confrontare continuamente i dettagli dei documenti, conviene mantenere nel contesto un insieme circoscritto di documenti integrali, verificando se una selezione più ristretta elimina informazioni necessarie.

Una sintesi serve quando i dettagli precedenti possono essere trasformati in uno stato dell’attività da conservare. Deve mantenere le decisioni prese, le incertezze ancora aperte e i riferimenti alle fonti che le sostengono. Per una modifica al codice, può contenere l’approccio scelto, il malfunzionamento attuale e i percorsi dei file pertinenti. Una clausola contrattuale esatta o un messaggio di errore non vanno sostituiti con una parafrasi approssimativa se la decisione successiva dipende dalla loro formulazione.

La compattazione serve quando è la conversazione stessa a occupare gran parte dello spazio. Sostituisce la cronologia accumulata con un contesto più piccolo da cui riprendere il lavoro. Anthropic avverte che una compressione troppo aggressiva può perdere dettagli importanti: occorre quindi controllare che cosa rimane, senza trattare la conversazione compattata come un archivio senza perdite. L’approfondimento di Anthropic sulla compattazione illustra il compromesso.

La guida al context engineering affronta più in generale come scegliere e mantenere questi contenuti durante il lavoro di un agente.

La cache dei prompt serve quando l’input utile si ripete. Riutilizza l’elaborazione di un prefisso del prompt corrispondente, cioè la parte iniziale della richiesta che non è cambiata. Le istruzioni stabili e il materiale condiviso vanno collocati prima dei contenuti variabili, rispettando le regole di cache del modello. La guida attuale di OpenAI descrive il funzionamento dei breakpoint espliciti, mentre la pagina di Gemini 4 Argon indica il solo caching implicito. Si vedano la cache di OpenAI e il supporto alla cache di Gemini.

I prompt lunghi aggiungono token di input fatturabili. Quando la cache viene riutilizzata, può ridurre il costo dell’input ripetuto, secondo le regole di scrittura in cache, ma quei token continuano a occupare la finestra. Il funzionamento della cache è trattato a parte.

Compattare o riscrivere l’inizio di un prompt può ridurre il riutilizzo della cache. Conviene preservare un prefisso stabile finché resta utile ed eliminare la cronologia irrilevante quando compromette la richiesta. Un’alta percentuale di riutilizzo della cache non certifica la qualità della risposta.

Quali promesse sul contesto lungo sono esagerate?

Spesso si chiede al dato sulla capacità di dimostrare cose che non misura. Non garantisce un recupero perfetto delle informazioni, una memoria permanente o la possibilità di sostituire ogni sistema di recupero delle fonti con un prompt più grande.

Il motivo utile per scegliere una finestra più ampia è concreto: il compito richiede più informazioni pertinenti contemporaneamente, la richiesta più piccola perde relazioni essenziali e quella più grande produce risultati corretti nelle valutazioni. In questo caso ha senso usare la capacità in più.

Occorre intervenire quando log, cronologia o raccolte di fonti sottraggono spazio alla risposta. Il primo passo è migliorare ciò che entra nella richiesta. Una finestra più ampia va presa in considerazione se il materiale pertinente continua a non entrare. Si può aspettare quando il flusso di lavoro è affidabile e l’unica motivazione è una specifica più generosa.

Domande frequenti sulla finestra di contesto

Che cos’è la finestra di contesto di un modello linguistico IA?

È la capacità in token che il modello ha, per ogni richiesta, per l’input che considera e l’output che genera. Nei modelli di ragionamento occorre conteggiare anche il ragionamento secondo le regole del produttore.

Quanto contiene una finestra di contesto da 200K?

200K significa 200,000 token. Non corrisponde a un numero fisso di parole o pagine e, se la finestra è condivisa, deve contenere anche l’output generato. Il materiale va contato con il tokenizer del modello scelto o con l’endpoint di conteggio supportato.

Che cosa significa contesto in programmazione?

Il contesto è l’insieme delle informazioni circostanti a disposizione di un’operazione. In un’applicazione LLM comprende le istruzioni, i messaggi e il materiale di supporto riuniti per la richiesta corrente al modello.

Qual è un esempio di context engineering?

Un assistente di supporto riceve il ticket corrente, la procedura applicabile e un resoconto sintetico delle decisioni precedenti. Recupera ulteriori informazioni quando servono, anziché ricevere l’intero archivio dei ticket.

Quanto guadagna un context engineer?

La specifica di una finestra di contesto non permette di stabilire uno stipendio. Per assumere, occorre definire se il lavoro riguarda il recupero delle informazioni, lo sviluppo applicativo, le valutazioni o l’infrastruttura, e poi confrontare ruoli con quelle mansioni nel proprio mercato locale.

Come si impara il context engineering?

Si possono esaminare le richieste complete di una piccola applicazione, modificare separatamente istruzioni, informazioni recuperate o cronologia conservata e confrontare le risposte con risultati corretti già noti. L’obiettivo è saper spiegare perché una modifica ha migliorato la correttezza, oltre al motivo per cui ha accorciato il prompt.

Qual è la differenza tra context engineering e prompt engineering?

Il prompt engineering si concentra sulle istruzioni e sugli esempi forniti al modello. Il context engineering comprende anche la selezione delle informazioni, la disponibilità degli strumenti e il mantenimento dello stato utile mentre il lavoro prosegue.

Quali sono le buone pratiche del context engineering?

Calcolare il budget dell’intera richiesta, riservare spazio all’output, conservare le informazioni pertinenti e mantenere i riferimenti alle fonti quando si sintetizza. Dopo un taglio o una compattazione, verificare che la risposta resti corretta.

Quali capacità servono agli agenti per il context engineering?

Dare all’agente strumenti mirati per trovare le fonti, esaminare i passaggi rilevanti e conservare lo stato dell’attività. Il criterio per valutarli è se i loro risultati aiutano la decisione successiva senza riempire la richiesta di materiale superfluo.

Da dove cominciare lunedì

Prendere una richiesta che non è riuscita o ha trascurato un dettaglio importante. Contare l’input completo, riservare spazio all’output atteso e individuare il blocco più grande che non aiuta a rispondere alla domanda. Sostituirlo con informazioni selezionate o una nota per riprendere il lavoro, quindi ripetere il compito confrontandolo con una risposta corretta già nota. La richiesta più piccola va mantenuta solo se preserva gli elementi necessari e il risultato.

Per guide pratiche alla costruzione di flussi di lavoro affidabili con l’IA, iscriviti alla newsletter.