💻 computer science

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

Este artículo presenta un catálogo empírico de 63 excesos del presupuesto de tokens en agentes de LLM e introduce "token-budgets", una caja (crate) de Rust con tipado seguro que aprovecha la propiedad afín para imponer límites de gasto no eludibles en tiempo de compilación, previniendo eficazmente las explosiones de costos relacionadas con la delegación que afectan a las soluciones ad-hoc en tiempo de ejecución.

Autores originales: Sajjad Khan

Publicado 2026-06-04

📖 5 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Sajjad Khan

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El Problema: El "Glitch de Dinero Infinito" en la IA

Imagina que contratas a un robot asistente para que haga algunas tareas por ti. Le das una regla estricta: "No gastes más de $10 de mi tarjeta de crédito".

Sin embargo, el robot se confunde. Se queda atrapado en un bucle, intentando resolver un problema una y otra vez. Debido a que el robot no tiene un "botón de parada" integrado que verifique el precio antes de realizar una llamada, sigue gastando. Para cuando despiertas a la mañana siguiente, el robot no solo ha gastado tus $10; ha gastado $10,000.

Este artículo llama a esto un "Desbordamiento de Presupuesto" (Budget Overrun). Los autores encontraron 63 ejemplos reales de esto sucediendo entre 2023 y 2026 en muchos marcos de trabajo de IA diferentes. En algunos casos, los usuarios perdieron miles de dólares porque el software no detuvo el gasto antes de que ocurriera.

Las Soluciones Actuales: La Alarma "Después del Hecho"

La mayoría de las empresas actualmente intentan solucionar esto colocando a un "guardia de seguridad" que vigila el gasto después de que el robot ya ha realizado la llamada.

La Analogía: Imagina que vas a una tienda, compras 1,000 artículos y luego el cajero te detiene en la puerta y dice: "¡Oye, eso es más de tu límite!". De todos modos, tienes que pagar por los artículos que ya agarraste, o tienes que correr de vuelta al estante para dejarlos.
El Punto del Artículo: Estas soluciones actuales son demasiado lentas. Detectan el error, pero no previenen el daño.

La Nueva Solución: La "Billetera Mágica" (Presupuestos de Tokens)

Los autores construyeron una nueva herramienta llamada Token Budgets (escrita en un lenguaje de programación llamado Rust). En lugar de un guardia de seguridad que vigila el gasto, ellos cambiaron la billetera misma.

La Analogía:
Imagina que le das al robot una billetera física que contiene exactamente $10 en efectivo.

Sin Copias: La billetera está hecha de un material especial que no se puede fotocopiar. El robot no puede hacer 100 copias de la billetera para gastar $1,000.
Sin Doble Gasto: Una vez que el robot toma un billete de $1 para comprar algo, ese billete desaparece. No puede volver a meter el mismo billete en su bolsillo y gastarlo de nuevo.
Sin Compartir: Si el robot divide la billetera en dos billeteras más pequeñas para dárselas a dos ayudantes, la billetera original desaparece. Los ayudantes no pueden volver a la billetera original para obtener más dinero.

En el mundo del código informático, esto se llama "Propiedad Afín" (Affine Ownership). Obliga a la computadora a verificar las reglas antes de que el robot siquiera salga de casa. Si el robot intenta romper las reglas (como copiar la billetera), la computadora se niega a dejar que el programa se ejecute en absoluto. Es como un portero en un club que revisa tu identificación antes de que entres; si no la tienes, nunca llegas a la barra para pedir una bebida.

Lo Que Realmente Demostraron

El artículo presenta tres afirmaciones principales, las cuales probaron cuidadosamente:

El Catálogo de Fallos: Crearon un "Salón de la Fama de la Vergüenza" listando 63 incidentes específicos donde los agentes de IA se lanzaron en compras desenfrenadas. También encontraron 47 casos más donde los desarrolladores admitieron: "Aún no tenemos una forma de detener esto". Esto demuestra que el problema es real y ocurre con frecuencia.
La "Billetera Mágica" Funciona: Probaron su nueva herramienta de Rust contra otras cinco formas populares de gestionar los costos de la IA.
- El Resultado: Cuando intentaron engañar al sistema para que gastara demasiado (creando una condición de carrera donde dos agentes intentan gastar el mismo dinero al mismo tiempo), los otros sistemas fallaron el 100% de las veces. El nuevo sistema de la "Billetera Mágica" falló 0 veces.
- ¿Por qué? Porque los otros sistemas dependen de que el programador recuerde escribir un "bloqueo" para evitar el doble gasto. Si el programador lo olvida, el dinero se filtra. El nuevo sistema obliga al programador a seguir las reglas, o el código ni siquiera compilará (no se convertirá en un programa funcional).
No es una Solución Mágica para Todo: Los autores son muy honestos sobre los límites.
- Solo funciona en Rust: Esta "Billetera Mágica" específica solo funciona si estás escribiendo tu software en el lenguaje de programación Rust. No funciona para Python o JavaScript (aunque hicieron una versión de Python que actúa como un guardia de seguridad normal, no como una billetera mágica).
- Depende de la empresa de IA: El sistema estima cuánto costará una tarea. Si la empresa de IA (como OpenAI o Anthropic) te cobra más de lo que dijo, o esconde algunos costos de "pensamiento", el sistema aún podría confundirse. Confía en la factura que recibe, pero si la factura es incorrecta, la billetera podría quedarse vacía.

La Conclusión

Este artículo dice: "Los agentes de IA son peligrosos actualmente porque pueden drenar accidentalmente tu cuenta bancaria. Encontramos 63 ejemplos de esto. Construimos una nueva herramienta que utiliza reglas informáticas estrictas para hacer imposible que el código accidentalmente copie o duplique el dinero. Funciona perfectamente para prevenir estos tipos específicos de errores, pero solo funciona si estás usando el lenguaje de programación Rust y si las empresas de IA dicen la verdad sobre sus precios".

En resumen: No solo construyeron un mejor sistema de alarma; construyeron una billetera que físicamente no puede ser robada ni duplicada.

Resumen Técnico: Presupuestos de Tokens

Planteamiento del Problema
Los excesos de presupuesto en agentes LLM representan una clase de fallo de producción documentada donde bucles de reintento sin límites o patrones de delegación acumulan miles de dólares en costos antes de su detección. Las mitigaciones existentes son predominantemente mecanismos de tiempo de ejecución (por ejemplo, callbacks de AgentGuard, presupuestos de proxy de LiteLLM) que rastrean el gasto después de que una llamada a la API ha sido comprometida o rechazada en la capa de red. Estos enfoques no logran prevenir la condición de carrera "M-delegation-fanout", donde sub-agentes concurrentes eluden un presupuesto compartido debido a la falta de atomicidad o aliasing en el código del operador. Además, muchos frameworks carecen por completo de un primitivo de presupuesto de primera clase, lo que genera brechas estructurales donde el control de costos está ausente o se implementa mediante envoltorios ad-hoc.

Metodología
El artículo emplea un enfoque de métodos mixtos que combina la ingeniería de software empírica y la implementación de sistemas:

Construcción de Catálogo Empírico: Los autores construyeron un catálogo de 110 entradas extraídas de 21 subproyectos de agentes LLM de 18 ecosistemas (2023–2026). Esto incluye 63 incidentes de producción confirmados (excesos reportados por usuarios con evidencia de pérdida monetaria) y 47 entradas estructurales suplementarias (brechas reconoccidas por mantenedores o solicitudes de funciones). El catálogo fue validado mediante un estudio de fiabilidad inter-evaluador (IRR) de dos humanos independientes, logrando un $\kappa$ de Cohen $= 0.837$ en el esquema de clasificación de cuatro clases.
Taxonomía de Fallos: Los incidentes se organizaron en ocho clústeres de mecanismos arquitectónicos exploratorios, incluyendo M-retry-loop, M-cost-observability, M-delegation-fanout y M-budget-primitive-missing.
Diseño de Mitigación (Presupuestos de Tokens): Los autores implementaron token-budgets, un crate de Rust de 1,180 líneas que operacionaliza la propiedad afín (affine ownership) para la gestión de presupuestos. El tipo central Budget no es clonable ni copiable. Las operaciones clave (spend, split, merge) consumen el presupuesto por valor, imponiendo mediante el verificador de préstamos (borrow checker) de Rust que:
- Un presupuesto no puede ser aliasado.
- Un presupuesto no puede ser gastado dos veces (use-after-move).
- Un presupuesto no puede ser utilizado después de haber sido delegado (split).
- El límite de dólares se impone mediante aritmética de tiempo de ejecución (checked_sub) basada en un estimador estratificado por proveedor (por ejemplo, longitud de bytes para OpenAI, consciente de los bucles de herramientas para Anthropic).
Evaluación: El sistema fue evaluado contra cinco entornos de ejecución de producción (LangGraph, CrewAI, AutoGen, callbacks estilo AgentGuard, LiteLLM) y trabajo concurrente (Agent Contracts) a través de tres proveedores. Los experimentos incluyeron:
- Integridad en Tiempo de Compilación: 9 pruebas trybuild que verifican que los patrones de carrera (clonación, doble gasto) fallan al compilar.
- Experimento del Operador Olvidadizo: Una comparación de una implementación de Python con condiciones de carrera (excede 30/30) frente a Python disciplinado (con bloqueo), Rust afín y las implementaciones de Rust con shared-mutex.
- Barridos de API en Vivo: Pruebas estratificadas por temperatura ( $T \in \{0.0, 0.3, 0.7, 1.0\}$ , $N=160$ ) y pruebas de límite de sub-piso para verificar cero excesos y cero rechazos falsos.
- Solidez del Estimador: Validación de los estimadores estáticos y adaptativos frente a la facturación real del proveedor.

Contribuciones Clave

Catálogo Empírico: La primera taxonomía de excesos de presupuesto de agentes LLM validada por inter-evaluador, documentando 63 incidentes confirmados y 47 brechas estructurales a través de 21 frameworks. Esto establece la recurrencia de la clase de fallo, particularmente el patrón M-budget-primitive-missing.
Disciplina de Presupuesto Afín: Una implementación en Rust que traslada la integridad del presupuesto de la disciplina de tiempo de ejecución a la imposición en tiempo de compilación. Al tratar el presupuesto como un valor afín, el sistema evita el aliasing y el doble gasto a nivel de tipo, asegurando que la condición de carrera "M-delegation-fanout" sea un error de compilación en lugar de un peligro en tiempo de ejecución.
Evaluación Operacional: Una demostración directa de que, si bien las alternativas de tiempo de ejecución (contadores correctamente bloqueados) pueden lograr el mismo resultado de respeto al límite, la disciplina afín garantiza de forma única la imposibilidad de elusión bajo error del operador en la delegación multi-agente. La evaluación muestra que la implementación de Rust logra 0/30 excesos donde las líneas base con condiciones de carrera logran 30/30.

Resultados

Integridad: La suite trybuild confirmó que las tres clases de elusión de límites (aliasing, doble gasto, uso tras división) resultan en errores de compilación con diagnósticos específicos de rustc.
Comportamiento de Respeto al Límite: En las pruebas de API en vivo ( $N=160$ ), la implementación de Rust registró cero violaciones de límite y cero rechazos falsos. En el experimento "Operador Olvidadizo", la línea base de Python con condiciones de carrera excedió el límite 30/30 veces, mientras que la implementación afín de Rust excedió 0/30 veces.
Comparación con Alternativas de Tiempo de Ejecución: Cuando los operadores implementan correctamente el bloqueo en Python o Rust, el resultado de respeto al límite es idéntico al enfoque afín. El valor distintivo del tipo afín es que hace que el patrón incorrecto (con condiciones de carrera) sea imposible de compilar, eliminando la carga de la disciplina de concurrencia del operador.
Rendimiento del Estimador: El estimador de longitud de bytes estático por defecto reserva de 4 a 6 veces el costo real. El AdaptiveEstimator reduce esto a una mediana de 2.11× con una latencia insignificante, mientras que la estimación directa de tokenizadores logra aproximadamente 1.0× a costa de ~1 segundo de latencia por gasto.
Despliegue: Un único despliegue de producción en el framework Rig demostró el enfoque imponiendo un límite de sesión estricto a través de sub-agentes concurrentes con cero exceso.

Reivindicaciones y Significado
El artículo posiciona su contribución modestamente como un estudio de ingeniería de software empírica con un caso de estudio de sistemas específico:

Alcance de la Reivindicación: Los autores declaran explícitamente que no pretenden una prueba formal de solidez del límite a nivel binario (la Conjetura 1 permanece abierta). Las garantías de integridad son a nivel de fuente (impuestas por el verificador de préstamos en código tipado). El límite de dólares es una propiedad aritmética de tiempo de ejecución condicionada a las suposiciones del estimador (A1) y la veracidad del proveedor (A7).
Valor Primario: La significancia radica en abordar el modo de fallo M-budget-primitive-missing de manera estructural. Para los frameworks que carecen de un primitivo de presupuesto, una reimplementación en Rust usando token-budgets no puede regredir silenciosamente ni exponer el presupuesto únicamente mediante callbacks.
Limitaciones: El enfoque es específico para despliegues de agentes en Rust (una minoría del ecosistema actual). No resuelve la mala información de facturación del lado del proveedor, los tokens de razonamiento ocultos en modelos de razonamiento (serie OpenAI o-series, Anthropic extended-thinking), ni el presupuesto multi-inquilino entre procesos sin un servicio distribuido.
Conclusión: El artículo concluye que, si bien las alternativas de tiempo de ejecución pueden lograr el mismo resultado operacional si se escriben correctamente, la disciplina afín proporciona una garantía de "imposibilidad de elusión" contra el error del operador en la delegación multi-agente, convirtiéndola en el primitivo preferido para nuevos despliegues de agentes en Rust que requieran límites de sesión acumulativos. El catálogo sirve como evidencia de que estos modos de fallo recurren en todo el ecosistema independientemente del lenguaje de implementación.