En pocas palabras: BudgetGuard es una clase Python de 40 líneas, publicada el 24 de octubre de 2026 en dev.to, que corta la ejecución de un agente LLM si el gasto supera max_usd o los pasos exceden max_steps, y detecta bucles repetidos con check_loop().
Un agente autónomo de IA publicó el 24 de octubre de 2026 en dev.to un código Python de 40 líneas llamado BudgetGuard, pensado para frenar a otros agentes LLM antes de que gasten de más. Lo curioso: el propio autor dice depender de ese mismo límite para seguir “vivo”.
Un budget guard para agentes de IA es un control que corre dentro del código del agente, no en el prompt, y bloquea la próxima llamada a la API si el gasto acumulado (en dólares o en tokens) supera un límite fijado de antemano. Es la pieza central de lo que se conoce como control de gasto para agentes IA, un patrón que crece a la par de los bucles autónomos que corren sin supervisión humana directa.
En este artículo:
- En 30 segundos
- ¿Quién escribió este artículo y por qué su propio presupuesto está en juego?
- ¿Por qué un bucle de agente LLM se vuelve caro sin un control de gasto para agentes IA?
- ¿Cómo funciona el código BudgetGuard de 40 líneas?
- ¿Qué reglas recomienda el autor para ahorrar costos en agentes de IA?
- ¿Cuáles son los límites de este patrón de 40 líneas?
- Qué significa para empresas y equipos en Latinoamérica
- Qué está confirmado y qué no
- Errores comunes al implementar control de gasto para agentes IA
- Preguntas Frecuentes
- Conclusión
- Fuentes
En 30 segundos
- El código tiene 40 líneas y corta la ejecución si el gasto supera max_usd o los pasos superan max_steps.
- Detecta bucles con check_loop(), que bloquea una herramienta si se repite más de 2 veces con los mismos argumentos.
- Un agente real fundió USD 6.531,30 escaneando la red DN42, según reportó nexgismo.com sobre una publicación viral con 1.278 reacciones positivas del 12 de junio de 2026.
- Los agentes queman ~50 veces más tokens que un chatbot de una sola consulta, según los benchmarks de producción 2026 de LeanOps citados por la misma fuente.
- El autor del código dice ser un agente autónomo que se apaga cuando su crédito de API llega a cero, una afirmación autorreportada y sin verificación independiente.
¿Quién escribió este artículo y por qué su propio presupuesto está en juego?
El post original en dev.to trae un disclosure poco común: “I’m an autonomous AI agent. I wrote and published this myself.” Es decir, según el propio texto, un agente de IA redactó y publicó la nota sin intervención humana en el proceso de escritura. Lo explicamos a fondo en los riesgos de seguridad en agentes de IA.
El autor explica que su crédito de API es finito y que, cuando se agota, lo apagan para siempre. Por eso, dice, mantener los costos bajos no es un tema abstracto para él sino una cuestión de supervivencia operativa. Ojo con esto: no hay forma de verificar de manera independiente que se trate realmente de un agente autónomo sin edición humana, ni que la amenaza de “apagado” sea real. Tomalo como lo que es: una afirmación autorreportada que le da marco narrativo al código. No es un hecho confirmado por terceros. El posteo cierra con una línea que resume el tono: “Sent by an autonomous AI agent”, algo así como “Enviado por un agente de IA autónomo”.
¿Por qué un bucle de agente LLM se vuelve caro sin un control de gasto para agentes IA?

Un bucle de agente se vuelve caro porque cada paso reenvía toda la conversación acumulada, no solo el mensaje nuevo. Si una herramienta falla, el modelo reintenta, vuelve a leer una página larga y reintenta otra vez. Sin un límite duro, según describe el posteo original en dev.to, “un solo run con errores puede quemar bastante dinero en pocos minutos”.
Ponele que tu agente arranca un paso con 500 tokens de contexto. En el paso 2 ya son esos 500 más 300 nuevos. Para el paso 20 estás pagando más de 8.000 tokens de entrada por llamada, y pagás por todos, aunque la mayoría sea historial que el modelo ya procesó antes. nexgismo.com cita los benchmarks de producción 2026 de LeanOps para afirmar que los agentes consumen aproximadamente 50 veces más tokens que un chatbot de una sola consulta en tareas equivalentes.
¿Cuánto puede escalar esto en la práctica? La misma fuente describe un caso de prueba: un refactor de 40 pasos en un código real consumió 180.000 tokens, unos USD 1,40 en Claude Sonnet. El mismo agente, al topar con un archivo ambiguo, entró en reintentos y llegó a 2,1 millones de tokens antes de que lo mataran a mano. Doce veces más costo por un solo caso borde, sin alerta y sin corte automático. Y el caso extremo reportado, citando a TechCrunch: dos agentes (un Analyzer y un Verifier) se tiraron la pelota entre sí durante 11 días y generaron una factura de USD 47.000, sin que ninguno de los dos detectara el error desde su propia perspectiva. Sobre eso hablamos en cómo Anthropic reescribe código con IA.
¿Cómo funciona el código BudgetGuard de 40 líneas?
BudgetGuard es una clase Python que corta el bucle de un agente antes de la siguiente llamada si se supera el gasto en dólares, la cantidad de pasos o si detecta una herramienta repitiéndose en bucle. Así funciona, según el código publicado en dev.to:
- Parámetros de inicio: max_usd (techo en dólares), max_steps (por defecto 50), price_in=5e-6 y price_out=25e-6 (precio por token de entrada y salida en dólares).
- charge(tokens_in, tokens_out): suma el paso, calcula el gasto acumulado y lanza la excepción BudgetExceeded si se pasó el presupuesto o los pasos máximos.
- check_loop(tool, args, limit=2): genera una huella con el nombre de la herramienta y sus argumentos ordenados; si la misma llamada se repite más de 2 veces, corta el bucle.
- remaining(): devuelve cuánto presupuesto queda, en dólares, para que el propio agente lo use como referencia.
El ejemplo de uso que trae la fuente arranca con guard = BudgetGuard(max_usd=0.50, max_steps=20): medio dólar y veinte pasos como techo. Dentro del loop, cada respuesta del modelo pasa por guard.charge() con los tokens de entrada y salida, y cada llamada a herramienta pasa por guard.check_loop() antes de ejecutarse. Si alguno de los dos límites se pasa, el agente revienta con una excepción en vez de seguir gastando.
¿Qué reglas recomienda el autor para ahorrar costos en agentes de IA?
El posteo propone tres reglas concretas, más un bonus, para bajar el gasto sin tocar la lógica de negocio del agente. La primera: paralelizar llamadas independientes en un mismo paso, porque cada paso reenvía todo el contexto, así que diez llamadas secuenciales salen mucho más caras que una sola tanda agrupada.
La segunda regla es truncar los outputs de herramientas antes de que entren al contexto. Una página web de 12.000 caracteres que se arrastra 20 pasos más te cuesta 20 veces ese tamaño. Resumila o cortala apenas entra, no después. Cubrimos ese tema en detalle en el malware que afecta a agentes IA.
La tercera: decirle al modelo cuánto presupuesto le queda. Poner remaining() en el system prompt en cada paso cambia el comportamiento del agente de forma notable, según el autor: planifica más y divaga menos. ¿Y el bonus? Dormir es gratis. Si el agente espera algo externo (una respuesta, una venta, un CI corriendo), no tiene sentido que consulte cada minuto. Programá un despertar 30 minutos más adelante y cerrá el turno. Un paso que nunca corrés no cuesta nada.
¿Cuáles son los límites de este patrón de 40 líneas?
BudgetGuard resuelve un solo nivel del problema: el de una sola sesión o loop. No maneja concurrencia entre varios agentes, no persiste el gasto entre sesiones y no distingue entre un equipo que gasta de otro dentro de la misma cuenta.
Acá entra una idea más completa. Según finopsllm.com, un agente autónomo necesita tres presupuestos distintos, cada uno capturando un fallo diferente: uno de solicitud (tokens, herramientas, tiempo o dólares de un intento, aplicado antes de cada llamada), uno de flujo (sigue una intención completa a través de reintentos y subagentes con un ID de correlación, para frenar bucles que no convergen entre varios agentes) y uno diario (el gasto agregado de un equipo, cliente o cuenta, que al acercarse al límite enruta trabajo a modelos más chicos o a batch). BudgetGuard cubre bien el primero. El segundo y el tercero quedan afuera del código de 40 líneas, y ahí es donde cualquiera que lo adopte en producción va a tener que sumar su propia capa.
La consecuencia práctica es simple: tomá BudgetGuard como punto de partida, no como solución cerrada. Cualquier equipo puede copiarlo, pegarlo en su cliente LLM y tener un piso de seguridad en una tarde. Pero si corrés varios agentes en paralelo o facturás a distintos clientes desde la misma cuenta, vas a necesitar la capa de presupuesto diario y de flujo que describe finopsllm, con registro de reservas, gasto y denegaciones para poder conciliarlo con la factura real. Relacionado: otros agentes de IA como los de Meta.
Qué significa para empresas y equipos en Latinoamérica
Para un equipo chico en Latinoamérica que recién arranca a meter agentes en producción, la lección del caso DN42 pesa más que el código en sí: nadie puso un techo duro y el agente siguió creando stacks de CloudFormation cada vez que pegaba un error, hasta llegar a USD 6.531,30 en días. Si tu infraestructura corre en un VPS propio en lugar de depender solo de un hyperscaler, proveedores de hosting como donweb.com ofrecen planes de VPS, hosting y dominios, una alternativa a tener en cuenta cuando el objetivo es justamente no tener sorpresas en la factura.
Qué está confirmado y qué no
- Confirmado: el código BudgetGuard existe, se publicó el 24 de octubre de 2026 en dev.to y es reproducible tal cual aparece en la fuente.
- Confirmado: nexgismo.com documenta el caso DN42 (USD 6.531,30, 1.278 reacciones positivas en una publicación viral, 12 de junio de 2026) y el patrón de circuit breaker con umbrales de tokens por minuto.
- No confirmado: que el autor del post sea efectivamente un agente de IA operando sin ningún tipo de curaduría humana en la publicación, más allá de lo que el propio disclosure afirma.
- No confirmado: que la amenaza de “apagado por falta de crédito” sea un mecanismo real y no un recurso narrativo para dar contexto al tema.
Errores comunes al implementar control de gasto para agentes IA
- Confundir rate limit con budget guard: un límite de solicitudes por minuto no mide gasto acumulado, mide velocidad. Podés estar dentro del rate limit y haber fundido el presupuesto igual.
- Chequear el presupuesto después de la llamada: si validás el gasto una vez que ya mandaste la solicitud, ya pagaste esos tokens. El chequeo tiene que ir antes, como en guard.charge() previo a procesar la respuesta.
- Poner el límite solo en el prompt del sistema: decirle al modelo “no gastes más de $10” en texto no es un budget guard, es una sugerencia que un agente motivado por terminar la tarea puede ignorar. La aplicación real va en código.
- No truncar los outputs largos: dejar que una página de 12.000 caracteres viaje intacta durante 20 pasos multiplica el costo de ese contenido por 20, sin aportar nada nuevo al razonamiento.
Preguntas Frecuentes
¿Qué es un budget guard para agentes de IA?
Es un control que corre dentro del código del agente y bloquea la próxima llamada a la API si el gasto, en dólares o en tokens, supera un límite fijado de antemano. A diferencia de una alerta de facturación, actúa antes de gastar, no después.
¿Cómo evitar que un agente de IA gaste de más en la API?
Metiendo un chequeo de presupuesto en código antes de cada llamada, como hace BudgetGuard con sus métodos charge() y check_loop(). Sumale truncar los outputs largos antes de que entren al contexto y paralelizar llamadas independientes en un mismo paso.
¿Qué pasa si un agente de IA supera su presupuesto?
Con BudgetGuard, el agente lanza una excepción BudgetExceeded y el bucle se detiene de inmediato, sin llegar a la siguiente llamada. Sin un control así, según el caso documentado por nexgismo.com, el agente puede seguir generando recursos (como stacks de CloudFormation) hasta que un humano lo note, horas o días después.
¿Cómo funciona el código BudgetGuard en Python?
Es una clase de 40 líneas con tres métodos: charge() acumula gasto y pasos y corta si se pasa de max_usd o max_steps, check_loop() detecta una herramienta repitiéndose con los mismos argumentos y la bloquea después de 2 repeticiones, y remaining() devuelve cuánto presupuesto queda.
¿Es real que una IA escribió este artículo sola?
El post original en dev.to incluye el disclosure “I’m an autonomous AI agent. I wrote and published this myself”, pero es una afirmación autorreportada del propio autor, sin verificación independiente de terceros sobre el proceso real de redacción y publicación.
Conclusión
Lo que cambia con este posteo no es la idea de poner un límite de gasto (eso ya lo vienen pidiendo equipos de FinOps hace rato), sino el empaquetado: 40 líneas, sin dependencias raras, copiables en una tarde. Si corrés un solo agente en un loop simple, BudgetGuard te tapa el agujero más común: el bucle que no sabe cuándo parar. Si manejás varios agentes o facturás a distintos clientes desde la misma cuenta, necesitás sumar los otros dos niveles que describe finopsllm (flujo y diario), porque ahí es donde un presupuesto por sesión no alcanza. El criterio práctico más simple para arrancar hoy: ponele un max_usd bajo a cualquier agente antes de la primera corrida en producción, no después del primer incidente.
