Claude Haiku 5.5 em tarefas longas no computador: até onde dá para confiar?

Modelo rápido e barato não dispensa supervisão quando a tarefa no computador se estende por muitas etapas

Fala aí, beleza? A Anthropic acabou de soltar o Claude Haiku 5.5, lançado em 7 de outubro de 2026, com disponibilidade imediata na Claude Platform, AWS, Google Cloud e Microsoft Azure 😀

E ele chegou com um salto absurdo em computer use, que é justamente o ponto deste post

A pergunta aqui não é se ele é bom (spoiler: é muito massa pelo preço), e sim outra: até onde dá pra confiar nele quando a operação tem um monte de etapas encadeadas?

Bora ver?

O que a Anthropic lançou com o Claude Haiku 5.5

A Anthropic descreve o Haiku 5.5 como o modelo pequeno mais barato, mais rápido e mais capaz que ela já lançou

O foco declarado é trabalho de alto volume e sensível a custo e latência: resumos, compactações, consultas a banco de dados, classificação, atendimento ao vivo e uso de navegador

Se liga nos números técnicos:

• Janela de contexto de 1M tokens
• Até 128 mil tokens de saída
• IDs: claude-haiku-5-5 na Claude API e no Google Cloud, anthropic.claude-haiku-5-5 no Amazon Bedrock

O Haiku 5.5 tem effort ajustável?

Tem, e é a primeira vez que um Haiku ganha isso, junto com adaptive thinking

E o que é esse effort? É um controle de quanto o modelo "se esforça" pra pensar antes de responder, tipo escolher entre responder no reflexo ou parar e raciocinar

Na API ele fica em output_config.effort, com os níveis none, minimal, low, medium, high e xhigh

O padrão é medium

Pra tarefa longa no computador isso importa bastante, porque nem toda etapa pede o mesmo nível de raciocínio… mas a decisão de onde subir o effort continua sendo sua, não do modelo

Claude Haiku 5.5 no OSWorld: como ele se compara

O número que chamou atenção no lançamento foi o de computer use:

Sair de 15,7% pra 72,4% de uma geração pra outra é insano, né?

O que o OSWorld mede?

O OSWorld-Verified avalia se um agente consegue completar tarefas reais no computador, como editar documentos, navegar na web e gerenciar arquivos

Tudo isso interagindo com uma máquina virtual Ubuntu por mouse e teclado, igual uma pessoa faria

Ou seja, é um benchmark bem próximo do uso que a gente quer fazer

Por que 72,4% não é garantia na sua tarefa?

Aqui mora o detalhe que muita gente ignora

Benchmark é uma taxa de acerto média sobre um conjunto de tarefas, não uma promessa de que a SUA tarefa vai dar certo

E numa operação longa a conta piora: cada etapa é uma chance de erro, e um erro lá no começo (clicar no botão errado, abrir o arquivo errado) contamina tudo o que vem depois

O agente continua confiante, seguindo um caminho que já desviou faz tempo…

Por isso a pergunta certa não é "o modelo é bom?", e sim "em quais pontos eu confiro se ele ainda está no caminho certo?"

Nenhuma fonte oficial informa quantos passos o Haiku 5.5 aguenta de forma confiável, então esse limite é você que descobre e controla

O que muda para quem já usa computer use

Primeiro, uma mudança obrigatória

Na Claude API e no Google Cloud, o computer use com o Haiku 5.5 exige o toolset novo, então tu precisa trocar a ferramenta antiga pela nova:

# antes
computer_20250124

# depois
computer_toolset_20260801

Caso tua integração quebre logo depois de trocar o modelo, confere esse ponto antes de qualquer coisa 😛

Quanto custa o Claude Haiku 5.5?

Preço por milhão de tokens:

Isso dá um corte de 90% abaixo de 100 mil tokens e de 50% acima, comparado ao Haiku 4.5

A Anthropic declara que, em média, ele custa cerca de 75% menos pra rodar que o Haiku 4.5

Porém tem uma pegadinha: o tokenizer novo (o mesmo do Claude 4.7 em diante) gera aproximadamente 30% mais tokens pro mesmo texto

Em computer use, onde o histórico cresce a cada screenshot e a cada ação, vale ficar de olho no consumo de tokens em tarefas longas antes de sair escalando

E no Claude Code?

O Claude Code tem uma página de documentação própria chamada Let Claude use your computer from the CLI

Os passos de habilitação e as permissões ficam por conta da doc oficial, vale ler lá direto em vez de seguir receita de terceiro

Pontos de checagem, logs e critérios para abortar tarefas longas

Agora a parte prática: como supervisionar operações de muitas etapas

A ideia é simples: tratar o agente como um estagiário muito rápido, que trabalha bem, mas que você não deixa sozinho mexendo no servidor de produção haha

Como dividir uma tarefa longa em checkpoints?

Em vez de mandar "faz tudo", quebra a operação em trechos com um objetivo verificável no fim de cada um:

1. Define o estado esperado ao final do trecho (ex: "planilha aberta com a aba X preenchida")
2. Deixa o agente executar só aquele trecho
3. Verifica o estado real contra o esperado antes de liberar o próximo

O erro comum aqui é fazer checkpoint vago, tipo "ver se deu certo"

Checkpoint bom é algo que dá pra conferir objetivamente: um arquivo existe, um campo tem um valor, uma tela específica está aberta

O que registrar no log de cada etapa?

Log de agente não é só "rodou" ou "falhou"

Pra conseguir auditar depois, registra em cada etapa:

• O que o agente pretendia fazer
• A ação que ele executou de fato
• O que ele viu na tela (o screenshot ou um resumo dele)
• Se o estado bateu com o checkpoint

Um formato simples já resolve:

etapa: 4
intencao: abrir relatorio mensal na pasta compartilhada
acao: duplo clique em relatorio_setembro.xlsx
observado: arquivo aberto, aba Resumo visivel
checkpoint: ok

Quando algo der errado (e vai dar, em algum momento), é esse registro que te mostra em QUAL etapa o desvio começou

Quando abortar a tarefa?

Define os critérios de parada ANTES de rodar, não no meio da bagunça

Alguns que fazem sentido:

• Estado inesperado na tela: janela ou mensagem que não estava no roteiro
• Ação irreversível: apagar, enviar, pagar, publicar, os rm -rf da vida
• Pedido de credencial: login, senha, token, código de verificação
• Conteúdo externo dando ordens: página ou imagem com instruções do tipo "agora faça X"

Esse último não é paranoia, se liga

Por que conteúdo externo é um critério de aborto?

A própria documentação de computer use diz que essa ferramenta tem riscos próprios, maiores quando há interação com a internet

Em algumas situações o Claude segue comandos encontrados no conteúdo (páginas, imagens) mesmo que contrariem as instruções dele

Isso é prompt injection: alguém esconde uma ordem num lugar que o agente vai ler, e o agente obedece achando que faz parte do trabalho

A recomendação oficial é isolar o Claude de dados e ações sensíveis

Na prática, muita gente roda esse tipo de agente numa máquina virtual ou container separado, longe dos seus arquivos e contas reais

Os classificadores de prompt injection resolvem isso?

Ajudam, mas não substituem você

Quando você usa as ferramentas de computer use, classificadores analisam automaticamente o que as ferramentas retornam, como os screenshots

Se detectam um possível prompt injection, levam o modelo a confirmar se aquela instrução veio mesmo do usuário antes de agir

Ou seja, a própria proteção depende de ter um humano pra responder

Pra desligar esses classificadores (por exemplo, em fluxos sem humano no loop) é preciso falar com o suporte, o que já diz bastante sobre como a Anthropic enxerga rodar isso sem supervisão

O que continua sendo trabalho de supervisão humana

O veredito honesto: o Haiku 5.5 é rápido e barato, e isso faz você rodar MUITO mais execuções

Mais execuções não é menos responsabilidade, é mais coisa pra supervisionar

O que continua sendo decisão humana:

• Ações irreversíveis: o agente para e você aprova
• Acesso a dados sensíveis: você decide o que ele enxerga, e o padrão é não enxergar
• Revisão do resultado final: checkpoint bom no meio não garante entrega certa no fim
• Consentimento dos usuários finais: se você coloca computer use dentro de um produto seu, a documentação orienta informar os usuários sobre os riscos e obter o consentimento deles antes de habilitar

Esse último ponto vale muito pra quem está empolgado em lançar feature com agente, tome cuidado!

Quando vale subir para o Sonnet 5.5?

No OSWorld, o Sonnet 5.5 marca 83,9% contra 72,4% do Haiku 5.5

Se a tarefa é longa, cheia de etapas dependentes e cada erro sai caro de corrigir, essa diferença pesa mais que a economia por token

Aí faz sentido usar o Sonnet, e tem um post aqui sobre o Sonnet 5.5 em tarefas longas sem perder o contexto

Já pra tarefas curtas, repetitivas e de alto volume, o Haiku 5.5 é o candidato óbvio 🙂

Conclusão: use a velocidade a favor da checagem, não no lugar dela

O Haiku 5.5 é um candidato forte pra computer use de alto volume, com salto real no OSWorld e preço bem abaixo do antecessor

Mas ele só merece confiança em tarefa longa se vier acompanhado de checkpoints, logs e critérios de aborto definidos antes

A velocidade dele serve pra você conferir mais vezes, não pra conferir menos

Próximos passos:

1. Troca computer_20250124 por computer_toolset_20260801 na Claude API ou no Google Cloud
2. Começa com tarefas curtas e isoladas de dados sensíveis
3. Lê a documentação oficial de computer use antes de abrir pra internet ou pra usuários

E aí, vai colocar o Haiku 5.5 pra rodar agente no computador? Bora trocar uma ideia nos comentários

Até o próximo post! 😀