Resultado 76x del agente de navegador de GPT-6.1 Sol: lo que Asana midió en realidad

Asana publicó un estudio de costos de agentes de navegador el 8 de octubre de 2026, y el desarrollador de GPT-6.1 Sol lo redactó al día siguiente bajo el titular «Asana recorta los costos del modelo 76x en pruebas de navegador con GPT-6.1 Sol». Ese 76x es real en el sentido de que alguien lo midió, pero no es un hecho sobre el precio de GPT-6.1 Sol. Es un hecho sobre lo que ocurre cuando se corrige una caché de prompts rota en un agente de navegador y luego se cambia el modelo que está detrás. La misma optimización, ejecutada sobre el modelo que Asana ya tenía en producción —un modelo al que llama Model B—, recortó el costo 29x por sí sola. GPT-6.1 Sol aportó el 2.6x restante. Los experimentos los ejecutó GPT-6 Astra trabajando en Codex, y el modelo detrás de la línea base es un modelo de la competencia al que Asana llama Model B, así que en la historia aparecen dos niveles del mismo proveedor y un rival sin nombre. Lo que sigue separa la parte del resultado que puedes copiar el lunes de la parte que pertenece al stack particular de Asana.

La comparación, expresada exactamente

El stack de Asana para esto es StackAI, la plataforma de automatización de flujos de trabajo que adquirió, que ejecuta un agente de navegador que navega por sitios web, rellena formularios y recopila información sin necesidad de código. La tarea de prueba era acotada y concreta: recopilar seis campos de cada uno de los 32 libros de un catálogo de demostración público. Eso es representativo de lo que ejecutan algunos clientes y, además, es lo bastante pequeño como para que un estudio de 144 ejecuciones quepa en una semana.

El diseño consistió en seis políticas de caché y capturas de pantalla con dos presupuestos de historial, tres ejecuciones por condición, en cuatro modelos — 144 ejecuciones, más un seguimiento de 12 ejecuciones. Los costes se calcularon a partir de los propios contadores de tokens de cada proveedor, y cada respuesta se puntuó frente a una referencia preparada de forma independiente. Los cuatro modelos eran tres modelos frontera sin nombre (los modelos A, B y C) y GPT-6.1 Sol. El modelo A es un modelo más pequeño y más barato de otro laboratorio, lanzado en otoño de 2025, con un precio de la mitad que GPT-6.1 Sol. El modelo B es el modelo que estaba en producción, del mismo laboratorio que A, lanzado en verano de 2026, con el mismo precio que GPT-6.1 Sol. El modelo C es una versión más reciente del modelo B, lanzada en otoño de 2026, también con el mismo precio que GPT-6.1 Sol. Los tres no tienen nombre en ninguno de los dos informes, así que la comparación no es reproducible por quien lee — conviene saberlo antes de tratar 29x como un número sobre el modelo de otra persona. Estas son cifras publicadas por Asana y OpenAI, no auditadas de forma independiente.

La escalera de resultados, todas cifras propias de Asana:

• Producción de referencia en Model B — al menos $36.21 por ejecución, al menos 22.5 minutos por ejecución. Algunas ejecuciones de referencia alcanzaron el límite de pasos antes de finalizar, por lo que la media es un mínimo y no un promedio real.

• Model B, agente optimizado — $1.24 por ejecución, 4 veces más rápido que la referencia, una reducción de costos de 29 veces.

• GPT-6.1 Sol, el mismo agente optimizado — $0.47 por ejecución, unos cuatro minutos, una reducción de costos de 76x y 5 veces más rápido.

• GPT-6.1 Sol, antes frente a después de la corrección — de $1.97 a $0.47 por ejecución, una reducción de 4x solo con cambios en caché y poda.

Como la línea base es un límite inferior, 76x es en sí mismo un piso. La lectura honesta es "al menos 76x", no "76x".

Qué cambió en realidad y por qué no es una característica del modelo

El mecanismo es la mecánica de la caché de prompts, y vale la pena entenderlo porque se aplica a cualquier agente que ejecutes en cualquier modelo. Un agente de navegador reenvía sus herramientas, su prompt de sistema y su historial creciente de texto de páginas y capturas de pantalla en cada llamada al modelo. El almacenamiento en caché de prompts aplica un descuento a la parte repetida, pero solo al prefijo sin cambios más largo; en cuanto algo cambia en medio de la solicitud, la reutilización se rompe a partir de ese punto.

El agente de producción de Asana tenía dos fallos que se agravaban mutuamente. Cachaba sus instrucciones fijas y las definiciones de sus herramientas, pero no su historial de navegación. Y editaba ese historial en casi cada paso: descartaba la captura de pantalla anterior cada vez y recortaba el texto más antiguo para ajustarse a un presupuesto de historial. Cada edición invalidaba el prefijo, de modo que el caché habría sido casi inútil aunque se hubiera activado. El informe de Asana señala que, en los modelos probados, las lecturas de caché costaban entre 0,05 y 0,1 veces el precio estándar de entrada, así que el premio era grande y el agente lo estaba rechazando sistemáticamente.

La solución tiene dos partes. Primero, almacena también el historial en caché, con un marcador de caché en el resultado de herramienta más reciente. Segundo, deja de editarlo en cada llamada: conserva las capturas de pantalla y las poda en lotes a una proporción de 20 a 1, de modo que el agente retenga hasta 20 y luego recorte hasta la más reciente. Unas 19 llamadas consecutivas reutilizan entonces un prefijo sin cambios. Aumenta el presupuesto de historial de 120.000 a 480.000 caracteres para que el texto antiguo deje de recortarse, y las cuentas cuadran: en GPT-6.1 Sol, cada llamada costó aproximadamente 3 veces menos porque el 89 % de la entrada provino de la caché.

El hallazgo más importante aquí es uno negativo. Almacenar en caché el historial sin poda por lotes, con el presupuesto mayor, costó más que no almacenar en caché en absoluto en tres de los cuatro modelos — la caché se reescribía continuamente y rara vez se leía. La infraestructura de caché que se activa sin una disciplina de historial de solo añadir es una forma de pagar una prima de escritura a cambio de nada. Ese modo de fallo es independiente del modelo, y es la razón por la que la misma corrección movió el Model B en 29x.

Dónde la elección del modelo realmente valió la pena

Deja de lado la corrección del flujo de trabajo y compara lo comparable: con el mismo agente optimizado, GPT-6.1 Sol resultó 2,6 veces más barato que Model B, al mismo precio de lista. El factor adicional es el comportamiento de aciertos de caché, no la tarifa. Sol leyó el 89 % de su entrada desde la caché; Asana no publica la proporción equivalente para Model B, por lo que el 2,6x es un resultado medido sin un desglose publicado. Interprétalo como «este modelo, con esta carga de trabajo, aprovechó mejor su caché», no como una ventaja general de 2,6x sobre un modelo que no podemos nombrar.

El lado del runtime es inequívoco: 5 veces más rápido que la línea base, con el flujo de trabajo optimizado de Sol en aproximadamente cuatro minutos frente a una línea base de al menos 22,5 minutos. La velocidad importa para el costo en agentes que facturan por token, porque un modelo lento que entra en bucles paga por sus bucles.

Para quien esté calculando esto: las tarifas estándar de la API de GPT-6.1 Sol son $2.00 por millón de tokens de entrada, $0.10 por millón de tokens de entrada en caché y $10.00 por millón de tokens de salida, y su descuento por lectura de caché es 0.05x la tarifa de entrada, el más profundo en la tarjeta actual de OpenAI. GPT-6 Astra, el modelo que hizo el trabajo de ingeniería en Codex, cuesta $10.00 de entrada y $50.00 de salida, que es la brecha de cinco veces sobre la que se apoyó el enfoque de lanzamiento de OpenAI. La razón por la que el estudio produjo ejecuciones de $0.47 en lugar de ejecuciones de $2 no es la tarjeta de tarifas; es que el 89% de una solicitud muy repetitiva se facturó a una vigésima parte de la tarifa de entrada. En un agente con uso intensivo de caché, la línea de descuento hace más trabajo que el precio destacado, y en nuestro propio catálogo los precios de lista de los proveedores se trasladan con un 0% de recargo, así que si un proveedor mueve un medidor de entrada en caché, lo mueve en tu factura el mismo día.

El otro número en el estudio: el presupuesto de historial decidió si el agente respondía o no.

El costo por ejecución es el dato que todos citan, pero el resultado más útil del estudio tiene que ver con la fiabilidad, y es el que un operador debería leer primero.

• Con el presupuesto de 120.000 caracteres, el Modelo C no respondió en ninguna de sus 18 ejecuciones y GPT-6.1 Sol respondió en 3 de 18 — la mayoría de las ejecuciones alcanzó el límite de pasos sin producir una respuesta.

• A los 480.000 caracteres, todas las ejecuciones en ambos modelos respondieron, cada una con la respuesta correcta.

• Los modelos más nuevos consumieron más rápido el presupuesto más pequeño: el Modelo C recortó su historial por primera vez en la llamada 10, y el Modelo A en la llamada 64.

• En el flujo de trabajo optimizado, cada ejecución completó la tarea y devolvió la respuesta correcta, y cada ejecución en las mejores condiciones en cada modelo se encontró con los 192 hechos que se suponía que debía recopilar.

Ese es un argumento distinto del de "más barato". Un presupuesto de historial demasiado pequeño en un modelo capaz produce un agente que falla por quedarse sin espacio, y falla al alcanzar el límite de pasos, que es la forma más cara de fallar: pagas la ejecución completa y no obtienes nada. Aumentar el presupuesto elevó el costo por llamada y redujo el costo por respuesta, que es el único número que debería seguir quien gestiona producción. Si estás evaluando un modelo no probado para un agente como este, el patrón de bajo riesgo es mantener tu ruta de producción en el modelo en el que confías y poner el nuevo detrás de un failover o de una ruta dividida, de modo que un fallo por límite de pasos aparezca como un hecho de enrutamiento y no como un incidente. Todos los modelos de esta comparación son accesibles a través de una sola API para más de 200 modelos con los precios de lista de los proveedores transferidos sin cambios, lo que además hace que el descuento por lectura de caché sea comparable entre proveedores en la misma factura en lugar de en cinco paneles.

Qué sacar de esto, en orden

Si ejecutas un navegador o un agente de uso de computadora, hay tres palancas en el estudio de Asana que vale la pena accionar antes de mirar una tarjeta de tarifas:

• Haz que el prefijo de la solicitud solo permita añadir al final. Cualquier edición por llamada en medio del historial anula por completo la reutilización de caché a partir de ese punto.

• Poda por lotes. El seguimiento de Asana encontró que conservar cada captura de pantalla costó 1.2x menos por llamada que la mejor condición de poda en Model B y GPT-6.1 Sol, y alrededor de un 5% menos en Model C. La poda sigue siendo importante para tareas largas, ventanas de contexto pequeñas y lecturas de caché costosas, pero el argumento a favor de una proporción de lote de 20:1 tiene que ver con la estabilidad de la caché, no con las capturas de pantalla en sí.

• Establece el presupuesto de historial por modelo y compáralo con tu límite de pasos. Un presupuesto que le basta a un modelo puede dejar sin recursos al siguiente.

Dos salvaguardas del estudio son fáciles de omitir y no deberían serlo. Ninguna ejecución alcanzó el presupuesto de 480.000 caracteres, así que el presupuesto nunca restringió estas ejecuciones, pero un agente que se desvía crece hacia su límite de contexto y, si la caché se rompe, cada llamada paga el precio completo. Los límites máximos de pasos, tokens y coste por ejecución son lo que acota una mala ejecución. Por separado, el estudio usó tres o cuatro ejecuciones por condición con recuentos variables de llamadas, lo cual, según la propia Asana, es suficiente para mostrar patrones generales y no suficiente para distinguir condiciones que difieren en unos pocos puntos porcentuales. No extraigas un delta del 5 % de esto ni reestructures tu pipeline en función de ello.

La parte que es verdaderamente nueva, y la parte que no lo es

Las salvedades sobre la configuración merecen decirse sin rodeos: cuatro modelos, tres de ellos sin nombre, una sola tarea acotada de 32 libros, los contadores instrumentados de la propia Asana y el propio informe de un proveedor que aloja el resultado. Nada de esto se ha reproducido fuera de Asana. Pero el mecanismo está especificado por completo —historial de solo adición, marcador de caché en el último resultado de la herramienta, poda por lotes, presupuesto mayor, medir las lecturas de caché con los contadores del proveedor—, y es el tipo de hallazgo que sobrevive a que se atribuya al laboratorio equivocado. El 76x es una cifra de Asana sobre una carga de trabajo de Asana. La razón por la que vale la pena leerlo es que demuestra una regla que puedes probar en una tarde: un agente que edita su propio historial en cada paso está pagando el precio completo por una conversación que ya ha tenido.