Asana corta custo de agente de navegação em 76 vezes com GPT-6.1 Sol

A Asana publicou, em parceria com a OpenAI, um estudo sobre como reduziu em 76 vezes o custo de um agente de navegação web usado pela StackAI, plataforma que a empresa adquiriu para automatizar tarefas em sites e formulários sem código. O caso, descrito pela OpenAI, não é sobre trocar de modelo: é sobre consertar como o agente lidava com o próprio histórico de navegação.

O protagonista técnico da história é Frank Hidalgo, CTO da StackAI na Asana, que usou o GPT-6 Astra rodando no Codex para investigar o agente, propor correções e comparar resultados. Segundo Hidalgo, o trabalho que levaria de um a dois meses manualmente foi feito em cerca de uma semana.

Isso levaria de um a dois meses se eu fizesse na mão. Com o GPT-6 Astra no Codex, levou cerca de uma semana: eu definia um /goal antes de dormir e revisava os resultados de manhã.

This would have taken me one to two months by hand. With GPT-6 Astra in Codex, it took about a week: I'd set a /goal before going to bed and review the results in the morning.Frank Hidalgo, PhD, CTO da StackAI na Asana

Onde o dinheiro estava sendo queimado

A investigação começou com o GPT-6 Astra mapeando a base de código para explicar como o agente montava cada requisição ao modelo. A descoberta: o agente cacheava as instruções fixas e as definições de ferramentas, prática padrão em APIs de LLM↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI →, mas não cacheava o histórico crescente de texto de página e screenshots que ia acumulando durante a navegação.

Na prática, cada chamada reenviava esse histórico inteiro a preço cheio, mesmo quando boa parte dele já tinha sido processada na chamada anterior. Para piorar, o agente descartava screenshots antigos e cortava texto a quase cada passo, o que invalidava qualquer tentativa de cache, porque cada edição alterava o histórico que vinha antes dela. Era um padrão comum em protótipos de agentes: a política de poda de contexto, pensada para economizar tokens, acabava sabotando o cache e multiplicando o custo.

Um experimento com 144 execuções e quatro modelos

Com o diagnóstico em mãos, Hidalgo selecionou três hipóteses para testar: estender o cache ao histórico de navegação, aumentar a quantidade de texto retido e remover screenshots em lotes em vez de a cada passo. Como o código original não foi desenhado para experimentos controlados, o GPT-6 Astra refatorou a aplicação para que um único frontend↳Front-end60 conteúdosFront-end em larga escala: quando seu projeto vira um Frankenstein (e como evitar)Dev (Back & Front) · mar 2026Build e bundling no front-end: 7 decisões que impactam performance de verdadeDev (Back & Front) · abr 2026Como modelar APIs pensando no front-end: 8 práticas para evitar retrabalho entre timesDev (Back & Front) · abr 2026Ver tudo em Dev (Back & Front) → e backend suportassem várias configurações em paralelo.

O desenho final do estudo testou dois orçamentos de histórico (120 mil e 480 mil caracteres) e seis políticas de cache e descarte de screenshot, cada combinação rodada três vezes em quatro modelos diferentes: GPT-6.1 Sol e mais três modelos de outros laboratórios, chamados na publicação de Modelo A, B e C. A tarefa de referência era sempre a mesma: coletar seis campos para 32 livros de um catálogo de demonstração pública, representativo do que clientes da StackAI rodam na prática.

Todas as sessões, requisições e resultados ficaram registrados no Command, a plataforma de entrega de software da própria Asana, o que permitiu revisar o estudo inteiro depois e transformar os achados em tickets e pull requests até chegarem à produção.

De US$ 36 para US$ 0,47 por execução

No Modelo B, que rodava em produção originalmente, a otimização reduziu o custo estimado de pelo menos US$ 36,21 por execução (algumas rodadas originais estouravam o limite de passos antes de terminar) para US$ 1,24, uma queda de 29 vezes. O fluxo otimizado rodando em GPT-6.1 Sol foi 2,6 vezes mais barato ainda, fechando em US$ 0,47 por execução, o número que dá nome ao estudo: 76 vezes mais barato que a configuração original em produção.

Isolando só o efeito da política de cache no GPT-6.1 Sol, com o orçamento de histórico maior, o custo caiu de US$ 1,97 para US$ 0,47 por execução, uma queda de 4 vezes. A explicação está na taxa de acerto do cache: 89% do input das chamadas veio do cache, cobrado a 5% do preço do token não cacheado. O tempo de execução também caiu, de pelo menos 22,5 minutos no setup original em Modelo B para cerca de quatro minutos no fluxo otimizado, uma diferença de 5 vezes.

Talvez o dado mais relevante para quem desenvolve agentes não seja o custo, e sim a confiabilidade: com o orçamento de histórico menor (120 mil caracteres), apenas 3 das 18 execuções em GPT-6.1 Sol produziram uma resposta completa. Com o orçamento maior (480 mil caracteres), as 18 execuções terminaram, todas com a resposta correta. Cortar contexto agressivamente não só não ajudava a economizar, como fazia o agente falhar a tarefa.

O que isso muda para quem constrói agentes

Em resumo: o ganho não veio de um modelo mais barato, veio de três decisões de engenharia sobre como montar o contexto da requisição. São técnicas replicáveis em qualquer stack de agente que acumule estado ao longo de várias chamadas, não um truque específico da OpenAI.

A lógica, simplificada, é algo como:

# padrão ingênuo: só o prompt de sistema é cacheado
request = system_prompt + tools + full_running_history  # recalculado a cada chamada

# padrão observado no estudo: cache estendido ao histórico,
# com poda em lote em vez de poda a cada passo
if len(screenshots) > 20:
    screenshots = screenshots[-1:]
# o texto da página permanece intacto por mais chamadas,
# preservando o prefixo que o cache de prompt reaproveita

Três pontos valem a pena levar para o próprio projeto:

• Cache não é só para o prompt estático. Se o agente acumula histórico (texto de página, saída de ferramentas, mensagens), esse histórico também pode ser cacheado, desde que não seja reescrito a cada passo.
• Poda de contexto a cada turno é inimiga do cache. Editar o histórico com frequência invalida o prefixo cacheado; podar em lotes maiores (a cada 20 passos, no caso do estudo) preserva o cache por mais tempo.
• Contexto maior pode ser mais barato, não mais caro, se ele evitar que o agente precise revisitar páginas já lidas. No estudo, o orçamento de histórico mais generoso foi o que viabilizou tanto o cache quanto a taxa de sucesso.

Também chama atenção o processo usado para chegar lá: em vez de um engenheiro testar hipóteses manualmente, o GPT-6 Astra rodando no Codex executou a bateria inteira de 144 combinações e examinou requisições, registros de uso e saídas, enquanto sessões de modelo separadas revisaram o trabalho e produziram um relatório estruturado. É um uso de agente de codificação para experimentação empírica, não só para escrever código, algo que ainda é incomum na maioria dos times.

Isso é como times de humanos e agentes funcionam na prática. Um engenheiro definiu a direção, o GPT-6 Astra rodou os experimentos, e os resultados passaram pelo Command até a produção.

This is what teams of humans and agents look like in practice. An engineer set the direction, GPT-6 Astra ran the experiments, and the results went through Command to production.Arnab Bose, CPO da Asana

O que o estudo não resolve

Vale ponderar o que fica de fora. Os números de custo são específicos da tarefa testada (32 livros, seis campos cada) e da precificação vigente dos quatro modelos comparados; a proporção de 76 vezes não é uma constante universal de engenharia de agentes, é o resultado de um workload específico com um gargalo específico de cache.

O estudo também não conta quanto custou rodar o próprio GPT-6 Astra para gerar e revisar as 144 execuções, nem o esforço de engenharia para refatorar o código a ponto de suportar testes paralelos controlados, algo que a publicação reconhece como pré-requisito para o experimento funcionar. Para times menores, replicar a metodologia completa (orçamentos de histórico, seis políticas de cache, quatro modelos, três repetições) pode custar mais em tempo de engenharia do que a economia justifica, a menos que o volume de execuções em produção seja alto o suficiente para compensar.

A Asana diz que já liberou as mudanças de navegação na StackAI e planeja incorporar esse tipo de teste às avaliações da própria plataforma, para que clientes comparem custo, tempo de execução e qualidade da resposta ao configurar agentes. Isso sugere que a metodologia, hoje um estudo pontual, pode virar uma funcionalidade de produto, o que é o ponto mais interessante para quem acompanha para onde ferramentas de agente estão indo: de experimento interno para capacidade nativa da plataforma.

Fonte: OpenAI News