A ideia parecia genial: em vez de construir integrações API para cada sistema, deixe a IA “ver” a tela e clicar nos botões como um humano faria. O problema? Essa abordagem custa 45 vezes mais do que chamar uma API estruturada — e os números não mentem.

Um benchmark publicado pelo time da Reflex colocou lado a lado dois agentes executando exatamente a mesma tarefa em um painel administrativo. O resultado foi tão brutal que qualquer empresa rodando agentes de “computer use” em produção deveria parar e recalcular a conta agora mesmo.

O Benchmark que Expôs o Problema

O teste era simples mas realista: encontrar um cliente chamado “Smith” com mais pedidos, localizar o pedido pendente mais recente, aprovar reviews em espera e marcar o pedido como entregue. O dataset continha 900 clientes, 600 pedidos e 324 reviews — nada absurdo, é o tipo de volume que qualquer SaaS pequeno tem.

De um lado, um agente de visão usando Claude Sonnet, controlando o navegador via screenshots — o famoso “computer use”. Do outro, o mesmo Claude Sonnet chamando endpoints de API estruturada que espelham as ações da interface.

Aqui estão os números:

Leu direito: 550 mil tokens de entrada contra 12 mil. O agente de visão consumiu 45x mais tokens para fazer a mesma coisa. E demorou 51x mais tempo.

Mas não é só questão de tokens. A variância conta uma história assustadora: o agente de visão oscilou entre 749 e 1.257 segundos entre as tentativas. O agente de API? Consistente como um relógio suíço, com desvio padrão de praticamente zero. Em produção, variância alta significa que você não consegue prever SLAs, não consegue dimensionar infraestrutura, e acaba over-provisionando tudo.

Por Que a Diferença É Tão Absurda

Cada screenshot que o agente de visão processa é convertido em tokens. Um screenshot de 1280×720 pode facilmente virar 1.500 a 3.000 tokens. E o agente não tira um screenshot — ele tira dezenas. A cada ação (clicar em um botão, rolar a página, esperar carregar), ele precisa de um novo screenshot para entender o que mudou.

Pense no loop completo de uma ação simples como “clicar no botão Aprovar”:

1. Tirar screenshot da tela atual (~2.000 tokens)
2. Enviar ao modelo com o contexto da conversa (~5.000+ tokens acumulados)
3. Modelo decide: “preciso clicar no botão em (x, y)”
4. Executar o clique
5. Esperar a página atualizar
6. Tirar novo screenshot para confirmar (~2.000 tokens)
7. Enviar ao modelo de novo para decidir o próximo passo

Multiplique isso por 53 passos e você entende os 550 mil tokens.

O agente de API? Manda um JSON, recebe um JSON. Sem imagens, sem interpretação visual, sem ambiguidade. Uma chamada POST /reviews/456/approve retorna {"status": "approved"} em 200ms. Fim.

Eu costumo comparar com pedir comida. O agente de visão é alguém que entra no restaurante, lê o cardápio inteiro na parede, fotografa cada página, analisa as fotos, decide o que quer, grita o pedido e espera o garçom entender. O agente de API é alguém que liga, diz “quero o combo 3” e desliga. Os dois conseguem comer, mas um gasta 45x mais energia.

O Problema Fundamental que Modelos Melhores Não Resolvem

Aqui é onde a coisa fica interessante. Muita gente assume que “quando os modelos melhorarem, computer use vai ficar barato”. O artigo original da Reflex desmente isso com uma observação cirúrgica:

“Um agente que precisa ver para agir sempre vai pagar pelo ato de ver, independente de quão bom o modelo se torne.”

Modelos melhores vão errar menos por screenshot. Vão entender a interface mais rápido. Mas o número de screenshots necessários não muda — porque a arquitetura exige observar o estado visual a cada passo. É um custo estrutural, não um custo de competência.

Pense assim: mesmo que você tenha a visão mais perfeita do mundo, ainda precisa abrir os olhos para ver. E cada vez que abre os olhos no mundo dos LLMs, você paga tokens.

O custo dos tokens pode cair com o tempo? Sim, e já caiu bastante nos últimos dois anos. Mas a razão entre os dois métodos se mantém. Se tokens ficarem 10x mais baratos, computer use fica 10x mais barato E APIs ficam 10x mais baratas. A diferença de 45x permanece.

Quando Computer Use Faz Sentido (Spoiler: Raramente)

Antes de decretar que computer use é inútil, vamos ser justos. Existem cenários onde ele é a única opção:

• Sistemas legados sem API — aquele ERP de 2005 que só tem interface web e o vendor sumiu. Ninguém vai escrever uma API para um sistema que deveria ter sido aposentado há 10 anos, mas que ainda roda porque “funciona”.
• Testes de interface end-to-end — validar que a UI funciona como esperado, do ponto de vista do usuário. Aqui o objetivo é justamente testar a camada visual.
• Automações one-shot — tarefas manuais que você faz uma vez por mês e não justificam uma integração. Preencher aquele relatório em um portal do governo, por exemplo.
• Scraping de sites que bloqueiam bots — quando você precisa navegar como humano para extrair dados. Embora existam soluções melhores para isso também.
• Prototipagem rápida — quando você quer validar se uma automação vale a pena antes de investir em construir a integração proper.

Fora desses casos? API sempre. Não é nem close.

A Conta em Dinheiro Real

Vamos traduzir tokens em dólares. Usando os preços atuais do Claude Sonnet 4.6 ($3 por milhão de tokens de entrada, $15 por milhão de tokens de saída):

Agente de Visão por execução:

• Entrada: 550.976 tokens x $3/1M = $1,65
• Saída: 37.962 tokens x $15/1M = $0,57
• Total: ~$2,22 por tarefa

Agente de API por execução:

• Entrada: 12.151 tokens x $3/1M = $0,04
• Saída: 934 tokens x $15/1M = $0,01
• Total: ~$0,05 por tarefa

Uma empresa que executa 1.000 tarefas dessas por dia gasta $2.220 com computer use versus $50 com API. Por mês, são $66.600 contra $1.500. A diferença de $65.100 por mês paga fácil um engenheiro sênior para construir e manter as integrações API.

E se você usar o Opus em vez do Sonnet? Os custos de entrada sobem para $5/1M e saída para $25/1M. O agente de visão vai para $3,69 por tarefa — $110.700 por mês para as mesmas 1.000 execuções diárias. A essa altura, é mais barato contratar 10 estagiários para fazerem o trabalho manualmente.

E lembra daquela variância enorme? O agente de visão às vezes leva 12 minutos, às vezes 21. Em produção, isso significa timeouts, retries e custos ainda maiores que o benchmark sugere.

O Elefante na Sala: Confiabilidade

Custo nem é o pior problema. É a confiabilidade.

No benchmark, o agente de visão falhou na primeira tentativa. Ele não percebeu que existiam mais dados abaixo do fold — conteúdo que não aparecia no screenshot sem rolar a página. Precisou de um walkthrough detalhado de 14 passos para completar a tarefa. O agente de API? 8 chamadas, zero variância, 100% de sucesso em todos os trials.

Isso revela um problema arquitetural profundo: o agente de visão opera com informação parcial. Ele só vê o que está na viewport. Dados paginados, conteúdo abaixo do fold, menus que precisam de hover — tudo isso é invisível até que o agente tome a ação de revelar. E tomar essa ação custa mais tokens.

Quando você roda computer use em produção, cada mudança no layout pode quebrar o agente:

• Atualizou o CSS? Quebrou.
• Mudou a posição de um botão? Quebrou.
• Adicionou um banner de cookie? Quebrou.
• Mudou de light mode para dark mode? Pode quebrar.
• Adicionou lazy loading nas imagens? Screenshots ficam incompletos.

Com APIs, o contrato é estável — endpoints não mudam por causa de um redesign visual. O POST /orders/123/deliver funciona igual independente de a interface estar usando React, Vue, ou papiro.

Eu já vi empresas gastando mais tempo debugando agentes de computer use do que gastavam fazendo a tarefa manualmente. A ironia é poética.

Como Migrar de Computer Use para APIs

Se você já está usando computer use e quer migrar, aqui vai um roadmap prático:

1. Mapeie as ações do agente

# Antes: agente de visao
agent.click("button.submit-order")
agent.wait_for("div.success-message")
agent.screenshot()

# Depois: agente de API
response = api.post("/orders/123/submit")
assert response.status == "delivered"

2. Priorize por frequencia

Liste todas as tarefas que seu agente executa. Ordene por frequência. As top 5 provavelmente representam 80% do custo. Comece por elas.

3. Use geradores de API automaticos

Frameworks como Reflex, que gerou o benchmark original, já oferecem geração automática de endpoints a partir dos event handlers da UI. A ideia é simples: se o frontend já chama uma função approve_review(review_id), por que não expor essa mesma função como endpoint HTTP?

# Reflex gera endpoints automaticamente
# Cada event handler da UI vira um endpoint HTTP
class AdminState(rx.State):
    def approve_review(self, review_id: int):
        # Essa funcao JA existe para a UI
        # O framework a expoe como POST /api/approve_review
        self.db.update_review(review_id, status="approved")

Isso elimina a barreira clássica de “preciso manter dois codebases” — um para a UI e outro para a API.

4. Fallback para computer use

Mantenha o agente de visão apenas como fallback para os 5% de casos que não têm API. Não como estratégia principal.

O Futuro: MCP e o Fim do Computer Use

O Model Context Protocol (MCP) da Anthropic está acelerando a morte do computer use para tarefas de rotina. Com MCP, qualquer ferramenta pode expor suas funcionalidades como “tools” que agentes chamam diretamente — sem precisar ver a tela.

O ecossistema já tem MCPs para dezenas de serviços:

• Comunicação: Slack, Gmail, Google Calendar, Discord
• Desenvolvimento: GitHub, GitLab, Jira, Linear
• Dados: Postgres, MySQL, MongoDB, BigQuery
• Cloud: AWS, GCP, Azure
• Produtividade: Notion, Airtable, Google Sheets

Cada MCP que é criado é mais um sistema onde computer use se torna desnecessário. A tendência é clara: a camada visual é para humanos. Agentes devem operar na camada de dados.

E o movimento é acelerado: com milhares de desenvolvedores criando MCPs para ferramentas populares, a cobertura cresce exponencialmente. Daqui a um ano, a pergunta não vai ser “esse sistema tem MCP?” mas “por que esse sistema ainda não tem MCP?”.

O Verdadeiro Custo do Hype

Computer use recebeu uma quantidade absurda de hype quando foi lançado. Demos impressionantes mostravam IAs navegando na web, preenchendo formulários, comprando passagens. O problema é que demos otimizam para “uau” e não para “quanto custa em produção”.

Quando a Anthropic lançou o computer use do Claude, o primeiro instinto de muita gente foi “nunca mais preciso construir API”. Na real, é exatamente o oposto: agora você precisa mais do que nunca de APIs bem feitas, porque elas são o caminho 45x mais barato para dar superpoderes aos seus agentes.

As empresas que estão ganhando com agentes de IA não são as que eliminaram APIs — são as que construíram APIs melhores e mais completas para que seus agentes operem com eficiência máxima. Os dados do benchmark da Reflex não deixam margem para interpretação.

Se você está construindo um produto e precisa decidir entre investir em computer use ou em uma API robusta, os dados são inequívocos. Invista na API. Seu agente vai agradecer, seu CFO vai agradecer, e seus usuários vão ter respostas em 20 segundos em vez de 17 minutos.

Um Teste Rápido para Sua Empresa

Quer saber se você está desperdiçando dinheiro com computer use? Responda:

1. Seu agente tira mais de 10 screenshots por tarefa? Provavelmente está caro demais.
2. A mesma tarefa poderia ser feita com uma chamada API? Então deveria.
3. Seu agente quebra quando alguém muda o layout? Red flag enorme.
4. Você não sabe quanto gasta por tarefa em tokens? Hora de medir.

Se respondeu “sim” a duas ou mais, é hora de auditar. A migração para APIs não precisa ser tudo de uma vez — comece pelas tarefas mais frequentes, meça a economia, e use os números para justificar o investimento no resto.

O benchmark da Reflex mostrou 45x. Na sua empresa, o número pode ser diferente — mas aposto que não é menor.

Fonte de inspiração: Computer Use is 45x more expensive than structured APIs — Reflex Blog