Resultado de 76x do Agente de Navegador do GPT-6.1 Sol: O que a Asana realmente mediu

A Asana publicou um estudo de custos de agente de navegador em 8 de outubro de 2026, e o desenvolvedor do GPT-6.1 Sol escreveu sobre isso no dia seguinte sob a manchete "Asana reduz os custos de modelo em 76x em testes de navegador com GPT-6.1 Sol." O 76x é real no sentido de que alguém o mediu, mas não é um fato sobre o preço do GPT-6.1 Sol. É um fato sobre o que acontece quando você corrige um cache de prompt quebrado em um agente de navegador e depois troca o modelo que fica por trás dele. A mesma otimização, executada no modelo que a Asana já tinha em produção — um modelo que ela chama de Model B — reduziu o custo em 29x por si só. O GPT-6.1 Sol forneceu os 2,6x restantes. Os experimentos foram executados pelo GPT-6 Astra trabalhando no Codex, e o modelo por trás da linha de base é um modelo de um concorrente que a Asana chama de Model B, então dois níveis do mesmo fornecedor e um rival não nomeado aparecem todos na história. O que segue separa a parte do resultado que você pode copiar na segunda-feira da parte que pertence à stack específica da Asana.

A comparação, declarada exatamente

A stack da Asana para isso é a StackAI, a plataforma de automação de fluxos de trabalho que ela adquiriu, executando um agente de navegador que navega por sites, preenche formulários e coleta informações sem código. A tarefa de teste era restrita e concreta: coletar seis campos para cada um dos 32 livros de um catálogo de demonstração público. Isso é representativo do que alguns clientes executam, e também é pequeno o suficiente para que um estudo de 144 execuções caiba em uma semana.

O design consistia em seis políticas de cache e captura de tela em dois orçamentos de histórico, três execuções por condição, em quatro modelos — 144 execuções, mais um acompanhamento de 12 execuções. Os custos foram calculados a partir dos próprios contadores de tokens de cada fornecedor, e cada resposta foi avaliada em relação a uma referência preparada de forma independente. Os quatro modelos eram três modelos de fronteira não nomeados (Modelos A, B e C) e o GPT-6.1 Sol. O Modelo A é um modelo menor e mais barato de outro laboratório, lançado no outono de 2025, custando metade do GPT-6.1 Sol. O Modelo B é o modelo que estava em produção, mesmo laboratório que o A, lançado no verão de 2026, custando o mesmo que o GPT-6.1 Sol. O Modelo C é uma versão mais recente do Modelo B, lançada no outono de 2026, também custando o mesmo que o GPT-6.1 Sol. Os três permanecem anônimos em ambos os textos, então a comparação não é reprodutível por um leitor — vale a pena saber antes de tratar 29x como um número sobre o modelo de outra pessoa. Estes são números publicados da Asana e da OpenAI, não números auditados de forma independente.

A escada de resultados, todos os números da própria Asana:

• Produção de linha de base no Model B — pelo menos US$ 36,21 por execução, pelo menos 22,5 minutos por execução. Algumas execuções de linha de base atingiram o limite de etapas antes de terminar, então a média é um piso, e não uma média real.

• Model B, agente otimizado — $1.24 por execução, 4x mais rápido que o baseline, uma redução de custo de 29x.

• GPT-6.1 Sol, o mesmo agente otimizado — US$ 0,47 por execução, cerca de quatro minutos, uma redução de custo de 76x e 5x mais rápido.

• GPT-6.1 Sol, antes vs depois da correção — $1.97 a $0.47 por execução, um corte de 4x apenas de mudanças de cache e poda.

Como a linha de base é um limite inferior, o próprio 76x é um piso. A leitura honesta é "no mínimo 76x", não "76x".

O que realmente mudou, e por que não é um recurso do modelo

O mecanismo é a mecânica de cache de prompt, e vale a pena entendê-lo porque se aplica a qualquer agente que você execute em qualquer modelo. Um agente de navegador reenvia suas ferramentas, seu prompt de sistema e seu histórico crescente de texto de página e capturas de tela a cada chamada ao modelo. O cache de prompt desconta a parte repetida, mas apenas o prefixo inalterado mais longo — no momento em que algo no meio da requisição muda, o reaproveitamento se rompe a partir daí.

O agente de produção da Asana tinha duas falhas que se agravavam mutuamente. Ele fazia cache das suas instruções fixas e definições de ferramentas, mas não do seu histórico de navegação. E editava esse histórico em quase todos os passos: descartava a captura de tela anterior a cada vez e cortava o texto mais antigo para caber num orçamento de histórico. Cada edição invalidava o prefixo, de modo que o cache teria sido quase inútil mesmo se tivesse sido ativado. O relatório da Asana observa que, nos modelos testados, as leituras de cache custavam de 0,05x a 0,1x o preço padrão de entrada — portanto, o prêmio era grande e o agente estava sistematicamente recusando-o.

A correção tem duas partes. Primeiro, faça cache do histórico também, com um marcador de cache no resultado mais recente da ferramenta. Segundo, pare de editá-lo a cada chamada: mantenha as capturas de tela e pode-as em lotes numa proporção de 20 para 1, de modo que o agente mantenha até 20 e depois reduza para a mais recente. Cerca de 19 chamadas consecutivas então reutilizam um prefixo inalterado. Aumente o orçamento do histórico de 120.000 para 480.000 caracteres para que o texto antigo pare de ser cortado, e a aritmética fecha: no GPT-6.1 Sol, cada chamada custou cerca de 3x menos porque 89% da entrada veio do cache.

A descoberta que mais importa aqui é negativa. Fazer cache do histórico sem poda em lote, no orçamento maior, custou mais do que não fazer cache nenhum em três dos quatro modelos — o cache era continuamente reescrito e raramente lido. Infraestrutura de cache que é ativada sem uma disciplina de histórico somente-anexação é uma forma de pagar um custo extra de escrita em troca de nada. Esse modo de falha é independente do modelo, e é a razão pela qual a mesma correção melhorou o Model B em 29x.

Onde a escolha do modelo realmente valeu a pena

Retire a correção do fluxo de trabalho e compare o que é comparável: no mesmo agente otimizado, o GPT-6.1 Sol saiu 2,6x mais barato que o Model B, pelo mesmo preço de tabela. O fator extra é o comportamento de acerto de cache, não a tabela de preços. O Sol leu 89% de sua entrada do cache; a Asana não publica a parcela equivalente para o Model B, portanto, o 2,6x é um resultado medido sem uma decomposição publicada. Trate isso como "este modelo, nesta carga de trabalho, usou melhor o seu cache", e não como uma vantagem geral de 2,6x sobre um modelo que não podemos nomear.

O lado de execução é inequívoco: 5x mais rápido que a linha de base, com o fluxo de trabalho Sol otimizado em cerca de quatro minutos, contra uma linha de base de pelo menos 22,5 minutos. A velocidade importa para o custo em agentes que cobram por token, porque um modelo lento que entra em loop paga por seus loops.

Para quem está calculando isso: as tarifas padrão da API do GPT-6.1 Sol são US$ 2,00 por milhão de tokens de entrada, US$ 0,10 por milhão de tokens de entrada em cache e US$ 10,00 por milhão de tokens de saída, e seu desconto de leitura de cache é 0,05x a tarifa de entrada — o mais profundo da tabela de preços atual da OpenAI. O GPT-6 Astra, o modelo que fez o trabalho de engenharia no Codex, custa US$ 10,00 de entrada e US$ 50,00 de saída, que é a diferença de cinco vezes na qual o enquadramento de lançamento da OpenAI se apoiou. O motivo pelo qual o estudo produziu execuções de US$ 0,47 em vez de execuções de US$ 2 não é a tabela de tarifas; é que 89% de uma solicitação muito repetitiva foi cobrada a um vigésimo da tarifa de entrada. Em um agente com uso intenso de cache, a linha de desconto faz mais trabalho do que o preço de destaque, e, no nosso próprio catálogo, os preços de tabela dos provedores são repassados com 0% de markup, então, quando um fornecedor mexe em um medidor de entrada em cache, isso aparece na sua fatura no mesmo dia.

O outro número no estudo: o orçamento de histórico decidiu se o agente respondia ou não.

O custo por execução é o número que todos citam, mas o resultado mais útil do estudo diz respeito à confiabilidade, e é esse que um operador deve ler primeiro.

• No orçamento de 120.000 caracteres, o Modelo C não respondeu em nenhuma das suas 18 execuções e o GPT-6.1 Sol respondeu em 3 de 18 — a maioria das execuções atingiu o limite de etapas sem produzir uma resposta.

• Com 480.000 caracteres, cada execução em ambos os modelos respondeu, cada uma com a resposta correta.

• Os modelos mais novos consumiram o orçamento menor mais rápido: o Modelo C cortou seu histórico pela primeira vez na chamada 10, o Modelo A na chamada 64.

• No fluxo de trabalho otimizado, cada execução concluiu a tarefa e retornou a resposta correta, e cada execução nas melhores condições em cada modelo encontrou todos os 192 fatos que deveria coletar.

Esse é um argumento diferente de "mais barato". Um orçamento de histórico pequeno demais em um modelo capaz produz um agente que falha por ficar sem espaço, e falha por atingir o limite de passos, que é a forma mais cara de falhar — você paga pela execução inteira e não recebe nada. Aumentar o orçamento elevou o custo por chamada e reduziu o custo por resposta, que é o único número que um responsável pela produção deveria acompanhar. Se você está avaliando um modelo ainda não comprovado para um agente como este, o padrão de baixo risco é manter sua rota de produção no modelo em que você confia e colocar o novo atrás de um failover ou de uma rota dividida, para que uma falha por limite de passos apareça como um fato de roteamento em vez de um incidente. Todo modelo nesta comparação é acessível por meio de uma API para mais de 200 modelos com os preços de tabela dos provedores repassados sem alteração, o que também torna o desconto de leitura de cache comparável entre fornecedores na mesma fatura, em vez de cinco painéis.

O que tirar disso, em ordem

Se você opera um agente de navegador ou de uso de computador, três alavancas no estudo da Asana valem a pena acionar antes de consultar uma tabela de preços:

• Torne o prefixo da requisição somente anexável. Qualquer edição, por chamada, no meio do histórico zera a reutilização do cache a partir desse ponto em diante.

• Faça a poda em lotes. O estudo de seguimento da Asana descobriu que manter cada captura de tela custou 1,2x menos por chamada do que a melhor condição de poda no Model B e no GPT-6.1 Sol, e cerca de 5% menos no Model C. A poda continua importante para tarefas longas, janelas de contexto pequenas e leituras de cache caras — mas o argumento a favor de uma proporção de lote de 20:1 tem a ver com a estabilidade do cache, não com as próprias capturas de tela.

• Defina o orçamento de histórico por modelo e verifique-o em relação ao seu limite de etapas. Um orçamento que serve para um modelo pode ser insuficiente para o próximo.

Duas salvaguardas do estudo são fáceis de ignorar, e não deveriam ser. Nenhuma execução atingiu o orçamento de 480.000 caracteres, então o orçamento nunca limitou essas execuções — mas um agente à deriva cresce em direção ao seu limite de contexto, e, se o cache quebrar, cada chamada paga o preço cheio. Limites máximos de etapas, tokens e custo por execução são o que restringe uma execução ruim. Separadamente, o estudo usou três ou quatro execuções por condição, com contagens variáveis de chamadas, o que a própria Asana diz ser suficiente para mostrar padrões amplos e não o bastante para separar condições que diferem em alguns pontos percentuais. Não leia um delta de 5% nisso e reconstrua seu pipeline em torno disso.

A parte que é genuinamente nova, e a parte que não é.

As ressalvas sobre a configuração merecem ser declaradas sem rodeios: quatro modelos, três deles sem nome, uma tarefa estreita de 32 livros, os próprios contadores instrumentados da Asana e um relato do próprio fornecedor que hospeda o resultado. Nada aqui foi reproduzido fora da Asana. Mas o mecanismo está totalmente especificado — histórico que só permite acréscimos, marcador de cache no último resultado da ferramenta, poda em lote, orçamento maior, medir leituras de cache com os contadores do provedor — e é o tipo de descoberta que sobrevive a ser atribuída ao laboratório errado. O 76x é um número da Asana em uma carga de trabalho da Asana. O motivo de valer a pena ler é que ele demonstra uma regra que você pode testar em uma tarde: um agente que edita seu próprio histórico a cada passo está pagando o preço integral por uma conversa que já teve.