Las pruebas del agente de navegador de Asana reducen los costes de modelo 76 veces con GPT-6.1 Sol
Asana afirma que su agente de navegador pasó a ser 76 veces más barato y cinco veces más rápido después de que sus ingenieros modificaran cómo retenía y almacenaba en caché el historial de navegación. Las pruebas del agente de navegador de Asana utilizaron GPT-6 Astra en Codex para investigar el sistema, ejecutar experimentos y analizar trazas. Posteriormente, GPT-6.1 Sol ofreció el menor coste estimado de modelo dentro del flujo de trabajo optimizado.
El resultado principal parece una victoria del modelo. El hallazgo más importante se refiere a la arquitectura del agente. Asana modificó cuándo el agente eliminaba capturas de pantalla, amplió su límite de historial y almacenó en caché el registro creciente de pasos previos. Estos cambios redujeron el procesamiento repetido mientras preservaban la información que el agente necesitaba para completar su tarea.
Esta distinción es relevante para cualquier empresa que evalúe agentes de navegador. Un equipo puede cambiar a un modelo menos costoso y seguir desperdiciando tokens debido a una mala gestión del contexto. También puede elegir un modelo más capaz, conservar el historial adecuado y reducir los costes operativos totales. El experimento de Asana enfrenta directamente ambas estrategias.
El estudio del agente de navegador de Asana cambió más que el modelo
Las mayores mejoras de Asana provinieron de rediseñar el flujo de trabajo en torno al modelo, no simplemente de sustituir un modelo por otro.
La empresa publicó los resultados el 8 de octubre de 2026, seguidos de un caso de estudio de OpenAI el 9 de octubre. El trabajo se centró en un agente de navegador dentro de StackAI, la plataforma de automatización sin código que Asana adquirió a principios de 2026.
StackAI permite a los clientes crear agentes que navegan por sitios web, recopilan información y completan formularios en aplicaciones empresariales. Estos flujos de trabajo se parecen a la navegación humana, pero el agente subyacente envía repetidamente instrucciones, herramientas, texto de páginas, capturas de pantalla y acciones anteriores a un modelo.
Ese contexto repetido genera un patrón costoso. Cada nuevo paso incluye más historial que el anterior. Si el contenido previo sigue cambiando, un proveedor no puede reutilizar de forma fiable su representación almacenada en caché.
El agente original de Asana almacenaba en caché instrucciones fijas y definiciones de herramientas. No almacenaba eficazmente en caché el creciente historial de navegación. El agente también eliminaba capturas de pantalla antiguas y recortaba texto con frecuencia, alterando partes anteriores de la solicitud.
Estas modificaciones rompían el prefijo estable, es decir, el inicio sin cambios compartido por solicitudes consecutivas al modelo. Una vez que ese prefijo cambiaba, gran parte del historial de navegación tenía que procesarse de nuevo.
Frank Hidalgo, director de tecnología de StackAI en Asana, encargó a GPT-6 Astra en Codex que inspeccionara este comportamiento. El modelo trazó el mapa de la base de código, revisó cómo se ensamblaban las solicitudes e identificó variables que valía la pena probar.
Asana afirma que el estudio resultante incluyó 144 ejecuciones principales en cuatro modelos de frontera. Probó seis políticas de caché y capturas de pantalla, dos límites de historial y tres ejecuciones para cada condición. Más tarde, la empresa realizó un seguimiento más pequeño.
Cada configuración recibió la misma tarea. El agente de navegador debía recopilar seis campos para cada uno de 32 libros de un catálogo público de demostración. Esto implicaba encontrar 192 datos y mantener suficiente contexto para devolver una respuesta final correcta.
Los modelos incluían GPT-6.1 Sol y tres alternativas anonimizadas. Asana denominó a esos sistemas Modelos A, B y C. El Modelo B impulsaba la configuración original de producción, mientras que el Modelo C representaba un modelo más reciente del mismo proveedor.
Asana no reveló esos proveedores, lo que limita las comparaciones competitivas directas. Sin embargo, indicó que el flujo de trabajo optimizado con GPT-6.1 Sol costaba 76 veces menos que la configuración original del Modelo B. También finalizó aproximadamente cinco veces más rápido.
Desde entonces, la empresa ha incorporado los cambios de navegación del navegador en StackAI. Esto transforma el ejercicio de una comparación de laboratorio en un cambio de producción, aunque Asana no ha publicado datos amplios de rendimiento a nivel de cliente.
Por qué el almacenamiento en caché de prompts se convirtió en el mecanismo decisivo
La variable decisiva fue si el agente podía mantener sin cambios la mayor parte de su historial acumulado entre llamadas.
El almacenamiento en caché de prompts guarda el estado computacional reutilizable asociado a un prefijo de prompt sin cambios. Las solicitudes posteriores pueden reutilizar ese estado en lugar de procesar el mismo material desde el principio.
La caché no almacena una respuesta final para reproducirla. El modelo sigue procesando material nuevo y genera una respuesta nueva. Simplemente evita repetir trabajo para el contexto elegible que permanece idéntico.
La guía de almacenamiento en caché de prompts de OpenAI recomienda colocar las instrucciones estables y el material de referencia antes del contenido cambiante. También aconseja que las aplicaciones añadan el historial de conversación en lugar de reescribir repetidamente los turnos anteriores.
El diseño original de Asana infringía ese segundo principio durante las ejecuciones del navegador. En casi cada paso, eliminaba una captura de pantalla anterior y, en ocasiones, recortaba texto más antiguo. Por tanto, la siguiente solicitud difería en mitad de su historial.
Almacenar en caché solo el prompt de sistema fijo no podía abarcar la mayor fuente de entrada repetida. El agente de navegador acumulaba texto de páginas, capturas de pantalla, observaciones y resultados de herramientas a medida que avanzaba en la tarea.
Asana probó una política diferente llamada poda por lotes. La poda consiste en eliminar contexto antiguo antes de que el historial acumulado se vuelva demasiado grande. Con la política seleccionada, el agente conservaba hasta 20 capturas de pantalla antes de reducir el conjunto a la más reciente.
Este enfoque creó tramos más largos de historial de solo adición. El agente podía añadir nuevas observaciones al final sin modificar el contenido anterior en cada paso. Por ello, una mayor parte de cada solicitud seguía siendo elegible para reutilización.
El flujo de trabajo optimizado también aumentó el límite de historial de texto de 120.000 caracteres a 480.000 caracteres. Esto dio al agente más espacio para conservar datos recopilados previamente en lugar de descartarlos.
El límite mayor tuvo un efecto importante en la finalización. Con el ajuste de historial más pequeño, GPT-6.1 Sol produjo una respuesta en solo tres de 18 ejecuciones. Con el ajuste más amplio, respondió en las 18 ejecuciones, según Asana.
Asana afirma que cada una de esas ejecuciones con mayor historial devolvió la respuesta correcta. El resultado cuestiona la suposición de que reducir agresivamente el contexto siempre mejora la eficiencia de los agentes.
Eliminar contexto reduce el tamaño inmediato de una solicitud. Sin embargo, puede obligar a un agente a volver a visitar páginas, repetir llamadas a herramientas o continuar sin evidencia recopilada previamente. También puede impedir la reutilización de la caché cuando la eliminación modifica el prefijo de la solicitud.
Por tanto, la mejor política depende de la economía total de la tarea. Los equipos deben considerar el procesamiento de entrada, la navegación repetida, las tasas de finalización, la calidad de las respuestas y la recuperación tras ejecuciones fallidas.
Asana informó que el 89 por ciento de la entrada de GPT-6.1 Sol provenía de la caché en la configuración optimizada. Esa proporción explica por qué un modelo más capaz podía convertirse en la opción menos costosa probada para la tarea completa.
Este es el mecanismo central detrás del resultado del agente de navegador de Asana. La empresa no se limitó a pedir a un modelo que utilizara menos tokens. Reorganizó el flujo de trabajo para que los tokens repetidos fueran más baratos de procesar.
Más contexto ayudó al agente a finalizar de forma fiable
El experimento sugiere que la solicitud más barata no siempre forma parte del flujo de trabajo completado más barato.
Los creadores de agentes suelen tratar el contexto como un recurso que debe minimizarse. Esta visión tiene sentido porque los prompts largos aumentan el procesamiento de entrada y pueden acercarse al límite de contexto de un modelo.
Los agentes de navegador complican el cálculo. Sus observaciones anteriores funcionan como memoria de trabajo. Eliminar una dirección, un atributo de producto, una advertencia o un resultado de navegación puede impedir que el agente complete su respuesta final.
El límite de historial más pequeño produjo resultados especialmente débiles para algunos modelos. Asana informa de que el Modelo C no devolvió ninguna respuesta en 18 ejecuciones bajo esa condición. GPT-6.1 Sol solo devolvió tres respuestas.
Estos fallos no demostraban que los modelos carecieran de capacidad general de navegación. El mayor límite de historial cambió el resultado. Ambos modelos respondieron en todas las ejecuciones después de recibir suficiente espacio para conservar el registro necesario.
El resultado respalda un principio de ingeniería más amplio. La política de contexto debe ajustarse al modelo y a la tarea. Un límite universal de tokens no producirá un comportamiento equivalente en sistemas distintos.
Los modelos pueden consumir contexto a ritmos diferentes porque generan descripciones, llamadas a herramientas y trazas de razonamiento distintas. Un agente puede alcanzar un umbral de poda tras un número reducido de acciones. Otro puede continuar durante mucho más tiempo.
Asana descubrió que los modelos más recientes o más capaces no utilizaban automáticamente el límite menor de forma más eficiente. El Modelo C empezó a recortar el historial mucho antes que el Modelo A durante el flujo de trabajo probado.
El experimento también reveló que el almacenamiento en caché por sí solo era insuficiente. Con el límite de historial mayor, el almacenamiento en caché sin poda por lotes costó más que no usar caché en tres de cuatro modelos.
Este resultado parece contradictorio hasta que se considera la estructura de la solicitud. Una caché ofrece un valor limitado cuando la aplicación reescribe constantemente el material que desea reutilizar. El sistema paga por procesar el historial cambiante sin obtener suficientes aciertos futuros de caché.
La política seleccionada por Asana alineó tres decisiones. Almacenó el historial en caché, preservó una secuencia de solo adición durante periodos más largos y proporcionó un límite mayor antes de que fuera necesario recortar.
Un seguimiento planteó otra cuestión. Asana probó configuraciones que conservaban todas las capturas de pantalla en lugar de podarlas. Algunas ofrecieron costes por llamada inferiores a los de la política seleccionada durante esta tarea concreta.
La empresa no interpretó esto como prueba de que la poda deba desaparecer. Los flujos de trabajo más largos pueden superar los límites de contexto, mientras que algunos proveedores cobran más por las operaciones de caché. Un agente que se desvía hacia una navegación innecesaria también necesita límites firmes.
Asana recomienda límites para pasos, tokens y coste total de ejecución. Estos límites evitan que un agente incorrecto o confundido expanda indefinidamente su historial. La compactación, que sustituye el historial antiguo por un resumen más corto, ofrece otra opción.
La compactación introduce su propia compensación. Reduce el tamaño del contexto, pero cambia el prompt anterior, lo que puede interrumpir la reutilización de la caché. Un resumen también puede omitir un detalle que más adelante se vuelva importante.
Por este motivo, los equipos necesitan registros fuera del prompt activo. Asana registró solicitudes, trazas y resultados en Command, su plataforma de entrega de software. Después, ingenieros y agentes adicionales pudieron revisar el experimento completo.
Un registro duradero también respalda una base de conocimiento con capacidad de búsqueda. El agente activo recibe únicamente el contexto necesario para su paso actual, mientras que los revisores conservan acceso a toda la cadena de evidencia.
Esta separación ayuda a los equipos a distinguir la memoria del modelo de la memoria organizativa. El contexto de trabajo de un agente debe seguir siendo acotado. El registro del experimento debe conservar suficiente detalle para reproducir decisiones e investigar fallos.
GPT-6 Astra convirtió el trabajo de evaluación en una tarea para agentes
Asana utilizó un modelo para mejorar el sistema y otro para ejecutar el flujo de trabajo de producción optimizado.
GPT-6 Astra trabajó dentro de Codex como agente de investigación e ingeniería. GPT-6.1 Sol sirvió como uno de los modelos de ejecución del agente de navegador. Tratar ambos como funciones separadas evita una interpretación engañosa de los resultados.
Hidalgo estableció la dirección de la investigación y seleccionó los cambios propuestos que valía la pena probar. GPT-6 Astra inspeccionó el código, instrumentó las solicitudes, realizó pruebas preliminares e identificó variables influyentes.
El código existente no estaba diseñado para comparaciones controladas. Asana afirma que el agente Codex refactorizó el sistema para que un frontend y backend compartidos pudieran admitir varios flujos de trabajo experimentales en paralelo.
GPT-6 Astra lanzó entonces el estudio, analizó los registros de uso y comparó los resultados. Sesiones independientes del modelo revisaron partes del trabajo, mientras los humanos evaluaron las conclusiones y aprobaron los cambios para producción.
Asana estima que el proyecto habría requerido uno o dos meses de trabajo manual. Con el flujo de trabajo de Codex, la investigación llevó aproximadamente una semana.
Esa afirmación procede de la empresa, no de una evaluación independiente. También describe un proyecto de ingeniería dirigido por un ejecutivo técnico familiarizado con el sistema. Otros equipos no deberían asumir la misma reducción de plazos.
Aun así, el flujo de trabajo ilustra un cambio significativo en el uso de agentes de programación. El agente no se limitó a implementar una función a partir de una especificación terminada. Ayudó a diseñar y ejecutar una investigación empírica.
La investigación generó trazas, resultados experimentales, tickets y pull requests. Esos artefactos pasaron por Command antes de que los cambios llegaran a producción en StackAI.
Ese proceso importa más que la afirmación de que un agente de IA realizó la mayor parte del trabajo mecánico. Sin registros estables, los revisores no pueden determinar con fiabilidad qué configuración se ejecutó, por qué falló o si una mejora comunicada sobrevivió a los cambios de código.
El estudio de Asana afirma que los humanos establecieron el objetivo y los estándares de evaluación. También revisaron los hallazgos. El agente de programación amplió la cantidad de experimentación que el equipo podía ejecutar entre esas decisiones.
Hidalgo describió una rutina de fijar un objetivo antes de irse a dormir y revisar los resultados a la mañana siguiente. Ese patrón asíncrono convierte el tiempo de ejecución del agente en un recurso de ingeniería.
También desplaza el cuello de botella. Cuando resulta fácil generar experimentos, los humanos deben dedicar más tiempo a seleccionar preguntas válidas, comprobar las mediciones y descartar conclusiones engañosas.
El riesgo es el ruido experimental automatizado. Un agente puede producir muchas ejecuciones sin generar evidencia sólida. Las pruebas repetidas siguen siendo vulnerables al diseño de los benchmarks, a variaciones ocultas de las tareas y a errores de puntuación.
Asana redujo parte de ese riesgo utilizando una tarea fija y una respuesta de referencia preparada de forma independiente. También registró los propios contadores de uso del proveedor en vez de estimar el consumo de tokens a partir de la longitud del texto.
La empresa realizó solo tres repeticiones para la mayoría de las configuraciones. Asana afirma explícitamente que el estudio revela patrones generales, no diferencias fiables de unos pocos puntos porcentuales.
Esa salvedad es importante. Las comparaciones de 76x y 5x son lo bastante grandes como para justificar atención, pero combinan cambios de arquitectura y de modelo. No aíslan una ventaja universal de GPT-6.1 Sol.
Los resultados internos de Asana muestran que el Modelo B también mejoró considerablemente tras recibir el flujo de trabajo optimizado. La arquitectura explicó una parte importante de la ganancia antes de que GPT-6.1 Sol redujera aún más los costes.
Lo que la afirmación de 76x no demuestra
Los resultados publicados constituyen evidencia de ingeniería convincente, pero no son un benchmark neutral del mercado de agentes de navegador.
El estudio utilizó una tarea estructurada en un catálogo público de libros. Cada ejecución siguió el mismo objetivo y recopiló el mismo conjunto de campos. La navegación empresarial real suele incluir autenticación, diseños cambiantes, instrucciones ambiguas y recuperación ante diálogos inesperados.
Un flujo de trabajo que destaca en la extracción repetitiva podría comportarse de otro modo en compras, soporte, cumplimiento normativo u operaciones internas. Esas tareas pueden requerir criterio entre varios sistemas, en lugar de la recopilación repetida desde páginas similares.
La prueba del agente de navegador de Asana también comparó GPT-6.1 Sol con tres modelos anonimizados. Los lectores no pueden inspeccionar la configuración específica de cada proveedor ni determinar cómo funcionaría cada alternativa tras una optimización independiente.
Asana afirma que los Modelos B, C y GPT-6.1 Sol tenían precios estándar comparables durante el estudio. El Modelo A se presentó como una alternativa menos costosa. El artículo público no identifica sus nombres.
Ese anonimato impide que el resultado se convierta en una clasificación clara de modelos. También protege el estudio de derivar hacia comparaciones entre proveedores que no cuentan con suficientes pruebas que las respalden.
El mayor titular compara el flujo de trabajo optimizado de GPT-6.1 Sol con la configuración original de producción del Modelo B. Dos variables cambiaron a la vez: el modelo y la arquitectura del agente.
Una comparación más acotada halló una reducción de costes de cuatro veces al aplicar la nueva política dentro de GPT-6.1 Sol. La diferencia restante provino de comparar ese sistema optimizado con la línea base de producción más antigua.
Eso no debilita el resultado. Cambia la conclusión. El estudio respalda combinar modelos capaces con una arquitectura consciente del contexto, no tratar un cambio de modelo como la solución completa.
La mejora de cinco veces en el tiempo de ejecución conlleva salvedades similares. Algunas ejecuciones originales del Modelo B alcanzaron un límite de pasos antes de completarse. Por ello, su duración medida representa un límite inferior para la tarea completa.
La calidad de finalización también necesita observación continua. Asana informa que todas las ejecuciones en las mejores condiciones encontraron los hechos requeridos y produjeron respuestas correctas. El material público no incluye cargas de trabajo de clientes ni tasas de error a largo plazo.
La replicación independiente sigue siendo limitada porque el estudio completo depende de la implementación y las trazas de Asana. La empresa compartió sus métodos y un estudio más completo, pero los equipos externos aún necesitan sus propias suites de tareas.
La adquisición de StackAI por parte de la empresa también genera un interés comercial en el resultado. Asana completó la adquisición de StackAI en mayo de 2026 para ampliar los flujos de trabajo de agentes entre sistemas.
OpenAI tiene un interés similar en mostrar cómo GPT-6 Astra y GPT-6.1 Sol respaldan agentes empresariales. Ambas fuentes primarias aportan valiosos detalles técnicos, pero ninguna representa una auditoría independiente del sector.
Las condiciones operativas también pueden cambiar el resultado. La disponibilidad de caché tiene una vida útil limitada. Los clientes simultáneos pueden tener historiales distintos, y el contexto personalizado puede reducir la cantidad de material compartido.
Los requisitos de privacidad pueden restringir qué contenido entra en el contexto del modelo. Los equipos de seguridad también necesitan controles para capturas de pantalla, credenciales, registros de clientes e información sensible recopilada durante la navegación.
El almacenamiento en caché no elimina esas obligaciones. Cambia el comportamiento de cómputo y facturación, no la necesidad de gobernanza de datos. Los equipos siguen necesitando políticas de retención, controles de acceso, trazas de auditoría y gestión de fallos.
Por tanto, la conclusión correcta es condicional. Asana encontró una optimización de alto valor para un agente de navegador específico y la llevó a producción. Otros equipos deberían tratar el mecanismo como una hipótesis comprobable.
La próxima prueba es el rendimiento en flujos de trabajo reales de clientes
Las siguientes tres señales mostrarán si el resultado de Asana se convierte en un modelo operativo reutilizable o sigue siendo un sólido caso de estudio interno.
La primera señal es una cobertura de evaluación más amplia. Asana afirma que está desarrollando herramientas que permitan a clientes y equipos internos comparar costes, tiempo de ejecución y calidad de las respuestas al configurar agentes.
Esas evaluaciones necesitan tareas que vayan más allá de la extracción estructurada de catálogos. Las suites de prueba útiles deberían incluir sitios web cambiantes, aplicaciones autenticadas, fallos parciales, rutas de navegación largas e instrucciones con puntos de finalización ambiguos.
Si la misma política de historial mejora esos flujos de trabajo, el argumento a favor de la optimización guiada por la arquitectura se fortalecerá. Si las ganancias se reducen, la configuración elegida por Asana podría estar estrechamente vinculada a la extracción repetitiva.
La segunda señal es la evidencia de adopción en producción. Asana ya ha incorporado los cambios de navegación del navegador a StackAI, pero no ha publicado resultados agregados de clientes.
La tasa de finalización debería importar más que el coste por llamada. Una solicitud más barata ofrece poco valor si los clientes deben volver a ejecutar trabajos o reparar manualmente resultados incompletos.
Los equipos también deberían vigilar la proporción de entradas atendidas desde caché, la duración mediana de las tareas, los fallos por límite de pasos y las tasas de intervención humana. Esas métricas revelan si el diseño optimizado resiste un tráfico de producción variable.
La tercera señal es cómo responden los proveedores de modelos y las plataformas de agentes competidoras. El almacenamiento en caché de prompts se ha convertido en una función de producto, pero la arquitectura de la aplicación determina si los desarrolladores pueden beneficiarse de ella.
Los proveedores pueden competir mediante una retención de caché más prolongada, mejores diagnósticos, menores tarifas para entradas en caché y datos de uso más claros. Los frameworks de agentes pueden exponer políticas de historial sin obligar a cada cliente a crear instrumentación personalizada.
OpenAI posiciona GPT-6.1 Sol como un modelo para trabajo agéntico capaz con un menor coste operativo que GPT-6 Astra. El estudio de Asana ofrece un ejemplo concreto de aplicación para ese posicionamiento.
Sin embargo, la presión competitiva más fuerte recae sobre los equipos de software de agentes. Los clientes esperarán cada vez más que las plataformas optimicen automáticamente el coste total de las tareas, en lugar de exponer únicamente un selector de modelos.
Una plataforma madura debería recomendar límites de contexto basados en el comportamiento observado. Debería identificar ediciones que rompen la caché, comparar políticas y advertir cuando la poda hace que el agente vuelva a visitar páginas anteriores.
También debería conservar suficiente evidencia externa para que los humanos puedan auditar el resultado. Un agente de navegador necesita una memoria de trabajo limitada, mientras que la organización necesita un registro operativo completo.
Asana planea incorporar pruebas similares a su sistema de evaluación. También está utilizando GPT-6 Astra en Codex para navegar por las funciones del producto, probar distintas entradas e informar de errores a revisores humanos.
Esa ampliación extiende la historia más allá de un único agente de navegador. Asana está probando si los agentes de ingeniería pueden evaluar continuamente a otros agentes y funciones de producto.
La oportunidad es clara. La experimentación automatizada puede evaluar más configuraciones de las que un pequeño equipo de ingeniería podría probar manualmente. También puede acortar el camino desde el análisis de trazas hasta cambios de código revisados.
La limitación es igual de clara. La atención humana se convierte en el recurso escaso cuando los agentes pueden generar experimentos, hallazgos y parches de forma continua. Los equipos deben decidir qué resultados merecen confianza y exposición en producción.
Para los desarrolladores, la acción inmediata es medir tareas completas en lugar de llamadas aisladas. Registren proporciones de aciertos de caché, calidad de finalización, tiempo de ejecución, reintentos y trabajo humano de reparación en condiciones realistas.
Para los compradores empresariales, pregunten a los proveedores cómo gestionan sus agentes los historiales crecientes. El nombre de un modelo por sí solo no revela si el sistema circundante conserva contexto útil o paga repetidamente por procesarlo.
Para los trabajadores del conocimiento, el cambio promete una automatización de navegador más rápida y capaz. Su valor dependerá de si los agentes pueden conservar los hechos necesarios sin exponer datos sensibles ni desviarse por pasos innecesarios.
El resultado del agente de navegador de Asana presenta un caso persuasivo de que el diseño de contexto ahora debe acompañar a la selección de modelos en toda evaluación de agentes. La siguiente pregunta es si esa lección se mantiene en los flujos de trabajo complejos que los clientes realmente quieren automatizar.
