Asana corta custo de modelo em 76x, mas a economia veio do fluxo
No mesmo modelo, corrigir como o agente fazia cache e cortava o histórico de navegação reduziu o custo estimado em 29x. Trocar para GPT-6.1 Sol adicionou 2.6x. O custo estava no fluxo.
Ouça este artigo · 5 min
Narração completa do artigo, gerada por IA.
O número manchete é 76x. O número mais útil é 29x, e foi alcançado sem trocar de modelo.
A OpenAI publicou a história em 9 de outubro. A plataforma StackAI da Asana, que a Asana adquiriu, executa um agente de navegador que clientes usam para navegar em sites, preencher formulários e coletar informações sem código. Frank Hidalgo, CTO da StackAI na Asana, direcionou o GPT-6 Astra no Codex para investigar por que o agente era caro, testar correções e comparar os resultados. O estudo resultante de 144 execuções testou o GPT-6.1 Sol e três outros modelos de fronteira, que a OpenAI rotula como Modelos A, B e C, em uma tarefa: coletar seis campos para cada um dos 32 livros de um catálogo de demonstração público.
O fluxo otimizado no GPT-6.1 Sol teve média de $0.47 em custo estimado de modelo e cerca de quatro minutos por execução, contra pelo menos $36.21 e 22,5 minutos para a configuração original de produção no Modelo B. Esse é o 76x e o 5x. Mas veja como isso se decompõe.
| Configuração | Custo estimado de modelo por execução | O que mudou |
|---|---|---|
| Configuração original de produção, Modelo B | Pelo menos $36.21 | Linha de base; algumas execuções atingiram o limite de passos |
| Fluxo otimizado, ainda Modelo B | $1.24 | Apenas cache e política de contexto: 29x |
| GPT-6.1 Sol, orçamento maior, política antiga | $1.97 | Modelo novo, comportamento de cache antigo |
| GPT-6.1 Sol, fluxo otimizado | $0.47 | Política cortou mais 4x; 2,6x abaixo do Modelo B otimizado |
O histórico era reenviado a preço cheio
A primeira descoberta do Astra foi trivial. O agente fazia cache das suas instruções fixas e definições de ferramentas, mas não do histórico crescente de texto de página e capturas de tela que coletava pelo caminho, então cada requisição reenviava esse histórico pelo preço cheio sem cache.
A correção óbvia não teria funcionado. O agente descartava capturas de tela mais antigas e cortava texto em quase todos os passos, então o histórico mudava constantemente, e um cache de prompt só ajuda quando o início do prompt permanece idêntico. Cada corte o invalidava.
A política vencedora deixava as capturas de tela se acumularem até 20 antes de cortar de volta para a mais recente. O histórico anterior então permanecia inalterado por longos trechos entre remoções, e o cache podia fazer seu trabalho. No GPT-6.1 Sol, 89% da entrada vinha do cache a 5% do preço sem cache, e cada chamada era cerca de 3x mais barata.
A lição geral: uma política de contexto que parece econômica por passo pode ser cara por execução. Cortar para economizar tokens pode quebrar o cache e custar mais do que economiza.
Manter mais memória concluiu mais execuções
A segunda descoberta é sobre qualidade, não custo. Com o orçamento menor de histórico de 120.000 caracteres, apenas 3 das 18 execuções do GPT-6.1 Sol produziram uma resposta. Com 480.000 caracteres, todas as 18 produziram, cada uma correta. O agente original não era apenas caro; ele perdia fatos que já havia lido e às vezes revisitava páginas para encontrá-los novamente.
É por isso que preço por token é a unidade errada. Uma configuração mais barata que falha cinco em cada seis vezes não é barata. A medida que importa é custo por tarefa concluída e correta, a mesma unidade que defendemos quando a linha de preço do Claude Haiku 5.5 transformou o tamanho do contexto em uma decisão de arquitetura.
O método é a parte transferível
Hidalgo estima que a investigação teria levado de um a dois meses manualmente; com o Astra rodando experimentos durante a noite, levou cerca de uma semana. As requisições, traces e resultados de cada sessão foram registrados no Command, a plataforma de entrega de software da Asana, e depois transformados em tickets e pull requests antes de chegar à produção. A Asana diz que planeja incorporar esses testes nas avaliações da StackAI para que os clientes possam comparar custo, runtime e qualidade das respostas ao configurar seus agentes.
Essa é a parte que vale copiar: configuração de agente tratada como uma variável experimental, com execuções controladas, traces registrados e um caminho revisável até a produção. A maioria dos times compara modelos. Poucos comparam orçamentos de contexto, políticas de cache e retenção de capturas de tela no mesmo modelo, e os números da Asana sugerem que é aí que estava a maior parte do dinheiro.
Os limites são reais. Esses são custos estimados de modelo, não custos totais de infraestrutura ou engenharia. É uma tarefa, em uma história de cliente de um fornecedor, e os modelos concorrentes são anonimizados. O histórico, as ferramentas e o comportamento de cache do seu agente serão diferentes.
Três verificações são baratas de rodar em qualquer agente de produção esta semana. Meça a taxa de acerto do cache por passo, não por sessão. Descubra onde o agente reescreve seu próprio histórico, porque cada reescrita reseta o cache. E antes de rotear para um modelo diferente, rode o atual com uma política de contexto diferente. Você pode encontrar seu 29x antes de precisar do 2.6x de ninguém.