Asana reduce costos 76 veces en pruebas web con GPT‑6.1 Sol
Con GPT‑6 Astra en Codex, Asana logró que su agente de navegador costara 76 veces menos y fuera 5 veces más rápido en pruebas para ofrecer modelos más capaces a sus clientes.
76x
Menores costos estimados del modelo con el flujo de trabajo optimizado de GPT-6.1 Sol
5x
Ejecuciones de navegador más rápidas con el flujo de trabajo optimizado de GPT-6.1 Sol
$0,47
Costo promedio estimado del modelo con el flujo de trabajo optimizado de GPT-6.1 Sol
Con GPT‑6 Astra en Codex a cargo de los experimentos, Asana optimizó el flujo de trabajo de su agente de navegador con GPT‑6.1 Sol para ejecutarlo a un costo 76 veces menor y 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 nueva ventana), una plataforma que adquirió(se abre en una nueva ventana). Con StackAI, los clientes pueden crear flujos de trabajo que navegan por sitios web, completan 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 Dr. Frank Hidalgo, director de tecnología de StackAI en Asana, se propuso lograr que el agente de navegador fuera más rápido y económico de ejecutar. Le pidió a GPT‑6 Astra en Codex que investigara el agente, probara mejoras y comparara los resultados. Un trabajo que, según sus estimaciones, habría llevado entre uno y dos meses de forma manual se completó en aproximadamente una semana.
El estudio de Asana de 144 ejecuciones(se abre en una nueva ventana) 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 resultante con GPT‑6.1 Sol promedió $0,47 en costos estimados del modelo y unos cuatro minutos por ejecución: un costo 76 veces menor y una velocidad 5 veces mayor que la configuración original de producción con el modelo B.
“Así funcionan los equipos de humanos y agentes en la práctica. Un ingeniero marcó el rumbo, GPT-6 Astra ejecutó los experimentos y los resultados pasaron por Command hasta llegar a producción. Esto demuestra cómo Asana hace realidad los equipos de humanos y agentes”.
Para avanzar rápido, Hidalgo empezó por usar GPT‑6 Astra en Codex para explorar la estructura del código base y explicar cómo el agente construía cada solicitud al modelo. GPT‑6 Astra descubrió que el agente almacenaba en caché sus instrucciones fijas y definiciones de herramientas, pero no el historial creciente de texto de páginas y capturas de pantalla que recopilaba. Por eso, cada solicitud reenviaba ese historial al precio completo.
El agente también eliminaba capturas antiguas y recortaba texto en casi todos los pasos. Cada cambio 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 probar:
Extender 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 comenzó con pruebas rápidas para determinar qué variables importaban. Como el código no estaba diseñado para experimentos controlados, luego lo refactorizó para que un solo frontend y backend pudieran admitir muchos flujos de trabajo en paralelo, cada uno con su propia configuración.
Astra llevó a cabo todo el estudio: 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 a continuación). La política con el mejor rendimiento permitía acumular 20 capturas de pantalla antes de conservar solo la más reciente. Esto mantenía el historial anterior sin cambios durante períodos más largos entre eliminaciones. Combinada con el mayor límite de historial, esta política dio lugar al flujo de trabajo optimizado. Cada configuración realizaba la misma tarea: recopilar seis campos para 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 vanguardia, lanzado en el otoño boreal de 2025 | La mitad del precio de GPT‑6.1 Sol |
Modelo B | El modelo usado originalmente en producción, del mismo laboratorio que el modelo A, lanzado en el verano boreal de 2026 | El mismo precio que GPT‑6.1 Sol |
Modelo C | Una versión actualizada del modelo B, lanzada en el otoño boreal 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 las salidas; otras sesiones del modelo revisaron el trabajo. Las solicitudes, trazas de datos y resultados de cada sesión se registraron en Command(se abre en una nueva ventana), la plataforma de entrega de software de Asana, para que el equipo pudiera revisar el estudio completo después. Desde Command, los hallazgos se convirtieron en tickets y luego en solicitudes de incorporación de cambios, y los cambios pasaron a producción.
“Esto me habría llevado entre uno y dos meses de forma manual. Con GPT-6 Astra en Codex, tomó alrededor de una semana: establecía un /goal antes de acostarme y revisaba los resultados por la mañana”.
En el modelo B, la optimización redujo el costo estimado del modelo de al menos $36,21 (algunas ejecuciones originales alcanzaban el límite de pasos antes de terminar) a $1,24 por ejecución: una reducción de 29 veces. El flujo de trabajo optimizado con GPT‑6.1 Sol tuvo un costo 2,6 veces menor aún: $0,47. Todas las ejecuciones del flujo de trabajo optimizado completaron la tarea y devolvieron la respuesta correcta.
Promedios de 3 ejecuciones. ≥: la configuración base incluye ejecuciones detenidas por un límite, por lo que su promedio 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 punteada).
Solo en GPT‑6.1 Sol, con el mayor límite de historial, la nueva política de caché y capturas de pantalla redujo el costo 4 veces, de $1,97 a $0,47 por ejecución. Cada llamada costaba aproximadamente un tercio, porque el 89 % de la entrada provenía de la caché y se cobraba al 5 % del precio de la entrada sin caché. Las ejecuciones también se volvieron más rápidas: de al menos 22,5 minutos con la configuración original en el modelo B a unos cuatro minutos con el flujo de trabajo optimizado en GPT‑6.1 Sol.
Promedio de 3 ejecuciones, con barras de error de desviación estándar. ≥: el promedio incluye una ejecución detenida por un límite o sin terminar, por lo que el valor real es al menos igual al indicado.
Las barras usan una paleta azul. Compara los efectos de la caché con la barra del mayor límite de historial (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 ejecución ni de las desviaciones estándar subyacentes.
Promedio de 3 ejecuciones, con barras de error de desviación estándar. ≥: el promedio incluye una ejecución detenida por un límite o sin terminar, por lo que el valor real es al menos igual al indicado.
Las barras usan una paleta azul. Compara los efectos de la caché con la barra del mayor límite de historial (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 ejecución ni de las desviaciones estándar subyacentes.
La investigación también mostró cómo la gestión del historial influía en si el agente llegaba a producir una respuesta. Darle a GPT‑6.1 Sol más espacio para conservar su historial de navegación aumentó la cantidad de ejecuciones que producían una respuesta: de tres de 18 con el menor límite de historial a las 18 con el mayor límite, todas con la respuesta correcta. Para Hidalgo, el valor empresarial está en dar a los clientes acceso a modelos más rápidos y capaces, manteniendo costos operativos sostenibles.
“Antes, el costo limitaba los modelos que podíamos ofrecer a los clientes para estas cargas de trabajo. Al hacer más eficiente el agente, podemos ofrecer a los clientes un modelo mejor y más rápido, y al mismo tiempo reducir nuestros costos operativos”.
Asana ya implementó los cambios de navegación web en StackAI y está desarrollando herramientas para facilitar la repetición de experimentos similares. Con el tiempo, el equipo planea incorporar estas pruebas a las evaluaciones de la plataforma, para que los clientes y equipos internos puedan comparar el costo, el tiempo de ejecución y la calidad de las respuestas al configurar sus agentes.
“La velocidad de entrega ya no es el cuello de botella; lo es la atención humana. Estamos cerca de un mundo en el que cada ingeniero es un gerente de producto que lidera una flota de agentes”.
Asana ahora usa GPT‑6 Astra en Codex para probar funciones del producto antes de lanzarlas: Astra navega por la plataforma, prueba distintas entradas e informa errores a los revisores humanos de control de calidad. Hidalgo ve esto como la base de un nuevo ciclo de vida del desarrollo de software, con muchas sesiones de agentes en la nube que prueban funciones en paralelo.
El estudio completo está disponible en los blogs de Asana(se abre en una nueva ventana) y StackAI(se abre en una nueva ventana).
