antonio leandro

claude, na prática

Computer use tool

tutorial · 02 · ferramentas · Anthropic · · ~51 min de leitura do original

a tese

o modelo não precisa que o software tenha api: screenshot, mouse e teclado bastam — e o preço disso é 4.500 tokens de definição, mais uma imagem por turno, mais o risco de obedecer o que está na tela

o que fica

  1. As coordenadas que Claude devolve estão no espaço de pixels do screenshot que você mandou, não no do seu monitor: se você reduziu a imagem antes de enviar, precisa reescalar o clique de volta antes de aplicá-lo.
  2. A API não redimensiona screenshot por você — uma imagem acima do limite do modelo volta como erro de validação em vez de ser reduzida.
  3. Um lote de ações roda em ordem e para no primeiro erro, mas todo bloco tool_use ainda precisa de um tool_result: deixar um sem resposta faz a requisição inteira ser rejeitada.
  4. Declarar o toolset custa cerca de 4.500 tokens de input antes de qualquer pixel, e cada screenshot devolvido custa de 1.000 a 1.800 tokens.
  5. Podar um screenshot velho a cada turno destrói o prompt cache, porque muda o prefixo toda vez; a recomendação é podar em lote, a cada 25 turnos, mantendo os três últimos.
  6. Claude obedece instruções que encontra dentro da tela; há classificadores que marcam injeção em screenshot e forçam confirmação humana, e a própria doc diz que isso não dispensa isolar o ambiente.

o problema

Software sem API não se automatiza — ou só se automatiza ao preço de um script preso a uma versão específica da tela. E boa parte do trabalho que sobra para uma pessoa num dia de escritório é exatamente isso: abrir o navegador, achar o menu certo do LibreOffice, arrastar a coluna, esperar o app carregar. Um modelo que enxerga imagem sabe descrever essa tela. Descrever não move o cursor.

A primeira resposta da Anthropic foi uma ferramenta única, chamada computer, com um campo action no input escolhendo entre clicar, digitar e fotografar a tela. Funcionava, mas pedia header beta, exigia declarar display_width_px e display_height_px na definição, e na prática rendia uma ação por round trip — o guia de migração precisa pedir, em letras, que o loop passe a iterar sobre todos os blocos da resposta em vez de ler só o primeiro. O computer_toolset_20260801 reorganiza a mesma capacidade.

a ideia

Uma entrada {"type": "computer_toolset_20260801"} no array tools entrega 17 ferramentas membro: screenshot, zoom, os cinco tipos de clique, arrasto, movimento de cursor, scroll, type, key, hold_key, wait. Claude não chama uma ferramenta genérica com um parâmetro de ação; ele chama left_click direto, e o bloco carrega "toolset_name": "computer" para dizer de onde aquele nome veio.

Nada disso roda do lado da Anthropic. O modelo devolve intenções e você executa: o container, o display virtual, o clique real e a captura da tela são todos seus. Daí a segunda decisão de projeto — se cada round trip é caro, o modelo devolve várias ações juntas. Clicar na barra de busca, digitar o termo, tirar screenshot: um turno só.

como funciona

O loop é o de sempre. Você manda mensagens, a resposta volta com stop_reason: "tool_use" e um ou mais blocos assim:

{
  "type": "tool_use",
  "id": "toolu_01Ppr3sZ3TnE9m6VUu4RyH2K",
  "name": "type",
  "toolset_name": "computer",
  "input": { "text": "pictures of cats" }
}

O despacho é pelo par (toolset_name, name), não pelo nome sozinho: uma ferramenta custom sua pode se chamar screenshot também, e o browser use tool tem membros homônimos.

O lote muda uma regra em relação ao parallel tool use normal: os blocos rodam em sequência, não em paralelo, porque o type depende do clique anterior ter dado foco. Se um falha, você não roda os seguintes — mas ainda responde todos, com is_error: true e o texto exato Not executed: an earlier computer action in this turn failed. Claude lê quais passaram, qual quebrou e quais foram puladas, e replaneja. Se o seu loop não sabe fazer isso, disable_parallel_tool_use limita a uma ação por turno.

Coordenadas são sempre em pixels do screenshot que você devolveu, origem no canto superior esquerdo. zoom não muda esse referencial: mesmo depois de inspecionar uma região ampliada, Claude continua falando no espaço da tela inteira. Retina de Mac captura em 2x — ou você reduz a imagem, ou divide as coordenadas por dois.

o que isso custou

O custo em tokens é grande e visível. A definição do toolset soma cerca de 4.500 tokens de input por requisição, dos quais uns 410 são só do zoom, que dá para desligar em configs. Cada screenshot custa de 1.000 a 1.800. Passando de 20 imagens numa requisição, todas passam a valer um limite por lado mais apertado.

Isso empurra para podar histórico, e podar briga com o cache: derrubar um screenshot por turno muda o prefixo toda vez e invalida tudo. A recomendação é podar em bloco, mantendo os três últimos e limpando a cada 25 turnos. No Fable 5.1 nem isso — remover um screenshot antigo invalida os blocos de thinking posteriores, e a saída é redimensionar mais e limpar do lado do servidor.

O resto das limitações a doc assume de frente. Latência alta demais para interação humana; o caso de uso indicado é o que roda no fundo. Coordenadas alucinadas. Scroll que às vezes não pega, e a saída é teclado. Planilha exige left_mouse_down e left_mouse_up na mão e ainda pode falhar. E prompt injection: instruções escondidas numa página ou numa imagem podem sobrepor as suas. Existe um classificador que, ao suspeitar, faz o modelo pedir confirmação — o que serve mal para loop sem humano, e por isso dá para desligar. As quatro precauções continuam de pé de qualquer jeito: VM dedicada, sem credencial sensível, allowlist de domínio, humano confirmando o que tem consequência real.

onde isso aparece hoje

O toolset é a forma madura do padrão descrito em Tool use with Claude e Implementing tool use, aplicado ao caso em que o “resultado” é uma imagem da tela — o mesmo canal de Vision, agora fechando o ciclo com ação. Na prática, quase toda a engenharia de um agente de desktop vira gestão de contexto: quantas imagens carregar, onde pôr o breakpoint de Prompt caching, quando limpar. Para agentes que atravessam várias sessões, a doc aponta para Effective harnesses for long-running agents e sugere verificação de ponta a ponta no início de cada sessão, não só no fim.

lido na íntegra por pipeline de llm, revisado por antonio leandro antes de publicar ·