Como testar se o Haiku dá conta da sua tarefa antes de trocar o modelo

A pior forma de escolher modelo é também a mais comum: rodar duas ou três tarefas, achar que "ficou pior" e voltar correndo pro modelo grande

Fala aí, beleza? O Claude Haiku 4.5 custa metade do Sonnet 5 nos dois lados da conta: US$ 1 contra US$ 2 por milhão de tokens de entrada, e US$ 5 contra US$ 10 por milhão de tokens de saída

Metade do preço é bonito no papel, mas preço nenhum resolve se a saída não serve pro que TU faz

E "não serve" não pode ser sentimento, tem que ser resultado medido nos teus próprios casos

Por isso a única resposta honesta pra pergunta "será que o Haiku dá conta?" é: monta uma avaliação com casos reais do teu projeto e descobre

Bora montar essa avaliação caseira, passo a passo?

O que você precisa antes de começar o teste

Nada de PC da Nasa aqui, o que você precisa é bem mais chato e bem mais barato: material real

• Acesso ao modelo: o Haiku 4.5 está disponível na API da Anthropic, no Amazon Bedrock e no Google Cloud Vertex AI
• O identificador certo do modelo, pra não errar na hora de chamar
• O prompt que já roda hoje, do jeito que ele está em produção, sem "melhorar" antes do teste
• Um histórico de casos reais: logs, tickets, falhas que usuários relataram, aquele print que alguém mandou no grupo
• Os critérios de sucesso da sua tarefa, escritos, antes de qualquer comparação

O identificador é este:

claude-haiku-4-5
claude-haiku-4-5-20251001

Que diferença faz a versão datada? Ela trava o modelo exato, o que ajuda quando você quer reexecutar a mesma suíte semanas depois e comparar com o mesmo alvo

E tem um aviso que vem da própria Anthropic e que eu acho o mais importante de todos: quanto mais você demora a começar a avaliação, mais difícil ela fica de construir

Ou seja, comece feio hoje em vez de bonito nunca 😀

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 116 aulas
• 4 projetos
• 9h 23min

Conhecer formação

Passo a passo: montando a avaliação caseira do Haiku

1. Defina os critérios de sucesso ANTES de desenhar a avaliação

A documentação da Anthropic é direta nisso: definir os critérios vem primeiro, e a maioria dos casos de uso precisa de avaliação multidimensional, medindo mais de um critério ao mesmo tempo

Extração, por exemplo, quase nunca é só "acertou o campo": tem formato, tem campo faltando, tem alucinação de campo que não existia

O erro comum deste passo: montar os casos primeiro e inventar o critério depois, olhando pras saídas. Aí você já viu a resposta e o critério nasce contaminado

2. Monte o conjunto de casos espelhando a distribuição real das suas tarefas

A recomendação oficial é desenhar avaliações que reflitam a distribuição real do seu uso e incluir casos de borda

O ponto de partida mais barato: aquelas checagens manuais que você já faz durante o desenvolvimento, e as falhas relatadas por usuários viram casos de teste, priorizadas por impacto no usuário

O erro comum deste passo: encher a suíte só com o caso feliz, aquele que você usa pra demonstrar pro cliente. Todo modelo passa nele

3. Separe os casos difíceis dos fáceis

Se difícil e fácil ficam misturados num placar único, o resultado vira média e a média esconde exatamente o que você queria ver

Dois grupos, dois placares: um pro caso rotineiro e outro pra borda

O erro comum deste passo: comemorar 90% de acerto quando 90% da suíte era trivial

4. Defina a régua de correção de forma empírica e específica

A orientação da Anthropic aqui é bem clara: a avaliação precisa ser empírica e específica, do tipo pedir uma saída apenas "correct" ou "incorrect", ou uma nota de 1 a 5

O motivo é prático: avaliação puramente qualitativa é difícil de julgar rápido e em escala

Estruture a pergunta de forma que dê pra corrigir automaticamente: múltipla escolha, comparação de string, correção por código ou correção por LLM

O erro comum deste passo: régua tipo "a resposta ficou boa?". Isso não é régua, é conversa de bar

5. Escolha a família de corretor certa pra cada critério

O post de engenharia da Anthropic sobre avaliação de agentes fala em três famílias combinadas:

• Determinístico (baseado em código): rápido, barato e reprodutível, ideal pra checagem objetiva como teste unitário, análise estática e verificação de chamada de ferramenta e estado final
• Baseado em modelo (LLM como juiz, com rubrica estruturada): bom pra qualidade de linguagem, empatia e cobertura em resposta aberta
• Humano: entra pra calibração

E tem uma preferência explícita: sempre que possível, cheque o resultado e o estado (os testes passam? o registro foi alterado direito? o estado do navegador está correto? os efeitos colaterais da ferramenta batem com o esperado?), guardando o transcript ou o trace separado do resultado final

O erro comum deste passo: corrigir tudo com LLM porque é mais fácil de escrever, inclusive o que dava pra checar com um assert

6. Rode mais de uma tentativa por caso

Comportamento de agente é estocástico, então múltiplas tentativas importam

E se liga: pass@k e pass^k respondem perguntas DIFERENTES de confiabilidade. Uma coisa é "acerta pelo menos uma vez em k tentativas", outra bem diferente é "acerta todas as k"

O erro comum deste passo: rodar uma vez, dar sorte, e trocar o modelo inteiro por causa daquela rodada

7. Rode o mesmo conjunto no modelo atual e no Haiku, e compare lado a lado

Mesmos casos, mesma régua, mesmo número de tentativas

Sem isso não existe comparação, existe impressão

O erro comum deste passo: ajustar o prompt no meio do caminho pra "ajudar" o modelo mais barato. Aí você não está mais comparando modelo, está comparando prompt

Onde o Haiku 4.5 tende a passar no teste (e onde vale desconfiar)

A documentação da Anthropic posiciona o Haiku 4.5 pra extração, classificação, respostas curtas, roteamento e outras cargas sensíveis a latência e custo

Isso é uma hipótese de partida, não veredito

Serve pra você escolher QUAIS tarefas do seu projeto entram primeiro na bateria: se tem um classificador de ticket ou um roteador de intenção rodando no modelo grande, esse é o primeiro candidato óbvio

E o resto? Fora dessa lista não existe promessa oficial nenhuma, então essas tarefas entram no teste sem hipótese pronta, valendo só o placar

O ponto que eu mais bato: o teste é POR TAREFA, não por modelo em abstrato

Não existe "o Haiku é bom" ou "o Haiku é ruim", existe "o Haiku resolve a extração de dados da nota fiscal com a mesma régua que eu já uso", e isso muda de projeto pra projeto

Se você ainda está na dúvida sobre a divisão geral do trabalho, eu já escrevi sobre qual modelo usar em cada tarefa no Claude Code

Por que a impressão sozinha engana: o que vi rodando tarefas reais

Aqui eu preciso ser honesto com você, porque eu já testei modelo novo do jeito caprichado, projeto real na frente e conferência na mão, e mesmo assim faltou o principal. Vou contar o que faltou

Quando saiu o Sonnet 5, eu montei uma bateria de prompts próprios em vez de confiar só no anúncio, e separei tarefas de tipos bem diferentes: um sistema web tipo Kanban, um projeto full stack fatiado em etapas e um jogo

O Kanban eu pedi inteiro em UM prompt só (one shot), justamente pra observar se o modelo planejava bem e entregava tudo de uma vez: colunas reordenáveis, arrastar cards, contador por coluna, limite configurável com aviso visual, cards com markdown, tags, prioridades e prazo opcional

No full stack eu fatiei: primeiro o backend, depois o frontend consumindo a API, avisando no prompt que ele tinha que manter consistência de nomes, arquivos, rotas e esquema entre um prompt e outro. E fixei a pasta do projeto, pra delimitar onde ele podia trabalhar

O jogo entrou porque mecânica, animação e física me parecem mais complexas que aplicação web comum, então é estresse maior

E eu não parei no código gerado: abri o Kanban no navegador e conferi na mão se movia coluna, se movia tarefa, se persistia dado, se filtro e busca funcionavam. No full stack eu rodei o fluxo pela interface e fui conferir se o dado tinha chegado certo no banco. No jogo eu joguei mesmo, checando movimentação, colisão, power up e tela de fim de jogo

Os números que sobraram foram estes: o Kanban ficou pronto em cerca de 10 minutos (no meio do vídeo, quando eu fui checar, tinham corrido cerca de 8 minutos), e a minha média pra scaffolding desse tipo de projeto em modelo maior é justamente cerca de 10 minutos

O jogo estilo Pac-Man levou quase 30 minutos, subiu na porta 8123 e o modelo criou 2 níveis

Agora vem a parte incômoda: mesmo com projeto real na frente, mesmo abrindo tudo na mão, o que me sobrou foi uma SENSAÇÃO e um cronômetro

Não sobrou placar comparável

Se alguém me perguntasse "em quantos por cento dos casos difíceis ele acertou?", eu não teria número, teria história

E história é ótima pra vídeo, péssima pra decidir qual modelo vai rodar sua carga em produção pelos próximos seis meses

É exatamente esse buraco que a avaliação com casos fixos fecha

Outra coisa que me faz testar sempre: às vezes rolam nerfs silenciosos quando lançam versão nova, e sem bateria fixa você nunca sabe se piorou de verdade ou se foi teu dia ruim

Rodando a comparação: ferramenta de Avaliação do Console ou promptfoo

Duas rotas práticas, escolhe a que combina com teu fluxo

Rota 1: ferramenta de Avaliação do Console da Anthropic

1. Abra a tela de Evaluation no Console, que é onde mora a ferramenta de Avaliação pra testar prompt em vários cenários
2. Adicione os casos de teste, e aqui você tem três opções: o botão "+ Add Row" pra colocar um caso manualmente, o recurso "Generate Test Case" pro Claude gerar casos, ou importar de um arquivo CSV
3. Use a comparação lado a lado, que mostra as saídas de dois ou mais prompts na mesma tela
4. Dê a nota de qualidade, que a ferramenta oferece numa escala de 5 pontos por prompt
5. Versione o prompt, porque o versionamento é o que te deixa reexecutar a suíte de testes depois de mexer em alguma coisa

O erro comum desta rota: rodar uma vez, ficar satisfeito e não versionar. Duas semanas depois você não consegue reproduzir o que testou

Rota 2: promptfoo na linha de comando

1. Use o promptfoo, que é uma CLI e biblioteca open source pra testar e avaliar aplicações de LLM
2. Escreva a configuração em YAML, porque o uso básico só exige arquivos de configuração, sem programar nada
3. Aponte pro provedor, e ele suporta a Anthropic (Claude) entre outros
4. Pendure no CI, já que ele integra com GitHub Actions, GitLab CI e Jenkins, e retorna código de saída diferente de zero quando as asserções falham, quebrando o build

Esse último ponto é o mais massa da rota 2: sua avaliação deixa de ser um ritual manual e vira um portão

Nota de atribuição, porque isso mudou e muita gente ainda não viu: a OpenAI anunciou em 9 de março de 2026 a aquisição do promptfoo, e declarou que o projeto continua open source sob a licença atual

Quanto você economiza se o Haiku passar no teste

Ou seja: metade do preço na entrada e metade na saída

E tem multiplicador que vale pros dois lados da tabela, então não esquece deles na hora de fazer a conta:

• Batch API: processamento em lote tem 50% de desconto sobre tokens de entrada e de saída
• Cache de prompt: leitura de cache custa 10% do preço padrão de entrada (economia de até 90%), enquanto a escrita custa 1,25x na duração de 5 minutos e 2x na duração de 1 hora
• Os dois juntos: Batch API e cache de prompt podem ser combinados, e as economias se somam na mesma chamada

Um contexto de preço que vale registrar: o reajuste do Sonnet 5 que estava marcado pra 1 de setembro de 2026 (US$ 3 / US$ 15) foi cancelado, e US$ 2 / US$ 10 virou preço permanente em 10 de agosto de 2026

O que era introdutório virou padrão, então a conta de comparação com o Haiku é essa aí mesmo, sem asterisco de "vai subir mês que vem"

Como ler o placar e decidir a troca

Antes de olhar o resultado, olhe pra tarefa

A régua que a Anthropic usa pra dizer se uma tarefa de avaliação presta é linda de simples: uma boa tarefa é aquela em que dois especialistas do domínio chegariam, independentemente, ao MESMO veredito de aprovado ou reprovado

Se a sua tarefa não passa nesse critério, o problema não é o modelo, é a avaliação

E tem uma armadilha que eu acho a mais sacana de todas: avaliação de um lado só gera otimização de um lado só

O exemplo da própria Anthropic: se você só testa se o agente busca quando deveria buscar, acaba com um agente que busca pra quase tudo

Então teste os dois lados do comportamento, sempre. Quando deve fazer E quando NÃO deve fazer

Se a queixa que te trouxe até aqui foi lentidão e não qualidade, aliás, tem uma lista de coisas pra checar antes de trocar de modelo que costuma resolver sem mexer em modelo nenhum

E por fim: troca não precisa ser tudo ou nada

Eu delego tarefa menos importante pro modelo mais leve sempre que dá, porque isso economiza token, e o resto continua onde está

Seu placar pode dizer "passa na classificação, não passa na redação final", e essa resposta é ótima, é ela que te dá a troca parcial

Se o Haiku passar: como trocar o modelo no Claude Code

Atenção que aqui eu estou falando do Claude Code, o produto de linha de comando, e não da versão web

São quatro caminhos, nesta ordem de prioridade:

1. O comando de barra durante a sessão, que é a forma mais direta:

/model haiku

2. A flag ao iniciar, quando você já sabe de antemão com qual modelo quer começar:

claude --model haiku

3. A variável de ambiente ANTHROPIC_MODEL, que vale só pra sessão iniciada com ela

4. O campo model no arquivo de settings, que define o modelo INICIAL da sessão

Pra time que quer restringir quais modelos podem ser usados, existem ainda os campos availableModels (lista de modelos permitidos, aceita alias como "haiku") e enforceAvailableModels (booleano), que ficam no settings.json ao lado do campo model:

{
  "model": "haiku",
  "availableModels": ["haiku"],
  "enforceAvailableModels": true
}

O erro comum deste passo: confundir a precedência e achar que o settings manda em tudo

Não manda. O campo model do settings define o modelo inicial da sessão, e a flag e o /model vêm antes dele na ordem de prioridade

Já vi gente jurando que "configurou e não pegou", quando na real tinha subido a sessão com a flag e esquecido 🙂

Conclusão

Recapitulando o que importa aqui

A decisão de trocar de modelo deixa de ser opinião no minuto em que existem duas coisas: um conjunto fixo de casos reais do seu projeto e uma régua de correção definida ANTES do teste

Sem isso, o que você tem é cronômetro e sensação, e eu falei por experiência própria de como isso engana até quem está com o projeto rodando na frente

Com isso, você tem placar, e placar dá pra discutir com o time

Próximo passo concreto, pra hoje mesmo: escolhe UMA tarefa do teu projeto, junta as falhas que já apareceram (ticket, log, print no grupo), transforma em caso de teste e roda a primeira comparação entre o modelo atual e o Haiku

Uma tarefa só já resolve, não precisa mapear o sistema inteiro. Lembrando sempre daquele aviso: quanto mais você adia, mais difícil a avaliação fica de construir

E pra fechar o cenário: o Haiku 4.5 segue como o modelo atual da faixa Haiku em agosto de 2026, ao lado de Sonnet 5, Opus 5 e Fable 5

Agora é montar a bateria e deixar o placar decidir

até o próximo post! 😀