Context engineering con Claude: dove finiscono davvero i token (e perché conta in produzione)

Sento la stessa frase ogni settimana, in DM e nei commenti: "Claude consuma troppi token". Quasi sempre il dito è puntato sul modello, sul piano, sul limite di utilizzo. Quasi mai su come viene riempito il context window.

Il discorso è che il consumo di token non è un problema di modello. È un problema di context engineering. E la differenza tra i due non è semantica: è la differenza tra comprare un piano più caro e ridisegnare il modo in cui lavori.

Uso Claude in produzione ogni giorno per orchestrare 21+ automazioni che gestiscono LinkedIn, blog, SEO, outreach e monitoraggio del sito. Il sistema gira da metà febbraio 2026. In questi mesi la cosa che ha spostato di più i costi non è stata cambiare modello. È stato capire cosa entra nella finestra di contesto, quando, e perché.

Andiamo per ordine.

Cosa mangia davvero il context window

Il context window è lo spazio di lavoro del modello: tutto quello che Claude "vede" in una singola richiesta. Ogni token lì dentro costa, in denaro e in latenza. Il problema è che la maggior parte delle persone pensa che il peso sia nel proprio messaggio. Non è lì.

In una sessione di lavoro reale, il messaggio che scrivi è la parte più piccola. Il peso vero sta in altri quattro posti:

1) Il system prompt e le istruzioni di progetto. Un file di istruzioni da 8.000 parole entra in OGNI richiesta. Non una volta. Ogni volta.

2) Le definizioni dei tool. Ogni server MCP connesso espande la lista di strumenti disponibili, e ogni strumento porta con sé il suo schema. Dieci server attivi possono pesare più del lavoro vero.

3) Lo storico della conversazione. Cresce a ogni turno. Al venticinquesimo messaggio stai pagando i ventiquattro precedenti a ogni nuova richiesta.

4) Gli output dei tool. Una lettura di file da 2.000 righe, una query che torna 500 risultati, un log completo: finiscono tutti nel contesto e ci restano.

Il punto è questo: il token che paghi non è quello che scrivi, è quello che accumuli. E l'accumulo è invisibile finché non lo misuri. Per questo quasi tutti diagnosticano male il problema, e finiscono per cambiare piano quando dovevano cambiare metodo.

Context engineering non è prompt engineering

Qui serve un reframe. Il prompt engineering risponde alla domanda "come scrivo una buona istruzione". Il context engineering risponde a una domanda diversa: cosa deve esserci nella finestra in questo preciso momento, e cosa no.

Non è solo una questione di scrittura. È una questione di architettura. Stai decidendo quali informazioni il modello vede a ogni passo, quali tieni fuori, e dove vive lo stato tra un passo e l'altro. È un layer che sta sopra al prompt, non dentro.

Mi chiedo se gran parte di quello che chiamiamo "il modello è lento" o "il modello ha allucinato" non sia in realtà un sintomo. La causa è spesso una finestra di contesto satura di roba irrilevante, dove il segnale che conta è annegato nel rumore. Più contesto non vuol dire più intelligenza. Oltre una certa soglia vuol dire il contrario: il modello fatica a trovare l'informazione rilevante in mezzo a quella che non serve.

Il context engineering è la disciplina di tenere alto il rapporto segnale/rumore dentro la finestra. È meno appariscente del prompt perfetto. Ma è la leva che sposta i costi quando un sistema gira davvero in produzione, decine di volte al giorno, e non solo in una demo.

I tre sprechi di token che vedo più spesso

Quando guardo un setup che "consuma troppo", tre pattern tornano quasi sempre. Sono tutti risolvibili senza toccare il piano.

1) Tutti i tool caricati sempre. Molti tengono attivi dieci, quindici server MCP "perché potrebbero servire". Ma ogni schema di tool occupa spazio in ogni richiesta, anche quando non lo usi. La regola è semplice: carica gli strumenti quando servono, non per default. Su un setup tipico questo da solo libera diverse migliaia di token per interazione [stima qualitativa, non misurata in modo controllato].

2) Letture di file complete invece che mirate. "Leggi tutto il file" è comodo e costoso. Se ti serve una funzione, leggi quella funzione. Se ti serve una sezione, cerca la sezione. Un file da 1.500 righe letto per intero quando ti servivano 40 righe è puro spreco, e lo ri-paghi a ogni turno della conversazione perché quell'output resta nello storico.

3) Storico mai compattato. Le conversazioni lunghe sono il collo di bottiglia più sottovalutato. Dopo venti scambi, gran parte di quello storico è roba vecchia: task già completati, output di tool già usati, vicoli ciechi esplorati e abbandonati. Tenere tutto significa ri-pagarlo a ogni richiesta. Compattare lo storico, o ripartire da una finestra pulita quando il task cambia, costa un attimo e fa risparmiare per tutto il resto della sessione.

Un esempio concreto dal mio sistema. Uno dei task settimanali analizza un report e deve produrre tre raccomandazioni. La prima versione leggeva l'intero report più tre file di contesto storico nella stessa finestra, ogni volta. La seconda versione legge solo le sezioni rilevanti e delega la lettura dei file storici a un sub-agente, che torna una sintesi di poche righe. Stesso output finale, stessa qualità delle raccomandazioni. La finestra principale, però, è passata da satura a respirabile, e il task ha smesso di sbattere contro il limite di contesto nelle settimane più cariche.

Nessuno di questi tre è un trucco. Sono igiene. Ma è igiene che quasi nessuno applica, perché lo spreco è invisibile fino a quando non vai a guardarlo.

Come strutturo il contesto nelle 21 automazioni

Il sistema che orchestro non gira su una finestra gigante. Gira su tante finestre piccole e pulite. È la scelta architetturale che ha avuto più impatto sui costi, più di qualsiasi prompt.

Tre principi pratici, gli stessi che applico ogni giorno:

→ Le istruzioni di progetto come tabella di routing, non come discarica. Il file di istruzioni non deve contenere tutto lo scibile del progetto. Deve dire al modello DOVE guardare. Una riga "per le regole SEO leggi la cartella docs/seo/" vale più di duemila parole di regole SEO incollate. Il modello legge il dettaglio solo quando il task lo richiede. Il resto del tempo, quel peso resta fuori dalla finestra. Ho descritto come tengo questo file leggero nella mia guida completa a Claude Code, dove il file di contesto è una tabella di lookup, non un manuale.

→ Sub-agenti per isolare il contesto. Quando un task richiede di leggere venti file e produrre una sintesi, non lo faccio nella finestra principale. Lo delego a un sub-agente. Il sub-agente apre la sua finestra, fa il lavoro sporco, e mi torna solo il risultato. I venti file non entrano mai nel mio contesto. Questo è il punto che quasi tutti sbagliano sui sub-agenti: non servono a fare più cose insieme, servono a tenere pulita la finestra di chi coordina. È lo stesso pattern del framework GSD, dove un modello fa da orchestratore e i modelli minori fanno da executor.

→ Caricamento on-demand di skill e strumenti. Una skill o un tool entra nella finestra quando il task la chiama, non prima. Tenere tutto caricato "per sicurezza" è il modo più rapido per saturare il contesto con roba che non userai in quella sessione.

La regola sotto tutte e tre è una sola: il default è la finestra vuota. Tutto quello che entra deve giustificare il suo costo. Non è una posizione minimalista per gusto. È che ogni token tenuto fuori è un token che non paghi e che non confonde il modello.

Misurare il consumo di token prima di ottimizzare

C'è una regola che vale qui più che altrove: non ottimizzare quello che non misuri. Tagliare token a sensazione è il modo migliore per rompere qualcosa di importante e non accorgersene.

Prima di toccare un setup, guardo dove vanno i token davvero:

→ Nell'uso via API, i campi di usage riportano input e output token per ogni chiamata, e separano i token serviti dalla cache da quelli nuovi. È il dato più onesto che hai. Se lavori via API, i numeri e i limiti che ti servono per leggere quei costi li ho raccolti nella guida ai prezzi e ai limiti dell'API di Claude.

→ In Claude Code hai visibilità su quanto contesto stai occupando durante una sessione, e vedi quando ti avvicini al limite della finestra. Quel segnale è il momento giusto per compattare o ripartire.

→ Per il testo grezzo, esiste il conteggio token: prima di incollare un documento da 30.000 parole in un prompt, vale la pena sapere quanto pesa.

Solo dopo aver guardato i numeri decido cosa tagliare. Nove volte su dieci il colpevole non è quello che immaginavo. È un output di tool gigante, o uno storico che non ho mai ripulito, non il prompt su cui stavo agonizzando. La diagnosi a occhio quasi sempre punta nella direzione sbagliata.

Prompt caching: il costo reale del contesto ripetuto

C'è un pezzo di questo discorso che è puramente economico. Se il tuo system prompt e le tue istruzioni di progetto sono stabili tra una richiesta e l'altra, stai ripagando lo stesso contesto a tappeto.

Il prompt caching serve esattamente a questo: marcare la parte stabile del contesto (system prompt, istruzioni, definizioni di tool) come cache, così che le richieste successive paghino quei token a una frazione del prezzo. Non riduce quanti token entrano nella finestra. Riduce quanto ti costano quando si ripetono. Secondo la documentazione ufficiale di Anthropic, il caching può abbattere i costi fino al 90% e la latenza fino all'80% sui prefissi ripetuti: trovi i dettagli nella pagina sul prompt caching.

Per un sistema che gira a cron, con lo stesso blocco di istruzioni invocato decine di volte al giorno, la differenza si sente sul conto a fine mese. La struttura della richiesta conta: la parte fissa va messa dove la cache la può prendere, la parte variabile dopo. Mettere un timestamp o un dato che cambia all'inizio del prompt, prima del blocco stabile, basta a invalidare la cache per tutto quello che segue. È un errore piccolo che costa ogni singola chiamata.

Quando un sub-agente conviene davvero

Torno sui sub-agenti perché è la domanda che ricevo più spesso, e la risposta di solito sorprende.

Un sub-agente non è gratis: ha il suo overhead, il suo giro di contesto, il suo costo di avvio. Quindi non si usa per tutto. Si usa quando il guadagno in pulizia della finestra principale supera il costo del giro extra.

In pratica conviene quando un task produce tanto rumore intermedio e poco segnale finale. Leggere venti documenti per estrarre tre conclusioni. Scandagliare un log da 5.000 righe per trovare l'errore. Fare ricerca esplorativa che genera molto testo e poche risposte buone. In tutti questi casi il sub-agente assorbe il rumore nella sua finestra e ti restituisce solo il segnale.

Non conviene quando il task è breve, lineare, o quando l'output intermedio È il valore e ti serve tutto nella finestra principale. Delegare a un sub-agente una cosa da due passi è come prendere l'auto per attraversare la strada: spendi più nel mettere in moto che nel tragitto.

La metrica per decidere non è "è un task complesso?". È "quanto rumore genera questo task, e quanto di quel rumore mi serve davvero dopo?". Se la risposta è "tanto rumore, poco segnale da tenere", isola in un sub-agente.

Non è un framework, è una disciplina

Il context engineering non si compra e non si installa. È un modo di pensare a quello che il modello vede a ogni passo.

La domanda non è "come scrivo il prompt perfetto". La domanda è: cosa deve esserci nella finestra adesso, e cosa può starne fuori. Chi se la pone a ogni passo spende sensibilmente meno, e ottiene risposte più nitide, di chi riempie la finestra e spera.

Il modello non è il collo di bottiglia. Lo è quasi sempre come lo nutri.

Se vuoi partire dalle basi e capire l'ecosistema prima di mettere mano al contesto, ho raccolto il workflow completo nella guida operativa Claude Mastery: è il punto di partenza che do a chi vuole costruire sistemi che girano, non demo che impressionano e basta.