💻 computer science

Token Budgets: An Empirical Catalog of 63 LLM-Agent Budget-Overrun Incidents, with an Affine-Typed Rust Mitigation as a Case Study

Questo articolo presenta un catalogo empirico di 63 sforamenti del budget di token di agenti LLM e introduce "token-budgets", una crate Rust a tipizzazione sicura che sfrutta l'ownership affine per imporre limiti di spesa non aggirabili al tempo di compilazione, prevenendo efficacemente le esplosioni di costi legate alla delega che affliggono le soluzioni ad hoc a runtime.

Autori originali: Sajjad Khan

Pubblicato 2026-06-04

📖 5 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Sajjad Khan

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Il Problema: Il "Glitch dei Soldi Infiniti" nell'IA

Immaginate di assumere un robot assistente per svolgere del lavoro per voi. Gli date una regola ferrea: "Non spendere più di 10 dollari con la mia carta di credito."

Tuttavia, il robot si confonde. Si incastra in un loop, cercando di risolvere un problema ripetutamente. Poiché il robot non ha un "pulsante di stop" integrato che controlli il prezzo prima di effettuare una chiamata, continua a spendere. Quando vi svegliate la mattina successiva, il robot non ha solo speso i vostri 10 dollari; ha speso 10.000 dollari.

Questo articolo chiama questo fenomeno "Budget Overrun" (superamento del budget). Gli autori hanno trovato 63 esempi reali di ciò che accade tra il 2023 e il 2026 in molti diversi framework di IA. In alcuni casi, gli utenti hanno perso migliaia di dollari perché il software non ha interrotto la spesa prima che avvenisse.

Le Soluzioni Attuali: L'Allarme "Dopo il Fatto"

La maggior parte delle aziende attualmente cerca di risolvere il problema mettendo un "custode della sicurezza" che controlla la spesa dopo che il robot ha già effettuato la chiamata.

L'Analogia: Immaginate di andare in un negozio, comprare 1.000 articoli e poi il cassiere vi ferma alla porta dicendo: "Ehi, questo è oltre il tuo limite!". Avete comunque dovuto pagare gli articoli che avevate già preso, o dovete correre indietro agli scaffali per rimetterli tutti a posto.
Il Punto del Paper: Queste soluzioni attuali sono troppo lente. Intercettano l'errore, ma non prevengono il danno.

La Nuova Soluzione: Il "Portafoglio Magico" (Token Budgets)

Gli autori hanno costruito un nuovo strumento chiamato Token Budgets (scritto in un linguaggio di programmazione chiamato Rust). Invece di un custode che controlla la spesa, hanno cambiato il portafoglio stesso.

L'Analogia:
Immaginate di dare al robot un portafoglio fisico contenente esattamente 10 dollari in contanti.

Nessuna Copia: Il portafoglio è fatto di un materiale speciale che non può essere fotocopiato. Il robot non può fare 100 copie del portafoglio per spendere 1.000 dollari.
Nessuna Doppia Spesa: Una volta che il robot prende una banconota da 1 dollaro per comprare qualcosa, quella banconota è sparita. Non può rimettere la stessa banconota in tasca e spenderla di nuovo.
Nessuna Condivisione: Se il robot divide il portafoglio in due portafogli più piccoli per darli a due aiutanti, il portafoglio originale scompare. Gli aiutanti non possono tornare al portafoglio originale per prendere altri soldi.

Nel mondo del codice informatico, questo è chiamato "Affine Ownership" (proprietà affine). Costringe il computer a controllare le regole prima che il robot esca di casa. Se il robot tenta di infrangere le regole (come copiare il portafoglio), il computer si rifiuta di far eseguire il programma. È come un buttafuori in un club che controlla il tuo documento prima ancora che tu entri; se non ce l'hai, non arrivi nemmeno al bancone per ordinare un drink.

Cosa Hanno Effettivamente Dimostrato

Il paper presenta tre affermazioni principali, che sono state testate con cura:

Il Catalogo dei Fallimenti: Hanno creato una "Galleria della Vergogna" elencando 63 episodi specifici in cui agenti di IA sono andati in spese folli. Hanno anche trovato altri 47 casi in cui gli sviluppatori hanno ammesso: "Non abbiamo ancora un modo per fermare questo". Ciò dimostra che il problema è reale e accade spesso.
Il "Portafoglio Magico" Funziona: Hanno testato il loro nuovo strumento Rust contro altri cinque modi popolari di gestire i costi dell'IA.
- Il Risultato: Quando hanno cercato di ingannare il sistema per fargli spendere troppo (creando una "race condition" dove due agenti cercano di spendere lo stesso denaro contemporaneamente), gli altri sistemi sono falliti il 100% delle volte. Il nuovo sistema a "Portafoglio Magico" è fallito 0 volte.
- Perché? Perché gli altri sistemi si affidano al fatto che il programmatore si ricordi di scrivere un "blocco" (lock) per evitare la doppia spesa. Se il programmatore dimentica, i soldi perduti. Il nuovo sistema costringe il programmatore a seguire le regole, altrimenti il codice non viene nemmeno compilato (non diventa un programma funzionante).
Non è una Soluzione Magica per Tutto: Gli autori sono molto onesti riguardo ai limiti.
- Funziona solo in Rust: Questo specifico "Portafoglio Magico" funziona solo se state scrivendo il vostro software nel linguaggio di programmazione Rust. Non funziona per Python o JavaScript (sebbene abbiano creato una versione Python che agisce come un normale custode della sicurezza, non come un portafoglio magico).
- Si affida all'azienda di IA: Il sistema stima quanto costerà un compito. Se l'azienda di IA (come OpenAI o Anthropic) vi addebita più di quanto dichiarato, o nasconde alcuni costi di "pensiero" (thinking costs), il sistema potrebbe comunque confondersi. Esso si fida della fattura che riceve, ma se la fattura è errata, il portafoglio potrebbe svuotarsi.

In Sintesi

Questo paper dice: "Gli agenti di IA sono attualmente pericolosi perché possono accidentalmente prosciugare il vostro conto bancario. Abbiamo trovato 63 esempi di questo. Abbiamo costruito un nuovo strumento che utilizza regole informatiche rigorose per rendere impossibile al codice copiare o spendere due volte accidentalmente il denaro. Funziona perfettamente per prevenire questi specifici tipi di errori, ma funziona solo se state usando il linguaggio di programmazione Rust e se le aziende di IA dicono la verità sui loro prezzi."

In breve: Non hanno solo costruito un sistema di allarme migliore; hanno costruito un portafoglio che fisicamente non può essere rubato o duplicato.

Riepilogo Tecnico: Token Budgets

Problematica
I superamenti del budget degli agenti LLM rappresentano una classe di guasti documentata in produzione, dove loop di retry illimitati o pattern di delega accumulano migliaia di dollari di costi prima della rilevazione. Le mitigazioni esistenti sono prevalentemente meccanismi di runtime (ad esempio, callback di AgentGuard, budget del proxy di LiteLLM) che tracciano la spesa dopo che una chiamata API è stata impegnata o rifiutata a livello di rete. Questi approcci non riescono a prevenire la condizione di race "M-delegation-fanout", in cui sub-agenti concorrenti aggirano un budget condiviso a causa della mancanza di atomicità o aliasing nel codice dell'operatore. Inoltre, molti framework mancano completamente di un primitivo di budget di prima classe, portando a lacune strutturali in cui il controllo dei costi è assente o implementato tramite wrapper ad hoc.

Metodologia
Il documento impiega un approccio a metodi misti che combina l'ingegneria del software empirica e l'implementazione di sistemi:

Costruzione del Catalogo Empirico: Gli autori hanno costruito un catalogo di 110 voci tratte da 21 sottoprogetti di agenti LLM appartenenti a 18 ecosistemi (2023–2026). Questo include 63 incidenti confermati in produzione (superamenti segnalati dagli utenti con prove di perdita economica) e 47 voci strutturali supplementari (lacune o richieste di funzionalità riconosciute dai manutentori). Il catalogo è stato validato tramite uno studio di affidabilità inter-rater (IRR) indipendente a due umani, raggiungendo un coefficiente di Cohen $\kappa = 0.837$ sullo schema di classificazione a quattro classi.
Tassonomia dei Guasti: Gli incidenti sono stati organizzati in otto cluster di meccanismi architettonici esplorativi, tra cui M-retry-loop, M-cost-observability, M-delegation-fanout e M-budget-primitive-missing.
Design della Mitigazione (Token Budgets): Gli autori hanno implementato token-budgets, una crate Rust di 1.180 righe che operazionalizza l'ownership affine per la gestione del budget. Il tipo core Budget è non-clonabile e non-copiabile. Le operazioni chiave (spend, split, merge) consumano il budget per valore, imponendo tramite il borrow checker di Rust che:
- Un budget non possa essere aliasato.
- Un budget non possa essere utilizzato due volte (use-after-move).
- Un budget non possa essere utilizzato dopo essere stato delegato (split).
- Il limite di spesa in dollari sia imposto tramite aritmetica di runtime (checked_sub) basata su uno stimatore stratificato per provider (ad esempio, lunghezza in byte per OpenAI, consapevole dei loop di tool per Anthropic).
Valutazione: Il sistema è stato valutato rispetto a cinque runtime di produzione (LangGraph, CrewAI, AutoGen, callback in stile AgentGuard, LiteLLM) e al lavoro concorrente (Agent Contracts) attraverso tre provider. Gli esperimenti includevano:
- Integrità a tempo di compilazione: 9 test trybuild che verificano che i pattern racy (clonazione, doppio utilizzo) falliscano la compilazione.
- Esperimento dell'Operatore Dimenticante: Un confronto tra un'implementazione Python racy (supera 30/30) contro una Python disciplinata (con lock), una affine in Rust e un'implementazione Rust con shared-mutex.
- Scansioni Live-API: Test stratificati per temperatura ( $T \in \{0.0, 0.3, 0.7, 1.0\}$ , $N=160$ ) e test di cap a sottolivello per verificare lo zero overshoot e lo zero falsi rifiuti.
- Solidità dello Stimatore: Validazione degli stimatori statici e adattivi rispetto alla fatturazione reale dei provider.

Contributi Chiave

Catalogo Empirico: La prima tassonomia validata tramite inter-rater dei superamenti di budget degli agenti LLM, documentando 63 incidenti confermati e 47 lacune strutturali in 21 framework. Ciò stabilisce la ricorrenza della classe di guasto, in particolare il pattern M-budget-primitive-missing.
Disciplina del Budget Affine: Un'implementazione in Rust che sposta l'integrità del budget dalla disciplina di runtime all'imposizione a tempo di compilazione. Trattando il budget come un valore affine, il sistema previene l'aliasing e il doppio utilizzo a livello di tipo, garantendo che la condizione di race "M-delegation-fanout" sia un errore di compilazione piuttosto che un rischio di runtime.
Valutazione Operativa: Una dimostrazione testa a testa che, sebbene le alternative di runtime (contatori correttamente bloccati) possano raggiungere lo stesso risultato di rispetto del cap, la disciplina affine garantisce unicamente l'impossibilità di bypass in caso di errore dell'operatore nella delega multi-agente. La valutazione mostra che l'implementazione Rust raggiunge 0/30 superamenti dove i baseline racy raggiungono 30/30.

Risultati

Integrità: La suite trybuild ha confermato che tutte e tre le classi di elusione del cap (aliasing, doppio utilizzo, use-after-split) risultano in errori di compilazione con specifici diagnostici rustc.
Comportamento di Rispetto del Cap: Nei test Live-API ( $N=160$ ), l'implementazione Rust ha registrato zero violazioni del cap e zero falsi rifiuti. Nell'esperimento "Forgetful-Operator", il baseline Python racy ha superato il cap 30/30 volte, mentre l'implementazione affine Rust ha superato lo 0/30 delle volte.
Confronto con Alternative di Runtime: Quando gli operatori implementano correttamente il locking in Python o Rust, il risultato di rispetto del cap è identico all'approccio affine. Il valore distintivo del tipo affine è che rende impossibile da compilare il pattern errato (racy), rimuovendo l'onere della disciplina di concorrenza dall'operatore.
Prestazioni dello Stimatore: Lo stimatore predefinito basato sulla lunghezza dei byte riserva 4–6× il costo effettivo. L' AdaptiveEstimator stringe questo valore a una mediana di 2.11× con latenza trascurabile, mentre la stima diretta tramite tokenizer raggiunge circa ~1.0× al costo di circa 1 secondo di latenza per ogni operazione di spend.
Deployment: Un singolo deployment in produzione sul framework Rig ha dimostrato l'approccio nell'imporre un limite di sessione rigido tra sub-agenti concorrenti con zero overshoot.

Rivendicazioni e Significatività
Il documento posiziona il proprio contributo modestamente come uno studio di ingegneria del software empirica con un caso di studio specifico sui sistemi:

Ambito della Rivendicazione: Gli autori dichiarano esplicitamente di non rivendicare una prova formale della solidità del cap a livello binario (la Congettura 1 rimane aperta). Le garanzie di integrità sono a livello di sorgente (imposte dal borrow checker sul codice tipizzato). Il limite di spesa in dollari è una proprietà aritmetica di runtime condizionata dalle assunzioni dello stimatore (A1) e dalla veridicità del provider (A7).
Valore Primario: La significatività risiede nel risolvere strutturalmente la modalità di guasto M-budget-primitive-missing. Per i framework che mancano di un primitivo di budget, una ri-implementazione in Rust usando token-budgets non può regredire silenziosamente o esporre il budget solo tramite callback.
Limitazioni: L'approccio è specifico per i deployment di agenti in Rust (una minoranza dell'attuale ecosistema). Non risolve la segnalazione errata della fatturazione lato provider, i token di ragionamento nascosti nei modelli di ragionamento (serie OpenAI o, Anthropic extended-thinking), o il budgeting multi-tenant tra processi diversi senza un servizio distribuito.
Conclusione: Il documento conclude che, sebbene le alternative di runtime possano raggiungere lo stesso risultato operativo se scritte correttamente, la disciplina affine fornisce una garanzia di "non-bypassabilità" contro l'errore dell'operatore nella delega multi-agente, rendendola il primitivo preferito per i nuovi deployment di agenti Rust che richiedono limiti cumulativi di sessione. Il catalogo serve come prova che queste modalità di guasto ricorrono nell'ecosistema indipendentemente dal linguaggio di implementazione.