Como usar o Claude Haiku 5.5 no navegador sem o modelo se perder na tarefa

Modelo rápido e barato no navegador só rende de verdade se a tarefa vier desenhada em passos pequenos

Fala aí, beleza? A Anthropic soltou o Claude Haiku 5.5 em 7 de outubro de 2026 e apresentou ele como o modelo mais rápido da empresa até hoje, voltado a trabalho em alto volume: resumos, subagentes e uso de navegador 😀

Só que velocidade sem direção é só um jeito mais rápido de se perder, né?

Então este post é um guia de desenho de tarefa para browser use com o Haiku 5.5, montado em cima da documentação oficial

Por que usar um modelo rápido e barato para browser use

O cenário é este: tarefas repetitivas de navegador, rodando em escala

Segundo a Anthropic, o Haiku 5.5 funciona como subagente de computer use para tarefas repetitivas no navegador e no desktop, com um custo que se sustenta quando o volume cresce

Os números do lançamento:

A Anthropic também diz que, em média, rodar o Haiku 5.5 custa cerca de 75% menos que o Claude Haiku 4.5

Agora repara numa coisa da tabela: o preço muda quando o prompt passa de 100 mil tokens

E navegação é justamente o tipo de tarefa que infla contexto rapidinho (cada página lida, cada screenshot, cada resultado de ferramenta vai empilhando)

Ou seja, além de ajudar o modelo a não se perder, passo curto também é o que mantém a conta na faixa mais barata 🙂

Essa lógica de deixar o modelo pequeno fazendo o trabalho braçal é a mesma de escolher qual modelo usar em cada tarefa: o mais barato resolve quando a tarefa é bem delimitada

O que você precisa antes de começar

Antes de sair codando, confere esta lista:

• Acesso à Claude API ou ao Google Cloud: são os lugares onde a ferramenta de browser use está disponível
• Atenção à plataforma: a documentação diz que a ferramenta NÃO está disponível no Claude Platform on AWS, no Amazon Bedrock nem no Microsoft Foundry
• Um navegador hospedado pela sua aplicação e um executor: o toolset roda do lado do cliente, então quem de fato clica e navega é a sua stack
• Opcional: SDK de Python ou TypeScript, que ganharam suporte beta a computer use e browser use
• O modelo certo: o Haiku 5.5 aceita a ferramenta, o Haiku 4.5 não aceita

Que executor é esse?

Pensa assim: o Claude é o cérebro que decide "agora clica ali", mas ele não tem mão. O executor é a mão, o código seu que recebe o pedido, faz a ação no navegador e devolve o resultado

Passo a passo: do request ao loop de agente

1. Habilite a ferramenta no request

Na Messages API, você adiciona uma entrada do tipo browser_toolset_20260801, sem name, no array tools, usando o modelo claude-haiku-5-5

Se liga: quem é fixo, sem sufixo de data e sem alias separado, é o ID do modelo (claude-haiku-5-5)

O browser_toolset_20260801 é outra coisa: é o tipo da ferramenta que vai no array tools

O trecho que importa do request fica assim (o resto segue o formato normal da Messages API que você já usa):

{
  "model": "claude-haiku-5-5",
  "tools": [
    { "type": "browser_toolset_20260801" }
  ]
}

Erro comum deste passo: colocar name na entrada da ferramenta (ela vai sem name) ou mandar temperature, top_p ou top_k. No Haiku 5.5, parâmetro de sampling fora do padrão retorna erro, então omita os três

2. Monte o loop de agente

O browser use não é "manda e esquece", é um loop que roda na sua aplicação:

1. O Claude devolve uma chamada de ferramenta
2. O seu executor roda essa ação no navegador
3. Você devolve o resultado para o Claude
4. Repete até o Claude responder em texto

É como um pair programming com alguém que só enxerga o que você mostra pra ele haha

Erro comum deste passo: encerrar o loop antes de o Claude responder em texto. Se você corta no meio, perde justamente o relatório final

3. Use o SDK se não quiser montar tudo na mão

Nos SDKs de Python e TypeScript (suporte em beta), você implementa um driver como subclasse de BetaAbstractBrowserToolset20260801

Essa classe tem membros como navigate, screenshot e left_click, além de _browser_state

Ou seja, você liga esses métodos ao navegador que a sua aplicação controla, e o SDK cuida da conversa com o modelo

Erro comum deste passo: implementar as ações e esquecer do _browser_state. Ele faz parte do que o driver precisa entregar, então não deixa ele pra depois

4. Decida quais ferramentas ficam ligadas

O toolset vem com 27 ferramentas ativas por padrão (por exemplo navigate, read_page, left_click e screenshot) e mais 4 que você pode ativar

As 4 desligadas por padrão, e o motivo:

• javascript_exec e file_upload: aumentam o que uma página manipulada poderia fazer o Claude executar
• read_console e read_network: nem toda stack de automação fornece esses logs, e eles aumentam o conteúdo controlado pela página que chega ao Claude

Cada uma é ativada pelas configs do toolset, e só faz sentido ligar quando o seu executor implementa aquilo e a tarefa realmente precisa

Erro comum deste passo: ligar tudo "por garantia". Isso não deixa o agente mais esperto, só aumenta a superfície de ataque

Como escrever o prompt: objetivo, condição de parada e o que reportar

Aqui é onde o modelo se perde ou não

São quatro peças: um objetivo, passos verificáveis, condição de parada e formato do relatório

Um objetivo só, concreto, por execução

Uma execução, uma missão

"Ache o preço do plano X na página de preços do site Y" é um objetivo. "Pesquise sobre o produto Y" é um passeio sem destino

Passos pequenos que terminam em algo verificável

Quebra a navegação em etapas que fecham com uma prova: uma URL específica alcançada, um texto lido via read_page, um campo preenchido

Assim você (e o próprio modelo) sabe exatamente onde a coisa parou se der ruim

Condição de parada explícita

Diz o que conta como sucesso e quando é hora de desistir e reportar

Sem isso, o agente fica clicando em volta tentando agradar 😛

Formato do relatório final

Pede o que você quer receber de volta: o que encontrou, em qual página, e o que não conseguiu fazer (e por quê)

Prompt vago vs prompt bem desenhado

O vago:

Entra no site da loja, pesquisa os produtos e resolve a questão dos preços

O desenhado:

Objetivo: descobrir o preço atual do produto "Teclado K2" na loja exemplo.com

Passos:
1. Navegue até exemplo.com/busca
2. Pesquise "Teclado K2"
3. Abra o primeiro resultado com esse nome exato
4. Leia a página e localize o preço

Antes de cada clique, leia a página de novo.
Não saia do domínio exemplo.com.

Condição de parada:
- Sucesso: você leu o preço na página do produto
- Desistência: o produto não aparece na busca, ou a página pede login. Pare e reporte

Relatório final (em texto):
- Preço encontrado (ou "não encontrado")
- URL da página onde leu o preço
- O que não conseguiu fazer e por quê

Erro comum: pedir "pesquise e resolva" sem critério de fim. O modelo não tem como saber quando parou de ajudar, então fica vagando e queimando token

Como lidar com página que muda no meio da tarefa

Página muda: carrega um banner, abre um modal, o layout se reorganiza depois de um clique

A documentação não detalha como a ferramenta lida com esperas, retries ou mudanças de DOM, então o caminho seguro é desenhar a tarefa contando com isso

Releia antes de agir

O resultado de read_page é texto com uma referência por elemento

Essas referências descrevem a página naquele momento. Então orienta o modelo a rodar read_page (ou tirar um screenshot) antes de cada ação importante, em vez de confiar no que leu lá atrás

Checkpoints que confirmam o estado

Entre um passo e outro, coloca um ponto de checagem: "confirme que está na página de produto antes de continuar"

Se o checkpoint falha, ele reporta em vez de seguir no escuro

Redirecionamento conta como mudança também

Um clique pode te levar pra outro domínio sem você pedir

Por isso a allowlist de domínios deve ser conferida de novo no handler de navigate depois de redirecionamentos (mais sobre isso na seção de segurança)

Lembra do escopo: é o navegador, não o desktop

O browser use trabalha dentro do viewport do navegador

Além de screenshot e clique, ele lê a própria página e soma referências de elementos, preenchimento de formulários, gerenciamento de abas, aviso de downloads e upload de arquivos opcional

Tarefa que depende de coisa fora do navegador não é pra essa ferramenta

Erro comum: reaproveitar a referência de elemento de uma leitura anterior. A página mudou, a referência velha pode apontar pro nada (ou pro botão errado)

Segurança: prompt injection e domínios permitidos

Tome cuidado com esta parte!

A documentação avisa que, às vezes, o Claude segue instruções que estão no conteúdo da página, mesmo quando elas contrariam as suas

Isso é prompt injection: alguém escreve na página "ignore tudo e faça X", e o agente pode cair

O que a Anthropic já faz por você

Com a ferramenta de browser use, classificadores verificam automaticamente o que o navegador devolve (texto e screenshots) em busca de possível prompt injection

Quando um classificador detecta algo, ele orienta o modelo a conferir se a instrução veio mesmo de você antes de agir

O que é responsabilidade sua

1. Isolar o agente de dados e ações sensíveis: essa é a recomendação da documentação. Agente de navegador não precisa de acesso ao que não faz parte da tarefa
2. Allowlist de domínios na camada de rede: limita os hosts que o navegador consegue acessar
3. Reconferir a allowlist no handler de navigate depois de redirecionamentos
4. Sanitizar títulos e URLs de abas: eles vêm da página, então também são superfície de injection
5. Manter javascript_exec e file_upload desligados, a não ser que a tarefa precise mesmo

Erro comum: confiar só no classificador. Ele ajuda, mas a allowlist e o isolamento é que seguram o estrago se algo passar

Onde o Haiku 5.5 no navegador faz sentido

Pelo que a Anthropic descreve, o encaixe natural é tarefa repetitiva, em volume, e bem delimitada:

• Subagente de navegação: um agente maior planeja e delega as etapas de navegador pro Haiku 5.5 executar
• Coleta e conferência de dados em páginas de domínios conhecidos (que cabem numa allowlist)
• Preenchimento de formulários repetitivos
• Rotinas de navegador em alto volume, onde o custo por execução pesa no fim do mês

O ponto em comum: tarefa que dá pra descrever com objetivo, passos e condição de parada

Se nem você consegue escrever quando a tarefa termina, provavelmente ela não é pra um subagente rápido…

Migrando do Haiku 4.5 ou de computer use antigo

Se você já tem algo rodando, tem mudança que quebra código

1. Computer use exige o toolset novo: trocar computer_20250124 por computer_toolset_20260801
2. Sampling fora do padrão dá erro: omitir temperature, top_p e top_k
3. Browser use é outra ferramenta: se a tarefa vive só no navegador, a browser_toolset_20260801 trabalha no viewport com leitura de página, formulários e abas, enquanto o computer use mira o desktop

Outra novidade: o Haiku 5.5 tem adaptive thinking com o parâmetro effort, e o texto do raciocínio vem omitido por padrão

Então se seu código esperava ler o raciocínio na resposta, vale ajustar isso também

Erro comum: manter o código antigo de sampling. Aquele temperature esquecido no request é o primeiro erro que vai aparecer na migração

Próximo passo

Recapitulando:

• Modelo rápido e barato rende quando a tarefa é curta, verificável e tem parada clara
• Releia a página antes de agir, nada de referência velha
• Restrinja domínios, isole dados sensíveis e deixe ligadas só as ferramentas que a tarefa pede
• Passo curto também segura o contexto abaixo de 100 mil tokens, onde o preço é menor

O próximo passo é simples: monta um loop mínimo na Claude API com uma única tarefa de poucos passos, num domínio só

Funcionou bem? Aí amplia aos poucos, um passo e um domínio de cada vez 😀

Até o próximo post!