Asana divide por 76 los costes del modelo con GPT‑6.1 Sol
Con GPT‑6 Astra en Codex, Asana logró un agente de navegador 76 veces más barato y 5 veces más rápido en las pruebas para ofrecer modelos más capaces a sus clientes.
76x
Menores costes estimados del modelo con el flujo de trabajo optimizado de GPT-6.1 Sol
5x
Ejecuciones del navegador más rápidas con el flujo de trabajo optimizado de GPT-6.1 Sol
0,47 $
Coste medio estimado del modelo con el flujo de trabajo optimizado de GPT-6.1 Sol
Con GPT‑6 Astra en Codex realizando experimentos, Asana optimizó el flujo de trabajo de su agente de navegador con GPT‑6.1 Sol para que costase 76 veces menos y fuese 5 veces más rápido.
Asana ayuda a sus clientes a automatizar el trabajo entre aplicaciones empresariales a través de StackAI(se abre en una ventana nueva), una plataforma que adquirió(se abre en una ventana nueva). Con StackAI, los clientes pueden crear flujos de trabajo que navegan por sitios web, rellenan formularios y recopilan información sin escribir código. A la escala de Asana, las pequeñas ineficiencias de estos flujos de trabajo se acumulan.
El doctor Frank Hidalgo, director tecnológico de StackAI en Asana, se propuso hacer que el agente de navegador fuese más rápido y económico de ejecutar. Pidió a GPT‑6 Astra en Codex que analizase el agente, probase mejoras y comparase los resultados. Un trabajo que, según sus cálculos, habría llevado uno o dos meses de forma manual se completó en aproximadamente una semana.
El estudio de Asana, con 144 ejecuciones(se abre en una ventana nueva), puso a prueba GPT‑6.1 Sol y otros tres modelos de vanguardia, denominados aquí modelos A, B y C. El flujo de trabajo optimizado con GPT‑6.1 Sol obtuvo un coste medio estimado del modelo de 0,47 $ y un tiempo de unos cuatro minutos por ejecución: 76 veces más barato y 5 veces más rápido que la configuración original en producción con el modelo B.
«Así funcionan en la práctica los equipos de personas y agentes. Un ingeniero marcó el rumbo, GPT-6 Astra realizó los experimentos y los resultados pasaron a producción a través de Command. Esto demuestra cómo Asana hace realidad los equipos de personas y agentes».
Para avanzar rápido, Hidalgo empezó utilizando GPT‑6 Astra en Codex para analizar la estructura del código y explicar cómo construía el agente cada solicitud al modelo. GPT‑6 Astra descubrió que el agente almacenaba en caché sus instrucciones fijas y las definiciones de las herramientas, pero no el historial creciente de texto de páginas y capturas de pantalla que recopilaba. Por eso, cada solicitud volvía a enviar ese historial a precio completo.
El agente también eliminaba capturas de pantalla antiguas y recortaba texto en casi todos los pasos. Cada modificación alteraba el historial, por lo que almacenarlo en caché no habría bastado. Además, perder esos datos podía obligar al agente a volver a visitar páginas que ya había leído.
Hidalgo revisó las soluciones propuestas por GPT‑6 Astra y eligió tres para probarlas:
Ampliar el almacenamiento en caché al historial de navegación del agente
Aumentar la cantidad de texto que podía conservar
Eliminar capturas de pantalla por lotes en lugar de hacerlo en cada paso
GPT‑6 Astra empezó con pruebas rápidas para determinar qué variables eran relevantes. Como el código no estaba diseñado para experimentos controlados, lo refactorizó para que un único frontend y backend pudiese admitir muchos flujos de trabajo en paralelo, cada uno con su propia configuración.
Astra realizó el estudio completo: límites de historial de 120 000 y 480 000 caracteres y seis políticas de caché y capturas de pantalla, cada una probada tres veces en cada uno de los cuatro modelos (consulta la tabla siguiente). La política que obtuvo los mejores resultados permitía acumular hasta 20 capturas de pantalla antes de conservar solo la más reciente. Así, el historial anterior se mantenía sin cambios durante periodos más largos entre eliminaciones. Esta política, combinada con el límite de historial más amplio, dio lugar al flujo de trabajo optimizado. Todas las configuraciones realizaban la misma tarea: recopilar seis campos de cada uno de los 32 libros de un catálogo público de demostración, una tarea representativa de lo que algunos clientes de Asana ejecutan en StackAI.
Modelo | Descripción | Precio |
|---|---|---|
Modelo A | Un modelo más pequeño y económico de otro laboratorio de IA de vanguardia, lanzado en otoño de 2025 | La mitad del precio de GPT‑6.1 Sol |
Modelo B | El modelo utilizado originalmente en producción, del mismo laboratorio que el modelo A, lanzado en verano de 2026 | El mismo precio que GPT‑6.1 Sol |
Modelo C | Una versión actualizada del modelo B, lanzada en otoño de 2026 | El mismo precio que GPT‑6.1 Sol |
GPT‑6.1 Sol | El modelo de OpenAI |
GPT‑6 Astra ejecutó los flujos de trabajo y examinó las solicitudes, los registros de uso y los resultados; otras sesiones del modelo revisaron el trabajo. Las solicitudes, las trazas de datos y los resultados de cada sesión se registraron en Command(se abre en una ventana nueva), la plataforma de entrega de software de Asana, para que el equipo pudiese revisar después el estudio completo. Desde Command, los hallazgos se convirtieron en tickets y después en solicitudes de incorporación de cambios; finalmente, los cambios pasaron a producción.
«Hacer esto a mano me habría llevado uno o dos meses. Con GPT-6 Astra en Codex, tardé aproximadamente una semana: fijaba un /goal antes de acostarme y revisaba los resultados por la mañana».
En el modelo B, la optimización redujo el coste estimado del modelo de al menos 36,21 $ (algunas ejecuciones originales alcanzaron el límite de pasos antes de terminar) a 1,24 $ por ejecución: un coste 29 veces menor. El flujo de trabajo optimizado con GPT‑6.1 Sol resultó aún más barato: 0,47 $, un coste 2,6 veces menor. Todas las ejecuciones del flujo de trabajo optimizado completaron la tarea y devolvieron la respuesta correcta.
Medias de 3 ejecuciones. ≥: la configuración base incluye ejecuciones detenidas por el límite, por lo que su media es un límite inferior.
Los dos factores de mejora de la derecha se comparan con el modelo B optimizado. El modelo B se ejecutó en la fase 1; el modelo C y Sol 6.1, en la fase 2 del mismo estudio (línea de puntos).
Solo en GPT‑6.1 Sol, con el límite de historial más amplio, la nueva política de caché y capturas de pantalla dividió el coste por 4, de 1,97 $ a 0,47 $ por ejecución. Cada llamada resultó unas 3 veces más barata, porque el 89 % de la entrada procedía de la caché y costaba el 5 % del precio de la entrada sin caché. Las ejecuciones también fueron más rápidas: pasaron de al menos 22,5 minutos con la configuración original del modelo B a unos cuatro minutos con el flujo de trabajo optimizado de GPT‑6.1 Sol.
Media de 3 ejecuciones, con barras de error de desviación estándar. ≥: la media incluye una ejecución detenida por el límite o sin finalizar, por lo que el valor real es al menos el indicado.
Las barras usan la paleta azul. Compara los efectos de la caché con la barra del límite ampliado a 480 000.
Los marcadores de ejecución y las barras de error de desviación estándar son reconstrucciones aproximadas de la imagen original; no se disponía de los valores de las ejecuciones ni de las desviaciones estándar subyacentes.
Media de 3 ejecuciones, con barras de error de desviación estándar. ≥: la media incluye una ejecución detenida por el límite o sin finalizar, por lo que el valor real es al menos el indicado.
Las barras usan la paleta azul. Compara los efectos de la caché con la barra del límite ampliado a 480 000.
Los marcadores de ejecución y las barras de error de desviación estándar son reconstrucciones aproximadas de la imagen original; no se disponía de los valores de las ejecuciones ni de las desviaciones estándar subyacentes.
La investigación también mostró cómo la gestión del historial influía en que el agente llegase a producir una respuesta. Dar a GPT‑6.1 Sol más espacio para conservar su historial de navegación aumentó el número de ejecuciones que producían una respuesta: de tres de 18 con el límite más pequeño a las 18 con el más amplio, todas con la respuesta correcta. Para Hidalgo, el valor empresarial reside en dar a los clientes acceso a modelos más rápidos y capaces, a la vez que se mantienen unos costes operativos sostenibles.
«Antes, el coste limitaba los modelos que podíamos ofrecer a los clientes para estas cargas de trabajo. Al hacer que el agente sea más eficiente, podemos ofrecer a los clientes un modelo mejor y más rápido, a la vez que reducimos nuestros costes operativos».
Asana ya ha implementado los cambios de navegación web en StackAI y está desarrollando herramientas para facilitar la repetición de experimentos similares. A largo plazo, el equipo planea incorporar estas pruebas a las evaluaciones de la plataforma, para que los clientes y los equipos internos puedan comparar el coste, el tiempo de ejecución y la calidad de las respuestas al configurar sus agentes.
«El cuello de botella ya no es la velocidad de entrega, sino la atención humana. Nos acercamos a un mundo en el que cada ingeniero es un responsable de producto al frente de una flota de agentes».
Asana utiliza ahora GPT‑6 Astra en Codex para probar funciones del producto antes de lanzarlas: Astra navega por la plataforma, prueba distintas entradas e informa de los errores al equipo humano de control de calidad. Hidalgo considera que esto sienta las bases de un nuevo ciclo de vida del desarrollo de software, con muchas sesiones de agentes en la nube probando funciones en paralelo.
El estudio completo está disponible en los blogs de Asana(se abre en una ventana nueva) y StackAI(se abre en una ventana nueva).
