Asana reduz custos 76x em testes de navegador com GPT‑6.1 Sol
Usando o GPT‑6 Astra no Codex, a Asana tornou seu agente de navegação 76 vezes mais barato e 5 vezes mais rápido em testes para oferecer modelos mais capazes aos clientes.
76x
Custos estimados de uso do modelo menores com o fluxo de trabalho otimizado do GPT-6.1 Sol
5x
Execuções de navegação mais rápidas com o fluxo de trabalho otimizado do GPT-6.1 Sol
US$ 0,47
Custo estimado médio de uso do modelo com o fluxo de trabalho otimizado do GPT-6.1 Sol
Com o GPT‑6 Astra no Codex conduzindo experimentos, a Asana otimizou o fluxo de trabalho de seu agente de navegação com o GPT‑6.1 Sol para executá-lo a um custo 76 vezes menor e com velocidade 5 vezes maior.
A Asana ajuda clientes a automatizar o trabalho em aplicativos empresariais por meio da StackAI(abre em uma nova janela), uma plataforma que adquiriu(abre em uma nova janela). Com a StackAI, os clientes podem criar fluxos de trabalho que navegam por sites, preenchem formulários e coletam informações sem escrever código. Na escala da Asana, pequenas ineficiências nesses fluxos de trabalho se acumulam.
Frank Hidalgo, PhD, CTO da StackAI na Asana, se propôs a tornar o agente de navegação mais rápido e mais barato de operar. Ele orientou o GPT‑6 Astra no Codex a investigar o agente, testar melhorias e comparar os resultados. Um trabalho que, segundo sua estimativa, levaria de um a dois meses se feito manualmente levou cerca de uma semana.
O estudo da Asana, com 144 execuções,(abre em uma nova janela) testou o GPT‑6.1 Sol e outros três modelos de fronteira, chamados aqui de Modelos A, B e C. O fluxo de trabalho otimizado com o GPT‑6.1 Sol apresentou custo estimado médio de uso do modelo de US$ 0,47 e cerca de quatro minutos por execução: um custo 76 vezes menor e velocidade 5 vezes maior que a configuração original em produção com o Modelo B.
"É assim que equipes de humanos e agentes funcionam na prática. Um engenheiro definiu a direção, o GPT-6 Astra conduziu os experimentos e os resultados passaram pelo Command até chegar à produção. Isso demonstra como a Asana torna realidade as equipes de humanos e agentes."
Para avançar rapidamente, Hidalgo começou usando o GPT‑6 Astra no Codex para mapear a base de código e explicar como o agente montava cada requisição ao modelo. O GPT‑6 Astra descobriu que o agente armazenava em cache suas instruções fixas e definições de ferramentas, mas não o histórico crescente de textos de páginas e capturas de tela que coletava. Assim, cada requisição reenviava esse histórico pelo preço integral.
O agente também descartava capturas de tela antigas e cortava texto em quase todas as etapas. Cada edição alterava o histórico, de modo que apenas armazená-lo em cache não teria ajudado. Além disso, perder essas informações poderia obrigar o agente a revisitar páginas que já havia lido.
Hidalgo analisou as correções propostas pelo GPT‑6 Astra e selecionou três para testar:
Estender o armazenamento em cache ao histórico de navegação do agente
Aumentar a quantidade de texto que ele podia reter
Remover capturas de tela em lotes, em vez de a cada etapa
O GPT‑6 Astra começou com testes rápidos para identificar quais variáveis eram relevantes. Como o código não havia sido projetado para experimentos controlados, o modelo o refatorou para que um único frontend e backend pudessem dar suporte a muitos fluxos de trabalho em paralelo, cada um com suas próprias configurações.
O Astra conduziu o estudo completo: limites de histórico de 120.000 e 480.000 caracteres e seis políticas de cache e capturas de tela, cada uma testada três vezes em cada um dos quatro modelos (veja a tabela abaixo). A política com melhor desempenho permitia acumular 20 capturas de tela antes de manter apenas a mais recente. Isso mantinha o histórico anterior inalterado por períodos mais longos entre as remoções. Combinada com o maior limite de histórico, essa política deu origem ao fluxo de trabalho otimizado. Cada configuração realizava a mesma tarefa: coletar seis campos para cada um dos 32 livros de um catálogo público de demonstração, representativa do que alguns clientes da Asana executam na StackAI.
Modelo | Descrição | Preço |
|---|---|---|
Modelo A | Um modelo menor e mais barato de outro laboratório de IA de fronteira, lançado no outono de 2025 no hemisfério norte | Metade do preço do GPT‑6.1 Sol |
Modelo B | O modelo originalmente usado em produção, do mesmo laboratório do Modelo A, lançado no verão de 2026 no hemisfério norte | Mesmo preço do GPT‑6.1 Sol |
Modelo C | Uma versão atualizada do Modelo B, lançada no outono de 2026 no hemisfério norte | Mesmo preço do GPT‑6.1 Sol |
GPT‑6.1 Sol | Modelo da OpenAI |
O GPT‑6 Astra executou os fluxos de trabalho e examinou as requisições, os registros de uso e as saídas. Sessões separadas do modelo revisaram o trabalho. As requisições, os rastreamentos de dados e os resultados de cada sessão foram registrados no Command(abre em uma nova janela), a plataforma de entrega de software da Asana, para que a equipe pudesse revisar o estudo completo depois. A partir do Command, as descobertas foram transformadas em tickets e, depois, em pull requests, e as mudanças foram para produção.
"Eu teria levado de um a dois meses para fazer isso manualmente. Com o GPT-6 Astra no Codex, levou cerca de uma semana: eu definia um /goal antes de dormir e revisava os resultados pela manhã."
Para o Modelo B, a otimização reduziu o custo estimado de uso do modelo de pelo menos US$ 36,21 (algumas execuções originais atingiram o limite de etapas antes de terminar) para US$ 1,24 por execução, uma redução de 29 vezes. O fluxo de trabalho otimizado com o GPT‑6.1 Sol foi ainda 2,6 vezes mais barato, com custo de US$ 0,47. Todas as execuções do fluxo de trabalho otimizado concluíram a tarefa e retornaram a resposta correta.
Médias de 3 execuções. ≥: a configuração de referência inclui execuções interrompidas pelo limite; portanto, sua média é um limite inferior.
Os dois fatores de redução à direita comparam os resultados com o Modelo B otimizado. O Modelo B foi executado na fase 1; o Modelo C e o Sol 6.1, na fase 2 do mesmo estudo (linha pontilhada).
Considerando apenas o GPT‑6.1 Sol com o maior limite de histórico, a nova política de cache e capturas de tela reduziu o custo em 4 vezes, de US$ 1,97 para US$ 0,47 por execução. Cada chamada ficou cerca de 3 vezes mais barata, pois 89% da entrada vinha do cache, a 5% do preço da entrada sem cache. As execuções também ficaram mais rápidas: de pelo menos 22,5 minutos na configuração original com o Modelo B para cerca de quatro minutos no fluxo de trabalho otimizado com o GPT‑6.1 Sol.
Média de 3 execuções, com barras de erro de desvio padrão. ≥: a média inclui uma execução interrompida pelo limite ou não concluída; portanto, o valor real é pelo menos esse.
As barras usam o tema azul. Avalie os efeitos do cache em comparação com a barra do maior limite de histórico, de 480 mil.
Os marcadores de execução e as barras de erro de desvio padrão são reconstruções aproximadas da imagem original; os valores das execuções e os desvios padrão originais não estavam disponíveis.
Média de 3 execuções, com barras de erro de desvio padrão. ≥: a média inclui uma execução interrompida pelo limite ou não concluída; portanto, o valor real é pelo menos esse.
As barras usam o tema azul. Avalie os efeitos do cache em comparação com a barra do maior limite de histórico, de 480 mil.
Os marcadores de execução e as barras de erro de desvio padrão são reconstruções aproximadas da imagem original; os valores das execuções e os desvios padrão originais não estavam disponíveis.
A investigação também mostrou como a gestão do histórico afetava a própria capacidade do agente de produzir uma resposta. Dar ao GPT‑6.1 Sol mais espaço para reter seu histórico de navegação aumentou o número de execuções que produziram uma resposta: de três em 18 com o menor limite de histórico para todas as 18 com o maior limite, cada uma com a resposta correta. Para Hidalgo, o valor para o negócio está em dar aos clientes acesso a modelos mais rápidos e capazes, mantendo os custos operacionais sustentáveis.
"O custo antes limitava quais modelos podíamos oferecer aos clientes para essas cargas de trabalho. Ao tornar o agente mais eficiente, podemos oferecer aos clientes um modelo melhor e mais rápido, ao mesmo tempo que reduzimos nossos custos operacionais."
A Asana disponibilizou as mudanças na navegação da StackAI e está desenvolvendo ferramentas para facilitar a repetição de experimentos semelhantes. Com o tempo, a equipe planeja incorporar esses testes às avaliações da plataforma, para que clientes e equipes internas possam comparar custo, tempo de execução e qualidade das respostas ao configurar seus agentes.
"A velocidade de entrega já não é o gargalo; é a atenção humana. Estamos perto de um mundo em que cada engenheiro é um gerente de produto liderando um conjunto de agentes."
A Asana agora usa o GPT‑6 Astra no Codex para testar funcionalidades do produto antes do lançamento: o Astra navega pela plataforma, testa diferentes entradas e relata bugs para os revisores humanos de garantia da qualidade (QA). Hidalgo vê nisso a base de um novo ciclo de vida de desenvolvimento de software, com muitas sessões de agentes na nuvem testando funcionalidades em paralelo.
O estudo completo está disponível nos blogs da Asana(abre em uma nova janela) e da StackAI(abre em uma nova janela).
