Controlar um navegador com um LLM por meio de modelos de uso de computador pode custar cerca de 45 vezes mais do que chamar o mesmo fornecedor via uma API estruturada.
Este guia mostra de onde vem esse custo, quando o uso de computador ainda faz sentido e como projetar um caminho mais barato e confiável com Apidog. A lógica se aplica a OpenAI Operator, uso de computador da Anthropic, uso de navegador, Skyvern e qualquer ferramenta baseada em loop de captura de tela.
Se você escreve APIs para agentes de IA, leia também o guia complementar sobre como escrever arquivos agents.md. As convenções ali ajudam a tornar a API estruturada o caminho padrão para agentes.
TL;DR
- Uso de computador: o LLM analisa capturas de tela e emite cliques, teclas e rolagens.
- APIs estruturadas: o LLM emite chamadas JSON que seu backend executa.
- Para a mesma tarefa, uso de computador costuma consumir 30 a 50 vezes mais tokens.
- Use uso de computador apenas quando não houver API, a API for inviável ou o fluxo depender de uma UI legada.
- Use API estruturada para pagamentos, pesquisa, CRM, ferramentas internas e qualquer operação documentável com OpenAPI.
- Em produção, o padrão mais realista é híbrido: APIs estruturadas para a maioria dos fluxos e uso de computador para a cauda longa.
- Use o Apidog para desenhar esquemas JSON, simular endpoints e testar o fluxo antes de gastar créditos com agentes reais.
Por que a diferença de custo é tão grande
A diferença de 45x não vem de um benchmark isolado. Ela vem do modo como cada abordagem consome tokens.
Uma chamada de API estruturada envia:
- a solicitação do usuário;
- o schema da ferramenta;
- uma resposta JSON curta;
- uma chamada HTTP executada pelo runtime.
Em geral, isso custa algumas centenas de tokens de entrada, dezenas de tokens de saída e um salto de rede.
Um loop de uso de computador envia:
- prompt do usuário;
- captura de tela;
- ação sugerida pelo modelo;
- nova captura de tela;
- nova ação;
- repetição até concluir.
Uma tarefa como “reservar um voo” pode exigir de 12 a 30 rodadas. Cada captura de tela pode custar cerca de 1.500 tokens na resolução típica. Além disso, há novas tentativas quando o modelo clica no lugar errado, rola demais ou precisa fechar banners de cookies.
A própria documentação de uso de computador da Anthropic expõe o custo de tokens por captura de tela. O tópico do HN Uso de Computador é 45x mais caro que APIs Estruturadas estima a penalidade típica entre 30x e 50x, o que é consistente com execuções comparando o mesmo fluxo via navegador e via API no Apidog.
Quando a API estruturada vence
Prefira APIs estruturadas quando qualquer uma destas condições for verdadeira.
1. Existe uma especificação ou contrato
Se o fornecedor publica OpenAPI, GraphQL, REST ou qualquer contrato JSON, o agente pode preencher os campos necessários.
Exemplos:
- criar um cliente no Stripe;
- atualizar um negócio no HubSpot;
- publicar uma mensagem no Slack;
- disparar uma execução de CI;
- consultar pagamentos com falha.
Em vez de abrir o painel e clicar em filtros, o agente pode chamar uma função tipada.
2. A tarefa cabe em um ou dois endpoints
Se a operação é uma chamada simples, usar navegador é desperdício.
Exemplo de intenção:
Mostre os pagamentos com falha de ontem.
Caminho ruim:
Abrir navegador → login → painel → filtro de data → filtro de status → extrair tabela.
Caminho melhor:
Chamar list_failed_payments({ start, end })
3. O fluxo roda sem supervisão
Cron jobs, webhooks e workers de fila não devem depender de um loop visual que pode rolar para o lugar errado.
Chamadas estruturadas são mais fáceis de:
- validar;
- repetir;
- versionar;
- auditar;
- observar em logs.
4. Latência importa
Uma chamada estruturada pode retornar em centenas de milissegundos.
Um loop com 15 capturas de tela pode levar 30 a 90 segundos. Se o usuário está esperando na interface, o caminho da API quase sempre é melhor.
5. Você precisa testar antes de implantar
Simular um endpoint JSON no Apidog é simples. Simular um loop inteiro de navegador é muito mais caro e frágil.
Quando o uso de computador compensa
Uso de computador ainda faz sentido em alguns casos.
Portais legados sem API
Alguns portais de compras, frete, benefícios ou sistemas internos antigos não oferecem API pública. Muitos funcionam com sessões ASP.NET, formulários e interfaces sem contrato de máquina.
Nesses casos, uso de computador pode substituir automações frágeis baseadas em Selenium ou Playwright.
Ferramentas internas que você não pode modificar
Exemplos:
- CRM legado;
- ERP antigo;
- painel SharePoint;
- ferramenta comprada anos atrás e sem equipe mantenedora.
Se você não pode criar uma integração e a empresa não quer contratar iPaaS, o loop de captura de tela pode ser uma solução pragmática.
Tarefas únicas ou de baixo volume
Exemplo:
Pesquise estes 50 concorrentes e salve os destaques no Notion.
Se isso roda uma vez, talvez não valha criar uma API, schema e pipeline.
Fluxos bloqueados por termos ou autenticação
Se a solicitação é “raspar este site via uso de computador”, valide os Termos de Serviço antes. O custo de tokens pode ser o menor problema.
Framework de decisão
Antes de usar computador, passe a tarefa por estas verificações:
| Verificação | Se sim | Se não |
|---|---|---|
| Existe uma API documentada? | Use a API. | Continue. |
| Você pode criar um adaptador leve no servidor? | Construa o adaptador e exponha JSON. | Continue. |
| A tarefa é única ou de baixo volume, por exemplo, menos de 100 execuções/dia? | Uso de computador pode ser aceitável. | Continue. |
| Você aceita pagar 30x a 50x mais tokens por execução? | Use computador. | Pare e negocie acesso à API. |
Na prática, muitos fluxos já falham nas duas primeiras linhas. O uso de computador só deve sobreviver quando não há API e não há como criar um adaptador.
Como uma API estruturada se parece em um agente
A tarefa: buscar pagamentos com falha de ontem.
Em vez de navegar pelo painel do Stripe, exponha uma ferramenta estruturada:
import json
from openai import OpenAI
import stripe
client = OpenAI()
tools = [
{
"type": "function",
"function": {
"name": "list_failed_payments",
"description": "List failed payments in a date range",
"parameters": {
"type": "object",
"properties": {
"start": {
"type": "string",
"format": "date",
"description": "Start date in YYYY-MM-DD format"
},
"end": {
"type": "string",
"format": "date",
"description": "End date in YYYY-MM-DD format"
}
},
"required": ["start", "end"]
}
}
}
]
resp = client.chat.completions.create(
model="gpt-5.5",
messages=[
{
"role": "user",
"content": "Show yesterday's failed payments."
}
],
tools=tools,
tool_choice="auto"
)
call = resp.choices[0].message.tool_calls[0]
args = json.loads(call.function.arguments)
payments = stripe.PaymentIntent.list(
created={
"gte": args["start"],
"lte": args["end"]
},
limit=100
)
print(payments)
Esse fluxo tem:
- um prompt de entrada;
- uma resposta JSON;
- uma chamada HTTP;
- nenhum navegador;
- nenhuma captura de tela.
O equivalente com uso de computador faria login no Stripe, abriria o painel, clicaria no filtro de data, selecionaria intervalo, aplicaria filtro de status, rolaria tabela e extrairia dados visuais. Cada captura adiciona custo, latência e chance de erro.
Projetando o caminho estruturado com Apidog
O motivo mais comum para equipes caírem em uso de computador não é falta de modelo. É falta de uma superfície de ferramenta bem definida.
Use o Apidog para transformar operações do agente em endpoints claros.
Passo 1: modele as operações do agente
Crie endpoints para as ações reais que o agente precisa executar.
Exemplos:
POST /invoices/search
POST /deals/update-stage
POST /messages/send
POST /payments/failed
POST /tickets/escalate
Não tente expor todo o seu backend. Comece com as operações que substituem cliques repetitivos.
Passo 2: defina schemas de entrada e saída
Exemplo de schema para pagamentos com falha:
{
"type": "object",
"properties": {
"start": {
"type": "string",
"format": "date"
},
"end": {
"type": "string",
"format": "date"
},
"status": {
"type": "string",
"enum": ["failed"]
}
},
"required": ["start", "end", "status"]
}
O Apidog gera documentação OpenAPI 3.1 a partir do design da API. Esse contrato pode ser usado como fonte para ferramentas de agente.
Passo 3: conecte o OpenAPI ao framework do agente
OpenAPI 3.1 pode alimentar:
-
toolsda OpenAI; -
tool_useda Anthropic; - carregadores OpenAPI no LangChain;
- integrações próprias com modelos que aceitam JSON Schema.
O objetivo é que o agente tenha funções tipadas em vez de instruções vagas em linguagem natural.
Passo 4: ative o mock server
Antes de conectar produção, ative o servidor de mock do Apidog.
Isso permite:
- testar chamadas do agente;
- validar payloads;
- simular respostas;
- reproduzir casos de erro;
- evitar gasto desnecessário em execuções reais.
O mesmo padrão aparece no guia de desenvolvimento contract-first do Apidog.
Passo 5: reproduza e compare execuções
Registre cada request e response durante a execução do agente. Quando uma chamada falhar, compare com uma execução bem-sucedida.
Procure:
- argumento ausente;
- tipo incorreto;
- enum inválido;
- endpoint errado;
- erro de autenticação;
- mudança de contrato.
Esse ciclo é muito mais simples do que depurar cliques em capturas de tela.
Passo 6: publique e monitore
O mesmo projeto pode servir como:
- documentação pública;
- contrato da ferramenta;
- ambiente de QA;
- mock server;
- referência para observabilidade.
Arquitetura híbrida: usando os dois caminhos
Em produção, muitos agentes acabam com uma arquitetura híbrida:
- 90% das operações passam por ferramentas estruturadas;
- 10% usam computador para portais legados;
- um roteador decide qual caminho usar.
Exemplo de regra no system prompt:
Se a operação solicitada existir em known_tools, use a ferramenta estruturada.
Caso contrário, encaminhe para o agente de navegador.
Exemplo em pseudocódigo:
known_tools = {
"list_failed_payments",
"update_deal_stage",
"send_slack_message",
"create_invoice"
}
def route_task(task_name: str):
if task_name in known_tools:
return "structured_tool"
return "browser_agent"
Claude 4.5, GPT-5.5 e DeepSeek V4 podem seguir esse padrão de roteamento. Para o formato de requisição do DeepSeek, veja como usar a API DeepSeek V4.
Monitore os caminhos separadamente:
structured_api.volume
structured_api.cost
structured_api.latency
computer_use.volume
computer_use.cost
computer_use.latency
Um sinal saudável:
- chamadas estruturadas: maior parte do volume;
- uso de computador: pequena parte do volume, mas parcela relevante do custo.
Se o fallback visual começa a crescer, provavelmente falta um endpoint na superfície estruturada.
Erros comuns a evitar
Ignorar o schema
Não lance agentes apenas com instruções em prosa.
Use JSON Schema rigoroso:
{
"type": "object",
"properties": {
"deal_id": {
"type": "string"
},
"stage": {
"type": "string",
"enum": ["lead", "qualified", "proposal", "closed_won", "closed_lost"]
}
},
"required": ["deal_id", "stage"]
}
Schemas reduzem ambiguidade e tornam erros fáceis de validar.
Deixar o agente criar schemas em runtime
Schema é superfície de produto. Versione como API.
Evite:
Agente decide quais campos enviar.
Prefira:
Contrato definido no Apidog → exportado como OpenAPI → usado pelo agente.
Medir apenas tokens, não custo real
Tokens de imagem podem ter preço diferente. Verifique o console de faturamento do provedor, não apenas seu tracing interno.
Confundir uso de computador com RPA
RPA executa cliques roteirizados em elementos conhecidos. Uso de computador decide visualmente onde clicar a cada tela.
- RPA: mais repetível e barata;
- uso de computador: mais flexível e caro.
Se a UI é estável, Playwright ou Puppeteer podem ser suficientes.
Ignorar latência
O custo de tokens é apenas uma parte. Um fluxo visual de 60 segundos pode quebrar a experiência do usuário.
Se o usuário está esperando, prefira API.
Alternativas antes do uso de computador
Se o fornecedor não tem API pública, considere estas opções antes de usar um agente visual.
1. Browser automation com Playwright ou Puppeteer
Vantagem:
- custo baixo por execução após desenvolvimento.
Desvantagem:
- quebra quando a UI muda;
- exige manutenção.
2. Conectores Zapier ou Make
Se o fornecedor já tem conector em uma plataforma iPaaS, talvez seja mais barato pagar a licença do que manter integração própria.
3. APIs privadas
Muitos painéis web conversam com endpoints JSON internos. Você pode inspecionar a aba Network das DevTools, documentar os endpoints no Apidog e tratá-los como semi-estáveis.
Esse padrão também aparece em testes de API sem o Postman.
Uso de computador deve ser o último recurso, não o padrão.
Casos de uso reais
Uma equipe de conformidade fintech substituiu um relatório Stripe de 6 etapas baseado em uso de computador por três chamadas estruturadas. O custo de tokens caiu 92% e o tempo de execução passou de 41 para 2 segundos.
Um agente de suporte de SaaS B2B manteve uso de computador para apenas um fluxo: um portal de compras sem API. Todo o resto foi roteado por chamadas OpenAPI projetadas no Apidog. O gasto total de tokens caiu de US$ 4.200 para US$ 310 por mês.
Um fundador solo usou uso de computador uma vez por semana para atualizar um painel do Notion a partir de um ERP legado. O custo 45x em uma execução semanal era irrelevante; criar uma integração levaria semanas. Esse é um bom caso para uso de computador.
Conclusão
O custo 45x é um sinal de arquitetura. Sempre que existir uma API, um endpoint interno ou um adaptador simples, prefira uma ferramenta estruturada.
Resumo prático:
- Uso de computador custa 30x a 50x mais tokens do que uma chamada estruturada equivalente.
- Um endpoint documentado com JSON Schema vence em custo, latência e confiabilidade.
- Arquiteturas híbridas são normais: estruture os 90% principais e use computador para a cauda longa.
- Simule a superfície da ferramenta antes de conectar modelos ativos.
- Monitore APIs estruturadas e uso de computador separadamente.
Próximo passo: abra o Apidog, crie um projeto para a superfície de ferramentas do seu agente e ative o mock server. Em uma hora, você saberá se o fluxo que parecia exigir uso de computador pode ser reduzido a duas chamadas estruturadas.
FAQ
O uso de computador é alguma vez mais barato do que uma API estruturada?
Não por execução. Tokens de captura de tela dominam o custo. Ele pode ser mais barato no total apenas quando o custo de integração seria maior do que anos de execução, o que geralmente só acontece em fluxos de volume muito baixo e sem API disponível.
Como simular uma superfície JSON para um agente?
Projete os endpoints no Apidog, ative o mock server integrado e aponte o agente para a URL do mock. Cada requisição retorna JSON realista sem atingir produção. Veja também ferramentas de teste de API para engenheiros de QA.
Posso usar OpenAPI para chamadas de ferramentas em qualquer modelo?
Sim. O parâmetro tools da OpenAI, o bloco tool_use da Anthropic e o endpoint de tool calling do DeepSeek V4 podem consumir schemas OpenAPI 3.1 ou JSON Schema. O Apidog exporta esse contrato. Veja como usar a API DeepSeek V4.
O GPT-5.5 ainda oferece suporte ao uso de computador?
A OpenAI oferece uso de computador por meio do Operator e da API de Respostas. O perfil de custo é semelhante ao da Anthropic quando o fluxo depende de capturas de tela. A recomendação vale independentemente do fornecedor.
E quanto a Skyvern, uso de navegador e agentes open source?
A matemática é parecida. Modelos abertos podem reduzir o preço por chamada, mas o número de rodadas e o tamanho das capturas continuam pesando. Onde existe API estruturada, ela ainda tende a vencer por ampla margem.
Como sei que falta um endpoint para uma tarefa de agente?
Observe quando o agente tenta recorrer ao navegador. Isso geralmente indica uma lacuna na superfície estruturada. Adicione o endpoint no Apidog, regenere o schema e atualize as ferramentas do agente.
Top comments (0)