Le deviazioni dell’IA per cui non dovresti pagare

Non è detto che le aziende di IA all’avanguardia non cerchino di manipolare la situazione a proprio favore quando ci vendono token, se potessero farla franca: dopotutto, a giugno Anthropic ha applicato un aumento effettivo dei prezzi del 30%; ad agosto DeepSeek ha aumentato i prezzi delle API; e alla fine di settembre OpenAI ha fatto malvolentieri marcia indietro su un declassamento della quota di token disponibile nella fascia intermedia. È ormai piuttosto evidente, quindi, una tendenza verso l’austerità.

In effetti, il pensiero torna spesso quando il tuo agente IA esaurisce la quota giornaliera di token in 45 minuti di codice non necessariamente glorioso e ti dice di riprovare tra 3-4 ore. In un momento così frustrante, non si può fare a meno di chiedersi se alcuni dei meccanismi alla base di questa attività siano orientati a vantaggio dei fornitori. Dopotutto, è un buon modo per indurci a sborsare denaro per una ricarica speciale di token, o persino a attivare la «ricarica automatica».

Se davvero fosse così, in questa fase le aziende all’avanguardia potrebbero a buon diritto trincerarsi dietro l’idea che non comprendiamo del tutto come vengono utilizzati i token nei carichi di lavoro basati su agenti, tra modelli e harness. E nemmeno loro lo capiscono. A eccezione dei loro processi di attivazione dei pagamenti (davvero molto fluidi), è tutto ancora in fase pre-alfa e continua ad alimentare la ricerca più avanzata, nonostante la diffusa commoditizzazione del prodotto.

Gestire gli sprechi

Il fatto che gli agenti IA sprechino token (e quindi i tuoi soldi) quando ragionano nei flussi di lavoro basati su agenti è già ampiamente assodato: esattamente un anno fa ho scritto di nuove ricerche che indicavano quanto i modelli di IA capaci di ragionare tendessero a bruciare token «divagando»; all’inizio di quest’anno ho parlato di ulteriori ricerche che indicavano che il ragionamento a catena di pensieri fosse «decorativo»; e la settimana scorsa Nils Bunge, responsabile del prodotto di Tsuga, in un articolo di leadership di pensiero pubblicato qui, ha dichiarato:

«Un team che consuma il doppio dei token non crea necessariamente il doppio del valore. Potrebbe occuparsi di attività più difficili, utilizzare un modello inutilmente potente o affidarsi a un agente che riprova ripetutamente attività non riuscite.»

Meno noto è il modo in cui i token vengono sprecati in attività o processi superflui; è proprio questo il tema di un nuovo articolo che oggi ha riportato la mia attenzione sull’argomento.

Intitolata How Do Ai Agents Waste Your Money?, questa nuova collaborazione accademica statunitense* propone un quadro unificato in grado di quantificare quanto i processi basati su agenti siano effettivamente dispendiosi in termini di token. Nei casi in cui i modelli siano closed source, una metodologia «ombra» si combina con le statistiche e le metriche ufficiali dei fornitori per ricostruire in modo equivalente, passo dopo passo, che cosa è successo ai token mentre l’IA ragionava e agiva:

Il nuovo metodo per misurare gli sprechi di token dell’IA. Il ragionamento, le azioni e i costi di ciascun agente vengono registrati e poi esaminati per individuare ripetizioni, richieste superflue e deviazioni evitabili. Gli sprechi individuati vengono eliminati e si verifica nuovamente la capacità dell’agente di completare l’attività originale. Fonte

Come mostrato sopra, si lascia che l’agente lavori normalmente, intercettando e registrando le comunicazioni con il fornitore di IA, compresi i passaggi di ragionamento, l’uso degli strumenti, il consumo di token e i costi. Le registrazioni vengono poi esaminate da valutatori basati su Large Language Model (LLM), che distinguono il lavoro utile dalle ripetizioni, dalle ricerche superflue e dalle deviazioni. In seguito, si eliminano gli sprechi presunti, si calcola il risparmio di token e si riprende il lavoro dell’agente per verificare se l’attività possa ancora essere completata con successo.

Nei test, i ricercatori hanno scoperto che circa il 18% dei token di output degli agenti andava sprecato. In oltre il 45% delle attività, un agente sprecava più token di quanti ne servissero a un altro per completare con successo lo stesso lavoro. Hanno inoltre rilevato che eliminare il 41–46% del ragionamento superfluo incideva pochissimo sulle prestazioni, suggerendo che è possibile ottenere risparmi considerevoli senza compromettere in misura significativa i risultati.

Il documento afferma:

«Nell’insieme delle traiettorie raccolte, circa il 18% dei token di output è identificato come spreco.»

«È sorprendente che, in oltre il 45% delle attività, il solo output sprecato da un agente superi l’output totale di un altro agente che porta a termine con successo la stessa attività.»

Inoltre, lo studio ha rilevato che gli agenti sprecavano più risorse quando si orientavano tra strumenti sconosciuti e seguivano approcci che alla fine non portavano a nulla; ha anche riscontrato che aumentare lo sforzo di ragionamento non produce miglioramenti costanti: al livello massimo, Kimi-K3 generava 6,6 volte più token di ragionamento rispetto al livello basso, senza alcuna garanzia corrispondente di ottenere risultati migliori.

Risultati dei test che mostrano le prestazioni di Kimi-K3 a quattro livelli di intensità del ragionamento su cinque benchmark. Un’intensità maggiore non ha migliorato costantemente i tassi di successo e, talvolta, con l’intensità massima i risultati sono stati peggiori che con impostazioni inferiori.

Per analogia, invece di guidare un’auto potente senza mai sfruttarne davvero le capacità, queste sessioni con agenti sono più simili alla guida di un’auto che accelera fino alla massima velocità che è in grado di raggiungere a ogni viaggio, anche quando non serve e nonostante le possibili conseguenze negative.

Il documento esamina anche il ruolo dei diversi framework nella generazione di spreco di token e rileva che lo stesso modello di IA, Kimi-K3, può produrre oltre quattro volte più ragionamenti sugli stessi compiti, a seconda del framework utilizzato, senza necessariamente ottenere risultati migliori.

Parte dello spreco è riconducibile a semplici malfunzionamenti software: è stato rilevato che OpenCode, Kimi Code CLI e OpenClaw avviavano ripetutamente i compiti nell’ambiente Python sbagliato, causando errori e nuovi tentativi che consumavano token. Kimi Code CLI consentiva inoltre all’IA di richiedere timeout che il software stesso avrebbe rifiutato, costringendola a compiere altri tentativi costosi.

Contrariamente alle aspettative, i framework che offrivano più strumenti non erano necessariamente più dispendiosi, e alcune inefficienze ricorrenti sembravano avere origine nei modelli stessi, indipendentemente dal framework che li controllava.

‘[Several] proprietà del framework apparentemente ovvie non spiegano in modo coerente le differenze di spreco osservate. Per esempio, come mostra [below], i framework che mettono a disposizione più strumenti non sono necessariamente più dispendiosi. OpenClaw offre molti più strumenti degli altri framework, eppure genera uno spreco solo moderato. Inoltre, non tutto lo spreco varia in base al framework.

‘[Below right] mostra che, su SWE-bench Verified, Kimi-K3 compie ripetutamente una deviazione: scrive quella che ritiene essere la correzione originale del progetto e poi la abbandona. ‘

Risultati dei test che confrontano i token sprecati nei framework degli agenti IA. A sinistra: offrire più strumenti non aumenta necessariamente lo spreco. A destra: Kimi-K3 tenta ripetutamente una presunta correzione originale del software e poi la abbandona, indipendentemente dal framework, ma lo fa raramente con un altro tipo di compito.

Per rimediare al problema, gli autori suggeriscono che i framework degli agenti riconoscano quando le restrizioni dell’ambiente rendono impossibile progredire ulteriormente, comunichino chiaramente tali limitazioni al modello di IA e interrompano l’esecuzione, invece di consentire che ripetuti tentativi falliti consumino altri token. Propongono inoltre di utilizzare le loro misurazioni dei token sprecati per migliorare l’addestramento dei modelli, le strategie di ragionamento e la progettazione dei framework.

Metodo

Per ricostruire l’attività di un agente di IA, i ricercatori hanno monitorato ogni scambio tra il modello e il software che lo controllava, registrandone il ragionamento, le risposte, le richieste agli strumenti e i costi in token; il livello di dettaglio variava a seconda del fornitore: Kimi-K3 rivela l’intero processo di ragionamento; Gemini 3.1 Pro ne mostra solo dei riepiloghi; Claude non ne espone alcuno.

I risultati di ogni strumento venivano reinseriti nell’agente, consentendo ai ricercatori di seguirne il processo fino al completamento o al raggiungimento del limite operativo.

Quattro esempi di come gli agenti di IA consumano token. Ripetere informazioni già note, effettuare ricerche identiche e aggiungere scuse inutili sono considerati sprechi, mentre una ricerca senza esito non è necessariamente uno spreco, poiché l’agente potrebbe aver avuto buone ragioni per tentarla.

Le richieste degli agenti sono state instradate attraverso un proxy per monitorarne l’attività, con la necessità di apportare solo modifiche minime al codice; ogni richiesta era contrassegnata con il benchmark, l’esecuzione, il compito e la prova (tranne nel caso di OpenClaw, che non supporta tali tag: per ogni test è stato quindi utilizzato un proxy distinto, basato su LiteLLM).

Quattro categorie

Lo studio definisce lo spreco di token attraverso quattro schemi ricorrenti: Ripetizione (ripetere informazioni già note); Recupero duplicato (ripetere richieste non necessarie agli strumenti); Riempitivo (aggiungere testo irrilevante); e Deviazione (seguire approcci plausibili ma, in definitiva, improduttivi).

Ogni sessione registrata è stata esaminata da un LLM-as-a-Judge (LLMaJ**), a cui sono stati forniti il compito originale, il resoconto completo e i criteri per individuare tutti e quattro i modelli di spreco. Gli sprechi sospetti sono stati contrassegnati e rimossi, quindi i token rimanenti sono stati ricontati per calcolare la percentuale e il costo dello spreco. I conteggi sono stati poi verificati confrontandoli con i tokenizzatori o gli strumenti di conteggio dei singoli fornitori e con l’uso di output dichiarato (segnalando solo lievi differenze di formattazione).

Test

I modelli esaminati nello studio erano Kimi-K3; Gemini 3.1 Pro; GPT-5.6 Terra; GPT-6 Astra; Claude Sonnet 5; e Claude Fable 5.1. Sono stati valutati sui benchmark τ²-bench (assistenza clienti nei settori aereo e della vendita al dettaglio); SWE-bench Verified (ingegneria del software); Claw-Eval; e MCP-Atlas (uso di strumenti per finalità generali).

Inoltre, Kimi-K3 è stato testato a diversi livelli di ragionamento e sono stati confrontati cinque ambienti per agenti: OpenCode; OpenClaw; OpenHands; Hermes; e Kimi Code CLI. Questi ultimi confronti sono serviti a valutare in che modo i modelli, i compiti, l’impegno di ragionamento e la progettazione dell’ambiente per agenti incidano sullo spreco di token (e, in ulteriori test, è stato rimosso lo spreco sospetto per verificarne l’effetto sulle prestazioni).

Per determinare quanto denaro fosse stato sprecato da ciascun modello, il costo del testo e delle chiamate agli strumenti non necessari è stato confrontato con il costo totale degli output; i risultati sono stati poi mediati sui quattro benchmark. Il ragionamento interno è stato valutato separatamente per Kimi-K3, l’unico modello che rendeva visibile il proprio processo di ragionamento completo:

Risultati dei test che confrontano i costi degli output sprecati di sei modelli di IA, calcolati come media su quattro benchmark. A sinistra: percentuali complessive di spreco, con il ragionamento interno di Kimi-K3 mostrato separatamente. A destra: percentuali di spreco nei compiti completati con successo e in quelli falliti; in genere, i fallimenti comportano più spreco.

Come mostra il grafico qui sopra, si è stimato che tra l’11% e il 24,9% del denaro speso per generare risposte e usare strumenti sia stato sprecato: GPT-6 Astra ha ottenuto i risultati migliori e Claude Sonnet 5 i peggiori. Nel caso di Kimi-K3, è stato sprecato circa un token su sei nelle risposte e nell’uso degli strumenti; la quota saliva a più di un token su quattro durante il ragionamento interno.

In genere, i compiti falliti comportavano più spreco, anche se per il ragionamento di Kimi-K3 valeva il contrario; inoltre, non sono emerse prove chiare del fatto che spendere più token in attività non necessarie aumentasse le probabilità di successo.

In un altro test si è cercato di ridurre i token sprecati mentre l’IA era ancora al lavoro: a ogni passaggio, un giudice IA** rimuoveva dal ragionamento del modello le informazioni ripetute e il testo inutile, prima di consentire al compito di proseguire:

Risultati dei test che mostrano in che modo la rimozione del ragionamento superfluo dell’IA abbia influito sui tassi di successo in due benchmark. Eliminare il 41-46% del ragionamento ha avuto un effetto minimo sulle prestazioni, mentre rimuoverlo del tutto ha causato un numero sensibilmente maggiore di fallimenti.

Su SWE-bench Verified è stato eliminato il 41% del ragionamento senza alcun calo delle prestazioni; anzi, il tasso di successo è aumentato leggermente, dall’89% all’89,5%. Su MCP-Atlas è stato rimosso il 46%, con una diminuzione contenuta del tasso di successo, dal 65% al 62,3%.

In altre parole, quasi metà del ragionamento poteva essere eliminata mentre l’IA era al lavoro, senza compromettere seriamente la sua capacità di portare a termine il compito.

Infine^†, Kimi-K3 è stato testato su compiti identici con diversi ambienti per agenti. In questo caso, la quantità di ragionamento generata variava di oltre quattro volte, senza alcun miglioramento costante delle prestazioni, come mostra il grafico qui sotto:

Risultati dei test che confrontano il consumo di token di Kimi-K3 con diversi ambienti per agenti su due benchmark. Il ragionamento interno è mostrato in blu, le risposte e le chiamate agli strumenti in arancione. Nei compiti di programmazione, Mini-SWE ha generato oltre quattro volte più ragionamento di Hermes.

Parte dello spreco è stata ricondotta a problemi software di base. OpenCode, Kimi Code CLI e OpenClaw hanno avviato i test di programmazione nell’ambiente Python sbagliato, causando errori e nuovi tentativi.

Conclusione

Questo è solo un breve sguardo a uno studio la cui lunghezza e il cui metodo scrupoloso potrebbero ripagare una lettura più approfondita.

L’argomento mi ha fatto venire in mente una cosa di cui sono spesso consapevole: l’enorme divario tra ciò che noi e i fornitori di modelli più avanzati capiamo davvero di questi processi e la disponibilità delle aziende a confezionare il prodotto come se avesse trascorso gli ultimi tre mesi in un analizzatore statico e avesse superato l’esame a pieni voti.

Per come stanno le cose al momento, se si verificano esiti negativi non possiamo incolpare nessuno se non noi stessi, perché stiamo acquistando un prodotto che quasi tutti sappiamo essere profondamente sperimentale e imprevedibile.

* Con contributi dichiaratamente paritari da parte di University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) e di un ricercatore indipendente.

* Per quanto riesca a capire, l’articolo non identifica quale modello sia stato utilizzato.

^† Per questo articolo, non per il paper, che è più lungo di quanto io sia solito trattare e contiene più test e un livello di approfondimento che non possiamo permetterci qui. Per maggiori dettagli, consultate il PDF originale, al link qui sopra.

Pubblicato per la prima volta venerdì 6 novembre 2026