Testes do agente de navegador da Asana reduzem custos de modelo em 76x com GPT-6.1 Sol

A Asana afirma que seu agente de navegador ficou 76 vezes mais barato e cinco vezes mais rápido depois que engenheiros mudaram a forma como ele retinha e armazenava em cache o histórico de navegação. Os testes do agente de navegador da Asana usaram o GPT-6 Astra no Codex para investigar o sistema, executar experimentos e analisar rastros. O GPT-6.1 Sol então apresentou o menor custo estimado de modelo no fluxo de trabalho otimizado.

O resultado principal parece uma vitória do modelo. A descoberta mais importante diz respeito à arquitetura do agente. A Asana mudou quando o agente removia capturas de tela, ampliou o limite de histórico e armazenou em cache o registro crescente de etapas anteriores. Essas mudanças reduziram o processamento repetido, preservando as informações de que o agente precisava para concluir sua tarefa.

Essa distinção importa para toda empresa que avalia agentes de navegador. Uma equipe pode migrar para um modelo menos caro e ainda desperdiçar tokens por causa de uma gestão de contexto inadequada. Ela também pode escolher um modelo mais capaz, preservar o histórico correto e reduzir os custos operacionais totais. O experimento da Asana coloca essas duas estratégias em concorrência direta.

O estudo do agente de navegador da Asana mudou mais do que o modelo

Os maiores ganhos da Asana vieram do redesenho do fluxo de trabalho em torno do modelo, e não apenas da substituição de um modelo por outro.

A empresa publicou os resultados em 8 de outubro de 2026, seguidos por um estudo de caso da OpenAI em 9 de outubro. O trabalho se concentrou em um agente de navegador dentro do StackAI, a plataforma de automação sem código que a Asana adquiriu no início de 2026.

O StackAI permite que clientes criem agentes que navegam em sites, coletam informações e preenchem formulários em aplicações empresariais. Esses fluxos de trabalho se assemelham à navegação humana, mas o agente subjacente envia repetidamente instruções, ferramentas, texto de páginas, capturas de tela e ações anteriores a um modelo.

Esse contexto repetido cria um padrão caro. Cada nova etapa inclui mais histórico do que a anterior. Se o conteúdo prévio continua mudando, um provedor não consegue reutilizar de forma confiável sua representação armazenada em cache.

O agente original da Asana armazenava em cache instruções fixas e definições de ferramentas. Ele não armazenava de forma eficaz o histórico de navegação em crescimento. O agente também removia capturas de tela antigas e cortava texto com frequência, alterando partes anteriores da solicitação.

Essas edições quebravam o prefixo estável, que é o início inalterado compartilhado por solicitações consecutivas ao modelo. Quando esse prefixo mudava, grande parte do histórico de navegação precisava ser processada novamente.

Frank Hidalgo, diretor de tecnologia da StackAI na Asana, orientou o GPT-6 Astra no Codex a inspecionar esse comportamento. O modelo mapeou a base de código, revisou como as solicitações eram montadas e identificou variáveis que valia a pena testar.

A Asana afirma que o estudo resultante incluiu 144 execuções principais em quatro modelos de fronteira. Foram testadas seis políticas de cache e capturas de tela, dois limites de histórico e três execuções para cada condição. A empresa realizou posteriormente um acompanhamento menor.

Cada configuração recebeu a mesma tarefa. O agente de navegador precisava coletar seis campos para cada um dos 32 livros de um catálogo público de demonstração. Isso significava encontrar 192 fatos, mantendo contexto suficiente para retornar uma resposta final correta.

Os modelos incluíam o GPT-6.1 Sol e três alternativas anônimas. A Asana chamou esses sistemas de Modelos A, B e C. O Modelo B alimentava a configuração original de produção, enquanto o Modelo C representava um modelo mais recente do mesmo provedor.

A Asana não revelou esses provedores, o que limita comparações competitivas diretas. No entanto, afirmou que o fluxo de trabalho otimizado com GPT-6.1 Sol custou 76 vezes menos que a configuração original do Modelo B. Ele também foi concluído cerca de cinco vezes mais rápido.

Desde então, a empresa lançou as mudanças de navegação no StackAI. Isso transforma o exercício de uma comparação de laboratório em uma mudança de produção, embora a Asana não tenha publicado dados amplos de desempenho no nível dos clientes.

Por que o cache de prompts se tornou o mecanismo decisivo

A variável decisiva foi se o agente conseguia manter inalterada a maior parte de seu histórico acumulado entre chamadas.

O cache de prompts armazena o estado computacional reutilizável associado a um prefixo de prompt inalterado. Solicitações posteriores podem reutilizar esse estado em vez de processar o mesmo material desde o início.

O cache não armazena uma resposta pronta para reprodução. O modelo ainda processa material novo e gera uma nova resposta. Ele simplesmente evita repetir o trabalho para o contexto elegível que permanece idêntico.

O guia de cache de prompts da OpenAI recomenda posicionar instruções estáveis e material de referência antes do conteúdo que muda. Ele também aconselha aplicações a acrescentar o histórico da conversa em vez de reescrever repetidamente turnos anteriores.

O design original da Asana violava esse segundo princípio durante execuções no navegador. Em quase todas as etapas, ele removia uma captura de tela anterior e, às vezes, cortava texto mais antigo. A solicitação seguinte, portanto, diferia no meio de seu histórico.

Armazenar em cache apenas o prompt fixo do sistema não conseguia capturar a maior fonte de entrada repetida. O agente de navegador acumulava texto de páginas, capturas de tela, observações e resultados de ferramentas à medida que avançava pela tarefa.

A Asana testou uma política diferente chamada poda em lote. Podar significa excluir contexto mais antigo antes que o histórico acumulado se torne grande demais. Sob a política selecionada, o agente mantinha até 20 capturas de tela antes de reduzir o conjunto à mais recente.

Essa abordagem criou períodos mais longos de histórico somente por acréscimo. O agente podia adicionar novas observações ao final sem alterar o conteúdo anterior em cada etapa. Assim, uma parte maior de cada solicitação permanecia elegível para reutilização.

O fluxo de trabalho otimizado também aumentou o limite de histórico de texto de 120.000 caracteres para 480.000 caracteres. Isso deu ao agente mais espaço para preservar fatos coletados anteriormente, em vez de descartá-los.

O limite maior teve um efeito importante na conclusão. Com a configuração de histórico menor, o GPT-6.1 Sol produziu uma resposta em apenas três de 18 execuções. Com a configuração maior, ele respondeu em todas as 18 execuções, segundo a Asana.

A Asana afirma que cada uma dessas execuções com histórico maior retornou a resposta correta. O resultado desafia a suposição de que reduzir o contexto de forma agressiva sempre melhora a eficiência de agentes.

Excluir contexto reduz o tamanho imediato de uma solicitação. No entanto, isso pode forçar um agente a revisitar páginas, repetir chamadas de ferramentas ou seguir adiante sem evidências coletadas anteriormente. Também pode interromper a reutilização do cache quando a exclusão altera o prefixo da solicitação.

A melhor política, portanto, depende da economia total da tarefa. As equipes precisam considerar o processamento de entrada, a navegação repetida, as taxas de conclusão, a qualidade das respostas e a recuperação de execuções que falharam.

A Asana relatou que 89 por cento da entrada do GPT-6.1 Sol veio do cache na configuração otimizada. Essa proporção explica por que um modelo mais capaz poderia se tornar a opção testada menos cara para a tarefa completa.

Esse é o mecanismo central por trás do resultado do agente de navegador da Asana. A empresa não pediu apenas que um modelo usasse menos tokens. Ela reorganizou o fluxo de trabalho para que tokens repetidos se tornassem mais baratos de processar.

Mais contexto ajudou o agente a concluir as tarefas de forma confiável

O experimento sugere que a solicitação mais barata nem sempre faz parte do fluxo de trabalho concluído mais barato.

Os criadores de agentes frequentemente tratam o contexto como um recurso que precisa ser minimizado. Essa visão faz sentido porque prompts longos aumentam o processamento de entrada e podem se aproximar do limite de contexto de um modelo.

Agentes de navegador complicam esse cálculo. Suas observações anteriores funcionam como memória de trabalho. Remover um endereço, atributo de produto, aviso ou resultado de navegação pode deixar o agente incapaz de concluir sua resposta final.

O limite de histórico menor produziu resultados especialmente fracos para alguns modelos. A Asana relata que o Modelo C não retornou nenhuma resposta em 18 execuções nessa condição. O GPT-6.1 Sol retornou apenas três respostas.

Essas falhas não foram evidência de que os modelos não possuíam capacidade geral de navegação. O limite maior de histórico mudou o resultado. Ambos os modelos responderam a todas as execuções depois de receber espaço suficiente para reter o registro necessário.

O resultado apoia um princípio de engenharia mais amplo. A política de contexto precisa se adequar ao modelo e à tarefa. Um único limite universal de tokens não produzirá comportamento equivalente em sistemas diferentes.

Os modelos podem consumir contexto em ritmos diferentes porque produzem descrições, chamadas de ferramentas e rastros de raciocínio distintos. Um agente pode atingir um limite de poda após um pequeno número de ações. Outro pode continuar por muito mais tempo.

A Asana descobriu que modelos mais novos ou mais capazes não usavam automaticamente o limite menor de forma mais eficiente. O Modelo C começou a cortar o histórico muito antes do Modelo A durante o fluxo de trabalho testado.

O experimento também constatou que o cache sozinho era insuficiente. Com o limite maior de histórico, o cache sem poda em lote custou mais do que não usar cache em três dos quatro modelos.

Esse resultado parece contraditório até que a estrutura da solicitação seja considerada. Um cache oferece valor limitado quando a aplicação reescreve constantemente o material que pretende reutilizar. O sistema paga para processar um histórico em mudança sem receber hits de cache suficientes no futuro.

A política selecionada pela Asana alinhou três decisões. Ela armazenou o histórico em cache, preservou uma sequência somente por acréscimo por períodos mais longos e forneceu um limite maior antes que a poda se tornasse necessária.

Um acompanhamento levantou outra questão. A Asana testou configurações que mantinham todas as capturas de tela em vez de podá-las. Algumas apresentaram custos por chamada menores do que a política selecionada nessa tarefa específica.

A empresa não tratou isso como prova de que a poda deveria desaparecer. Fluxos de trabalho mais longos podem exceder os limites de contexto, enquanto alguns provedores cobram mais por operações de cache. Um agente que se desvia para navegação desnecessária também precisa de limites firmes.

A Asana recomenda limites para etapas, tokens e custo total de execução. Esses limites impedem que um agente incorreto ou confuso expanda seu histórico indefinidamente. A compactação, que substitui o histórico mais antigo por um resumo menor, oferece outra opção.

A compactação introduz sua própria contrapartida. Ela reduz o tamanho do contexto, mas altera o prompt anterior, potencialmente interrompendo a reutilização do cache. Um resumo também pode omitir um detalhe que posteriormente se torna importante.

As equipes precisam de registros fora do prompt ativo por esse motivo. A Asana registrou solicitações, rastros e resultados no Command, sua plataforma de entrega de software. Engenheiros e agentes adicionais puderam então revisar o experimento completo.

Um registro durável também sustenta uma base de conhecimento pesquisável. O agente ativo recebe apenas o contexto necessário para sua etapa atual, enquanto os revisores mantêm acesso à trilha completa de evidências.

Essa separação ajuda as equipes a distinguir a memória do modelo da memória organizacional. O contexto de trabalho de um agente deve permanecer limitado. O registro do experimento deve permanecer detalhado o suficiente para reproduzir decisões e investigar falhas.

GPT-6 Astra transformou o trabalho de avaliação em uma tarefa para agentes

A Asana usou um modelo para melhorar o sistema e outro para executar o fluxo de trabalho de produção otimizado.

O GPT-6 Astra trabalhou dentro do Codex como agente de pesquisa e engenharia. O GPT-6.1 Sol serviu como um dos modelos de execução do agente de navegador. Tratar essas funções como separadas evita uma interpretação enganosa dos resultados.

Hidalgo definiu a direção da pesquisa e selecionou as mudanças propostas que valia a pena testar. GPT-6 Astra inspecionou o código, instrumentou solicitações, executou testes preliminares e identificou variáveis influentes.

O código existente não foi projetado para comparações controladas. A Asana afirma que o agente Codex refatorou o sistema para que um frontend e backend compartilhados pudessem sustentar vários fluxos de trabalho experimentais em paralelo.

Em seguida, GPT-6 Astra iniciou o estudo, analisou registros de uso e comparou os resultados. Sessões separadas do modelo revisaram partes do trabalho, enquanto humanos avaliaram as conclusões e aprovaram as mudanças para produção.

A Asana estima que o projeto teria exigido um ou dois meses de trabalho manual. Com o fluxo de trabalho do Codex, a investigação levou cerca de uma semana.

Essa afirmação vem da empresa, e não de uma avaliação independente. Ela também descreve um projeto de engenharia conduzido por um executivo técnico familiarizado com o sistema. Outras equipes não devem pressupor a mesma redução de prazo.

Ainda assim, o fluxo de trabalho ilustra uma mudança significativa no uso de agentes de programação. O agente não apenas implementou um recurso a partir de uma especificação concluída. Ele ajudou a projetar e executar uma investigação empírica.

A investigação gerou rastros, resultados experimentais, tickets e pull requests. Esses artefatos passaram pelo Command antes de as mudanças chegarem à produção do StackAI.

Esse processo importa mais do que a alegação de que um agente de IA executou a maior parte do trabalho mecânico. Sem registros estáveis, os revisores não conseguem determinar de forma confiável qual configuração foi executada, por que ela falhou ou se uma melhoria relatada resistiu a mudanças no código.

O estudo da Asana afirma que os humanos estabeleceram o objetivo e os padrões de avaliação. Eles também revisaram as conclusões. O agente de programação ampliou a quantidade de experimentação que a equipe conseguia executar entre essas decisões.

Hidalgo descreveu uma rotina de definir um objetivo antes de dormir e revisar os resultados na manhã seguinte. Esse padrão assíncrono transforma o tempo de execução do agente em um recurso de engenharia.

Ele também desloca o gargalo. Quando os experimentos se tornam fáceis de gerar, os humanos precisam dedicar mais tempo à seleção de perguntas válidas, à verificação de medições e à rejeição de conclusões enganosas.

O risco é o ruído experimental automatizado. Um agente pode produzir muitas execuções sem produzir evidências sólidas. Testes repetidos continuam vulneráveis ao desenho do benchmark, à variação oculta das tarefas e a erros de pontuação.

A Asana reduziu parte desse risco ao usar uma tarefa fixa e uma resposta de referência preparada de forma independente. Também registrou os próprios contadores de uso do provedor, em vez de estimar o consumo de tokens pelo comprimento do texto.

A empresa executou apenas três repetições para a maioria das configurações. A Asana afirma explicitamente que o estudo revela padrões amplos, não diferenças confiáveis de poucos pontos percentuais.

Essa ressalva é importante. As comparações de 76x e 5x são grandes o suficiente para justificar atenção, mas combinam mudanças de arquitetura e de modelo. Elas não isolam uma vantagem universal para GPT-6.1 Sol.

Os resultados internos da Asana mostram que o Modelo B também melhorou substancialmente após receber o fluxo de trabalho otimizado. A arquitetura respondeu por uma parcela importante do ganho antes que GPT-6.1 Sol reduzisse ainda mais os custos.

O Que a Alegação de 76x Não Comprova

Os resultados publicados são evidências de engenharia convincentes, mas não constituem um benchmark neutro do mercado de agentes de navegador.

O estudo utilizou uma tarefa estruturada em um catálogo público de livros. Cada execução seguiu o mesmo objetivo e coletou o mesmo conjunto de campos. A navegação empresarial real frequentemente envolve autenticação, layouts em mudança, instruções ambíguas e recuperação após diálogos inesperados.

Um fluxo de trabalho que se destaca na extração repetitiva pode se comportar de forma diferente em compras, suporte, conformidade ou operações internas. Essas tarefas podem exigir julgamento entre diversos sistemas, em vez de coleta repetida de páginas semelhantes.

O teste do agente de navegador da Asana também comparou GPT-6.1 Sol com três modelos anonimizados. Os leitores não podem inspecionar configurações específicas dos provedores nem determinar como cada alternativa se comportaria após otimização independente.

A Asana afirma que os Modelos B, C e GPT-6.1 Sol tinham preços padrão comparáveis durante o estudo. O Modelo A foi posicionado como uma alternativa mais barata. O artigo público não identifica seus nomes.

Esse anonimato impede que o resultado se torne um ranking limpo de modelos. Também protege o estudo contra uma deriva para comparações entre fornecedores que não seriam sustentadas por testes suficientes.

A maior manchete compara o fluxo de trabalho otimizado de GPT-6.1 Sol com a configuração de produção original do Modelo B. Duas variáveis mudaram ao mesmo tempo: o modelo e a arquitetura do agente.

Uma comparação mais restrita encontrou uma redução de custo de quatro vezes quando a nova política foi aplicada dentro de GPT-6.1 Sol. A diferença restante veio da comparação desse sistema otimizado com a base de produção mais antiga.

Isso não enfraquece o resultado. Muda a conclusão. O estudo sustenta a combinação de modelos capazes com uma arquitetura consciente do contexto, e não tratar uma troca de modelo como a solução completa.

A melhoria de cinco vezes no tempo de execução traz ressalvas semelhantes. Algumas execuções originais do Modelo B atingiram um limite de etapas antes de serem concluídas. Portanto, sua duração medida representa um limite inferior para a tarefa completa.

A qualidade da conclusão também exige observação contínua. A Asana relata que todas as execuções nas melhores condições encontraram os fatos necessários e produziram respostas corretas. O material público não inclui cargas de trabalho de clientes nem taxas de erro de longo prazo.

A replicação independente continua limitada porque o estudo completo depende da implementação e dos rastros da Asana. A empresa compartilhou seus métodos e um estudo mais completo, mas as equipes externas ainda precisam de seus próprios conjuntos de tarefas.

A aquisição da StackAI pela empresa também cria um interesse comercial no resultado. A Asana concluiu a aquisição da StackAI em maio de 2026 para ampliar fluxos de trabalho de agentes entre sistemas.

A OpenAI tem um interesse semelhante em demonstrar como GPT-6 Astra e GPT-6.1 Sol sustentam agentes empresariais. Ambas as fontes primárias fornecem detalhes técnicos valiosos, mas nenhuma representa uma auditoria independente do setor.

As condições operacionais também podem mudar o resultado. A disponibilidade de cache tem vida útil limitada. Clientes simultâneos podem ter históricos diferentes, e o contexto personalizado pode reduzir a quantidade de material compartilhado.

Os requisitos de privacidade podem restringir quais conteúdos entram no contexto do modelo. As equipes de segurança também precisam de controles para capturas de tela, credenciais, registros de clientes e informações sensíveis coletadas durante a navegação.

O cache não elimina essas obrigações. Ele altera o comportamento de computação e cobrança, não a necessidade de governança de dados. As equipes ainda precisam de políticas de retenção, controles de acesso, trilhas de auditoria e tratamento de falhas.

A conclusão correta é, portanto, condicional. A Asana encontrou uma otimização de alto valor para um agente de navegador específico e a levou à produção. Outras equipes devem tratar o mecanismo como uma hipótese testável.

O Próximo Teste É o Desempenho em Fluxos de Trabalho Reais de Clientes

Os próximos três sinais mostrarão se o resultado da Asana se torna um modelo operacional reutilizável ou continua sendo um sólido estudo de caso interno.

O primeiro sinal é uma cobertura de avaliação mais ampla. A Asana afirma estar desenvolvendo ferramentas que permitem a clientes e equipes internas comparar custo, tempo de execução e qualidade das respostas ao configurar agentes.

Essas avaliações precisam incluir tarefas além da extração estruturada de catálogos. Conjuntos de testes úteis devem incluir sites em mudança, aplicações autenticadas, falhas parciais, trajetos de navegação longos e instruções com pontos de parada ambíguos.

Se a mesma política de histórico melhorar esses fluxos de trabalho, o argumento em favor da otimização liderada pela arquitetura se fortalece. Se os ganhos diminuírem, a configuração selecionada pela Asana pode estar intimamente ligada à extração repetitiva.

O segundo sinal são evidências da adoção em produção. A Asana já lançou as mudanças de navegação no navegador para o StackAI, mas não publicou resultados agregados de clientes.

A taxa de conclusão deve importar mais do que o custo por chamada. Uma solicitação mais barata oferece pouco valor se os clientes precisarem executar tarefas novamente ou corrigir manualmente resultados incompletos.

As equipes também devem acompanhar a parcela de entrada atendida pelo cache, a duração mediana das tarefas, falhas por limite de etapas e taxas de intervenção humana. Essas medidas revelam se o design otimizado resiste ao tráfego variável de produção.

O terceiro sinal é como provedores de modelos concorrentes e plataformas de agentes respondem. O cache de prompts se tornou um recurso de produto, mas a arquitetura da aplicação determina se os desenvolvedores podem se beneficiar dele.

Os provedores podem competir com retenção de cache mais longa, melhores diagnósticos, tarifas menores para entrada em cache e dados de uso mais claros. Frameworks de agentes podem expor políticas de histórico sem obrigar todos os clientes a criar instrumentação personalizada.

A OpenAI posiciona GPT-6.1 Sol como um modelo para trabalho agentivo capaz com custo operacional menor que GPT-6 Astra. O estudo da Asana oferece a esse posicionamento um exemplo concreto de aplicação.

No entanto, a pressão competitiva mais forte recai sobre as equipes de software de agentes. Os clientes esperarão cada vez mais que as plataformas otimizem automaticamente o custo total das tarefas, em vez de expor apenas um seletor de modelo.

Uma plataforma madura deve recomendar limites de contexto com base no comportamento observado. Ela deve identificar edições que interrompem o cache, comparar políticas e alertar quando a poda faz o agente revisitar páginas anteriores.

Ela também deve reter evidências externas suficientes para que os humanos possam auditar o resultado. Um agente de navegador precisa de memória de trabalho limitada, enquanto a organização precisa de um registro operacional completo.

A Asana planeja incorporar testes semelhantes ao seu sistema de avaliação. Ela também está usando GPT-6 Astra no Codex para navegar por recursos do produto, testar diferentes entradas e relatar bugs para revisores humanos.

Essa extensão amplia a história para além de um único agente de navegador. A Asana está testando se agentes de engenharia podem avaliar continuamente outros agentes e recursos do produto.

A oportunidade é clara. A experimentação automatizada pode avaliar mais configurações do que uma pequena equipe de engenharia conseguiria testar manualmente. Ela também pode encurtar o caminho entre a análise de rastros e mudanças de código revisadas.

A restrição é igualmente clara. A atenção humana se torna o recurso escasso quando os agentes podem gerar experimentos, descobertas e patches continuamente. As equipes devem decidir quais resultados merecem confiança e exposição em produção.

Para desenvolvedores, a ação imediata é medir tarefas completas, e não chamadas isoladas. Registre proporções de acertos de cache, qualidade de conclusão, tempo de execução, novas tentativas e trabalho humano de reparo em condições realistas.

Para compradores empresariais, pergunte aos fornecedores como seus agentes gerenciam históricos crescentes. O nome de um modelo, por si só, não revela se o sistema ao redor preserva contexto útil ou paga repetidamente para processá-lo.

Para trabalhadores do conhecimento, a mudança promete automação de navegador mais rápida e capaz. Seu valor dependerá de os agentes conseguirem reter os fatos necessários sem expor dados sensíveis ou se desviar por etapas desnecessárias.

O resultado do agente de navegador da Asana apresenta um argumento persuasivo de que o design de contexto agora deve acompanhar a seleção de modelos em toda avaliação de agentes. A próxima questão é se essa lição se mantém nos fluxos de trabalho complexos que os clientes realmente querem automatizar.