- Na mesma tarefa de painel administrativo, o agente de visão manipulou a UI com capturas de tela e cliques, enquanto o agente de API chamou os mesmos handlers da aplicação com respostas estruturadas, deixando apenas a interface como variável de custo
- No prompt básico, o agente de API concluiu a tarefa com 8 chamadas, mas o agente de visão não viu 3 das 4 avaliações pendentes que estavam abaixo da área visível e aprovou apenas 1
- Ao adicionar um UI walkthrough de 14 etapas, o agente de visão também conseguiu concluir, mas a execução levou cerca de 14 minutos e aproximadamente 500 mil tokens de entrada, e esse tipo de orientação específica por si só já representa um custo extra de engenharia
- No resultado geral, com Sonnet o caminho de visão usou em média 53 etapas, 1003 segundos e 550.976 tokens de entrada, enquanto o caminho de API terminou com 8 chamadas, 19,7 segundos e 12.151 tokens de entrada, com muito menos variação de custo e tempo
- A diferença de custo veio da estrutura da interface, e não do desempenho do modelo; quando handlers de evento passam a gerar endpoints HTTP automaticamente, como no Reflex 0.9, o cálculo de custo favorece o caminho de API estruturada em ferramentas internas feitas pela própria equipe
Objetivo do benchmark e configuração do experimento
- O custo foi medido fazendo o mesmo painel administrativo ser operado por um agente de visão e por uma abordagem de API estruturada
- Ao fazer agentes de IA operarem webapps que não oferecem API, o agente de visão tende a virar a escolha padrão
- Em equipes com mais de 20 ferramentas internas, criar uma superfície MCP ou REST para cada app vira um projeto de engenharia separado, então muitas equipes escolhem agentes de visão
- O app de teste é um painel administrativo para gerenciar clientes, pedidos e avaliações, modelado a partir do react-admin Posters Galore demo
- Os dois agentes usaram o mesmo app em execução, o mesmo Claude Sonnet, o mesmo dataset fixo e a mesma tarefa, com apenas a interface como variável
- A tarefa era encontrar, entre os clientes chamados “Smith”, aquele com mais pedidos; localizar o pedido pendente mais recente desse cliente; aprovar todas as avaliações pendentes; e marcar o pedido como entregue
- A tarefa envolve três recursos e inclui filtragem, paginação, consultas entre entidades, leitura e escrita, o que a torna parecida com trabalho típico em ferramentas internas
Os dois caminhos de execução
-
Caminho A: Vision agent
- O Claude Sonnet usou o browser-use 0.12 em modo de visão para manipular a UI com capturas de tela e cliques
-
Caminho B: API agent
- O Claude Sonnet chamou diretamente os endpoints HTTP do app no modo de uso de ferramentas
- Cada ferramenta é mapeada para um ou mais handlers de evento do estado do app, usando as mesmas funções que seriam chamadas por um clique em botão
- Em vez da página renderizada, o agente recebe respostas estruturadas
Por que o agente de visão falhou com o prompt básico
- Os dois agentes foram executados com a mesma tarefa descrita em seis frases
- O agente de API concluiu a tarefa com 8 chamadas
- Listou as avaliações de clientes filtradas como pendentes
- Aprovou cada avaliação
- Marcou o pedido como entregue
- Embora os dois agentes chamem a mesma lógica de aplicação, o agente de API lê diretamente respostas estruturadas em vez de olhar para a página renderizada
- Com o mesmo prompt, o agente de visão encontrou e aprovou apenas 1 das 4 avaliações pendentes antes de seguir para a etapa seguinte
- As 3 avaliações restantes estavam abaixo da área visível da página de avaliações, e o agente não recebeu nenhum sinal de que precisava rolar a tela
- Essa falha não veio de um problema de raciocínio do modelo, mas da ausência de um sinal de que a página renderizada não mostrava tudo
- O agente de API chama os mesmos handlers usados pela UI, mas a resposta inclui o conjunto completo de resultados retornado pelo handler, não apenas as linhas atualmente renderizadas
- O agente de API não precisa interpretar controles de paginação a partir de pixels; ele lê diretamente informações como “página 1 de 4 com 50 itens por página”
Resultado após adicionar uma orientação de UI em 14 etapas
- Para uma comparação justa, o prompt de visão foi reescrito como um UI walkthrough explícito
- Foram nomeados os elementos da UI com os quais o agente deveria interagir em cada etapa, como itens da barra lateral, abas e campos de formulário
- O processo de navegação que antes o agente não conseguia descobrir sozinho foi escrito em 14 instruções numeradas
- Com essa orientação, o agente de visão conseguiu concluir a tarefa
- Ainda assim, a execução levou 14 minutos e consumiu cerca de 500 mil tokens de entrada
- Cada instrução numerada não aparece na contagem de tokens, mas representa um custo real de engenharia
- Para colocar um agente de visão em ferramentas internas, é preciso escrever prompts nesse nível de detalhe ou aceitar a possibilidade de o agente ignorar tarefas silenciosamente
Forma de execução e variabilidade
- O caminho de API foi executado 5 vezes, e o de visão 3 vezes
- O caminho de visão levava de 14 a 22 minutos por execução e consumia de 400 mil a 750 mil tokens, por isso foi limitado a 3 execuções
- O caminho de visão mostrou grande variância entre execuções
- Nas 3 execuções, o tempo de relógio variou de 749 a 1257 segundos
- Os tokens de entrada variaram de 407 mil a 751 mil
- A execução mais curta teve 43 ciclos, e a mais longa 68 ciclos
- Há não determinismo suficiente no ciclo captura de tela → raciocínio → clique para que uma única execução não seja suficiente para estimar um custo representativo
- O caminho de API não apresentou essa variabilidade
- O Sonnet usou exatamente as mesmas 8 chamadas de ferramenta nas 5 execuções
- A contagem de tokens de entrada variou apenas dentro de ±27 nas 5 execuções
- Como as respostas estruturadas não dão motivos para o agente se desviar, ele chama os mesmos handlers na mesma ordem
Resultado geral
| Métrica | Vision agent (Sonnet) | API (Sonnet) | API (Haiku) |
|---|---|---|---|
| Etapas / chamadas | 53 ± 13 | 8 ± 0 | 8 ± 0 |
| Tempo de relógio | 1003 s ± 254 s, cerca de 17 min | 19,7 s ± 2,8 s | 7,7 s ± 0,5 s |
| Tokens de entrada | 550.976 ± 178.849 | 12.151 ± 27 | 9.478 ± 809 |
| Tokens de saída | 37.962 ± 10.850 | 934 ± 41 | 819 ± 52 |
- Os números são média ± desvio padrão amostral (n−1); no caminho de API, n=5, e no caminho de visão, n=3
- Os detalhes completos das execuções estão disponíveis no repositório
- O Haiku não conseguiu concluir o caminho de visão
- A falha é limitada ao schema de saída estruturada do browser-use 0.12, que o Haiku não conseguiu gerar com estabilidade nem em modo de visão nem em modo somente texto
- No caminho de API, o Haiku concluiu em menos de 8 segundos e com menos de 10 mil tokens de entrada, sendo a configuração mais barata entre as testadas
A diferença estrutural de custo
- A diferença de custo vem diretamente da arquitetura
- Um agente que precisa ver para agir sempre paga o custo de ver, mesmo com modelos melhores
- Um modelo de visão melhor pode reduzir a taxa de erro por captura de tela, mas não reduz o número de capturas necessárias para chegar aos dados relevantes
- Cada renderização vira uma captura de tela, e cada captura de tela vira milhares de tokens de entrada
- Os dois agentes passam pela mesma lógica da aplicação
- Ambos fazem filtragem, paginação e atualizações do mesmo jeito que a UI
- A diferença está no que cada um lê em cada etapa
- O agente de visão lê pixels e precisa renderizar e interpretar todos os estados intermediários
- O agente de API lê respostas estruturadas vindas dos mesmos handlers, e essas respostas já contêm os dados que a UI pretendia mostrar
- Modelos melhores podem reduzir o custo por etapa, mas não o número de etapas, porque isso é determinado pela interface
Quando o menor custo de engenharia de API muda a decisão
- O benchmark foi executado com baixo custo graças ao Reflex 0.9
- O Reflex 0.9 inclui um plugin que gera automaticamente endpoints HTTP a partir dos handlers de evento de aplicações Reflex
- O argumento estrutural não depende do Reflex, mas ele permitiu executar o caminho de API sem uma base de código separada
- O ponto central é o que se torna possível quando o custo de engenharia da superfície de API se aproxima de zero
- Agentes de visão continuam adequados para aplicações fora do seu controle direto
- Produtos SaaS de terceiros
- Sistemas legados
- Aplicações que não podem ser modificadas
- Em ferramentas internas construídas pela própria equipe, a conta de custo passa a pender para o outro lado
Escopo do experimento e observações
- Os resultados de visão se limitam ao modo de visão do browser-use 0.12; outros agentes de visão podem se comportar de forma diferente
- O runner do caminho B transformou os endpoints gerados automaticamente em uma pequena superfície REST de cerca de 30 linhas
- O agente vê isso como ferramentas como
list_customerseupdate_order - O dataset é fixo e pequeno
- 900 clientes
- 600 pedidos
- 324 avaliações
- O comportamento com dados em escala de produção não foi medido
- O agente de visão foi executado via
ChatAnthropicdo LangChain - O agente de API foi executado usando diretamente o SDK da Anthropic
- A contagem de tokens reportada é de tokens de entrada sem cache
Materiais para reprodução
- O repositório inclui a geração dos dados seed, a demo react-admin modificada, os scripts dos dois agentes e os resultados brutos
1 comentários
Comentários do Hacker News
Aqui está como tornar caro para um agente navegar por um site: mover os elementos da tela quando o mouse se mexe, fazer a UI só funcionar se o movimento do mouse parecer natural, trocar por nomes aleatórios os rótulos dos botões via JS toda vez que alguém visitar, e obrigar a rolar até o fim da tela para revelar tarefas extras ocultas
Pensando bem, isso parece um app SaaS corporativo comum
É interessante e meio deprimente ver todo mundo correndo para fazer isso porque a IA precisa. Não tinham disposição para fazer esse tipo de coisa pelos humanos, mas fazem pela IA, aparentemente só porque sentem que isso vai beneficiá-los pessoalmente mais do que alguma pessoa abstrata no futuro
[0] https://www.cs.unm.edu/~dlchao/papers/p152-chao.pdf
Isso era antes da IA generativa, mas mesmo assim tivemos que combinar OCR, entrada de usuário simulada e captura de impressão para conseguir operar o app e exportar os dados. Fico imaginando o que os desenvolvedores teriam feito se soubessem das APIs de DRM do Windows que bloqueiam captura de tela, ou que texto pode ser recuperado com facilidade de arquivos PostScript com formatação mínima
Ironicamente, o processo anterior a substituir isso era dar a mão de obra barata no exterior acesso remoto somente leitura a todos os dados do sistema, o que era um risco de segurança muito maior do que funcionários autorizados automatizando o trabalho com uma ferramenta local de um fornecedor confiável, sem acesso à rede
Estou criando algo para resolver exatamente esse problema[1]
Ainda não está destacado na landing page, mas em essência damos ao agente um pequeno conjunto de ferramentas para navegar pela superfície do app e, em especial, recursos comuns da API de funcionalidades do macOS ligadas à acessibilidade
Depois que o agente explora o app, ele pode escrever um workflow repetível e então executá-lo via CLI, tipo
invoke chrome pinTabUsamos acessibilidade porque, no fim, ela é um bom DOM para apps. Nem todo app implementa isso perfeitamente, mas apps suficientes implementam para isso ser muito útil
[1] https://getinvoke.com - a landing page atual é voltada a criadores, então ainda não cobre esse caso de uso
Dá para ver como as células verdes podem orientar um LLM a ler só partes específicas da tela ou usar OCR, quanto texto já vem embutido no motor de acessibilidade, e como isso pode levar não só a MCP, mas também a geradores de código que você mesmo cria e executa para rastrear a camada de acessibilidade de um workflow
Acho isso um terreno extremamente fértil. Os grandes laboratórios precisam usar abordagens que funcionem em várias plataformas e workflows arbitrários, e a visão de tela inteira é o menor denominador comum. Abordagens específicas por plataforma são um espaço aberto realmente interessante
Só parece essencial garantir que não sejam compartilhados workflows que extraiam informações do usuário, como senhas
O grande problema é que apps demais expõem esses elementos de forma péssima. Minha abordagem era usar UIAccess ou uma passada única de modelo de visão para criar templates de UI: https://github.com/willwade/app-automate?tab=readme-ov-file#...
Um contra-argumento no reddit é que a experiência real é quase o oposto. O UIA parece uniforme na documentação, mas WPF, WinForms e Win32 expõem padrões de controle diferentes, então no fim você precisa de handlers por toolkit. O Qt só expõe algo se QAccessible tiver sido compilado e o plugin de acessibilidade carregado em runtime, o que quase nunca acontece em binários distribuídos. O Electron é tão opaco no Windows quanto no macOS, porque no fim é o mesmo Chromium desenhando em canvas. A verdadeira divisão não é sistema operacional contra sistema operacional, e sim toolkit nativo contra todo o resto
Dizer que escrever uma superfície MCP ou REST para cada app é um projeto de engenharia separado não é necessariamente verdade se o backend estiver separado o bastante do frontend e se as operações do lado do servidor tiverem sido desenhadas com cuidado e de forma geral
Fico pensando se não daria para fazer um agente de visão “mapear” a UI e depois expor isso para outros agentes como um conjunto de interfaces que parecem mais uma API
Pelo que entendo, hoje o agente de visão precisa saber tanto que “próxima página” mostra mais resultados quanto que ele deveria buscar mais resultados em primeiro lugar
Se um agente explorasse só a UI num ambiente de teste e criasse alguma descrição estruturada dos vários elementos e ações da interface, e outro agente recebesse essa descrição, será que ele se sairia melhor do que um agente que precisa ao mesmo tempo explorar a UI e executar a tarefa?
Por exemplo, “buscar todas as avaliações” poderia ser definido como ir a cada página e clicar em “ver avaliação completa” para cada resumo de avaliação, enquanto “ir a cada página” poderia ser definido como começar na página 1, padrão da aba de avaliações, e apertar “próxima” até o botão desaparecer
Aí o segundo agente já teria essa técnica disponível e poderia pensar menos sobre como explorar, enquanto o primeiro só precisaria explorar a UI uma vez, em ambiente de teste, sem medo de errar. Posso ter entendido completamente errado o texto, mas ainda assim acho interessante
No fim você precisa atravessar HTML/CSS/JavaScript complexos. Para o bem ou para o mal, não é raro um app web ter 5 a 10 MiB
Em vez de abordar “de baixo para cima”, praticamente invertendo o que o motor do navegador faz, parece mais fácil abordar “de cima para baixo”, olhando a representação visual como um humano faria
Ainda restaria um pouco de trabalho de visão para a navegação, mas seria um trabalho visual simples, sem necessidade de raciocínio
Imagem→imagem usa a imagem inteira
Não entendo bem a premissa. Se é um app interno, por que recorrer a uso de computador em vez de fazer o agente criar uma CLI ou um MCP?
Claro que uso de computador é pior. É um último recurso. Não deveria ser usado quando se está lidando com estado em um DB que eu possuo
Na verdade, o impressionante é ser só 50 vezes pior
Concordo totalmente. Recentemente, ao criar ferramentas visuais com IA, experimentei as duas abordagens, e a latência e o custo do uso genérico de navegador em estilo “agente” são fatais para apps de consumo em tempo real hoje
APIs estruturadas, até mesmo só com cadeias de chamadas de LLM usando schema JSON estrito, não só são 40 vezes mais baratas, como também são o fator decisivo para conseguir colocar um produto estável no ar. Uso de computador é um demo legal; quem paga a conta do servidor são as APIs estruturadas
Se você acha que LLMs são boas para alguma tarefa, construa em cima do Openrouter um middleware bem definido e altamente determinístico para esse objetivo
APIs estruturadas exigem pensamento de verdade, e hoje em dia pensar não é visto como algo positivo
Há alguns meses fiz uma CLI desktopctl para controlar apps de GUI inspirada no
kubectlNo Mac, ela combina OCR com a Accessibility API para representar a UI em Markdown e expor ações de mouse e teclado
A ideia central é que o loop de percepção “rápido” seja totalmente local, otimizado em GPU para tokenização da UI e detecção de mudanças, enquanto o loop de controle “lento” exige ida e volta ao LLM, com uma interface Markdown eficiente em tokens na saída da CLI
Os controles usam identificadores relativamente estáveis, então o agente pode roteirizar ações genéricas como
desktopctl pointer click --id btn_savesem precisar do loop de tokenização da UIhttps://github.com/yaroshevych/desktopctl/tree/main
Bons apps mostram bem a informação e são otimizados para clicar, digitar etc.
As melhores GUIs aproveitam muito bem a memória muscular, então são candidatas perfeitas para serem roteirizadas via CLI. Por exemplo, uma sequência simples como “abrir o app Notes, apertar Cmd+F, digitar o termo de busca e ler a lista de resultados” pode virar um único comando Bash chamado por um agente de IA
Sempre fui cético com todo esse conceito de “uso de computador”. É como contratar alguém para entrar na sua casa e dizer que ele pode dormir na sua cama, usar seu banheiro, comer a comida da sua geladeira, ver TV e que a senha do cofre também está ali
Só que essa pessoa que você contratou é um macaco
No momento, sites que tentam bloquear Claude Code ou outros agentes de IA estão travando uma batalha perdida
Uso de computador ainda está no começo, e o que parece impedir a adoção em massa é a quantidade de tokens necessária. Se um agente testar em falso 10 comandos de CLI antes de encontrar o certo, quase não ligamos
Mas com agentes visuais como uso de navegador ou uso de computador, mesmo quando eles chegam ao lugar certo no fim, ninguém tem paciência de esperar 20 minutos para clicar em um único botão. Quando os tokens ficarem mais baratos e mais rápidos, é bem possível que apareçam modelos que usem interfaces de UI com a mesma naturalidade com que usam uma CLI