Agentes de navegação econômicos com Haiku 5.5: a fila de revisão é o novo custo

A Anthropic lançou o Claude Haiku 5.5 em 7 de outubro, posicionando-o diretamente para tarefas de navegação web. O artigo de lançamento o descreve como uma excelente opção para “tarefas sensíveis à velocidade, como suporte ao cliente em tempo real e uso do navegador”. A página do produto destaca casos de uso como preenchimento de formulários, entrada de dados e transferência de informações entre aplicativos. Além disso, o mesmo lançamento adicionou suporte a uso do computador e do navegador nos SDKs de Python e TypeScript da Anthropic em versão beta. No OSWorld 2.1, benchmark de uso de computador divulgado pela Anthropic, o Haiku 5.5 atinge 72,4% com custo de cerca de US$ 0,61 por tentativa no nível máximo de esforço (max effort), e 53,3% por cerca de US$ 0,13 no nível médio padrão.

O número em destaque, no entanto, é uma pontuação com crédito parcial. Ao analisar o system card, vê-se que as mesmas execuções têm uma taxa de aprovação estrita (strict pass rate) de 37,1%. Ou seja, uma equipe que integra o Haiku 5.5 a um fluxo de automação de navegador obtém uma execução que custa centavos, mas cujo resultado, na maioria das vezes, está apenas parcialmente concluído. A execução ficou barata; a revisão, não. Para quem opera vários agentes em paralelo, isso transfere o custo real da automação de navegador para quem precisa conferir os resultados.

Resumo (TL;DR)

No subconjunto offline do OSWorld 2.1 da Anthropic, o Haiku 5.5 atinge em média 72,4% de crédito parcial, mas conclui integralmente apenas 37,1% das tentativas. O Sonnet 5.5 e o Opus 5.5 apresentam a mesma discrepância de 34 a 35 pontos percentuais, a preços consideravelmente mais altos. Trate qualquer execução em navegador como parcialmente concluída até ser validada: defina um critério de aceitação rigoroso na Tarefa (Task), faça o Agente parar antes de qualquer ação irreversível de envio e reportar o que foi concluído, o que ficou pendente e as evidências comprobatórias, e deixe uma pessoa autorizar a etapa final por meio de um comentário que mencione o Agente (@). Invista esforço para economizar tempo de revisão; a execução é a parte barata. Agentes pesquisam, executam, testam e relatam. Pessoas definem o direcionamento, concedem aprovações e aceitam o resultado.

Crédito parcial não é tarefa concluída

A Anthropic executou o OSWorld 2.1 em 82 de suas 108 tarefas a 1080p, com até 500 etapas por tentativa, no esforço máximo, com médias calculadas ao longo de cinco testes. Ela divulgou duas métricas por modelo — e a segunda é exatamente aquela com a qual o revisor precisa lidar na prática.

Em primeiro lugar, esse descompasso não é uma exclusividade do Haiku. Todos os modelos da família deixam uma margem de cerca de 35 pontos entre “a maior parte das etapas foi realizada” e “a tarefa está concluída” — até mesmo o Opus 5.5 atinge aprovação integral apenas em cerca de metade das vezes. Uma fatia expressiva das tentativas de uso do computador, segundo a metodologia avaliada, termina incompleta. Em segundo lugar, o Haiku 5.5 torna extremamente barato produzir trabalho parcialmente finalizado. Por aprovação estrita, ele custa cerca de um sétimo do Sonnet 5.5; por tentativa, cerca de um nono.

E o trabalho parcialmente finalizado é justamente o cenário mais perigoso na automação de navegadores. Uma execução que falha de imediato não deixa rastros. Já uma execução que migra 31 de 40 registros para o CRM, ou preenche o cadastro de um fornecedor até o campo de tributos, altera o estado em uma aplicação de terceiros de forma que parece concluída à primeira vista. Quem for revisar precisará descobrir quais são os nove registros faltantes — e nada na interface vai apontar onde eles estão.

Para onde vai o custo quando a execução custa centavos

Ter um fluxo de navegador de baixo custo muda a linha do orçamento em que você precisa focar. A US$ 0,13 por tentativa, cem execuções de preenchimento de formulários são mero erro de arredondamento na fatura de LLM. Já cem execuções exigindo que uma pessoa confira o que foi preenchido representam um dia inteiro de trabalho humano. O Haiku 5.5 custa 90% menos do que o Haiku 4.5 para prompts de até 100 mil tokens; o revisor, com certeza, não.

Há também uma particularidade importante de precificação. O Haiku 5.5 cobra US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de saída para prompts de até 100 mil tokens, subindo para US$ 0,50 e US$ 2,50 em prompts que ultrapassam esse limite. Sessões longas de navegador podem facilmente ultrapassar essa marca, passando a ser cobradas na faixa mais cara a partir dali. Esse é mais um motivo para manter as Tarefas de navegador enxutas: um formulário, um lote de registros, uma Tarefa.

Os artigos A revisão humana é o gargalo e dias de trabalho de agentes por dia de trabalho humano já defendiam essa tese. O que o Haiku 5.5 altera é a proporção: a US$ 0,13 por execução, o custo de máquina se torna quase irrelevante, e modelos baratos podem sair mais caros quando a fila de revisão humana entra no cálculo. A única alavanca viável é agilizar cada checagem.

Revisão de agentes de uso do computador: o que a Tarefa precisa conter

Uma Tarefa executada por agente de navegador é auditável quando revisá-la leva menos tempo do que refazê-la do zero. Isso depende de três elementos fundamentais que o Agente não tem como inventar após a execução: um critério de aceitação rigoroso redigido antes da execução, um relatório que distinga claramente o que foi feito do que não foi feito, e evidências que uma pessoa possa abrir sem precisar reproduzir toda a sessão.

No Sharkly, a Tarefa já funciona como o registro compartilhado central. Ela reúne descrição, comentários, anexos e histórico de atividades; a comunicação do Agente com a equipe é registrada na própria Tarefa como um comentário vinculado à execução; e o log de execução registra as chamadas de ferramentas e os eventos do Runtime. Dessa forma, a arquitetura de revisão se apoia em dois pilares: a descrição da Tarefa estipula o que significa “concluído”, e as instruções do Agente definem o formato obrigatório do relatório. Eis um ponto de partida para as instruções de um Agente de preenchimento em navegador:

Restate the acceptance check from the Task description before you start.
Work up to, but not including, any submit, send, publish, pay, or delete action.
Then stop and report, in this order:
  Done: every record or field you completed, by its identifier.
  Not done: everything you skipped or could not complete, and why.
  Check: the acceptance check, and whether your own count meets it.
  Evidence: the paths of the screenshots you saved in the task directory.
Leave the Task waiting for human review. Do not take the final action
until a person @ mentions you in a comment on this Task to release it.

Defina o critério de aceitação com valores quantificáveis: “40 linhas no CRM, cada uma com o e-mail correspondente”, em vez de um genérico “importar a planilha”. A lista de pendências (“Not done”) é o ponto crítico que o crédito parcial mascara; listar explicitamente o que foi ignorado transforma uma execução com 72% de sucesso em uma execução de 72% com saldo restante conhecido. Nosso guia sobre como revisar código gerado por IA com evidências no nível da tarefa aprofunda os modelos de relatório recomendados.

Conforme a documentação de Agentes do Sharkly, o Agente segue o modelo padrão configurado no Runtime; para alterá-lo, defina um em Custom arguments no Agente ou no Runtime (claude-haiku-5-5 para Claude Code). Não há menu suspenso de seleção de modelo. As orientações de configuração estão disponíveis em como executar agentes Claude Haiku 5.5 no Sharkly.

Pare antes de enviar

Um resultado parcial é perfeitamente aceitável para um rascunho, mas inaceitável para um formulário já submetido. Por isso, isole a etapa irreversível da execução em vez de apenas torcer para que o modelo acerte.

Esse padrão aproveita recursos nativos do Sharkly. O Agente avança até a ação final e coloca a Tarefa no status aguardando revisão humana, que aparece na Caixa de Entrada do revisor. O revisor avalia o relatório e as capturas de tela, faz eventuais correções ou rejeita o resultado, e em seguida menciona (@) o Agente em um comentário na Tarefa para autorizar a conclusão. Um comentário comum não aciona o Agente; a menção explícita inicia ou retoma o diálogo na Tarefa, e a resposta é arquivada como um novo comentário atrelado àquela execução. O envio final ocorre na mesma Tarefa, dentro do mesmo histórico, após a autorização humana. Nosso guia de pontos de aprovação (approval gates) aborda outros cenários onde esse bloqueio prévio deve ser inserido.

Esse ponto de controle também mitiga outro risco inerente ao navegador: agentes de navegação leem conteúdos na web que eles não criaram. O system card da Anthropic indica que o Haiku 5.5 tem maior resistência a injeções de prompt do que qualquer versão anterior do Haiku, praticamente empatando com seus modelos de ponta contra invasores adaptativos em ambientes de uso de computador. Trata-se, contudo, de um resultado de benchmark, e não de uma garantia blindada para o portal do seu fornecedor. Uma instrução injetada que não consiga acionar o botão de envio sem um comentário humano de liberação gera um incidente de gravidade infinitamente menor. O isolamento no nível do host (um Computer dedicado, credenciais restritas por Agente via variáveis de ambiente secretas, uma única sessão de navegador por vez) segue as mesmas diretrizes do nosso guia de salvaguardas para uso do computador, e o artigo injeção de prompt e salvaguardas para agentes detalha os demais aspectos de segurança.

Um critério simples de decisão para o seu fluxo: use um Agente de navegador com Haiku 5.5 quando o resultado puder ser validado por meio de contagem ou lista em menos de um minuto e a ação final for reversível ou bloqueada por aprovação manual. Mantenha o fluxo sob responsabilidade humana — ou use um modelo de maior porte sob o mesmo portão de aprovação — quando validar exigir refazer todo o trabalho, pois, nesse caso, uma taxa de sucesso estrito de 37% só acarretará retrabalho completo.

Pague por esforço, economize na revisão

O Haiku 5.5 é o primeiro da linha Haiku a contar com ajuste de nível de esforço (effort setting), cujo padrão é médio. No benchmark OSWorld, o esforço melhora substancialmente o crédito parcial a um custo marginal muito baixo:

Passar do nível médio para o máximo adiciona cerca de US$ 0,49 por tentativa e gera 19 pontos percentuais a mais de crédito parcial. Se esses pontos reduzirem a duração da revisão humana mesmo que ligeiramente, o nível máximo se torna a opção mais econômica para qualquer Tarefa de navegador sujeita à validação de uma pessoa. O system card traça gráficos da taxa de aprovação estrita por esforço, mas só fornece o número explícito no nível máximo; portanto, meça os resultados estritos nas suas próprias Tarefas antes de adotar um nível inferior. O esforço é configurado no Claude Code dentro do Computer: o Agente não exibe seletores de modelo ou controles de profundidade de raciocínio. Reserve o modo econômico de baixo esforço para processos cujos resultados ninguém precisará revisar, como exploramos em Luna para os oitenta por cento rotineiros; fluxos de navegador definitivamente não se enquadram nisso.

Tarefas de navegador que gravam dados em sistemas externos devem ter sua própria Tarefa independente em vez de serem embutidas em execuções mais amplas, já que alguém precisará homologá-las; o artigo Haiku 5.5 como subagente ou como Agente independente discute essa regra geral.

Um agente de navegador mais barato estimula mais execuções — e mais execuções geram mais resultados parcialmente concluídos esperando validação humana. Se a sua operação já utiliza múltiplos agentes, o Sharkly oferece uma plataforma centralizada para orquestrar suas tarefas e resultados.