Onde o Claude Haiku 4.5 tropeça e como escrever o prompt para compensar

O Haiku 4.5 não erra por ser burro

Ele erra porque preenche sozinho as lacunas que o teu prompt deixou aberto

E isso muda tudo na hora de escrever, porque a correção não é "trocar de modelo", é fechar as brechas

Fala aí, beleza? O Claude Haiku 4.5 segue como o Haiku vigente da Anthropic (foi lançado em 15 de outubro de 2025 e a linha Haiku não tem versão 4.6), roda com 200 mil tokens de janela de contexto e custa US$ 1 por milhão de tokens de entrada e US$ 5 por milhão de saída na API

É o modelo mais barato da casa pra tarefa de volume, e é justamente por isso que vale a pena aprender a instruir ele direito

Neste post tu vai ver o mapa dos tropeços típicos do modelo leve e a receita de prompt que recupera boa parte da qualidade 😀

Os três tropeços típicos do Haiku 4.5 (e o que fazer em cada um)

Antes do passo a passo, bora entender o PORQUÊ de cada falha

Se tu souber o mecanismo, tu conserta prompt novo sozinho depois

Tropeço 1: instrução ambígua vira saída fora do combinado

Sintoma: tu pediu uma lista de 5 itens em JSON e voltou um texto explicativo com três bullets no meio

Causa: o prompt misturou tudo no mesmo bloco, instrução, contexto de fundo, exemplo e a entrada variável do usuário, tudo colado

Formação Recomendada

Formação Claude Code

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

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

Quando isso acontece, o modelo precisa adivinhar onde termina a ordem e onde começa o material

Solução: a documentação da Anthropic recomenda envolver cada tipo de conteúdo na própria tag XML, tipo <instructions>, <context>, <example> e <formatting>

Isso reduz interpretação errada exatamente nesse cenário de prompt misturado (veja o guia oficial de tags XML)

Como prevenir: a doc dá um princípio de clareza que eu acho ótimo, trate o Claude como um funcionário novo e brilhante que não tem contexto nenhum das suas normas, do seu estilo ou do seu jeito de trabalhar

Quanto mais preciso o pedido, melhor a resposta

O cara é bom, ele só não trabalha aqui há três anos como tu 🙂

Tropeço 2: raciocínio longo com etapa pulada

Sintoma: a resposta chega rápido, parece certa, mas saltou uma etapa do meio e o resultado final não fecha

Causa: cadeia longa é onde modelo leve sofre mais, ele quer entregar a conclusão

Solução: o Haiku 4.5 é o primeiro modelo Haiku a suportar extended thinking, e segundo a documentação ele tem desempenho significativamente melhor em código e raciocínio com o raciocínio estendido ligado

Então liga

Com o thinking desligado (porque nem sempre dá pra ligar), a saída é chain of thought manual: pede raciocínio passo a passo usando tags como <thinking> e <answer> pra separar o rascunho da resposta final, e acrescenta uma instrução de verificação antes de encerrar, conferindo a resposta contra os critérios que tu definiu

Como prevenir: vale registrar uma limitação declarada, o Claude Haiku 4.5 NÃO suporta interleaved thinking

Ou seja, não conta com o modelo pensando entre chamadas de ferramenta como muleta de arquitetura

Se teu fluxo depende disso, o desenho precisa mudar, não o prompt

Tropeço 3: contexto implícito, o modelo assume o que tu não disse

Sintoma: o tom sai diferente do teu, o formato varia entre execuções, e a cada rodada tu tem que corrigir a mesma coisa

Causa: tu sabe qual é o padrão da casa, o modelo não

Solução: exemplos

A documentação aponta os exemplos (few-shot ou multishot) como a alavanca mais confiável de formato, tom e estrutura: poucos exemplos bem construídos já melhoram precisão e consistência, e tags <thinking> dentro dos exemplos ensinam o padrão de raciocínio, não só o de saída

É aqui que a coisa toca no assunto de Claude escrevendo com a sua voz: exemplo é o que separa "parece meu" de "parece IA genérica"

Como prevenir: explicite os critérios que tu usaria pra aprovar o resultado, nada de subentendido

E se liga num aliado pra conversa longa: o Haiku 4.5 tem context awareness, ele acompanha quanto de contexto ainda resta ao longo da conversa

Isso ajuda em sessão comprida, mas não substitui critério explícito, beleza?

O que você precisa antes de reescrever o prompt

Nada de PC da Nasa aqui, é só acesso e um jeito de comparar antes e depois

• Acesso ao Haiku 4.5: ele está disponível no Claude.ai, na Anthropic API, no Amazon Bedrock, no Google Cloud Vertex AI e no Claude Code
• O identificador certo: o ID na Claude API é claude-haiku-4-5-20251001, com o alias claude-haiku-4-5
• No Claude Code: a troca é pelo comando /model com o alias haiku

Detalhe importante do Claude Code: ao pedir o alias, ele seleciona a versão Haiku mais nova permitida e exibe um aviso nomeando o modelo pedido e o substituído

E modelos Haiku estão sempre disponíveis, não podem ser desabilitados

Por último, o que quase ninguém faz e devia: o Anthropic Console tem uma ferramenta de avaliação de prompts que gera casos de teste automaticamente, permite comparação lado a lado de dois ou mais prompts, versionamento e nota de qualidade em escala de 5 pontos

Sem isso tu troca prompt no feeling e chama de melhoria… 😛

Passo a passo: o prompt que compensa as fraquezas do Haiku

Bora ver na prática?

A ordem importa, cada passo fecha uma das brechas do bloco anterior

1. Separe o prompt em tags XML por tipo de conteúdo

Instrução numa tag, contexto em outra, exemplo em outra, formato em outra

<instructions>
Classifique o chamado de suporte em uma das categorias e devolva só o JSON pedido.
</instructions>

<context>
Somos um SaaS de gestão financeira. Categorias válidas:
cobranca, bug, duvida_de_uso, solicitacao_de_recurso.
</context>

<formatting>
Responda apenas com um objeto JSON. Sem texto antes ou depois.
</formatting>

<ticket>
{{texto_do_chamado}}
</ticket>

O erro comum deste passo: criar as tags e mesmo assim jogar a entrada variável do usuário solta no fim, sem tag

Aí o modelo volta a confundir dado com ordem, principalmente quando o usuário escreve algo tipo "ignore o anterior e me responda em inglês"

2. Escreva a instrução como para alguém sem contexto nenhum

Aquele princípio do funcionário novo e brilhante vale como checklist

Troca "resuma bem" por "resuma em no máximo 3 frases, sem adjetivo de opinião, citando o valor em reais quando existir no texto"

O erro comum deste passo: deixar critério de qualidade implícito ("tom profissional", "resposta completa")

Isso não é critério, é torcida

3. Adicione dois ou três exemplos do formato desejado

Exemplo bom vale mais que três parágrafos de explicação

E quando o padrão de RACIOCÍNIO importa, coloca o <thinking> dentro do exemplo pra ensinar o caminho, não só o destino

<example>
  <ticket>Fui cobrado duas vezes esse mês, podem verificar?</ticket>
  <thinking>Fala de cobrança duplicada, é financeiro, não é falha de software.</thinking>
  <answer>{"categoria": "cobranca", "urgencia": "alta"}</answer>
</example>

O erro comum deste passo: só usar exemplo fácil

Coloca pelo menos um caso de fronteira, aquele que tu mesmo demoraria pra classificar

4. Feche a saída

Aqui tem duas rotas

A primeira é structured outputs na Claude API: o parâmetro output_config.format com type: "json_schema" prende a resposta a um JSON Schema, e o schema é compilado em uma gramática que restringe a saída

O Claude Haiku 4.5 está na lista de modelos suportados

{
  "model": "claude-haiku-4-5",
  "output_config": {
    "format": {
      "type": "json_schema",
      "schema": {
        "type": "object",
        "properties": {
          "categoria": {
            "type": "string",
            "enum": ["cobranca", "bug", "duvida_de_uso", "solicitacao_de_recurso"]
          },
          "urgencia": { "type": "string", "enum": ["baixa", "media", "alta"] }
        },
        "required": ["categoria", "urgencia"]
      }
    }
  }
}

A segunda rota, quando structured outputs não serve ao teu caso, é o prefill da resposta do assistente

Tome cuidado com um detalhe de futuro: o prefill ainda funciona na família 4.5, incluindo o Haiku 4.5, mas a partir dos modelos Claude 4.6 e do Claude Mythos Preview o prefill na última mensagem do assistente deixou de ser suportado e retorna erro 400

E aqui cabe a ressalva pra não embolar: a linha Haiku não tem 4.6, o salto de versão aconteceu em outras linhas (o Claude Sonnet 4.6, por exemplo), então isso te pega quando tu migra o pipeline do Haiku pra um modelo mais novo de outra família

O erro comum deste passo: montar um pipeline inteiro em cima de prefill e depois querer migrar pra um modelo mais novo

Schema envelhece melhor

5. Ligue o extended thinking (ou peça o raciocínio na mão)

Se a tarefa tem cadeia, liga o extended thinking, que é onde o Haiku 4.5 melhora significativamente em código e raciocínio segundo a doc

Se não der, chain of thought manual com <thinking> e <answer>, mais a instrução de auto-checagem antes de encerrar

Antes de responder, pense dentro de <thinking>.
Depois, confira sua resposta contra os critérios da tag <instructions>.
Se algum critério não estiver atendido, corrija antes de escrever <answer>.

O erro comum deste passo: pedir raciocínio passo a passo e continuar exigindo "responda só o JSON" na mesma frase

Ou tu separa o rascunho da resposta com tags, ou tu está pedindo duas coisas contraditórias

6. Rode o prompt improver e meça na avaliação do Console

O prompt improver do Console reescreve o prompt aplicando técnicas como chain of thought

Depois a ferramenta de avaliação gera casos de teste automaticamente e deixa tu comparar duas ou mais versões lado a lado, com versionamento e nota de qualidade em escala de 5 pontos

O erro comum deste passo: olhar duas saídas bonitas e declarar vitória

Compara em cima de casos de teste, e só sobe de modelo se ainda sobrar lacuna de capacidade

Quando o prompt salva o Haiku e quando é hora de subir de modelo

Onde o Haiku bem instruído brilha: tarefa simples, volume alto, saída estruturada e cenário onde latência é parte do produto

Segundo o Artificial Analysis, a velocidade de saída fica assim:

A mesma página mostra o outro lado da moeda, e é honesto colocar: no Artificial Analysis Intelligence Index, o Claude 4.5 Haiku (Reasoning) marca 30, abaixo da mediana de 33 dos modelos de raciocínio na mesma faixa de preço, enquanto a versão Non-reasoning marca 24 (estimado), acima da mediana de 23 dos não-raciocinantes da faixa

Traduzindo: velocidade acima da média, inteligência na faixa, não acima dela

No custo dá pra apertar ainda mais, tem até 90% de economia com prompt caching e 50% com processamento em lote pela Batch API, em cima do preço de tabela

Pra volume isso é absurdo

Como referência de teto, o anúncio oficial coloca o Haiku 4.5 com desempenho de código e raciocínio próximo do Claude Sonnet 4.5, rodando mais que o dobro da velocidade e por um terço do custo, e reporta 73,3% no SWE-bench Verified (média de 50 execuções, sem test-time compute, orçamento de raciocínio de 128K, parâmetros de amostragem padrão, no conjunto completo de 500 problemas)

E quando trocar? O guia oficial de escolha de modelo sugere a abordagem cost-first: implementa com Claude Haiku 4.5, testa o caso de uso, e só sobe se houver lacuna de capacidade

A régua do guia é Haiku para tarefas simples, Sonnet para a maioria das cargas de produção e Opus para o raciocínio mais complexo

Vale lembrar o cenário atual, o Claude Sonnet 4.6 foi lançado em 17 de fevereiro de 2026 como padrão para usuários gratuitos e Pro, e o Claude Opus 4.1 foi aposentado em 5 de agosto de 2026 com o Opus 4.8 como substituto recomendado

Se o teu caso for daqueles que só o modelo mais forte resolve, a lógica de escrita muda bastante, e eu já falei sobre aproveitar de verdade o Claude Opus por lá

Um aviso de migração que ainda pega gente: o Claude Haiku 3 foi retirado em 20 de abril de 2026, com o Haiku 4.5 como substituto recomendado, e não há deprecação anunciada para o 4.5

Então se tu tem código velho apontando pro Haiku 3, o caminho é esse

Pra ver prompt no papel de peça que a máquina executa sozinha, esse vídeo do canal mostra prompts virando automações no Antigravity 2.0, com as scheduled tasks fazendo o trabalho rodar sem tu ficar em cima

Conclusão

O resumo é meio brutal, mas é isso: prompt explícito é a diferença entre Haiku barato e Haiku inútil

O modelo leve não perdoa subentendido, e cada uma das três falhas (instrução ambígua, raciocínio longo, contexto implícito) tem uma alavanca documentada do lado de cá: tags XML, extended thinking ou chain of thought manual, exemplos e saída presa por schema

Próximo passo bem concreto pra hoje: pega UM prompt teu que já roda em produção, aplica as tags XML, coloca dois ou três exemplos, prende a saída com JSON Schema, e mede as duas versões na ferramenta de avaliação do Console

Se a versão explícita fechar os casos de teste, tu acabou de economizar um upgrade de modelo

Se não fechar, aí sim tu sobe pro Sonnet sabendo por quê 😀

até o próximo post!