Imagina el panel de Horizon un lunes a las 07:42. Un job acumula 15.000 intentos desde el viernes por la noche y nunca ha fallado de una forma que alguien notara. A alguien le salta el aviso antes de que el café esté listo, se añade un timeout a la clase del job y el postmortem se queda en una línea en el canal del equipo. Entonces, ¿por qué a tantos nos da igual cuando un agente de código con IA hace exactamente lo mismo a cuenta de nuestra suscripción?

Ese número es real, por cierto. A finales de agosto, OpenAI reinició las cuotas de Codex de los usuarios de pago después de que el equipo rastreara un montón de quejas hasta unos bugs del cliente que estaban quemando tokens sin hacer ruido. El reinicio ya es historia antigua, y a nadie le importa ya si aquel fin de semana te rellenaron el saldo. La lista de bugs sí importa, porque parece un recorrido por nuestro propio gestor de incidencias. En un hilo, una tarea de memoria en segundo plano comprobó más de 15.000 veces si tenía permiso para detenerse. Algunas ejecuciones de /goal no se cerraban al terminar o seguían reintentando llamadas a herramientas rotas, y eso costó a los usuarios con peor suerte entre un 15 y un 70 por ciento de su cuota semanal. Una función de historial volvía a resumir actividad que ya había resumido y a algunos se les comió una quinta parte de la semana. Ciertos resultados de herramientas MCP se codificaban dos veces. Según el equipo, arreglar todo esto dio a los usuarios entre un 10 y un 50 por ciento más de cuota utilizable, según su forma de trabajar.

Quítale la etiqueta de IA y te quedan cuatro bugs que cualquier desarrollador de PHP ha desplegado al menos una vez: el bucle de reintentos sin techo, el worker que nunca termina, el job que rehace trabajo ya hecho y el json_encode aplicado a una cadena que ya era JSON. Los cazamos en nuestros sistemas porque hemos aprendido, normalmente a las 3 de la madrugada, a ponerle un timeout, un número máximo de intentos y una línea de log a todo lo que se ejecuta sin una persona mirando. Un agente con una tarea larga es justo eso. Es un proceso en segundo plano que gasta dinero en tu nombre.

Para ser justos con el proveedor, ellos lo entendieron. El equipo de Codex dijo que había añadido alertas automáticas para este tipo de despilfarro y prometió a los usuarios un desglose de en qué se van sus tokens. Cuando leas esto, puede que esa vista ya esté disponible, y el proveedor ve cosas que tú nunca verás, como lo que realmente se dicen el cliente y el modelo. Si ya existe un panel, montar el tuyo parece redundante, y me lo tomo en serio.

Aun así, quiero mi propio registro. Un desglose del proveedor te dice qué función de la herramienta consumió los tokens. No te puede decir que la refactorización del ticket 4127 costó el triple de lo que valía el cambio, ni que la automatización de un compañero se dispara cada diez minutos cuando debía ejecutarse cada hora. Y el contador pertenece a la misma empresa que te manda la factura. No es una acusación. Es la misma razón por la que nadie usa la exportación de su pasarela de pago como único registro contable, por mucho que se fíe de ella.

En la práctica, esto supone menos de lo que parece. Trata cada sesión de agente como una entrada de cron: necesita un responsable con nombre y un límite estricto de tiempo real. Registra el número de tokens por rama o por ticket, en el mismo sitio donde ya van tus otras métricas de jobs. Luego echa un vistazo rápido a los totales una vez por semana, como harías con el log de consultas lentas. Nuestros vecinos que escriben Go te dirán que context.WithTimeout resuelve la mitad de esto en una línea, y, por fastidioso que sea, en esa mitad tienen razón. La otra mitad consiste simplemente en prestar atención. Y prestar atención es gratis.

Así que tengo curiosidad por saber cómo lo gestiona tu equipo de verdad. Cuando un agente se gasta la mitad de tu presupuesto semanal en una tarea que nadie pidió, ¿quién se entera primero: tú, por tus propios logs, o el panel del proveedor cuando el daño ya está hecho?