Como usar o Claude Haiku 5.5 para resumir e compactar contexto antes de chamar o Opus

Fala aí, beleza? Mandar material bruto direto pro Opus 5.5 é pagar preço de modelo grande pra ler ruído 😛

E hoje (2026-10-07) chegou uma peça muito massa pra resolver isso: o Claude Haiku 5.5

A Anthropic chama ele de o modelo pequeno mais barato, mais rápido e mais capaz que ela já lançou, feito pra tarefas de alto volume e sensíveis a custo

E se liga nisso: entre as cargas que ela diz que o Haiku 5.5 dá conta com confiabilidade estão justamente resumos e compactações 🙂

Aqui "compactar" é o Haiku encolher o material na tua mão, beleza? Não confunde com a compactação automática no servidor da API, que é outro recurso e aparece mais pra frente

Então a ideia aqui é montar um fluxo de duas camadas:

• o Haiku 5.5 lê o material bruto, filtra e resume
• o Opus 5.5 recebe só o essencial e faz o que ele faz de melhor, que é decidir

É como ter alguém muiiito rápido separando a papelada antes de levar pra mesa de quem assina haha

Bora ver na prática?

O que você precisa antes de montar o fluxo:

Primeiro, acesso à API do Claude

O Haiku 5.5 está disponível na Claude Platform, na AWS, no Google Cloud e no Microsoft Azure, então tu usa o provedor que já tem no projeto

Os IDs que vão aparecer no código são estes:

• claude-haiku-5-5 para a camada que resume
• claude-opus-5-5 para a camada que decide

Mudanças do Haiku 5.5 que quebram código antigo

Aqui mora o primeiro tombo, Tome cuidado!

Se tu vai reaproveitar código feito pra outro modelo, o Haiku 5.5 tem mudanças incompatíveis:

• Nada de temperature, top_p ou top_k: enviar qualquer um deles retorna erro 400, inclusive top_p de 1. O comportamento passa a ser guiado pelo prompt
• Nada de prefill do assistente: se a última mensagem for um turno do assistente, vem erro 400, mesmo com thinking desligado. As mensagens precisam terminar com um turno do usuário
• Sai o budget_tokens, entra o adaptive thinking: quem usava extended thinking com orçamento fixo precisa trocar

Se no mesmo projeto tu também tá migrando pro Sonnet 5.5, vale revisar seu código na API antes de virar a chave

O tokenizador novo muda suas estimativas

O Haiku 5.5 usa o tokenizador mais novo, o mesmo do Claude 4.7 em diante

Na prática, o mesmo texto conta cerca de 30% mais tokens do que no Haiku 4.5

Ou seja: se tu tinha planilha de custo ou de tamanho de lote feita com o modelo antigo, ela tá subestimando. Refaz a conta antes de confiar nela

Passo a passo: fluxo de duas camadas com Haiku 5.5 e Opus 5.5

A lógica é simples: o modelo barato faz o trabalho braçal, o caro só pensa em cima do que importa

Mas o fluxo inteiro depende de uma coisa: o resumo não pode perder o dado que o próximo passo precisa

Por isso o primeiro passo nem é código, é planejamento 🙂

1. Defina o contrato de saída

Antes de escrever qualquer prompt, lista o que o Opus vai precisar pra responder: números, nomes, datas, decisões, trechos que precisam ser citados ao pé da letra

Esse é o contrato: o formato que o Haiku é obrigado a devolver

{
  "numeros": [{ "valor": "", "unidade": "", "fonte": "" }],
  "nomes": [{ "nome": "", "papel": "", "fonte": "" }],
  "datas": [{ "data": "", "evento": "", "fonte": "" }],
  "decisoes": [{ "decisao": "", "fonte": "" }],
  "trechos_literais": [{ "texto": "", "fonte": "" }],
  "incertezas": [{ "ponto": "", "motivo": "", "fonte": "" }]
}

Adapta os campos ao teu caso, claro. Um pipeline de logs vai ter campos diferentes de um de contratos jurídicos

O erro comum deste passo: pedir só "resuma isso" sem dizer pra quê. Um resumo genérico escolhe sozinho o que é importante, e quase nunca escolhe o que o teu próximo passo precisava

2. Escreva o prompt de resumo que não perde dado

Como não tem temperature pra mexer, todo o controle fica no texto do prompt

E o prompt precisa deixar claro quatro coisas: valor exato, incerteza marcada, origem de cada item e formato estruturado

Você vai resumir o material abaixo para outro modelo, que vai usar o resumo para responder: {PERGUNTA}

Regras:
1. Preserve números, datas, nomes e valores EXATAMENTE como aparecem. Não arredonde e não converta unidades
2. Exceções, ressalvas e condições ("exceto", "desde que", "mas") são dado. Não descarte
3. Todo item leva a origem: arquivo, seção, linha ou id do trecho
4. Se algo for ambíguo ou contraditório, registre em "incertezas" em vez de escolher um lado
5. O que precisa ser citado ao pé da letra vai em "trechos_literais", sem reescrever
6. Ignore o que não ajuda a responder a pergunta
7. Se um campo não tiver nada, devolva lista vazia. Nunca omita a chave
8. Responda APENAS com JSON neste formato: {CONTRATO}

Repara que a pergunta final entra no prompt de resumo

É isso que deixa o Haiku saber o que é ruído e o que é sinal

O erro comum deste passo: pedir resumo em prosa. Prosa arredonda número ("cerca de 3 mil"), junta casos parecidos e some com a exceção que mudava a decisão. Estrutura com campo de origem é MUITO mais difícil de distorcer

3. Chame o Haiku 5.5

Aqui entra o claude-haiku-5-5 com o prompt do passo anterior e o material bruto

Mostro só os campos que importam pro fluxo, o resto da requisição segue como tu já usa na API:

{
  "model": "claude-haiku-5-5",
  "output_config": { "effort": "medium" },
  "messages": [
    {
      "role": "user",
      "content": "PROMPT DE RESUMO + material bruto do lote"
    }
  ]
}

E o que é esse effort?

O Haiku 5.5 é o primeiro Haiku com nível de esforço ajustável, com suporte a pensamento adaptativo

Os níveis são low, medium, high, xhigh e max, e o padrão é medium

Um detalhe importante: o effort afeta todos os tokens da resposta, ou seja, texto, chamadas de ferramenta e thinking. Subir o nível mexe direto no tamanho da resposta

Começa no padrão e só ajusta se o resumo vier faltando coisa

O erro comum deste passo: copiar uma requisição antiga com temperature ou com prefill do assistente e tomar erro 400. A mensagem final tem que ser do usuário, sempre

4. Filtre e valide o resumo antes de subir

Não manda o JSON pro Opus de olho fechado

Confere se o contrato veio cumprido: todas as chaves presentes e, onde fizer sentido, preenchidas

import json

CAMPOS_OBRIGATORIOS = [
    "numeros", "nomes", "datas",
    "decisoes", "trechos_literais", "incertezas",
]

def validar_resumo(texto_resposta):
    try:
        resumo = json.loads(texto_resposta)
    except json.JSONDecodeError:
        return None, ["json_invalido"]

    faltando = []
    for campo in CAMPOS_OBRIGATORIOS:
        if campo not in resumo:
            faltando.append(campo)
    return resumo, faltando

resumo, faltando = validar_resumo(resposta_do_haiku)

if faltando:
    # refaz só esse lote no Haiku, não o pipeline inteiro
    ...

Por que checar a chave e não o conteúdo?

Porque lista vazia pode ser legítima (o lote não tinha data nenhuma). O problema é a chave sumir, aí tu não sabe se não tinha nada ou se o modelo esqueceu

Foi por isso que a regra 7 do prompt existe 😉

O erro comum deste passo: confiar no resumo sem conferir os campos obrigatórios. Se faltou algo, refaz só aquele trecho no Haiku, que é barato, em vez de descobrir o buraco depois na resposta do Opus

5. Envie o essencial ao Opus 5.5

Agora sim o modelo grande entra em cena, recebendo só o resumo estruturado e a pergunta:

{
  "model": "claude-opus-5-5",
  "messages": [
    {
      "role": "user",
      "content": "Pergunta: {PERGUNTA}. Use apenas o resumo estruturado abaixo, gerado a partir do material original. Quando citar um dado, mantenha a fonte. Resumo: {JSON_VALIDADO}"
    }
  ]
}

Pedir pro Opus manter a fonte é o que te deixa rastrear de onde veio cada afirmação na resposta final

O erro comum deste passo: anexar o material bruto "por garantia". Aí tu paga o Haiku E paga o Opus pra ler tudo de novo, e a economia vai pro saco haha. Se tu sente que precisa do bruto, o problema tá no contrato do passo 1

Quanto custa cada camada: Haiku 5.5 e Opus 5.5 (com o Sonnet 5.5 de referência)

Valores por milhão de tokens, em dólar:

Se liga no salto do Haiku quando o prompt passa de 100 mil tokens

Isso é argumento direto pra quebrar o material bruto em lotes menores em vez de jogar tudo numa chamada só. E lembra do tokenizador novo: o mesmo texto conta mais tokens, então o lote chega nesse limite antes do que parece

Outra coisa que ajuda é cache. Como o prompt de resumo se repete em todo lote, ele é candidato natural:

• Haiku 5.5: leitura de cache a US$ 0,01/M (valor da listagem do OpenRouter)
• Opus 5.5: leitura de cache a US$ 0,20/M

E se a resposta do Opus não precisa sair na hora, ele tem 50% de desconto na Batch API

Segundo a Anthropic, rodar o Haiku 5.5 custa em média cerca de 75% menos que o Haiku 4.5, então quem já usava Haiku na frente também sente a diferença

Agora, se tu tá pensando no Sonnet como meio-termo pra segunda camada, tem o papo do custo por tarefa no Sonnet 5.5 pra conferir antes de decidir

Compactação no servidor ou resumo com Haiku: qual usar?

A API do Claude também tem uma compactação no servidor, que resume automaticamente o contexto antigo quando ele chega perto do limite

Ela é ativada pelo header beta compact-2026-01-12, com gatilho padrão de 150.000 tokens de entrada (mínimo de 50.000)

Parece a mesma coisa, mas resolve problema diferente:

Resumindo: a compactação no servidor cuida do histórico que cresce durante a conversa

O fluxo com Haiku cuida do material que já chega grande, antes de qualquer conversa começar

Antes de ligar o header, confere na documentação quais modelos suportam a compactação, beleza?

Quando o fluxo de duas camadas vale a pena?

Os melhores use cases batem com as cargas que a própria Anthropic e a documentação citam pro Haiku 5.5: resumos, compactações, extração, classificação, roteamento e tarefas de subagente

• Logs e documentos longos antes de uma análise: o Haiku resume por lote, o Opus analisa o conjunto dos resumos
• Extração de campos de material bruto: e-mails, tickets, relatórios. O Haiku puxa os campos do contrato, o Opus trabalha em cima dos dados já limpos
• Classificação e roteamento: o Haiku decide se o pedido precisa mesmo do modelo grande. Muita coisa resolve ali mesmo e nem chega no Opus
• Haiku como subagente: ele faz a parte braçal da investigação e entrega só a conclusão estruturada pro agente principal

E quando NÃO vale?

Sendo honesto: nem todo pipeline precisa disso

Se o material já é curto e cabe barato no modelo grande, a camada extra só adiciona latência, código e mais um ponto de falha

E se a tarefa depende do detalhe bruto inteiro (revisar um contrato cláusula por cláusula, procurar um bug numa linha específica de log), resumir é justamente o que tu não quer fazer. Aí o Opus tem que ver o original

Próximo passo: comece pelo contrato de saída

Recapitulando:

• o Haiku 5.5 filtra e resume o material bruto
• o Opus 5.5 recebe só o resumo validado e decide
• o contrato de saída e o prompt de resumo são o que garante que nenhum dado importante some no caminho

A qualidade do fluxo inteiro não depende do modelo, depende do prompt de resumo saber o que o próximo passo precisa

Então o próximo passo é bem prático: pega um pipeline que hoje manda tudo pro Opus, escreve o contrato de saída dele e coloca o claude-haiku-5-5 na frente com effort padrão

Roda, confere os campos, e só depois ajusta o effort ou o prompt

Faça o teste! 😀

Até o próximo post!