A Matemática de Custo dos Agentes de IA: Quando o Haiku Vence o Sonnet (e Quando Não)

Índice

Atualizado junho 2026.

TL;DR: Escolher o Claude Haiku em vez do Sonnet pode reduzir o custo por chamada em uma ordem de grandeza, mas só quando a tarefa tolera a taxa de sucesso menor do Haiku. A métrica que importa é o custo por resultado bem-sucedido — custo da chamada mais retentativas mais limpeza humana — não o preço de tabela por token. Eu roteio por tarefa, e uma parcela significativa dos meus passos de alto volume roda no Haiku enquanto as decisões de julgamento ficam no Sonnet.

Leitura do operador: Eu rodo mais de 100 agentes, e a inferência é um item de custo real. Mas já vi times “economizarem” forçando tudo no modelo mais barato e depois pagarem a conta em retentativas, escalonamentos e clientes irritados. A matemática de custo só funciona quando você mede o funil inteiro.

O modelo mais barato não é o que tem o menor preço por token. É o que tem o menor custo total para fazer o trabalho direito. Esses são números diferentes, e a diferença entre eles é exatamente onde a maioria das decisões de custo de agentes dá errado.

A economia dos tokens, dita sem rodeios

A Anthropic cobra pelo Claude por milhão de tokens, com entrada e saída faturadas separadamente, e a saída custando várias vezes mais que a entrada. Os números exatos mudam com o tempo, então confira os preços atuais da Anthropic — mas é a estrutura que orienta a decisão:

• Haiku é o nível barato e rápido — de longe o menor custo por token da família.
• Sonnet fica no meio — notavelmente mais caro que o Haiku, notavelmente mais barato que o Opus.
• Opus é o nível premium para o raciocínio mais difícil.

Duas coisas decorrem daí. Primeiro, os tokens de saída dominam o custo em tarefas generativas, então um modelo verboso custa mais mesmo com o mesmo preço por token. Segundo, a diferença de preço por token entre Haiku e Sonnet é grande o suficiente para que, num passo de alto volume, ela apareça com certeza na fatura. Esse é o argumento a favor do Haiku. Agora o argumento contra.

A métrica que realmente importa: custo por resultado bem-sucedido

O custo por chamada é um número de vaidade. Esta é a fórmula que de fato uso:

custo_por_sucesso = (custo_chamada × tentativas) + custo_limpeza
                     ÷ taxa_de_sucesso

Onde tentativas contabiliza as retentativas, e custo_limpeza é o custo esperado de um humano corrigir as falhas que escapam. Veja o que isso faz com a comparação.

Suponha que o Haiku custe cerca de um décimo do Sonnet por chamada. Se o Haiku acerta 80% das vezes numa tarefa e o Sonnet acerta 98%, a economia por chamada parece enorme. Mas se cada falha do Haiku dispara uma retentativa e 1 a cada 10 ainda precisa de um humano que custa dinheiro de verdade, o termo de limpeza pode engolir a economia de tokens. Numa tarefa de baixo risco e alto volume, a matemática favorece o Haiku de forma esmagadora. Numa tarefa em que uma falha envia um e-mail ao cliente errado, ela pode se inverter completamente.

Você não consegue tomar essa decisão sem medir a taxa de sucesso por modelo — que é exatamente o que um harness de avaliação te dá. Rode o mesmo conjunto de avaliação contra os dois modelos e leia as taxas de sucesso na mesma régua.

Onde o Haiku vence de forma decisiva

O Haiku é a escolha certa quando a tarefa é estreita, estruturada e verificável:

• Classificação e roteamento — “esta mensagem recebida é uma reserva, uma reclamação ou spam?” Três categorias, fácil de verificar, roda o tempo todo. Haiku o dia inteiro.
• Extração com um esquema — tirar uma data, um nome, um valor de um texto, validado com Zod. Se a saída faz parse, está quase certamente correta.
• Reescritas curtas e formatação — ajustes de tom, resumir uma entrada sabidamente boa, normalizar dados.
• Filtragem de primeira passagem — o Haiku faz a triagem, e só os casos ambíguos são escalonados para o Sonnet. Esse é o padrão de maior alavancagem.

O fio condutor: o custo de um erro do Haiku é baixo e o erro é barato de detectar. Quando a verificação é barata e o risco é baixo, o modelo barato vence.

Onde o Sonnet ganha o seu preço

O Sonnet (e às vezes o Opus) vale a pena quando a tarefa é aberta, de múltiplos passos ou cara de errar:

• Loops de agente com várias ferramentas onde uma chamada errada de ferramenta gera uma cascata. Maior confiabilidade de raciocínio se acumula ao longo dos passos — os padrões de orquestração que abordo em orquestração multiagente dependem de o modelo não perder o fio da meada.
• Geração voltada ao cliente onde uma saída ruim custa confiança, não apenas uma retentativa.
• Qualquer coisa em que a verificação seja em si difícil. Se você não consegue dizer de forma barata se a saída está correta, não pode se dar ao luxo de um modelo que erra com frequência.

Uma falha aqui não custa uma retentativa — custa um reembolso, um cliente perdido, ou o meu tempo. Diante disso, o adicional por token é erro de arredondamento.

A regra de roteamento que de fato coloco em produção

Eu não escolho um modelo por agente. Eu roteio por tarefa dentro do agente, geralmente com um classificador barato decidindo qual modelo a jusante cuida do trabalho:

function pickModel(task: Task): string {
  // Barato, verificável, alto volume → Haiku
  if (task.type === "classify" || task.type === "extract") {
    return "claude-haiku";
  }
  // Aberto ou voltado ao cliente → Sonnet
  if (task.customerFacing || task.steps > 2) {
    return "claude-sonnet";
  }
  return "claude-sonnet"; // por padrão, a escolha segura
}

Dois princípios codificados aqui. Por padrão, o modelo seguro, não o barato — você otimiza o custo para baixo a partir de uma base que funciona, nunca a confiabilidade para cima a partir de uma quebrada. E escale, não aposte: deixe o Haiku cuidar dos 80% fáceis e entregue os 20% difíceis ao Sonnet. Esse híbrido quase sempre vence rodar tudo em qualquer um dos modelos sozinho.

Há também o cache de prompt para colocar por cima: se o seu prompt de sistema é grande e reutilizado, o cache reduz substancialmente o custo de entrada independentemente do nível, o que às vezes torna o Sonnet barato o suficiente para que a questão do Haiku se torne irrelevante.

Um exemplo trabalhado do meu próprio stack

Pegue um passo de triagem de mensagens recebidas de alto volume. Ele roda milhares de vezes, a tarefa é uma classificação de três vias, e um erro só significa que o item cai numa fila de revisão — barato de detectar, baixo risco. Essa é uma tarefa de manual para o Haiku, e tirá-la do Sonnet reduziu significativamente o custo desse passo sem impacto mensurável no resultado que importava.

Agora pegue o passo que redige a resposta de fato ao cliente. Volume menor, aberto, e um rascunho ruim saindo custa confiança. Esse fica no Sonnet. Mesmo agente, dois modelos, roteados por risco. Acompanho o custo por execução e as métricas de sucesso dos dois, do jeito que descrevo em como meço se um agente de IA está realmente funcionando — e só rebaixo um passo de nível depois que a avaliação diz que o modelo mais barato mantém a taxa de sucesso.

FAQ

O Claude Haiku é sempre mais barato que o Sonnet na prática?

Por token, sim — por larga margem. Por resultado bem-sucedido, nem sempre. Se a taxa de sucesso menor do Haiku dispara retentativas e limpeza humana, o custo total pode superar o do Sonnet em tarefas onde os erros são caros de detectar ou corrigir.

Como decido entre Haiku e Sonnet para uma dada tarefa?

Pontue a tarefa em dois eixos: quão verificável é a saída e quão custoso é um erro. Trabalho barato de verificar, de baixo risco e alto volume vai para o Haiku; trabalho aberto, voltado ao cliente ou difícil de verificar vai para o Sonnet. Roteie por tarefa, não por agente.

Qual é a única métrica de custo que devo acompanhar?

Custo por resultado bem-sucedido — custo da chamada vezes tentativas mais custo de limpeza esperado, dividido pela taxa de sucesso. O preço por chamada sozinho esconde retentativas e tempo humano, que é onde os modelos baratos ficam caros sem você perceber.

Posso usar os dois modelos em um agente?

Sim, e geralmente você deveria. O padrão mais forte é uma primeira passagem barata (Haiku classifica ou filtra) que escalona só os casos ambíguos para o Sonnet. Esse híbrido normalmente vence rodar tudo em um único nível.