Los rodeos de la IA que no deberías pagar

No es que las empresas líderes en IA necesariamente dejaran de manipular las condiciones al vendernos tokens si pudieran salirse con la suya: Anthropic aplicó en junio un incremento efectivo del 30 % en el precio; DeepSeek subió los precios de su API en agosto; y OpenAI dio marcha atrás a una reducción de la asignación de tokens de su plan intermedio a finales de septiembre. Así que ahora está bastante clara la tendencia hacia la austeridad.

En efecto, esa idea suele volver a la mente cuando tu agente de IA agota tu asignación diaria de tokens en una ráfaga de 45 minutos de código no necesariamente glorioso y te dice que vuelvas dentro de 3-4 horas. En un momento tan frustrante, es inevitable preguntarse si algunos de los mecanismos que intervienen en ese proceso están sesgados a favor de los proveedores. Al fin y al cabo, es una buena manera de conseguir que paguemos un paquete adicional de tokens o incluso que activemos la «recarga automática».

Bueno, si realmente fuera así, en este momento las empresas pioneras podrían escudarse con bastante credibilidad en la idea de que no entendemos del todo cómo se usan los tokens en las cargas de trabajo con agentes, entre distintos modelos y entornos de ejecución. Y ellas tampoco. Salvo por sus sistemas de procesamiento de pagos (que sí son muy fluidos), todo está en una fase prealfa y sigue siendo materia de investigación de vanguardia, pese a la amplia mercantilización del producto.

Gestión del desperdicio

El hecho de que los agentes de IA desperdicien tokens (y, por tanto, tu dinero) al razonar en flujos de trabajo con agentes está ya ampliamente demostrado: hace exactamente un año escribí sobre nuevas investigaciones que indicaban hasta qué punto los modelos de IA con capacidad de razonamiento tendían a consumir tokens con divagaciones; a principios de este año, sobre nuevas investigaciones que señalaban que el razonamiento en cadena de pensamiento era «decorativo»; y la semana pasada, Nils Bunge, director de Producto de Tsuga, afirmó en un artículo de liderazgo intelectual publicado aquí:

«Un equipo que consume el doble de tokens no necesariamente genera el doble de valor. Puede que esté realizando un trabajo más difícil, utilizando un modelo innecesariamente potente o dependiendo de un agente que vuelve a intentar una y otra vez tareas fallidas».

Lo que se conoce menos es la forma en que se desperdician tokens en tareas o procesos innecesarios; este es el tema de un nuevo artículo que hoy volvió a llamar mi atención sobre el tema.

Titulado ¿Cómo desperdician tu dinero los agentes de IA?, este nuevo trabajo de colaboración académica estadounidense* propone un marco unificado capaz de cuantificar cuánto desperdician realmente los procesos con agentes. Cuando los modelos son de código cerrado, una metodología «en la sombra» se combina con las estadísticas y métricas oficiales de los proveedores para ofrecer un relato equivalente, paso a paso, de lo que ocurrió con los tokens mientras la IA razonaba y actuaba:

El nuevo método para medir el desperdicio de tokens de IA. Se registran el razonamiento, las acciones y los costos de cada agente; luego, se analizan para detectar repeticiones, solicitudes innecesarias y rodeos evitables. Se elimina el desperdicio detectado y se vuelve a comprobar si el agente puede completar la tarea original. Fuente

Como se muestra arriba, se permite que el agente trabaje con normalidad mientras se interceptan y registran sus comunicaciones con el proveedor de IA, incluidos los casos de razonamiento, uso de herramientas, consumo de tokens y costos. Después, jueces basados en Large Language Model (LLM) examinan los registros para separar el trabajo útil de las repeticiones, las búsquedas innecesarias y los rodeos. A continuación, se elimina el desperdicio sospechado, se calculan los tokens ahorrados y se reanuda el trabajo del agente para comprobar si todavía puede completar la tarea con éxito.

En las pruebas, los investigadores descubrieron que se desperdiciaba alrededor de un 18 % de los tokens de salida de los agentes. En más del 45 % de las tareas, un agente desperdició más tokens de los que otro necesitó para completar con éxito el mismo trabajo. También descubrieron que eliminar entre el 41 y el 46 % del razonamiento innecesario tenía muy poco efecto en el rendimiento, lo que sugiere que es posible lograr ahorros sustanciales sin comprometer significativamente los resultados.

El artículo afirma:

«En el conjunto de trayectorias recopiladas, se identifica como desperdicio aproximadamente el 18 % de los tokens de salida.

«Sorprendentemente, en más del 45 % de las tareas, los tokens de salida desperdiciados por un solo agente superan la totalidad de los tokens de salida de otro agente que resuelve con éxito la misma tarea».

Además, el estudio descubrió que los agentes desperdiciaban más recursos al familiarizarse con herramientas desconocidas y probar enfoques que finalmente no conducían a ninguna parte; también constató que aumentar el esfuerzo de razonamiento no produce mejoras constantes: con el esfuerzo al máximo, se observó que Kimi-K3 generaba 6,6 veces más tokens de razonamiento que con un esfuerzo bajo, sin que eso garantizara mejores resultados.

Resultados de pruebas que muestran el rendimiento de Kimi-K3 con cuatro niveles de esfuerzo de razonamiento en cinco pruebas de referencia. Un mayor esfuerzo de razonamiento no mejoró sistemáticamente las tasas de éxito, y el esfuerzo máximo a veces produjo peores resultados que los niveles inferiores.

A modo de analogía, en lugar de conducir un automóvil potente sin llegar nunca a aprovechar realmente sus capacidades, estas sesiones con agentes se parecen más a conducir un automóvil que acelera hasta alcanzar su velocidad máxima en cada trayecto, aunque eso no aporte ningún beneficio y pese a las posibles consecuencias negativas.

El artículo también examina el papel de los distintos entornos de ejecución en el desperdicio de tokens y concluye que el mismo modelo de IA, Kimi-K3, podía generar más de cuatro veces la cantidad de razonamiento para las mismas tareas, según el entorno utilizado, sin que necesariamente obtuviera mejores resultados.

Parte del desperdicio se atribuyó a fallos básicos del software: se descubrió que OpenCode, Kimi Code CLI y OpenClaw iniciaban repetidamente tareas en el entorno de Python equivocado, lo que provocaba errores y nuevos intentos que consumían tokens. Kimi Code CLI también permitía que la IA solicitara tiempos de espera que el propio software rechazaba, lo que obligaba a realizar más intentos costosos.

Contra lo que cabría esperar, los entornos que ofrecían más herramientas no eran necesariamente más proclives al desperdicio, y algunas ineficiencias recurrentes parecían originarse en los propios modelos, con independencia del entorno que los controlara.

‘[Several] las propiedades aparentemente obvias de los entornos no explican sistemáticamente las diferencias observadas en el desperdicio. Por ejemplo, como se muestra [below], los entornos que ofrecen más herramientas no son necesariamente más proclives al desperdicio. OpenClaw ofrece muchas más herramientas que los demás entornos y, aun así, presenta un nivel moderado de desperdicio. Además, no todo el desperdicio varía según el entorno.

‘[Below right] demuestra que, en SWE-bench Verified, Kimi-K3 se desvía reiteradamente por un camino en el que escribe lo que considera la solución original del proyecto y luego la abandona. ‘

Resultados de pruebas que comparan los tokens desperdiciados en distintos entornos para agentes de IA. Izquierda: ofrecer más herramientas no necesariamente aumenta el desperdicio. Derecha: Kimi-K3 intenta repetidamente aplicar una supuesta solución original de software y la abandona, independientemente del entorno, pero rara vez lo hace en otro tipo de tarea.

Como medida correctiva, los autores sugieren que los entornos de los agentes deberían reconocer cuándo las restricciones del entorno hacen imposible seguir avanzando, comunicar claramente esas limitaciones al modelo de IA y detener la ejecución, en lugar de permitir que los intentos fallidos repetidos consuman más tokens. También proponen utilizar sus mediciones de los tokens desperdiciados para mejorar el entrenamiento de los modelos, las estrategias de razonamiento y el diseño de los entornos.

Metodología

Para reconstruir la actividad de un agente de IA, los investigadores siguieron cada intercambio entre el modelo y el software que lo controlaba, y registraron su razonamiento, sus respuestas, las solicitudes de herramientas y el costo en tokens. El nivel de detalle variaba según el proveedor: Kimi-K3 revela todo su proceso de razonamiento; Gemini 3.1 Pro, solo resúmenes; y Claude no revela nada.

Los resultados de cada herramienta se devolvían al agente, lo que permitía a los investigadores seguir el proceso hasta su finalización o hasta que se alcanzara su límite operativo.

Cuatro ejemplos de cómo gastan tokens los agentes de IA. Repetir información conocida, realizar búsquedas idénticas y añadir disculpas innecesarias se consideran desperdicio; en cambio, una búsqueda infructuosa no es necesariamente un desperdicio, ya que el agente podría haber tenido buenos motivos para intentarla.

Las solicitudes de los agentes se canalizaron a través de un proxy para hacer un seguimiento de su actividad; solo hicieron falta cambios menores en el código y cada solicitud se etiquetó con su prueba de referencia, ejecución, tarea y ensayo (salvo en OpenClaw, que no admite esas etiquetas; en ese caso, se utilizó un proxy independiente, basado en LiteLLM, para cada prueba).

Cuatro actores

El estudio define el desperdicio de tokens mediante cuatro patrones recurrentes: Reformulación (repetir información conocida); Recuperación duplicada (repetir solicitudes innecesarias a herramientas); Relleno (añadir texto irrelevante); y Desvío (seguir enfoques plausibles pero que, en última instancia, no dan resultado).

Cada sesión registrada fue examinada por un LLM como juez (LLMaJ**), al que se le proporcionaron la tarea original, el registro completo y los criterios para identificar los cuatro patrones de desperdicio. Se marcaron y eliminaron los tokens que se consideraron desperdiciados, y se volvieron a contar los restantes para calcular la proporción y el costo del desperdicio. Luego, los recuentos se verificaron con los tokenizadores o las herramientas de conteo propios de cada proveedor y con el uso de salida declarado (se informaron únicamente diferencias menores de formato).

Pruebas

Los modelos evaluados en el estudio fueron Kimi-K3, Gemini 3.1 Pro, GPT-5.6 Terra, GPT-6 Astra, Claude Sonnet 5 y Claude Fable 5.1. Se probaron con los siguientes conjuntos de referencia: τ²-bench (atención al cliente de aerolíneas y comercios minoristas), SWE-bench Verified (ingeniería de software), Claw-Eval y MCP-Atlas (uso de herramientas de propósito general).

Además, Kimi-K3 se probó con distintos niveles de razonamiento y se compararon cinco entornos de agentes: OpenCode, OpenClaw, OpenHands, Hermes y Kimi Code CLI. Estas últimas comparaciones se utilizaron para evaluar cómo influyen en el desperdicio de tokens los modelos, las tareas, el esfuerzo de razonamiento y el diseño del entorno; en otras pruebas también se eliminó el desperdicio que se consideró tal para comprobar su efecto en el rendimiento.

Para determinar cuánto dinero desperdiciaba cada modelo, se comparó el costo del texto y las llamadas a herramientas innecesarios con el costo total de salida, y se promediaron los resultados de los cuatro conjuntos de referencia. El razonamiento interno se evaluó por separado en el caso de Kimi-K3, el único modelo que exponía su proceso de razonamiento completo:

Resultados de las pruebas que comparan el costo de salida desperdiciado en seis modelos de IA, con el promedio de cuatro conjuntos de referencia. Izquierda: tasas generales de desperdicio, con el razonamiento interno de Kimi-K3 mostrado por separado. Derecha: tasas de desperdicio en tareas completadas con éxito y tareas fallidas; en general, las fallidas generaron más desperdicio.

Como se muestra arriba, se estimó que entre el 11 % y el 24,9 % del dinero gastado en generar respuestas y usar herramientas se había desperdiciado; GPT-6 Astra obtuvo los mejores resultados y Claude Sonnet 5, los peores. En el caso de Kimi-K3, se desperdició alrededor de uno de cada seis tokens en respuestas y uso de herramientas, cifra que superó uno de cada cuatro durante el razonamiento interno.

En general, se observó más desperdicio cuando las tareas no se completaban, aunque lo contrario ocurrió con el razonamiento de Kimi-K3; tampoco hubo pruebas claras de que gastar más tokens en trabajo innecesario aumentara las probabilidades de éxito.

En otra prueba, se intentó reducir los tokens desperdiciados mientras la IA aún trabajaba: en cada paso, se usó un juez de IA** para eliminar la información repetida y el texto superfluo del razonamiento del modelo antes de permitir que la tarea continuara:

Resultados de las pruebas que muestran cómo afectó la eliminación de razonamiento innecesario de la IA a las tasas de éxito en dos conjuntos de referencia. Eliminar entre el 41 % y el 46 % del razonamiento tuvo poco efecto en el rendimiento, mientras que eliminarlo por completo provocó muchas más fallas.

En SWE-bench Verified, se eliminó el 41 % del razonamiento sin que disminuyera el rendimiento; de hecho, la tasa de éxito subió ligeramente, del 89 % al 89,5 %. En MCP-Atlas, se eliminó el 46 % y el éxito solo bajó moderadamente, del 65 % al 62,3 %.

En otras palabras, casi la mitad del razonamiento podía descartarse mientras la IA trabajaba sin perjudicar seriamente su capacidad para terminar la tarea.

Por último^†, se probó Kimi-K3 con tareas idénticas en distintos entornos de agentes. En este caso, la cantidad de razonamiento generado varió más de cuatro veces, sin que hubiera una mejora constante del rendimiento, como se muestra a continuación:

Resultados de las pruebas que comparan el consumo de tokens de Kimi-K3 en distintos entornos de agentes y dos conjuntos de referencia. El razonamiento interno aparece en azul, y las respuestas y llamadas a herramientas, en naranja. En las tareas de programación, Mini-SWE generó más de cuatro veces la cantidad de razonamiento que Hermes.

Parte del desperdicio se atribuyó a errores básicos de software. OpenCode, Kimi Code CLI y OpenClaw ejecutaron las pruebas de programación en un entorno de Python incorrecto, lo que provocó errores y nuevos intentos.

Conclusión

Esto no es más que un vistazo a un artículo cuya extensión y meticulosidad metodológica bien podrían justificar una lectura más detenida.

El tema sí me hizo pensar en algo que tengo muy presente: la enorme brecha entre lo que nosotros y los proveedores de modelos de frontera entendemos realmente sobre estos procesos, y la disposición de las empresas a presentar el producto como si hubiera pasado los últimos tres meses por una herramienta de análisis estático y hubiera superado la prueba con gran éxito.

Tal como están las cosas, por ahora, si se producen malos resultados, no podemos culpar actualmente a nadie más que a nosotros mismos, porque estamos comprando un producto que casi todos sabemos que es profundamente experimental e impredecible.

* Con contribuciones expresamente iguales de University of Illinois Urbana-Champaign, Northeastern University, University of California (Los Angeles) y un investigador independiente.

* El artículo no identifica qué modelo se utilizó, por lo que alcanzo a discernir.

^† Para este artículo, no para el artículo de investigación, que es más largo de lo que suelo permitirme cubrir y contiene más pruebas y profundidad de las que podemos incluir aquí. Consulte el PDF de la fuente, enlazado arriba, para obtener más detalles.

Publicado por primera vez el viernes 6 de noviembre de 2026