💻 computer science

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

Ce document présente un catalogue empirique de 63 dépassements de budget de jetons par des agents LLM et introduit « token-budgets », une crate Rust à typage fort qui exploite la propriété affine pour imposer des limites de dépenses non contournables au moment de la compilation, empêchant efficacement les explosions de coûts liées à la délégation qui affligent les solutions ad hoc d'exécution.

Auteurs originaux : Sajjad Khan

Publié 2026-06-04

📖 6 min de lecture🧠 Analyse approfondie

CC BY 4.0

Auteurs originaux : Sajjad Khan

Article original sous licence CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Ceci est une explication générée par l'IA de l'article ci-dessous. Elle n'a pas été rédigée ni approuvée par les auteurs. Pour une précision technique, consultez l'article original. Lire la clause de non-responsabilité complète

Le Problème : Le « Bug de l'Argent Infini » dans l'IA

Imaginez que vous engagiez un robot assistant pour faire du travail pour vous. Vous lui donnez une règle stricte : « Ne dépense pas plus de 10 $ sur ma carte de crédit. »

Cependant, le robot s'embrouille. Il se retrouve coincé dans une boucle, essayant de résoudre un problème encore et encore. Comme le robot ne possède pas de « bouton d'arrêt » intégré qui vérifie le prix avant d'effectuer un appel, il continue de dépenser. Le temps que vous vous réveilliez le lendemain matin, le robot n'a pas seulement dépensé vos 10 $ ; il a dépensé 10 000 $.

Ce papier appelle cela un « Dépassement de Budget » (Budget Overrun). Les auteurs ont identifié 63 exemples réels de ce phénomène entre 2023 et 2026 à travers de nombreux frameworks d'IA différents. Dans certains cas, les utilisateurs ont perdu des milliers de dollars parce que le logiciel n'a pas stoppé les dépenses avant qu'elles ne surviennent.

Les Solutions Actuelles : L'Alarme « Après Coup »

La plupart des entreprises tentent actuellement de corriger cela en plaçant un « garde de sécurité » qui surveille les dépenses après que le robot a déjà effectué l'appel.

L'Analogie : Imaginez que vous allez dans un magasin, achetez 1 000 articles, et qu'ensuite le caissier vous arrête à la porte en disant : « Holà, c'est au-dessus de votre limite ! ». Vous devez quand même payer les articles que vous avez déjà pris, ou vous devez courir en rayon pour les remettre en place.
Le Point de l'Article : Ces corrections actuelles sont trop lentes. Elles constatent l'erreur, mais elles ne préviennent pas les dommages.

La Nouvelle Solution : Le « Portefeuille Magique » (Budgets de Tokens)

Les auteurs ont construit un nouvel outil appelé Budgets de Tokens (écrit dans un langage de programmation appelé Rust). Au lieu d'un garde de sécurité qui surveille les dépenses, ils ont modifié le portefeuille lui-même.

L'Analogie :
Imaginez que vous donnez au robot un portefeuille physique contenant exactement 10 $ en espèces.

Pas de Copie : Le portefeuille est fait d'un matériau spécial qui ne peut pas être photocopié. Le robot ne peut pas faire 100 copies du portefeuille pour dépenser 1 000 $.
Pas de Double Dépense : Une fois que le robot prend un billet de 1 $ pour acheter quelque chose, ce billet est parti. Il ne peut pas remettre le même billet dans sa poche pour le dépenser à nouveau.
Pas de Partage : Si le robot divise le portefeuille en deux plus petits portefeuilles pour les donner à deux assistants, le portefeuille d'origine disparaît. Les assistants ne peuvent pas revenir au portefeuille d'origine pour récupérer plus d'argent.

Dans le monde du code informatique, cela s'appelle la « Possession Affine » (Affine Ownership). Cela force l'ordinateur à vérifier les règles avant même que le robot ne quitte la maison. Si le robot essaie de transgresser les règles (comme copier le portefeuille), l'ordinateur refuse de lancer le programme du tout. C'est comme un videur de boîte de nuit qui vérifie votre pièce d'identité avant même que vous n'entriez ; si vous ne l'avez pas, vous n'atteignez jamais le bar pour commander une boisson.

Ce Qu'Ils Ont Réellement Prouvé

L'article avance trois affirmations principales, qu'ils ont testées avec soin :

Le Catalogue des Échecs : Ils ont créé un « Mur de la Honte » listant 63 incidents spécifiques où des agents d'IA se sont lancés dans des folies de dépenses. Ils ont également trouvé 47 autres cas où les développeurs ont admis : « Nous n'avons pas encore de moyen d'arrêter cela ». Cela prouve que le problème est réel et fréquent.
Le « Portefeuille Magique » Fonctionne : Ils ont testé leur nouvel outil Rust contre cinq autres méthodes populaires de gestion des coûts d'IA.
- Le Résultat : Lorsqu'ils ont tenté de piéger le système pour qu'il dépense trop (en créant une « race condition » où deux agents tentent de dépenser le même argent en même temps), les autres systèmes ont échoué 100 % du temps. Le nouveau système de « Portefeuille Magique » a échoué 0 fois.
- Pourquoi ? Parce que les autres systèmes reposent sur le fait que le programmeur se souvienne d'écrire un « verrou » pour empêcher la double dépense. Si le programmeur oublie, l'argent fuit. Le nouveau système force le programmeur à suivre les règles, sinon le code ne compilera même pas (il ne se transformera pas en un programme fonctionnel).
Ce N'est Pas une Solution Miracle pour Tout : Les auteurs sont très honnêtes sur les limites.
- Cela ne fonctionne que dans Rust : Ce « Portefeuille Magique » spécifique ne fonctionne que si vous écrivez votre logiciel dans le langage de programmation Rust. Cela ne fonctionne pas pour Python ou JavaScript (bien qu'ils aient fait une version Python qui agit comme un garde de sécurité normal, et non comme un portefeuille magique).
- Cela dépend de l'entreprise d'IA : Le système estime le coût d'une tâche. Si l'entreprise d'IA (comme OpenAI ou Anthropic) vous facture plus que prévu, ou cache certains coûts de « réflexion », le système pourrait quand même être confus. Il fait confiance à la facture qu'il reçoit, mais si la facture est erronée, le portefeuille pourrait se vider.

L'Essentiel

Cet article dit : « Les agents d'IA sont actuellement dangereux car ils peuvent accidentellement vider votre compte bancaire. Nous avons trouvé 63 exemples de cela. Nous avons construit un nouvel outil qui utilise des règles informatiques strictes pour rendre impossible le fait que le code copie ou double la dépense de l'argent par accident. Cela fonctionne parfaitement pour prévenir ces types spécifiques d'erreurs, mais cela ne fonctionne que si vous utilisez le langage de programmation Rust et si les entreprises d'IA disent la vérité sur leurs prix. »

En bref : Ils n'ont pas seulement construit un meilleur système d'alarme ; ils ont construit un portefeuille qui est physiment impossible à voler ou à dupliquer.

Résumé Technique : Budgets de Tokens

Énoncé du Problème
Les dépassements de budget des agents LLM représentent une classe de défaillance en production documentée, où des boucles de tentatives infinies ou des modèles de délégation accumulent des milliers de dollars de coûts avant d'être détectés. Les atténuations existantes sont principalement des mécanismes d'exécution (ex: rappels AgentGuard, proxys LiteLLM) qui suivent les dépenses après qu'un appel API a été engagé ou rejeté au niveau de la couche réseau. Ces approches ne parviennent pas à prévenir la condition de course « M-delegation-fanout », où des sous-agents concurrents contournent un budget partagé en raison d'un manque d'atomicité ou d'aliasing dans le code de l'opérateur. De plus, de nombreux frameworks manquent totalement d'une primitive de budget de premier ordre, ce qui entraîne des lacunes structurelles où le contrôle des coûts est absent ou implémenté via des wrappers ad hoc.

Méthodologie
Le papier emploie une approche de méthodes mixtes combinant le génie logiciel empirique et l'implémentation de systèmes :

Construction d'un Catalogue Empirique : Les auteurs ont construit un catalogue de 110 entrées issues de 21 sous-projets d'agents LLM provenant de 18 écosystèmes (2023–2026). Cela inclut 63 incidents de production confirmés (dépassements signalés par les utilisateurs avec preuves de perte financière) et 47 entrées structurelles supplémentaires (lacunes ou demandes de fonctionnalités reconnues par les mainteneurs). Le catalogue a été validé via une étude de fiabilité inter-juges (IRR) humaine indépendante, atteignant un $\kappa$ de Cohen $= 0,837$ sur le schéma de classification à quatre classes.
Taxonomie des Défaillances : Les incidents ont été organisés en huit clusters de mécanismes architecturaux exploratoires, incluant M-retry-loop, M-cost-observability, M-delegation-fanout, et M-budget-primitive-missing.
Conception de l'Atténuation (Budgets de Tokens) : Les auteurs ont implémenté token-budgets, un crate Rust de 1 180 lignes qui opérationnalise la propriété affine (affine ownership) pour la gestion du budget. Le type central Budget est non-clonable et non-copiable. Les opérations clés (spend, split, merge) consomment le budget par valeur, imposant via le vérificateur d'emprunt (borrow checker) de Rust que :
- Un budget ne peut pas être aliasé.
- Un budget ne peut pas être dépensé deux fois (use-after-move).
- Un budget ne peut pas être utilisé après avoir été délégué (split).
- Le plafond de dollars est imposé via l'arithmétique d'exécution (checked_sub) basée sur un estimateur stratifié par fournisseur (ex: longueur en octets pour OpenAI, conscient des boucles d'outils pour Anthropic).
Évaluation : Le système a été évalué par rapport à cinq runtimes de production (LangGraph, CrewAI, AutoGen, rappels de type AgentGuard, LiteLLM) et un travail concurrent (Agent Contracts) à travers trois fournisseurs. Les expériences comprenaient :
- Intégrité à la Compilation : 9 tests trybuild vérifiant que les modèles de course (clonage, double dépense) échouent à la compilation.
- Expérience de l'Opérateur Oublieux : Une comparaison entre une implémentation Python sujette aux courses (dépasse 30/30) et une implémentation Python disciplinée (verrouillée), une implémentation Rust affine, et des implémentations Rust à mutex partagé.
- Scans d'API en Direct : Tests stratifiés par température ( $T \in \{0.0, 0.3, 0.7, 1.0\}$ , $N=160$ ) et tests de plafond de sous-plancher pour vérifier l'absence de dépassement et de faux refus.
- Validité de l'Estimateur : Validation des estimateurs statiques et adaptatifs par rapport à la facturation réelle des fournisseurs.

Principales Contributions

Catalogue Empirique : La première taxonomie de dépassements de budget d'agents LLM validée par inter-juges, documentant 63 incidents confirmés et 47 lacunes structurelles à travers 21 frameworks. Cela établit la récurrence de la classe de défaillance, particulièrement le motif M-budget-primitive-missing.
Discipline de Budget Affine : Une implémentation Rust qui déplace l'intégrité du budget de la discipline d'exécution vers l'imposition à la compilation. En traitant le budget comme une valeur affine, le système empêche l'aliasing et la double dépense au niveau des types, garantissant que la condition de course « M-delegation-fanout » est une erreur de compilation plutôt qu'un risque au runtime.
Évaluation Opérationnelle : Une démonstration directe montrant que si les alternatives de runtime (compteurs correctement verrouillés) peuvent atteindre le même résultat respectant le plafond, la discipline affine garantit de manière unique l'impossibilité de contournement en cas d'erreur de l'opérateur lors de la délégation multi-agents. L'évaluation montre que l'implémentation Rust atteint 0/30 dépassements là où les bases de référence sujettes aux courses atteignent 30/30.

Résultats

Intégrité : La suite trybuild a confirmé que les trois classes de contournement de plafond (aliasing, double dépense, usage après split) entraînent des erreurs de compilation avec des diagnostics rustc spécifiques.
Comportement de Respect du Plafond : Dans les tests d'API en direct ( $N=160$ ), l'implémentation Rust a enregistré zéro violation de plafond et zéro faux refus. Dans l'expérience de l'« Opérateur Oublieux », la base de référence Python sujette aux courses a dépassé le plafond 30/30 fois, tandis que l'implémentation Rust affine a dépassé 0/30 fois.
Comparaison avec les Alternatives de Runtime : Lorsque les opérateurs implémentent correctement le verrouillage en Python ou Rust, le résultat respectant le plafond est identique à l'approche affine. La valeur distinctive du type affine est qu'il rend le motif incorrect (sujet aux courses) impossible à compiler, supprimant ainsi la charge de la discipline de concurrence de l'opérateur.
Performance de l'Estimateur : L'estimateur par défaut de longueur d'octets réserve 4 à 6 fois le coût réel. L' AdaptiveEstimator resserre cela à une médiane de 2,11× avec une latence négligeable, tandis que l'estimation directe par tokenizer atteint environ 1,0× au prix d'une latence d'environ 1 seconde par dépense.
Déploiement : Un déploiement de production unique sur le framework Rig a démontré l'approche imposant un plafond de session strict à travers des sous-agents concurrents avec zéro dépassement.

Revendications et Signification
Le papier positionne sa contribution modestement comme une étude de génie logiciel empirique avec un cas d'étude système spécifique :

Portée de la Revendication : Les auteurs déclarent explicitement qu'ils ne revendiquent pas de preuve formelle de la validité du plafond au niveau binaire (la Conjecture 1 reste ouverte). Les garanties d'intégrité sont au niveau de la source (imposées par le vérificateur d'emprunt sur le code typé). Le plafond de dollars est une propriété arithmétique d'exécution conditionnée par les hypothèses de l'estimateur (A1) et la véracité du fournisseur (A7).
Valeur Primaire : La signification réside dans le traitement structurel du mode de défaillance M-budget-primitive-missing. Pour les frameworks manquant d'une primitive de budget, une réimplémentation en Rust utilisant token-budgets ne peut pas régresser silencieusement ou n'exposer le budget que via des rappels.
Limites : L'approche est spécifique aux déploiements d'agents en Rust (une minorité de l'écosystème actuel). Elle ne résout pas les erreurs de rapport de facturation côté fournisseur, les jetons de raisonnement cachés dans les modèles de raisonnement (séries OpenAI o, réflexion étendue d'Anthropic), ou le budget multi-locataire entre processus sans un service distribué.
Conclusion : Le papier conclut que bien que les alternatives de runtime puissent atteindre le même résultat opérationnel si elles sont correctement écrites, la discipline affine fournit une garantie de « non-contournement » contre l'erreur de l'opérateur dans la délégation multi-agents, ce qui en fait la primitive préférée pour les nouveaux déploiements d'agents Rust nécessitant des plafonds de session cumulatifs. Le catalogue sert de preuve que ces modes de défaillance réapparaissent dans l'écosystème quel que le langage d'implémentation.