El costo estaba en el flujo: Asana recortó 76x el costo de modelo de su agente de navegador
Con el mismo modelo, corregir cómo el agente cacheaba y recortaba su historial de navegación recortó el costo estimado 29x. Cambiar a GPT-6.1 Sol añadió 2.6x. El flujo de trabajo era la factura.
Escuche este artículo · 5 min
Narración completa del artículo, generada con IA.
El número del titular es 76x. El número más útil es 29x, y se logró sin cambiar de modelo.
OpenAI publicó la historia el 9 de octubre. La plataforma StackAI que Asana adquirió ejecuta un agente de navegador que los clientes usan para recorrer sitios web, rellenar formularios y reunir información sin escribir código. Frank Hidalgo, CTO de StackAI en Asana, dirigió a GPT-6 Astra en Codex para investigar por qué el agente era caro, probar correcciones y comparar los resultados. El estudio resultante, de 144 ejecuciones, probó GPT-6.1 Sol y otros tres modelos de frontera, que OpenAI etiqueta como Modelos A, B y C, en una sola tarea: recopilar seis campos de cada uno de 32 libros de un catálogo de demostración público.
El flujo de trabajo optimizado con GPT-6.1 Sol promedió $0.47 de costo de modelo estimado y unos cuatro minutos por ejecución, frente a un mínimo de $36.21 y 22.5 minutos del montaje original en producción con el Modelo B. Eso es el 76x y el 5x. Pero mire cómo se desglosa.
| Configuración | Costo de modelo estimado por ejecución | Qué cambió |
|---|---|---|
| Montaje original en producción, Modelo B | Al menos $36.21 | Línea base; algunas ejecuciones alcanzaron el límite de pasos |
| Flujo de trabajo optimizado, aún con el Modelo B | $1.24 | Solo caché y política de contexto: 29x |
| GPT-6.1 Sol, mayor presupuesto, política antigua | $1.97 | Modelo nuevo, comportamiento de caché antiguo |
| GPT-6.1 Sol, flujo de trabajo optimizado | $0.47 | La política recortó otro 4x; 2.6x por debajo del Modelo B optimizado |
El historial se reenviaba a precio completo
El primer hallazgo de Astra fue mundano. El agente guardaba en caché sus instrucciones fijas y las definiciones de herramientas, pero no el historial creciente de texto de página y capturas de pantalla que iba acumulando por el camino, así que cada solicitud reenviaba ese historial al precio completo sin caché.
La solución obvia no habría funcionado. El agente descartaba las capturas más antiguas y recortaba el texto en casi todos los pasos, de modo que el historial cambiaba constantemente, y una caché de prompt solo ayuda cuando el inicio del prompt permanece idéntico. Cada recorte la invalidaba.
La política ganadora dejaba que las capturas se acumularan hasta 20 antes de recortar hasta la más reciente. Así, el historial anterior permanecía sin cambios durante tramos largos entre recortes, y la caché podía hacer su trabajo. Con GPT-6.1 Sol, el 89% de la entrada vino de la caché a un 5% del precio sin caché, y cada llamada fue unas 3x más barata.
La lección general: una política de contexto que parece frugal por paso puede salir cara por ejecución. Recortar para ahorrar tokens puede romper la caché y costar más de lo que ahorra.
Conservar más memoria terminó más ejecuciones
El segundo hallazgo tiene que ver con la calidad, no con el costo. Con el presupuesto de historial más pequeño, de 120,000 caracteres, solo 3 de las 18 ejecuciones con GPT-6.1 Sol produjeron una respuesta. Con 480,000 caracteres, las 18 lo hicieron, todas correctas. El agente original no solo era caro: perdía datos que ya había leído y a veces volvía a visitar páginas para encontrarlos de nuevo.
Por eso el precio por token es la unidad equivocada. Una configuración más barata que falla cinco veces de cada seis no es barata. La medida que importa es el costo por tarea completada y correcta, la misma unidad que defendimos cuando la línea de precios de Claude Haiku 5.5 convirtió el tamaño del contexto en una decisión de arquitectura.
El método es la parte transferible
Hidalgo calcula que la investigación habría llevado uno o dos meses a mano; con Astra ejecutando experimentos durante la noche, tardó alrededor de una semana. Las solicitudes, las trazas y los resultados de cada sesión quedaron registrados en Command, la plataforma de entrega de software de Asana, y luego se convirtieron en tickets y pull requests antes de llegar a producción. Asana dice que planea incorporar estas pruebas a las evaluaciones de StackAI para que los clientes puedan comparar costo, runtime y calidad de las respuestas al configurar sus agentes.
Esa es la parte que vale la pena copiar: la configuración del agente tratada como una variable experimental, con ejecuciones controladas, trazas registradas y un camino revisable hacia producción. La mayoría de los equipos comparan modelos. Pocos comparan presupuestos de contexto, políticas de caché y retención de capturas de pantalla sobre el mismo modelo, y los números de Asana sugieren que ahí estaba la mayor parte del dinero.
Los límites son reales. Son costos de modelo estimados, no costos totales de infraestructura o de ingeniería. Es una sola tarea, dentro del caso de un cliente de un proveedor, y los modelos competidores están anonimizados. El historial, las herramientas y el comportamiento de la caché de su agente serán distintos.
Hay tres comprobaciones baratas que puede hacer esta semana en cualquier agente en producción. Mida la tasa de aciertos de caché por paso, no por sesión. Encuentre dónde el agente reescribe su propio historial, porque cada reescritura reinicia la caché. Y antes de enrutar a un modelo distinto, ejecute el actual con otra política de contexto. Puede que encuentre su 29x antes de necesitar el 2.6x de nadie.