Un gruppo di ricercatori di Microsoft Research, Microsoft Security e della University of California, Berkeley, ha sviluppato TokenEconomizer, un sistema open source progettato per ridurre il costo computazionale degli agenti di intelligenza artificiale utilizzati nello sviluppo software senza intervenire sui parametri dei modelli linguistici o modificarne l’architettura. Il progetto, descritto nello studio TokenEconomizer: Experience-Driven Black-Box Cost Control for Coding Agents e distribuito attraverso arXiv e GitHub, introduce un livello esterno di controllo capace di apprendere dalle attività già eseguite all’interno di un repository e utilizzare queste informazioni per rendere più efficienti le sessioni successive. L’approccio affronta una delle principali fonti di consumo dei sistemi di coding agentico: la ripetizione di operazioni necessarie a ricostruire informazioni già individuate durante lavori precedenti, il caricamento di strumenti che non verranno effettivamente utilizzati e la prosecuzione di tentativi improduttivi dopo il verificarsi di errori ricorrenti. TokenEconomizer è compatibile con Claude Code, Codex, GitHub Copilot CLI e Pi e opera mediante meccanismi di controllo esterni, senza richiedere un nuovo addestramento dei modelli o modifiche al codice degli agenti. Nei test condotti sul benchmark SWE-Bench, il sistema ha consentito di ridurre il costo medio di esecuzione dal 18,4% al 30,9%, mantenendo sostanzialmente inalterata o migliorando la capacità di completare correttamente le attività assegnate.
La valutazione sperimentale ha coinvolto 277 attività distribuite su sei repository software, utilizzando cinque combinazioni differenti di agenti e modelli linguistici. I ricercatori hanno confrontato le esecuzioni tradizionali con quelle gestite attraverso TokenEconomizer, considerando non soltanto il numero di token elaborati, ma anche il costo economico effettivo delle chiamate ai modelli, le tariffe differenti applicate ai token di ingresso e uscita, i vantaggi economici del riutilizzo della cache e il consumo aggiuntivo introdotto dagli stessi meccanismi di ottimizzazione. In tutte le trenta combinazioni ottenute incrociando i sei repository con le cinque configurazioni di agenti, il costo medio è risultato inferiore rispetto alla modalità ordinaria. La riduzione massima, pari al 30,9%, è stata osservata con Claude Code e Claude Opus 4.8, mentre Claude Code con Sonnet 5 ha registrato un risparmio del 23,6%. Codex con GPT-5.6 Terra ha ottenuto una riduzione del 24,7%, Codex con GPT-5.6 Sol del 26,1% e GitHub Copilot CLI con Sonnet 5 del 18,4%. L’efficacia nella risoluzione dei compiti, misurata mediante Pass@1, è aumentata in quattro delle cinque configurazioni: i miglioramenti sono stati rispettivamente di 1,3, 0,9, 1,6 e 2,6 punti percentuali nelle combinazioni interessate, mentre con Claude Opus 4.8 si è osservata una diminuzione di un punto percentuale. I risultati mostrano quindi che la riduzione dei costi non richiede necessariamente di sacrificare la percentuale di attività completate correttamente, pur non garantendo miglioramenti uniformi in ogni configurazione.
L’analisi preliminare dei ricercatori ha individuato tre categorie principali di inefficienza. La prima riguarda la ricostruzione ripetitiva delle caratteristiche del repository: quando un agente affronta una nuova attività, tende a riesaminare file, configurazioni, procedure di compilazione e comandi di test che aveva già identificato durante sessioni precedenti. In una valutazione effettuata con Claude Code, dopo l’esecuzione di almeno cinque attività nello stesso repository, circa il 30% delle chiamate agli strumenti ripeteva comportamenti già osservati nelle esecuzioni precedenti. La seconda categoria riguarda le definizioni degli strumenti rese disponibili al modello. Gli agenti possono ricevere a ogni richiesta le descrizioni di numerose funzioni, anche quando soltanto una parte di esse viene effettivamente utilizzata. Nell’ambiente esaminato dai ricercatori, sedici dei ventitré strumenti caricati non venivano mai richiamati. Poiché queste definizioni occupano spazio nel contesto e vengono riproposte durante l’elaborazione, la loro presenza determina un consumo di token anche quando non contribuiscono direttamente al completamento del compito. La terza inefficienza deriva dai cicli di errore, nei quali un agente continua a modificare file, eseguire test e tentare correzioni senza conseguire progressi. Dieci esecuzioni fallite, equivalenti al 17% del gruppo di attività analizzato in questa specifica valutazione, hanno rappresentato il 32% del costo complessivo.
Per ridurre la prima forma di spreco, TokenEconomizer introduce un meccanismo denominato Micro-skills, attraverso il quale le informazioni operative ricavate dai lavori precedenti vengono trasformate in istruzioni sintetiche riutilizzabili. Il sistema può apprendere, per esempio, che un determinato repository richiede l’esecuzione preliminare di una procedura di compilazione, che uno specifico comando di test funziona soltanto quando viene richiamato attraverso l’interprete Python oppure che un’applicazione necessita di una particolare variabile d’ambiente. Queste informazioni vengono ricavate dalle tracce delle sessioni completate, dai problemi incontrati ripetutamente e, quando la relativa funzione è abilitata, dall’intervento di un modello incaricato di individuare conoscenze operative utili. Le Micro-skills non costituiscono una memoria generica di tutte le conversazioni, ma una raccolta di indicazioni associate allo specifico repository e sottoposte a verifica sulla base delle esperienze successive. Una conoscenza viene inserita stabilmente nel contesto delle nuove sessioni soltanto dopo essere stata confermata da più evidenze e può essere rimossa quando nuovi risultati la contraddicono. Il sistema permette così di ridurre la necessità di riscoprire continuamente le stesse caratteristiche del progetto senza introdurre istruzioni permanenti basate su osservazioni isolate.
Il secondo meccanismo, denominato Tool Pruning, interviene sull’insieme degli strumenti disponibili per l’agente, eliminando dalle sessioni successive quelli che non risultano necessari in base alle attività già svolte. La soluzione non modifica le capacità interne del modello, ma agisce sulle configurazioni dell’ambiente che determinano quali definizioni di strumenti vengono caricate nel contesto. Le funzionalità fondamentali, come l’accesso alla shell e la lettura o modifica dei file, vengono preservate, mentre strumenti accessori rimasti inutilizzati possono essere temporaneamente esclusi. Nella configurazione predefinita, il sistema considera sia il numero di richieste nelle quali uno strumento non è stato utilizzato sia la distribuzione di tali richieste tra sessioni differenti, evitando di assumere decisioni sulla base di un singolo episodio. Un criterio prevede almeno dieci richieste distribuite su due sessioni, oppure cinque sessioni di inutilizzo, prima di valutare la rimozione. La modifica viene applicata attraverso le impostazioni dell’agente e può essere annullata mediante un comando di ripristino. Il sistema tiene inoltre conto del comportamento delle cache dei prompt, rinviando le modifiche alle configurazioni per evitare di invalidare inutilmente contesti ancora riutilizzabili. In questo modo, il risparmio non deriva dall’esecuzione di meno strumenti necessari, ma dalla riduzione delle informazioni accessorie che il modello deve ricevere ed elaborare.
Il terzo componente, Failure-Loop Intervention, è dedicato al riconoscimento delle attività che entrano in una sequenza ripetitiva di errori e tentativi di correzione inefficaci. TokenEconomizer osserva il comportamento dell’agente e costruisce una rappresentazione della durata e delle caratteristiche delle esecuzioni normalmente completate con successo nel repository. Quando un’attività presenta errori ripetuti, modifiche che non producono progressi oppure una durata anomala rispetto alle sessioni precedenti, il sistema può richiedere una valutazione supplementare a un modello incaricato di stabilire se il processo sia effettivamente bloccato. Se la probabilità stimata supera la soglia prevista, l’agente riceve un’indicazione correttiva che suggerisce di abbandonare l’approccio adottato e tentare una strategia differente. Nella configurazione standard, la soglia di confidenza è pari a 0,7 e viene consentito un intervento correttivo per ciascuna attività. Se il problema persiste, il plugin pubblico segnala la situazione all’utente e indica come interrompere l’esecuzione, ma non termina autonomamente il processo. Questa caratteristica distingue l’implementazione distribuita dalle configurazioni sperimentali che possono prevedere l’arresto di un’attività per limitare ulteriormente il consumo di risorse. Il meccanismo è progettato per non interferire con operazioni che, pur richiedendo numerosi passaggi, continuano a produrre progressi verificabili.
Un elemento centrale dell’architettura è la capacità di migliorare progressivamente l’efficienza attraverso attività consecutive nello stesso ambiente software. TokenEconomizer non tratta ogni richiesta come un’esecuzione completamente indipendente, ma mantiene uno stato associato al repository, aggiornandolo alla conclusione delle sessioni. Questo consente di distribuire il costo delle operazioni di apprendimento e controllo su più attività successive. Nelle prime esecuzioni, soprattutto quando il sistema non dispone ancora di informazioni sufficienti sulle caratteristiche del progetto, l’utilizzo del plugin può comportare un incremento temporaneo dei costi a causa delle operazioni aggiuntive di osservazione e valutazione. Nei test effettuati, tuttavia, il costo cumulativo è diventato inferiore rispetto alla configurazione di riferimento a partire dalla sesta attività in tutti i repository considerati. Il risparmio deriva quindi dall’accumulo e dal riutilizzo di conoscenza operativa, non soltanto dall’ottimizzazione del singolo prompt. La strategia differisce dai metodi che comprimono sistematicamente le risposte dei comandi, riducono indiscriminatamente il contesto o sintetizzano preventivamente i file sorgente, perché adatta le proprie decisioni alle caratteristiche osservate delle attività svolte nello specifico progetto.
I ricercatori hanno verificato il comportamento del sistema anche attraverso Web-Bench, un benchmark dedicato ad attività di sviluppo web, registrando riduzioni dei costi comprese tra il 16,0% e il 21,2%. I risultati indicano che una parte dei benefici può essere trasferita a contesti differenti rispetto alla manutenzione dei repository utilizzati in SWE-Bench, sebbene l’entità del risparmio dipenda dalla natura dei compiti, dal numero di sessioni consecutive, dagli strumenti disponibili e dalle caratteristiche del modello linguistico impiegato. La valutazione economica considera inoltre il costo delle chiamate supplementari generate dai componenti di controllo, evitando di rappresentare i risparmi come una semplice diminuzione del numero di token senza tener conto delle operazioni necessarie per ottenerli. Non tutte le funzionalità, tuttavia, vengono attivate automaticamente nella distribuzione pubblica. Il Tool Pruning e il controllo dei cicli di errore sono abilitati per impostazione predefinita, mentre le Micro-skills sono disattivate inizialmente perché la produzione di nuove conoscenze tramite un modello aggiuntivo può determinare costi che non vengono necessariamente compensati in ogni progetto. L’utente può configurare separatamente i tre meccanismi in base alle esigenze dell’ambiente operativo.
TokenEconomizer è stato pubblicato come software open source e può essere installato come plugin negli agenti compatibili, utilizzando un ambiente con Python 3.10 o versioni successive. Non richiede GPU dedicate né infrastrutture di addestramento, poiché utilizza i modelli già accessibili attraverso gli strumenti di coding dell’utente. Le informazioni apprese vengono conservate localmente nella directory di configurazione del plugin e organizzate in funzione del repository e dell’agente utilizzato. Le operazioni di ottimizzazione sono reversibili e il sistema è progettato affinché eventuali errori dei suoi componenti non interrompano il normale funzionamento dell’agente. Gli autori sottolineano comunque alcuni limiti della valutazione: gli esperimenti si concentrano prevalentemente su sequenze di attività svolte nello stesso repository e non misurano ancora in modo esteso l’efficacia del riutilizzo di conoscenze accumulate durante lunghi periodi di lavoro, attraverso molteplici progetti o in organizzazioni con flussi di sviluppo complessi. Saranno quindi necessarie ulteriori verifiche per stabilire quanto i risparmi osservati nei benchmark siano riproducibili nei processi produttivi reali. I risultati dimostrano tuttavia che una parte significativa del costo degli agenti di programmazione può dipendere dalla gestione inefficiente delle informazioni e delle operazioni ripetute, e che tale componente può essere ridotta attraverso sistemi esterni capaci di apprendere dall’esperienza senza sostituire o riaddestrare il modello linguistico.
Questo articolo è stato redatto con il supporto di strumenti di intelligenza artificiale (AI)