TokenEconomizer: cos’è e come taglia fino al 31% i costi di Claude Code, Codex e Copilot

Di Daniele Forciniti

TokenEconomizer è un plugin open source di Microsoft Research, Microsoft Security e UC Berkeley che fa spendere meno gli agenti di programmazione come Claude Code, Codex, GitHub Copilot CLI e Pi. Non cambia né l’agente né il modello: impara dalle sessioni già fatte in un progetto e taglia gli sprechi in quelle dopo. Nei test del paper su SWE-Bench ha ridotto il costo medio tra il 18,4% e il 30,9%, a seconda della combinazione tra agente e modello, e nella maggior parte dei casi l’agente ha risolto anche qualche problema in più. È gratuito, con licenza Apache 2.0, e si installa in pochi minuti.

Perché se ne parla tanto

Chi usa un agente di coding tutti i giorni lo sa: il conto sale in fretta. Un agente non risponde a una domanda e basta, lavora a giri. Legge i file, lancia un comando, guarda l’errore, corregge, rilancia. E a ogni giro rimanda al modello tutto quello che c’era prima: le istruzioni di sistema, l’elenco degli strumenti disponibili e la conversazione fino a quel momento. Più il lavoro è lungo, più si paga di nuovo la stessa roba.

Il secondo motivo è chi lo firma. Non è un trucco di un utente su Reddit, è un lavoro di ricerca con undici autori, tra cui Ion Stoica di Berkeley (uno dei fondatori di Databricks) e Jianfeng Gao di Microsoft Research, con un paper pubblico, il codice per rifare gli esperimenti e risultati misurati su cinque combinazioni diverse.

Il terzo è il metodo. Quasi tutti i trucchi per risparmiare token valgono per un singolo lavoro: comprimi l’output, abbassi il ragionamento, cambi modello. TokenEconomizer parte da un’idea diversa e molto concreta: noi sviluppatori usiamo lo stesso agente sullo stesso progetto per settimane, quindi gli sprechi si ripetono, e se si ripetono si possono imparare. Il repository su GitHub ha superato le 4.000 stelle in meno di tre settimane.

Cos’è TokenEconomizer

È un plugin che si aggiunge all’agente che usi già, come un’estensione. Il nome completo del progetto dice tutto: “controllo dei costi a scatola chiusa, guidato dall’esperienza”. A scatola chiusa vuol dire che non tocca il modello, i suoi pesi o il codice dell’agente: lavora solo con quello che l’agente già permette di configurare, cioè le istruzioni iniziali, gli strumenti caricati e gli eventi della sessione. Guidato dall’esperienza vuol dire che ogni sessione finita diventa un dato da cui imparare.

Due parole sui termini, perché tornano spesso. I token sono i pezzetti di parola con cui l’AI legge e scrive, e sono l’unità con cui si paga. Un agente di coding è un’AI che lavora da sola sul codice: apre i file, li modifica, lancia i test e ricomincia finché il lavoro non è finito. Se vuoi capire meglio come ragionano e quanto possono costare, ho scritto una guida completa agli agenti AI.

Dove si sprecano i token di un agente

Prima di costruire il plugin, i ricercatori hanno analizzato 60 lavori fatti da Claude Code con Opus 4.8 su sei progetti open source molto usati in Python: Django, scikit-learn, SymPy, Sphinx, Matplotlib e xarray. I lavori vengono da SWE-Bench, il test più usato per misurare quanto un agente sa correggere bug veri presi da GitHub. Hanno trovato tre fonti di spreco, e sono quelle che chiunque usi questi strumenti riconosce subito.

• Strumenti caricati e mai usati. A ogni turno l’agente riceveva la descrizione di 23 strumenti, ma nessun progetto ne usava più di 7. Sedici non venivano mai chiamati, e tre strumenti da soli facevano il 98% delle chiamate. Il problema è che la descrizione di ogni strumento viene rimandata a ogni richiesta, che serva o no.
• Lavori falliti che costano il doppio. I lavori non riusciti erano il 17% del totale, ma si mangiavano il 32% della spesa. Quando un agente si incastra, prova e riprova la stessa strada e ogni tentativo costa.
• Le stesse cose scoperte ogni volta. Tra il 12% e il 28% del traffico degli strumenti era fatto di azioni che si ripetevano in almeno metà dei lavori dello stesso progetto: come si lanciano i test, quale comando funziona, dove stanno certi file. Ogni sessione nuova le riscopre da capo.

A me questa terza voce suona familiarissima. Uso Claude Code tutti i giorni per il lavoro sui siti, e la scena è sempre quella: ogni sessione nuova l’agente riparte da zero e deve ricapire come si accede al server, quale comando svuota la cache, dove sta un certo file. Per evitarlo mi sono costruito un file di note che l’agente legge all’inizio. TokenEconomizer prova a fare la stessa cosa in automatico.

Come funziona: i tre meccanismi

Ogni fonte di spreco ha il suo meccanismo, e ognuno si può accendere o spegnere da solo. Il principio comune è che il plugin decide solo sulla base di prove raccolte nelle sessioni precedenti, e ogni sua azione si può annullare.

1. Micro-skills: ricordare come funziona il progetto

Il plugin raccoglie i fatti operativi che le sessioni continuano a riscoprire: un passaggio di build da fare prima, il comando giusto per i test in quel progetto (per esempio python -m pytest dove pytest da solo non c’è), una variabile d’ambiente necessaria, la cartella dove finiscono i file generati. Li impara in due modi: dagli errori che si ripetono tra una sessione e l’altra, e da un modello che ogni 3 sessioni rilegge le ultime e propone dei fatti.

Un fatto entra nelle istruzioni iniziali solo dopo che tre sessioni lo hanno confermato, e viene tolto appena una sessione successiva lo smentisce. Sono frasi di una riga, non documenti lunghi: aggiungere troppo contesto costerebbe più di quanto fa risparmiare.

2. Tool pruning: smettere di caricare strumenti inutili

Se uno strumento resta inutilizzato per 10 richieste distribuite su almeno 2 sessioni, oppure per 5 sessioni di qualsiasi lunghezza, il plugin lo toglie dalle sessioni successive usando le impostazioni dell’agente stesso. Su Claude Code scrive un elenco di esclusioni nel file .claude/settings.local.json, che tiene fuori da git. Basta un comando per riavere tutto.

Nel paper c’è un esempio che rende l’idea. Sul progetto Django, Claude Code con Sonnet 5 caricava 23 strumenti, e la prima richiesta di ogni lavoro pesava circa 43.000 token. Dal secondo lavoro il plugin ha escluso 19 strumenti mai usati, e la prima richiesta è scesa a circa 16.000 token: più o meno il 62% in meno, prima ancora che l’agente cominci a lavorare.

3. Failure-loop intervention: accorgersi quando l’agente gira a vuoto

Prima il plugin impara quanto dura di solito un turno andato bene in quel progetto. Poi, quando un turno inizia a ripetere gli stessi errori, chiede a un modello “giudice” se l’agente è davvero bloccato. Se il giudice è sicuro almeno al 70%, l’agente riceve una breve nota che gli suggerisce di cambiare strada. Una volta sola per turno. Se dopo la nota è ancora bloccato, il plugin ti avvisa e ti dice come fermarlo, ma non lo ferma mai da solo.

Questa prudenza ha un motivo preciso. Nei test, 36 lavori riusciti su 50 avevano comunque ripetuto lo stesso errore almeno una volta prima di arrivare alla soluzione. Ripetere un errore non vuol dire per forza essere bloccati, e un controllo troppo aggressivo avrebbe interrotto lavori che stavano per riuscire.

I risultati: quanto si risparmia davvero

I ricercatori hanno fatto girare 277 lavori di SWE-Bench presi dai sei progetti, ognuno come una sessione separata e in ordine cronologico, partendo senza nessuna esperienza. Ogni prova è stata ripetuta tre volte. I costi sono calcolati come vengono fatturati davvero, con i prezzi della cache, e includono tutte le chiamate al modello fatte dal plugin stesso.

La colonna dei risolti è il Pass@1, cioè la percentuale di bug corretti al primo tentativo. In quattro casi su cinque sale, nell’unico caso in cui scende (Opus 4.8) perde un punto. Il dato che mi ha colpito di più però è un altro: il risparmio c’è in tutti i 30 incroci tra progetto e combinazione, con tagli che vanno dal 5,2% al 40,1%. Non c’è un progetto in cui il plugin abbia fatto spendere di più.

Il paper misura anche quanto pesa ogni meccanismo da solo, sulle due combinazioni con Claude Code:

Il tool pruning è quello che rende di più, perché agisce su ogni singolo turno di ogni lavoro. Il loop guard fa meno, ma interviene proprio sui lavori più costosi.

C’è poi la prova su lavori diversi dalla correzione di bug. Su Web-Bench, dove l’agente costruisce un progetto web passo dopo passo, il risparmio è stato tra il 16,0% e il 21,2%. Su due test di sicurezza dove ogni lavoro è in un progetto diverso, quindi senza esperienza da riusare, il taglio è stato tra il 16,5% e il 19,6% su CredData (ricerca di credenziali dimenticate nel codice) e solo tra il 6,4% e il 9,3% su ReposVul (ricerca di vulnerabilità), dove le sessioni sono corte e c’è poco da tagliare.

Meglio di abbassare il ragionamento?

È la domanda giusta, perché il modo più semplice per spendere meno con un agente è abbassare il livello di ragionamento del modello. Il paper lo ha confrontato direttamente, insieme a due strumenti open source già molto usati: RTK (Rust Token Killer), che comprime l’output dei comandi, e la repo map di Aider, che passa all’agente una mappa del codice.

Ho fatto la media delle cinque combinazioni, ed esce un risultato interessante. Passare dal ragionamento alto a quello medio fa risparmiare in media quanto TokenEconomizer (circa il 24,7%), ma fa perdere 3,3 punti di bug risolti. Il ragionamento basso arriva a risparmiare il 39%, ma perde più di 8 punti. TokenEconomizer risparmia lo stesso del ragionamento medio e in media ne guadagna uno.

RTK e RepoMap da soli risparmiano poco e in modo incostante: RTK ha fatto spendere di più in 12 incroci su 30, RepoMap in 15. Il motivo, secondo gli autori, è che applicano la stessa ricetta ovunque, mentre ogni progetto ha i suoi sprechi. Un terzo strumento, Serena, è stato tolto dal confronto finale perché nelle prove iniziali era l’unico ad aumentare la spesa complessiva. La buona notizia è che i metodi si possono sommare: su Claude Code con Opus 4.8, TokenEconomizer insieme a RTK ha portato il risparmio al 33,2%.

Come si installa su Claude Code, Codex, Copilot CLI e Pi

Serve uno degli agenti supportati, già collegato al tuo account, e Python 3.10 o più recente. Il plugin non chiede chiavi API e non tocca le credenziali: le poche chiamate al modello che fa passano dal tuo agente, con lo stesso abbonamento. Per Claude Code, Codex e Copilot CLI si clona il repository in una cartella e lo si lascia lì, perché il plugin gira da quella copia.

Claude Code

git clone https://github.com/microsoft/TokenEconomizer.git
claude plugin marketplace add "$PWD/TokenEconomizer"
claude plugin install tokeneconomizer@tokeneconomizer

Poi avvii claude, confermi che ti fidi della cartella e lanci /tokeneconomizer:status. Una volta per computer, e di nuovo dopo ogni aggiornamento di Claude Code, va lanciato /tokeneconomizer:toolprune refresh-catalog, che registra tutti gli strumenti disponibili.

Codex

git clone https://github.com/microsoft/TokenEconomizer.git
codex plugin marketplace add "$PWD/TokenEconomizer"
codex plugin add tokeneconomizer@tokeneconomizer

All’avvio scegli “Trust and continue” e poi “Trust all and continue” per gli hook. Funziona dalla sessione successiva: esci con /exit, riapri e controlla con $tokeneconomizer:status.

Copilot CLI

git clone https://github.com/microsoft/TokenEconomizer.git
copilot plugin marketplace add "$PWD/TokenEconomizer"
copilot plugin install tokeneconomizer@tokeneconomizer

Pi: basta pi install git:github.com/microsoft/TokenEconomizer, poi dentro Pi si controlla con /te status.

Una cosa da sapere: il plugin è testato solo su versioni precise degli agenti, e quelle più nuove non sono ancora state provate.

I comandi di tutti i giorni sono pochi: status mostra cosa ha imparato e quanto costano le sessioni, microskills i fatti che usa, toolprune gli strumenti esclusi, toolprune restore li rimette, config mostra le impostazioni. Per spegnere tutto in una sessione si avvia l’agente con TE_DISABLE=1 claude.

Il dettaglio che quasi nessuno dice

Nel paper il risparmio dal 18,4% al 30,9% è misurato con tutti e tre i meccanismi accesi. Ma se installi il plugin così com’è, le micro-skills sono spente. Gli autori lo spiegano nel README: il modello che propone i fatti fa delle chiamate in più, e quanto rendono dipende dal progetto e dal tipo di lavoro.

Quindi con le impostazioni di partenza hai il tool pruning e il loop guard. Guardando i risultati dei singoli meccanismi, è ragionevole aspettarsi un risparmio un po’ più basso di quello del paper. Se vuoi il pacchetto completo devi accendere le micro-skills con un comando:

/tokeneconomizer:config set microskills=on

Esiste anche una via di mezzo, microskills=envfacts, che impara i fatti solo dagli errori ripetuti, senza nessuna chiamata al modello. Per chi vuole provarlo con prudenza è il punto di partenza che consiglierei.

Limiti e cose da sapere prima di usarlo

• Le prime sessioni costano di più. Il plugin parte senza esperienza. Nei test quasi tutti i progetti all’inizio costavano più del normale, e sono diventati più economici dal sesto lavoro in poi. Se apri un progetto una volta al mese, il vantaggio è minimo.
• I modelli dei test non sono gli ultimi. Gli esperimenti usano Sonnet 5, Opus 4.8 e GPT-5.6, non i modelli più recenti come Claude Opus 5.5. Il principio vale lo stesso, ma i numeri esatti potrebbero cambiare.
• Pi non è nei test. Il plugin supporta Pi, ma il paper misura solo Claude Code, Codex e Copilot CLI. Su Pi poi il tool pruning non fa nulla, perché Pi carica già solo quattro strumenti.
• I test non sono sessioni vere. Gli stessi autori scrivono che i lavori di SWE-Bench sono correzioni collegate ma indipendenti, non il lavoro reale di una persona. Loro si aspettano più risparmio nelle sessioni continue, ma è da verificare.
• Modifica le impostazioni dell’agente. Il tool pruning scrive nei file di configurazione (su Claude Code in .claude/settings.local.json). Aggiunge solo le sue voci e non tocca le tue, ma va saputo. Se lavori in modo interattivo e usi strumenti come la modalità piano solo ogni tanto, controlla con toolprune cosa ha escluso.
• Su Claude Code i suoi avvisi si vedono poco. I messaggi dei plugin compaiono solo nella trascrizione dettagliata (Ctrl+O), quindi l’avviso di blocco viene ripetuto da Claude nella risposta, e il modello può riformularlo o saltarlo.
• Nelle esecuzioni automatiche non ti ferma. Se usi l’agente senza nessuno davanti (per esempio claude -p in uno script), un turno bloccato va avanti fino ai limiti dell’agente: il plugin lo segnala, ma non lo interrompe.
• Sono numeri degli autori. Il codice per rifare gli esperimenti è pubblico nella cartella experiments/, ma per ora non ho trovato verifiche indipendenti.

Per chi è utile davvero

• Chi lavora a lungo sugli stessi progetti. È il caso perfetto: più sessioni fai nello stesso repository, più il plugin ha esperienza da usare.
• Chi paga a consumo con le API. Se usi gli agenti con una chiave API e paghi a token, un taglio del 20-30% si vede subito in fattura.
• Chi ha un abbonamento e finisce i limiti. Con i piani a canone non si risparmiano soldi, ma meno token per lavoro vuol dire arrivare meno spesso al limite di utilizzo.
• I team con tanti server MCP collegati. Ogni server aggiunge strumenti, e ogni strumento pesa su ogni richiesta. Su Copilot CLI il plugin esclude interi server MCP mai usati.
• Meno utile per chi apre progetti sempre diversi, fa lavori brevi o usa Pi, dove c’è poco da tagliare.

Cosa ne penso

Faccio siti e posizionamento da più di un decennio, e negli ultimi tempi gli agenti di coding sono entrati nella mia giornata come un collega in più, sia per lo sviluppo di siti WordPress sia per tutti i lavori ripetitivi che prima facevo a mano. Il costo dei token è diventato una voce vera, come l’hosting o le licenze.

TokenEconomizer mi convince per una ragione semplice: non promette magie, misura. Ha preso tre sprechi che chiunque usi questi strumenti vede ogni giorno, li ha contati e ha costruito una soluzione prudente, che decide solo con le prove in mano e si può annullare con un comando. E il confronto con il ragionamento più basso è la parte più utile del paper: risparmiare abbassando la qualità lo sappiamo fare tutti, risparmiare senza perderla è un’altra cosa. Chi ha già provato alternative a Claude Code come Muse Code di Meta sa che il prezzo per lavoro conta quanto il prezzo per token.

Non l’ho ancora messo nel mio lavoro di tutti i giorni, quindi questi sono i numeri del paper, non i miei. Se lo installi, il mio consiglio è questo: lascia le impostazioni di partenza per una o due settimane, controlla con status quanto spendi e cosa ha escluso, e solo dopo accendi le micro-skills. E tieni d’occhio le versioni supportate, perché Claude Code e Codex si aggiornano spesso.

Conclusione

TokenEconomizer è uno dei progetti più concreti usciti quest’anno sul costo degli agenti di programmazione. Non cambia il modello e non abbassa la qualità: impara dai lavori fatti nello stesso progetto, smette di caricare strumenti inutili, ricorda i fatti che l’agente riscopriva ogni volta e interviene quando l’agente gira a vuoto. I numeri del paper sono buoni e, soprattutto, costanti: risparmio in tutti i 30 casi misurati. I limiti ci sono (versioni supportate strette, micro-skills spente di default, nessuna verifica esterna per ora), ma per chi lavora ogni giorno sugli stessi repository vale la pena provarlo.

FAQ

Che cos’è TokenEconomizer?

È un plugin open source di Microsoft Research, Microsoft Security e UC Berkeley che riduce il costo in token degli agenti di programmazione. Impara dalle sessioni già fatte in un progetto e taglia gli sprechi in quelle successive, senza modificare l’agente o il modello.

Quanto fa risparmiare?

Nei test del paper su 277 lavori di SWE-Bench ha ridotto il costo medio tra il 18,4% e il 30,9%, a seconda della combinazione tra agente e modello. Su lavori di sviluppo web il taglio è stato tra il 16% e il 21%, su test di sicurezza tra il 6% e il 20%.

Con quali agenti funziona?

Con Claude Code, Codex, GitHub Copilot CLI e Pi. Il supporto per opencode e Cursor Agent è ancora in prova. Il paper però misura i risultati solo su Claude Code, Codex e Copilot CLI.

È gratis?

Sì. È open source con licenza Apache 2.0 e non chiede chiavi API. Le poche chiamate al modello che fa passano dal tuo agente, con il tuo abbonamento, e il loro costo è già incluso nei risparmi misurati.

Peggiora la qualità del lavoro dell’agente?

Nei test no: la percentuale di bug risolti è salita in quattro combinazioni su cinque ed è scesa di un punto solo con Opus 4.8. Abbassare il livello di ragionamento, al contrario, fa risparmiare in modo simile ma perde in media più di 3 punti.

Cosa fa con i miei dati?

Tutto quello che impara resta sul tuo computer, nella cartella ~/.tokeneconomizer. Le modifiche agli strumenti le scrive nei file di impostazioni locali dell’agente, tenuti fuori da git, e si annullano con il comando toolprune restore.

Funziona subito dopo l’installazione?

Ha bisogno di qualche sessione per imparare. Nei test i primi lavori costavano un po’ di più del normale e il risparmio è arrivato dal sesto in poi. Inoltre di default sono attivi solo il tool pruning e il loop guard: le micro-skills vanno accese a mano.

Leggi anche:
Claude Opus 5.5, GPT-6 Sol e Luna: prezzi e benchmark a confronto ·
Claude Duet: cos’è e per cosa utilizzarlo ·
7 risorse gratuite per sviluppatori: API di AI, database, email e monitoraggio

Fonti

• Microsoft, TokenEconomizer su GitHub: README con meccanismi, installazione, impostazioni e versioni supportate.
• Li et al., TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents, arXiv 2610.22732: il paper con tutti i risultati, i confronti e i limiti.
• Note di rilascio della versione 0.1.0: prima versione pubblica del 26 ottobre 2026.
• Pagina del progetto: grafici interattivi e risultati per singolo progetto.
• ExplainX: approfondimento su installazione e avvertenze.
• AI Mastery e AlphaSignal: sintesi della notizia e dei risultati.

Animazioni allo scroll in CSS: dal 2026 funzionano in tutti i browser, senza JavaScript

Blog ItalianoSviluppo Web

Animazioni allo scroll in CSS: dal 2026 funzionano in tutti

Animazioni allo scroll in CSS: dal 2026 funzionano in tutti i browser, senza JavaScript Di Daniele Forciniti Dal 27 ottobre 2026 le…

by Daniele Forciniti on 7 Novembre 2026

Kimi K3.1 Pro: novità, benchmark e prezzi del modello open-weight che sfida Opus 5.5

Blog ItalianoIntellizenza Artificiale

Kimi K3.1 Pro: novità, benchmark e prezzi del modello open-weight

Kimi K3.1 Pro: novità, benchmark e prezzi del modello open-weight che sfida Opus 5.5 Di Daniele Forciniti Kimi K3.1 Pro è il…

by Daniele Forciniti on 6 Novembre 2026

Google sposta gli AI Overviews dei brand nella colonna destra e prova a togliere AI Mode: cosa cambia per il traffico

Blog ItalianoSEO

Google sposta gli AI Overviews dei brand nella colonna destra

Google sposta gli AI Overviews dei brand nella colonna destra e prova a togliere AI Mode: cosa cambia per il…

by Daniele Forciniti on 5 Novembre 2026

Core Web Vitals nel 2026: cosa sono LCP, INP e CLS e come migliorarli

Blog ItalianoSEO

Core Web Vitals nel 2026: cosa sono LCP, INP e

Core Web Vitals nel 2026: cosa sono LCP, INP e CLS e come migliorarli Di Daniele Forciniti I Core Web Vitals sono…

by Daniele Forciniti on 4 Novembre 2026

Title, meta description e snippet nel 2026: come scriverli e perché Google li cambia

Blog ItalianoSEO

Title, meta description e snippet nel 2026: come scriverli e

Title, meta description e snippet nel 2026: come scriverli e perché Google li cambia Di Daniele Forciniti Il title e la meta…

by Daniele Forciniti on 30 Ottobre 2026

Gemini 4 Carbon: novità, benchmark e prezzi del modello più potente di Google

Blog ItalianoDigital MarketingIntellizenza Artificiale

Gemini 4 Carbon: novità, benchmark e prezzi del modello più

Gemini 4 Carbon: novità, benchmark e prezzi del modello più potente di Google Di Daniele Forciniti Gemini 4 Carbon è il nuovo…

by Daniele Forciniti on 29 Ottobre 2026