Andy Garcia · dev freelance
FRENES
Volver al blog
IA y Agentes

Asana hizo un agente de navegación 76 veces más barato en pruebas con GPT-6.1 Sol. En el estudio de 32 páginas, el mayor paso es un presupuesto de memoria más grande, no el modelo

19 de octubre de 2026 7 min de lectura

El viernes 9 de octubre, OpenAI publicó un caso de cliente sobre Asana. Un agente de navegación que Asana ejecuta a través de StackAI, la plataforma de agentes sin código que adquirió, costó en promedio 0,47 $ de modelo estimado por ejecución con GPT-6.1 Sol en pruebas, en unos cuatro minutos. OpenAI habla de 76 veces más barato y 5 veces más rápido que "la configuración de producción original en el Modelo B", un modelo sin nombre de otro laboratorio de frontera.

La cobertura que leí se detenía en la primera división: los cambios de workflow por sí solos redujeron el coste 29 veces en el Modelo B, y pasar a GPT-6.1 Sol añadió un factor de 2,6. Es correcto, y se queda un nivel corto. El blog de ingeniería de Asana enlaza el estudio completo, un PDF de 32 páginas fechado el 30 de septiembre y escrito por el CTO de StackAI, Frank Hidalgo, que hizo que GPT-6 Astra en Codex ejecutara los experimentos. Contiene el registro de ejecuciones, y ese registro cuenta una historia más útil que el titular.

Construyo agentes sobre Claude todos los días como CTO de una LegalTech, y BidForge, mi producto paralelo, lee expedientes de contratación pública franceses para pequeñas empresas. Ambos son máquinas de reenviar contexto. Así que leí el registro.

Qué hacía el agente

Un agente de navegación reenvía todo en cada llamada: las definiciones de herramientas, el prompt de sistema y un historial creciente de texto de páginas y capturas de pantalla. Una caché de prompt factura la parte repetida a una fracción del precio, pero solo reutiliza el prefijo inalterado más largo de una petición. El agente de Asana cacheaba sus herramientas y su prompt de sistema, no su historial. Y editaba ese historial en casi cada paso: quitaba la captura de pantalla anterior y recortaba el texto más antiguo para ajustarse a un presupuesto de 120 000 caracteres. Cada edición cambiaba una parte anterior de la petición, así que la reutilización de la caché se rompía en casi cada llamada.

La tarea de prueba: abrir books.toscrape.com, una librería ficticia creada para practicar scraping, visitar 32 páginas de libros, recoger seis campos por libro (192 datos) y devolver una tabla con el total de precios. Seis políticas de caché y poda, dos presupuestos de historial, cuatro modelos, tres ejecuciones cada uno: 144 ejecuciones entre el 14 y el 30 de septiembre, más un seguimiento de 12 ejecuciones el 1 de octubre.

Las 76 veces, un paso a la vez

El estudio añade un cambio a la vez en el Modelo B. Coste medio del modelo por ejecución:

  • Código original, presupuesto de 120 000 caracteres: al menos 36,21 $. Una ejecución alcanzó el límite de pasos, así que la media es un suelo.
  • Mismo código, presupuesto elevado a 480 000 caracteres: 4,87 $.
  • Más caché del historial (3,94 $ por sí sola), luego capturas de pantalla podadas por lotes: 1,24 $.
  • El mismo agente optimizado en GPT-6.1 Sol: 0,47 $.

Eso son aproximadamente 7,4 veces, luego 3,9 veces, luego 2,6 veces. Multiplícalas y vuelves a unas 76.

El paso más grande es el primero, y no implica ni caché ni modelo nuevo. Con 120 000 caracteres, el agente recortaba datos que ya había recogido, y la petición final de ninguna ejecución contenía aún los 192. Así que volvía a buscarlos. En el Modelo B, las revisitas a páginas pasaron de al menos 271 por ejecución de referencia a 2 con el presupuesto mayor, un recuento que, según el estudio, también incluye los regresos habituales al catálogo. Entre la configuración original y la mejor, el Modelo B hizo 9 veces menos llamadas, y cada ejecución envió 2,3 millones de tokens en lugar de 19,7 millones.

Un agente que olvida paga dos veces.

La trampa de la actualización

Los modelos más nuevos rompieron el presupuesto antiguo. El Modelo C, una versión más reciente del Modelo B lanzada en otoño de 2026, añadía unos 6 300 tokens de entrada por llamada antes de su primera poda, frente a 900 del Modelo A y 1 800 del Modelo B y de Sol. El Modelo C podó su historial por primera vez en la llamada 10, el Modelo A en la 64. Con 120 000 caracteres, el Modelo C no entregó respuesta en ninguna de sus 18 ejecuciones y GPT-6.1 Sol en 3. Con 480 000, todas las ejecuciones de ambos respondieron.

Léelo desde el lado del comprador. Cambias a un modelo más nuevo con los ajustes antiguos, y el modelo más nuevo parece roto. Un presupuesto de historial se ajusta a un modelo, lo que convierte una actualización de modelo en un cambio de configuración.

Solo la caché costó más

Este es el hallazgo que me parece más útil. Con el presupuesto mayor, cachear el historial sin cambiar la poda costó más que no cachearlo en el Modelo A, el Modelo C y Sol. Las escrituras de caché supusieron más del 90 por ciento del coste de esa condición, mientras que las lecturas de caché se quedaron por debajo de un tercio de la entrada.

La aritmética es simple. En la tabla de precios del estudio, una escritura de caché cuesta 1,25 veces el precio de entrada. Una lectura cuesta 0,1 veces en el otro proveedor y 0,05 veces en Sol. En GPT-6.1 Sol eso son 2,00 $ por millón de tokens de entrada sin caché, 2,50 $ por escribir y 0,10 $ por leer, las líneas que muestra la página de precios de OpenAI. Toma un historial simplificado de 50 000 tokens a lo largo de 20 llamadas. Sin caché: 20 × 50 000 × 2 $ / 1 M = 2,00 $. Escrito una vez, luego leído 19 veces: 0,125 $ + 0,095 $ = 0,22 $. Reescrito en cada llamada porque algo anterior cambió: 20 × 0,125 $ = 2,50 $, una cuarta parte más que sin caché alguna.

La poda por lotes es el remedio. A 20:1, el agente conserva hasta 20 capturas de pantalla y luego vuelve a una, de modo que unas 19 llamadas consecutivas reutilizan el historial cacheado. Las ejecuciones medianas de Sol en el estudio lo muestran en la llamada 24: unos 40 000 tokens de entrada, 9 por ciento desde la caché, con la política antigua; unos 58 000, 93 por ciento desde la caché, con la nueva. Según mi aritmética con esas cifras, ignorando la salida, la petición un 45 por ciento más grande costó aproximadamente 0,016 $ frente a 0,073 $.

Después, un seguimiento conservó todas las capturas de pantalla, sin poda alguna. El coste por llamada salió 1,2 veces más bajo que la mejor condición en el Modelo B y Sol. El estudio es cuidadoso: la poda sigue importando para tareas largas, ventanas de contexto más pequeñas y lecturas de caché más caras, y califica esta comparación de "indicativa", ya que el seguimiento se ejecutó como un solo lote con cachés compartidas. En esta tarea, añadir sin reescribir ganó.

Lo que omite el caso de cliente

Es una prueba de desarrollo, no una factura de producción. Donde la página de OpenAI y el blog de Asana dicen "configuración de producción", el estudio llama al punto de partida una "base de desarrollo". Examina el problema "antes de cualquier afirmación sobre ahorros en producción en Asana". Los costes se calculan a partir de contadores de tokens a precios de lista, "no son facturas" y excluyen los costes de sandbox y de servidor.

La mejor condición se eligió después de las ejecuciones, la media más baja entre doce, y el propio estudio nombra ese sesgo de selección. Tres ejecuciones por condición.

La comparación entre modelos es, en palabras del estudio, "descriptiva". El Modelo C y Sol se ejecutaron en una segunda fase con el esfuerzo en alto, y Sol obtuvo una vida de caché de 30 minutos frente a cinco minutos.

Parte de las 2,6 veces de Sol es una línea de precios. En la tabla de precios del estudio, los Modelos B, C y Sol cuestan todos 2 $ de entrada y 10 $ de salida por millón de tokens, pero Sol lee su caché a 0,10 $ frente a 0,20 $. Sol hizo 28 llamadas de media frente a las 12 del Modelo C y aun así salió más barato.

Sol respondió "con un breve resumen del total y de los libros más baratos y más caros en lugar de la tabla completa". Todas las respuestas de Sol tenían el total correcto. También eran más cortas de lo que pedía la tarea, y la salida es la línea más cara de la tarifa. El estudio no dice cuánto de la diferencia explica eso.

Incluso una cita se movió. En la página de Asana, su CPO, Arnab Bose, dice "un agente ejecutó los experimentos". En la página de OpenAI, la misma frase dice "GPT-6 Astra ejecutó los experimentos". Un caso de cliente es marketing. El estudio es la prueba.

Qué comprobaría en mis propios agentes

Nada de esto es específico de OpenAI: el estudio dice que sus lecciones se cumplieron en ambos proveedores.

Mide las lecturas de caché por llamada a partir de los contadores de uso del proveedor, no de tu configuración. El agente original de Asana tenía un marcador de caché y leía alrededor de una décima parte de su entrada desde la caché.

Enumera todo lo que reescribe mensajes anteriores: un recortador de texto, un eliminador de imágenes, un resultado de herramienta resumido en el sitio. El estudio añade uno que yo no habría adivinado: en el otro proveedor, cambiar la elección de herramienta reiniciaba la caché de mensajes, y cada llamada que forzaba una herramienta provocaba un fallo de caché.

Reajusta el presupuesto de historial en cada cambio de modelo. Registra la llamada en la que ocurre la primera poda, y si el agente revisita lo que ya leyó.

Calcula el precio de una poda antes de lanzarla. En una ejecución de Sol de 35 llamadas, el estudio estima que una poda solo se amortiza tras unas 27 llamadas más al precio de lectura de 0,05 veces de Sol, unas 13 a 0,1 veces.

Mantén las salvaguardas. Ninguna ejecución alcanzó el presupuesto de 480 000 caracteres, y el estudio aun así dice que se limiten los pasos, los tokens y el coste por ejecución, porque si la caché se rompe en un agente que se desvía, cada llamada paga la tarifa completa.

En septiembre escribí que, para los agentes, la lectura de caché es la línea que cambia la factura. Este estudio añade la condición que dejé implícita: la caché solo compensa cuando el agente deja de reescribir su propio pasado. El modelo fue el último 2,6. El primer 29 estaba en cómo el agente guardaba su memoria, y la misma corrección redujo el coste en cada modelo probado.

Fuentes

¿Un proyecto del mismo estilo?

Diseño y despliego productos como este. Hablemos.

Hablemos