Haiku 5.5 Aceita 1M De Contexto, Mas Recusa Temperature E Prefill: O Que Quebra Na Migração

Existe um tipo de mensagem de chat de time que eu aprendi a temer: "alguém sabe por que o classificador começou a dar 400?". Ela costuma chegar depois que alguém trocou uma string de model ID num arquivo de configuração, achando que era só isso. Não é incomum que a troca seja correta e que o erro seja, também, previsível. O problema é que a previsão está escrita num guia de migração que ninguém leu, porque o lançamento parecia uma atualização de rotina.

Na semana passada a Anthropic lançou o Claude Haiku 5.5, e eu li a notícia com um incômodo parecido com o da fadiga de lançamentos que comentei no domingo anterior. Mais um modelo, mais um nome, mais um "o mais rápido e econômico da família". Só que, ao abrir a documentação, percebi que o interessante não era o anúncio. Era a lista de coisas que deixam de funcionar quando o código que roda no Haiku 4.5 passa a apontar para o novo modelo.

Importante dizer como li o material: foi estudo de documentação, não migração feita. Não rodei esse código contra a API nem comparei saídas. Tudo o que está aqui vem da página de novidades, do guia de migração, da tabela de preços e das notas de versão da Anthropic, e quando um dado é específico eu aponto de onde ele vem. Onde falo de times e de custos, são cenários hipotéticos, marcados como tal.

O post cobre o que a documentação diz que o Haiku 5.5 é, a conta de tokens, a lista do que retorna 400, os comportamentos que mudam sem erro e, por fim, uma opinião sobre onde o modelo cabe em arquitetura de agentes, com um checklist de migração em prosa.

O Que A Documentação Diz Que O Haiku 5.5 É

As notas de versão da Anthropic registram o lançamento do Claude Haiku 5.5 em 7 de outubro de 2026 e o descrevem como o modelo pequeno mais rápido e mais eficiente em custo da empresa. As características de capa são 1 milhão de tokens de janela de contexto e esforço ajustável. A página de novidades do modelo acrescenta o público que a Anthropic tem em mente: trabalho de alto volume e sensível à latência, como classificação, roteamento, extração e tarefas de subagentes.

Por fim, a Anthropic oferece um atalho para a parte mecânica. Segundo o guia de migração, no Claude Code o comando /claude-api migrate this project to claude-haiku-5-5 aplica a troca de ID e as mudanças quebrantes e gera um checklist. Eu usaria como ponto de partida e revisaria o diff linha a linha, porque a ferramenta não conhece as suas suposições de negócio, como o que o seu parser espera encontrar na primeira posição da resposta. Um detalhe tranquilizador: quem usa Managed Agents, segundo a documentação, não precisa de nenhuma mudança além do nome do modelo.

A Conta Dos Tokens: 30% A Mais, A Faixa De 100 Mil E As Imagens

O tokenizador do Haiku 5.5 é o mesmo do Claude 4.7 e dos modelos posteriores. Segundo a documentação, o mesmo texto gera cerca de 30% mais tokens do que no Haiku 4.5, com variação conforme o conteúdo. Eu leio esse "cerca de" com cuidado: é uma média declarada pelo fornecedor, e código, JSON, português e texto com muitos números não se comportam igual. A única forma honesta de saber o seu número é medir com o seu tráfego.

As consequências são em cadeia. O campo usage da resposta passa a reportar mais tokens para a mesma entrada, qualquer contador local calibrado para o 4.5 fica desatualizado, e o max_tokens que você ajustou com folga curta para o 4.5 pode cortar uma saída equivalente no 5.5. A documentação também pede que as estimativas de custo sejam refeitas contando com model igual a claude-haiku-5-5, o que é uma forma educada de dizer que a planilha antiga não serve.

Agora, o preço. A tabela oficial da Anthropic lista duas faixas para o Haiku 5.5, por milhão de tokens. Com prompt de até 100.000 tokens: entrada a US$ 0,10, saída a US$ 0,50, escrita de cache de 5 minutos a US$ 0,125, escrita de 1 hora a US$ 0,20 e leitura de cache a US$ 0,01. Com prompt acima de 100.000 tokens: entrada a US$ 0,50, saída a US$ 2,50, escrita de 5 minutos a US$ 0,625, escrita de 1 hora a US$ 1,00 e leitura a US$ 0,05. Esses são os valores que a página de preços traz hoje, e vale conferir a página antes de orçar, porque tabela de preço é o tipo de dado que muda sem aviso no seu repositório.

O detalhe que muda a conta é como a faixa funciona. Segundo a tabela, a contagem do prompt inclui os tokens lidos e escritos de cache, a faixa é decidida por requisição, e quando o prompt passa de 100.000 tokens todos os tokens daquela requisição pagam a faixa maior, não só o excedente. Não é um imposto marginal; é um degrau. Para comparação, a mesma tabela traz o Sonnet 5.5 a US$ 2 de entrada e US$ 10 de saída e o Opus 5.5 a US$ 4 e US$ 20, ambos com 1 milhão de contexto e sem faixa por tamanho.

Um cenário hipotético mostra o efeito do degrau com o tokenizador. Imagine um time que envia a um classificador prompts de cerca de 80 mil tokens no Haiku 4.5, tudo confortavelmente abaixo de 100 mil. Se a inflação do tokenizador fosse de exatamente 30%, esses prompts passariam a ter cerca de 104 mil tokens e cruzariam o limite. Dentro do próprio Haiku 5.5, 100 mil tokens de entrada custam US$ 0,01 na faixa menor; 104 mil custam cerca de US$ 0,052 na faixa maior. São 4% a mais de tokens e algo perto de cinco vezes o custo de entrada, por requisição. Os números do exemplo são meus, a regra de cobrança é da tabela. É o raciocínio de gestão de tokens em produção: o custo de contexto não é linear, e o orçamento precisa olhar a distribuição de tamanhos de prompt.

Imagens têm a sua própria aritmética. O Haiku 5.5 usa a camada de alta resolução: reduz a imagem acima de 2.576 pixels no lado maior ou de 4.784 tokens visuais, enquanto o 4.5 reduzia acima de 1.568 pixels ou 1.568 tokens. Segundo a documentação, uma imagem de 2.000 por 1.500 custa cerca de 2,5 vezes mais tokens visuais no 5.5.

O Que Retorna 400 Quando Você Troca O Model ID

A parte mais útil do guia de migração é a lista de requisições que passam a falhar com 400. Resumi na tabela abaixo o que a documentação descreve, com o que fazer em cada caso. O ponto comum é que quase tudo é parâmetro que o 4.5 aceitava sem reclamar e que o 5.5 trata como inválido.

Vale comentar alguns itens. O de temperature é o que mais tende a pegar código herdado, porque muita biblioteca interna injeta temperature: 0 por padrão para "deixar determinístico". No 5.5, segundo a documentação, se você enviar o campo ele só pode valer 1, e top_p só pode valer 0,99. A saída prática é remover os dois da camada de cliente, e não confiar em "mas sempre funcionou".

O prefill é o item de maior impacto de design. Truque clássico de classificação e de formatação: você termina a conversa com um turno parcial do assistente, como uma chave de abertura de JSON ou o início de um rótulo, e o modelo continua dali. No Haiku 5.5, qualquer requisição cujo último turno seja do assistente retorna 400, e isso vale mesmo com thinking desligado. A documentação sugere quatro alternativas: structured outputs, tools com enum para classificação, uma instrução de sistema pedindo resposta direta e mover continuações para a mensagem do usuário.

O erro de thinking com bloco reenviado é o mais sutil do grupo. A regra descrita é que enviar de volta um bloco de thinking depois de ter mudado system, tools ou mensagens anteriores retorna 400, e a recomendação é manter a conversa append-only. Quem edita o histórico para "limpar" mensagens antigas, resumir turnos ou reordenar ferramentas no meio da sessão vai esbarrar nisso. A documentação faz uma ressalva sobre contas criadas antes de 31 de agosto de 2026 às 00:00 UTC: nelas o erro só vem se thinking.block_binding.prefix_mismatch_behavior estiver definido.

Thinking Adaptativo E A Armadilha Do max_tokens

A mudança de comportamento mais importante não gera erro nenhum, e por isso mesmo é a que me preocuparia mais. Segundo a documentação, o adaptive thinking vem ligado por padrão no Haiku 5.5. Se você não configurou nada, a resposta pode começar com blocos do tipo thinking. Código que faz response.content[0].text assume que a primeira posição é texto e passa a quebrar de forma intermitente, porque depende de o modelo ter decidido pensar ou não. A recomendação é selecionar os blocos por type, nunca por posição.

O segundo efeito é a armadilha do max_tokens. Os tokens de thinking contam para esse limite. Um max_tokens pequeno, pensado para uma classificação de uma palavra, pode terminar com stop_reason: "max_tokens" depois do thinking e antes de qualquer texto. O resultado é uma resposta "bem-sucedida", status 200, sem nada utilizável dentro. O exemplo de requisição "depois" da própria documentação usa max_tokens de 16.000 com thinking adaptativo e esforço médio, o que dá a ordem de grandeza do que a Anthropic considera um orçamento confortável para esse modo:

{
  "model": "claude-haiku-5-5",
  "max_tokens": 16000,
  "thinking": { "type": "adaptive" },
  "output_config": { "effort": "medium" },
  "messages": [ ... ]
}

Para o trabalho de alto volume que o Haiku mira, a alternativa é desligar o thinking com {"type":"disabled"}. A documentação diz que isso só é permitido com effort high ou menor, então o par precisa ser consistente. Num classificador simples, minha inclinação seria começar com thinking desligado e effort baixo, medir a qualidade e só então testar se um pouco de raciocínio paga o custo em latência e tokens.

Existe um terceiro efeito, mais financeiro do que técnico. No Haiku 5.5, os blocos de thinking de turnos anteriores permanecem no contexto e contam como entrada; no 4.5, só o do último turno ficava. Isso explica por que conversas multi-turno podem carregar mais tokens do que apenas os 30% do tokenizador justificariam. Quem tem agentes com muitos turnos e muito thinking vai ver a entrada crescer de forma composta. A documentação cita a limpeza de blocos antigos (thinking block clearing) como mitigação, mas lembre da regra do append-only: limpar é uma operação suportada, editar o histórico por conta própria não é.

O Que Muda Sem Dar Erro

Além do thinking, a documentação lista alterações que não quebram a requisição e mesmo assim mudam o comportamento do sistema. Começo pelo cache de prompt, que é a boa notícia: o mínimo cacheável caiu de 4.096 para 512 tokens. Prompts de sistema curtos, que antes ficavam abaixo do piso e nunca eram cacheados, agora podem ser. Para o contexto de preços da família, vale registrar que, na mesma data, a Anthropic também reduziu a leitura de cache do Sonnet 5.5 de US$ 0,20 para US$ 0,10 por milhão, assunto que merece post próprio.

Em segundo lugar, as tags de context-awareness não são injetadas no 5.5. Quem dependia de o modelo "saber" quanto contexto restava precisa olhar os task budgets, que a documentação descreve como beta. Em terceiro, a segurança: classificadores podem devolver stop_reason: "refusal", e não há fallback no servidor. O cliente precisa tratar esse caso explicitamente, com retentativa, roteamento para outro modelo ou escalonamento humano.

Em quarto, a portabilidade de blocos de thinking entre contas e entre modelos, que é onde arquiteturas multimodelo podem se complicar. Segundo a documentação, os blocos de thinking do Haiku 5.5 só funcionam na conta que os produziu ou em conta vinculada. Um serviço multi-cliente com um repositório central de conversas precisa reenviar pela conta de origem; blocos de outra conta são descartados sem erro. Sem erro significa que a conversa continua, só que sem o raciocínio anterior, e a qualidade pode cair de forma difícil de rastrear.

Onde O Haiku Faz Sentido Em Agentes, E Onde Eu Hesitaria

Aqui entra opinião minha, apoiada no que a documentação diz sobre o público-alvo. Classificação, roteamento, extração e subagentes têm em comum duas propriedades: a tarefa é bem delimitada e o volume é alto. Quando uma tarefa é pequena e se repete milhões de vezes, cada décimo de centavo por milhão de tokens vira orçamento, e latência vira experiência do usuário. É nesse desenho que um modelo pequeno costuma pagar a conta, e é o que a Anthropic descreve para o Haiku 5.5. Uma arquitetura plausível, que apresento como hipótese, é um modelo maior planejando e um enxame de Haikus executando passos estreitos, como extrair campos, rotular tickets ou decidir qual ferramenta chamar. Já falei sobre o raciocínio econômico por trás disso quando tratei da destilação de um modelo próprio de 8B para reduzir custo em produção: a pergunta é sempre qual o menor modelo que entrega a qualidade exigida para aquela etapa.

Onde eu hesitaria. Primeiro, em tarefas que exigem contexto realmente grande. O 1 milhão de tokens existe, mas o degrau de preço acima de 100 mil faz a entrada custar US$ 0,50 por milhão, e o Sonnet 5.5, a US$ 2, não tem faixa por tamanho. A diferença continua grande, só que o argumento "modelo pequeno é muito mais barato" fica menos folgado, e a qualidade em contexto longo é algo que a documentação não quantifica e que eu não tenho como afirmar. Segundo, em etapas em que um erro do subagente é caro e silencioso. Um classificador que erra o rótulo sem sinalizar incerteza polui o resto da cadeia; ali, vale pensar em amostragem de auditoria ou em um verificador. Terceiro, em fluxos que dependem de capacidade garantida, já que o Priority Tier não é suportado.

Para a escolha entre os modelos da família, o que fiz em comparações anteriores de Opus 5.5 e concorrentes vale aqui: separar o modelo da tarefa e medir com a sua própria avaliação. Este post não traz benchmark do Haiku 5.5 e eu prefiro não citar número que não consegui verificar. Quem já acompanhou o lançamento do Opus 5.5 sabe que a tabela de preços e a tabela de qualidade contam histórias diferentes, e que o custo por tarefa resolvida é a métrica que interessa.

Sobre orçamento, o que eu revisaria antes de migrar: a distribuição de tamanhos de prompt contra o limite de 100 mil, o fator real de inflação do tokenizador no seu tráfego, o custo de imagens se há OCR ou visão, o crescimento de entrada em conversas multi-turno por causa do thinking acumulado e a taxa de refusals. E o que eu mediria depois: tokens de saída por tarefa, já que o thinking adaptativo é um gasto novo que não existia na sua linha de base do 4.5.

Um Checklist De Migração Em Prosa

Se eu conduzisse essa migração num time, começaria pelo inventário: busca por budget_tokens, temperature, top_p, top_k, prefill, computer_20250124 e o header de fine-grained tool streaming. O prefill pode estar escondido em funções que montam mensagens, então qualquer chamada cujo último papel seja assistant é suspeita. Depois vem o parsing: selecionar blocos por type, tratar max_tokens e refusal como estados explícitos, revisar os valores de max_tokens e decidir, classificador a classificador, entre thinking desligado e adaptativo. Por fim, recontar tokens com o modelo novo e remontar a estimativa com as duas faixas.

O rollout vem depois: uma fatia pequena do tráfego, na conta de produção e não numa de testes, por causa da diferença entre contas criadas antes e depois de 31 de agosto. Compare taxa de erro, distribuição de stop_reason, tokens por requisição e custo por tarefa contra o 4.5, e teste o que acontece quando o Haiku 5.5 retoma conversas com blocos de thinking de modelos que ele não lê. Mantenha a volta para o 4.5 enquanto ele existir; Haiku 3 e 3.5 já foram aposentados e não servem de plano B.

Conclusão

Minha leitura é que a parte difícil dessa migração não é o código que quebra com 400. Esse é o melhor cenário: erro alto, barulhento, corrigido em uma tarde com a tabela acima na mão. O que me preocupa é o que passa em silêncio, como a resposta que começa com um bloco de thinking, o max_tokens que gasta tudo pensando, o prompt que cruza 100 mil tokens por causa do tokenizador e passa a custar uma faixa diferente, e o bloco de raciocínio que some entre contas ou modelos sem aviso.

Também acho honesto reconhecer o que este texto não sabe. Não há aqui benchmark, não rodei o modelo, e os números de custo são os da tabela da documentação em 11 de outubro, que a Anthropic pode ajustar. A recomendação concreta que sobrevive a essas incertezas é pequena: ler o guia de migração inteiro antes de trocar o ID, medir o seu tráfego em vez de confiar nos 30% da média, e tratar o limite de 100 mil como parte do desenho de contexto.

O Haiku 5.5 parece ser um bom candidato para o trabalho que a Anthropic descreve, e a lista de incompatibilidades é, no fim, um sinal de que o modelo tem um contrato mais estrito do que o anterior. Contratos estritos incomodam na migração e ajudam depois, porque reduzem as variações que você precisa testar. Se esse efeito compensa o trabalho de adaptação, só a sua avaliação dirá.

Fontes:

• Anthropic — Novidades do Claude Haiku 5.5
• Anthropic — Claude Haiku 5.5 migration guide
• Anthropic — Pricing
• Anthropic — Release notes