Asana reduz custos 76x em testes no navegador com GPT‑6.1 Sol
Com o GPT‑6 Astra no Codex, a Asana tornou o seu agente de navegador 76x mais económico e 5x mais rápido em testes, para oferecer modelos mais capazes aos clientes.
76x
Custos estimados de utilização do modelo mais baixos com o fluxo de trabalho otimizado do GPT-6.1 Sol
5x
Execuções no navegador mais rápidas com o fluxo de trabalho otimizado do GPT-6.1 Sol
0,47 USD
Custo estimado médio de utilização do modelo com o fluxo de trabalho otimizado do GPT-6.1 Sol
Com o GPT‑6 Astra no Codex a realizar experiências, a Asana otimizou o fluxo de trabalho do seu agente de navegador no GPT‑6.1 Sol, tornando a execução 76x mais económica e 5x mais rápida.
A Asana ajuda os clientes a automatizar o trabalho entre aplicações empresariais através da StackAI(abre numa nova janela), uma plataforma que adquiriu(abre numa nova janela). Com a StackAI, os clientes podem criar fluxos de trabalho que navegam em sites, preenchem formulários e recolhem informações sem escrever código. À escala da Asana, as pequenas ineficiências nestes fluxos de trabalho acumulam-se.
Frank Hidalgo, PhD, diretor de tecnologia da StackAI na Asana, decidiu tornar o agente de navegador mais rápido e económico. Pediu ao GPT‑6 Astra no Codex para analisar o agente, testar melhorias e comparar os resultados. Um trabalho que, segundo a sua estimativa, demoraria um a dois meses se fosse feito manualmente ficou concluído em cerca de uma semana.
O estudo da Asana, com 144 execuções,(abre numa nova janela) testou o GPT‑6.1 Sol e três outros modelos de fronteira, aqui designados por Modelos A, B e C. O fluxo de trabalho otimizado resultante, no GPT‑6.1 Sol, teve um custo estimado médio de utilização do modelo de 0,47 USD e demorou cerca de quatro minutos por execução: 76x mais económico e 5x mais rápido do que a configuração original em produção no Modelo B.
«É assim que as equipas de pessoas e agentes funcionam na prática. Um engenheiro definiu o rumo, o GPT-6 Astra realizou as experiências e os resultados passaram pelo Command até chegarem a produção. Isto demonstra como a Asana dá vida a equipas de pessoas e agentes.»
Para avançar rapidamente, Hidalgo começou por usar o GPT‑6 Astra no Codex para mapear a base de código e explicar como o agente construía cada pedido ao modelo. O GPT‑6 Astra descobriu que o agente guardava em cache as instruções fixas e as definições de ferramentas, mas não o histórico crescente de texto das páginas e capturas de ecrã que recolhia. Assim, cada pedido reenviava esse histórico ao preço integral.
O agente também descartava capturas de ecrã antigas e cortava texto em quase todos os passos. Cada edição alterava o histórico, pelo que guardá-lo em cache, por si só, não teria ajudado. Além disso, perder esses dados podia obrigar o agente a voltar a páginas que já tinha lido.
Hidalgo analisou as correções propostas pelo GPT‑6 Astra e selecionou três para testar:
Alargar o armazenamento em cache ao histórico de navegação do agente
Aumentar a quantidade de texto que o agente podia reter
Remover capturas de ecrã em lotes, em vez de a cada passo
O GPT‑6 Astra começou com testes rápidos para determinar quais as variáveis relevantes. Como o código não tinha sido concebido para experiências controladas, refatorizou-o de seguida para que um único frontend e backend pudessem suportar vários fluxos de trabalho em paralelo, cada um com as suas próprias definições.
O Astra realizou o estudo completo: limites de histórico de 120 000 e 480 000 carateres e seis políticas de cache e capturas de ecrã, cada uma testada três vezes em cada um dos quatro modelos (ver tabela abaixo). A política com melhor desempenho deixava acumular 20 capturas de ecrã antes de manter apenas a mais recente. Isto mantinha o histórico anterior inalterado durante períodos mais longos entre remoções. Combinada com o limite de histórico mais elevado, esta política deu origem ao fluxo de trabalho otimizado. Cada configuração executou a mesma tarefa: recolher seis campos para cada um de 32 livros de um catálogo público de demonstração, uma tarefa representativa do que alguns clientes da Asana executam na StackAI.
Modelo | Descrição | Preço |
|---|---|---|
Modelo A | Um modelo mais pequeno e económico de outro laboratório de IA de fronteira, lançado no outono de 2025 | Metade do preço do GPT‑6.1 Sol |
Modelo B | O modelo usado originalmente em produção, do mesmo laboratório do Modelo A, lançado no verão de 2026 | O mesmo preço do GPT‑6.1 Sol |
Modelo C | Uma versão atualizada do Modelo B, lançada no outono de 2026 | O mesmo preço do GPT‑6.1 Sol |
GPT‑6.1 Sol | O modelo da OpenAI |
O GPT‑6 Astra executou os fluxos de trabalho e analisou os pedidos, os registos de utilização e as saídas. Sessões separadas do modelo reviram o trabalho. Os pedidos, rastos de dados e resultados de cada sessão foram registados no Command(abre numa nova janela), a plataforma de entrega de software da Asana, para que a equipa pudesse rever todo o estudo posteriormente. A partir do Command, as conclusões foram convertidas em tickets e depois em pull requests, e as alterações passaram a produção.
«Teria demorado um a dois meses a fazer isto manualmente. Com o GPT-6 Astra no Codex, demorei cerca de uma semana: definia um /goal antes de me deitar e revia os resultados de manhã.»
No Modelo B, a otimização reduziu o custo estimado de utilização do modelo de, pelo menos, 36,21 USD (algumas execuções originais atingiram o limite de passos antes de terminar) para 1,24 USD por execução, uma redução de 29x. O fluxo de trabalho otimizado no GPT‑6.1 Sol foi ainda 2,6x mais económico, com um custo de 0,47 USD. Todas as execuções do fluxo de trabalho otimizado concluíram a tarefa e devolveram a resposta correta.
Médias de 3 execuções. ≥: a configuração de referência inclui execuções interrompidas por limite, pelo que a sua média é um limite inferior.
Os dois fatores de redução à direita usam o Modelo B otimizado como referência. 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 limite de histórico mais elevado, a nova política de cache e capturas de ecrã reduziu o custo 4x, de 1,97 USD para 0,47 USD por execução. Cada chamada ficou cerca de 3x mais económica, pois 89% dos dados de entrada provinham da cache, a 5% do preço dos dados não armazenados em cache. As execuções também ficaram mais rápidas: de, pelo menos, 22,5 minutos na configuração original do Modelo B para cerca de quatro minutos com o fluxo de trabalho otimizado no GPT‑6.1 Sol.
Média de 3 execuções, com barras de erro do desvio-padrão. ≥: a média inclui uma execução interrompida por limite ou não concluída, pelo que o valor real é, pelo menos, igual ao indicado.
As barras usam o tema azul. Compare os efeitos da cache com a barra do limite maior, de 480 mil carateres.
Os marcadores das execuções e as barras de erro do desvio-padrão são reconstruções aproximadas a partir da imagem original; os valores das execuções e os desvios-padrão subjacentes não estavam disponíveis.
Média de 3 execuções, com barras de erro do desvio-padrão. ≥: a média inclui uma execução interrompida por limite ou não concluída, pelo que o valor real é, pelo menos, igual ao indicado.
As barras usam o tema azul. Compare os efeitos da cache com a barra do limite maior, de 480 mil carateres.
Os marcadores das execuções e as barras de erro do desvio-padrão são reconstruções aproximadas a partir da imagem original; os valores das execuções e os desvios-padrão subjacentes não estavam disponíveis.
A investigação também mostrou como a gestão do histórico influenciava a capacidade do agente de produzir sequer uma resposta. Ao dar ao GPT‑6.1 Sol mais espaço para reter o histórico de navegação, o número de execuções que produziram uma resposta passou de três em 18, com o limite de histórico menor, para todas as 18, com o limite maior, sempre 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.
«Antes, o custo limitava os modelos que podíamos oferecer aos clientes para estas cargas de trabalho. Ao tornar o agente mais eficiente, podemos oferecer aos clientes um modelo melhor e mais rápido, reduzindo ao mesmo tempo os nossos custos operacionais.»
A Asana já disponibilizou as alterações à navegação na StackAI e está a desenvolver ferramentas que facilitem a repetição de experiências semelhantes. A prazo, a equipa planeia incorporar estes testes nas avaliações da plataforma, para que os clientes e as equipas internas possam comparar o custo, o tempo de execução e a qualidade das respostas ao configurar os seus agentes.
«A velocidade de entrega já não é o fator limitativo; é a atenção humana. Estamos perto de um mundo em que cada engenheiro é um gestor de produto a liderar uma frota de agentes.»
A Asana está agora a usar o GPT‑6 Astra no Codex para testar funcionalidades do produto antes do lançamento: o Astra navega na plataforma, experimenta diferentes entradas e comunica erros aos revisores humanos de controlo de qualidade. Hidalgo vê aqui a base de um novo ciclo de desenvolvimento de software, com várias sessões de agentes na nuvem a testar funcionalidades em paralelo.
O estudo completo está disponível nos blogues da Asana(abre numa nova janela) e da StackAI(abre numa nova janela).
