Asana redujo 76 veces el coste de su browser agent al corregir el historial

Asana probó un browser agent con cuatro modelos y descubrió que su problema más caro no estaba en el razonamiento. El agente modificaba continuamente partes anteriores del historial y anulaba su propia cache.

Un historial estable redujo cada ejecución a 0,47 dólares

El agente original eliminaba capturas y recortaba texto antiguo durante la tarea. Cada cambio alteraba el prefijo común del prompt, de modo que el proveedor volvía a cobrar a precio completo buena parte de la entrada.

Asana añadió el historial creciente a la cache, elevó su límite de 120 000 a 480 000 caracteres y pasó a eliminar capturas por lotes. En la mejor configuración, GPT-6.1 Sol leyó el 89 % de la entrada desde cache. Cada ejecución costó una media de 0,47 dólares, 76 veces menos, y terminó cinco veces más rápido que la configuración original de producción con el Modelo B anonimizado.

Medir la infraestructura aportó más que cambiar de modelo

El estudio evaluó seis políticas de historial, dos límites y tres repeticiones por condición. Fueron 144 ejecuciones más 12 pruebas posteriores, con el objetivo de recuperar 192 datos en cada caso.

La lección para los equipos es concreta: el coste del agente también se decide en la capa de aplicación. Un prefijo estable, un límite adecuado y métricas de cache reads pueden cambiar la economía sin otro fine-tuning ni un modelo menos capaz.

El titular de 76 veces mezcla optimización y cambio de modelo

La comparación enfrenta la configuración original del Modelo B con GPT-6.1 Sol ya optimizado. Manteniendo Sol constante, la nueva política redujo el coste cuatro veces, de 1,97 a 0,47 dólares. Los autores advierten además que tres o cuatro ejecuciones por condición muestran tendencias amplias, no pequeñas diferencias porcentuales.

Un historial mayor tampoco elimina los riesgos. Si el agente se desvía o falla la reutilización de cache, la factura vuelve a crecer. Siguen siendo necesarios límites de pasos, tokens y coste por ejecución.

Las tareas largas y cambiantes dirán si el resultado se sostiene

Asana afirma que los cambios ya funcionan en browser navigation de StackAI. La señal útil llegará con tareas que superen los 480 000 caracteres, recorran páginas cambiantes o duren mucho más de cuatro minutos.

Los equipos deberían medir juntos el coste por tarea completada, la proporción de cache reads, los pasos y la calidad. Así sabrán si la mejora sobrevive fuera de un catálogo de libros cuidadosamente instrumentado.

El veredicto de Lilith

Asana encontró una factura de 36 dólares donde un agente reescribía sin parar su propio cuaderno. A veces el problema más caro del modelo es una aplicación pulsando Delete.