Esta nota responde a uma pergunta que aparece em quase todo projeto com Claude: qual modelo usar? A resposta tentadora é “o maior, para não errar”. A resposta cara é a mesma, e este texto existe para mostrar por que ela costuma estar errada. O modelo maior acerta mais em tarefas difíceis, mas também custa mais por token e costuma responder mais devagar. Escolher bem exige três coisas: saber quais níveis existem e o que cada um promete, montar um conjunto de exemplos pequeno que se pareça com o seu tráfego real, e medir qualidade, latência e custo nesse conjunto antes de decidir. No fim, a decisão precisa ficar registrada com os números, para que alguém consiga revisitá-la quando um modelo novo sair.

Os preços, nomes e limites desta aula foram conferidos nas páginas oficiais da Anthropic em 18 de outubro de 2026. Preço e nome de modelo mudam, então a lista de fontes no fim traz os endereços para você conferir de novo antes de usar qualquer número em produção.

Mapa da aula

Pré-requisitos: LLMs explica tokens, janela de contexto e o que o modelo faz com o texto. Prompt e contexto mostra como montar a entrada, o que pesa no custo e no cache. Avaliação de RAG traz a lógica de conjunto de avaliação, juiz e ruído estatístico, que aparece aqui em outra escala.

Parte 1: a escolha e a medição

1. O problema da escolha

Imagine que você precisa transportar caixas de um depósito para outro. Um caminhão de carga resolve, mas usá-lo para entregar uma encomenda de três quilos é um desperdício de combustível, de tempo de manobra e de dinheiro. Uma bicicleta resolve a encomenda pequena e chega antes porque não passa pelo trânsito pesado. O erro não está em ter caminhão. Está em usá-lo sem ter olhado a carga. Escolher modelo funciona do mesmo jeito: o modelo maior tem mais capacidade, e essa capacidade só vale o preço quando a tarefa realmente precisa dela.

O erro comum tem duas faces. A primeira é escolher o maior “por segurança”, sem nenhuma medição, e pagar por uma capacidade que a tarefa nunca usa. A segunda é escolher o menor por custo, sem nenhuma medição, e descobrir depois, em produção, que ele erra justamente nos casos que mais importam. As duas decisões têm a mesma raiz: não houve um número para comparar. Quem escolhe pelo nome do modelo ou pela impressão de uma demonstração está, na prática, apostando.

A saída é transformar a escolha em uma pergunta respondível. Em vez de “qual modelo é melhor?”, a pergunta passa a ser “qual é o modelo mais barato que atinge a qualidade que este produto exige, com a latência que esta experiência tolera?”. Essa pergunta tem uma resposta. Ela depende de um critério de qualidade que você define, de um tempo de resposta aceitável e de um orçamento. Quando você tem os três, a escolha deixa de ser questão de gosto.

2. Por que o eval existe

Um eval, forma curta de avaliação, é um conjunto de casos com resposta esperada ou critério de correção, rodado sempre do mesmo jeito, para medir um sistema. Ele parece burocracia até o momento em que você compara dois modelos e os dois parecem bons. Uma conversa de dez minutos com o modelo mostra o que ele faz bem nos exemplos que você lembrou de testar. Ela não mostra o que acontece nos cem casos que você não pensou em testar, e é justamente aí que os modelos diferem.

A comparação medida resolve dois problemas ao mesmo tempo. O primeiro é a memória seletiva: a gente lembra dos casos em que o modelo brilhou e esquece os que falhou. Um conjunto fixo obriga a olhar todos os casos com o mesmo peso. O segundo é o ruído: uma diferença pequena entre dois modelos pode ser sorte de uma execução. Um eval com número de casos suficiente e a mesma pontuação repetida deixa claro quando a diferença é real e quando é só variação. A seção 8 volta a esse ponto.

Vale notar o que a própria documentação diz sobre o assunto. A página de escolha de modelo recomenda criar testes específicos para o seu caso de uso e afirma que ter um bom conjunto de avaliação é o passo mais importante do processo. O resto desta aula é a receita para montar esse conjunto e lê-lo sem se enganar.

A figura abaixo mostra o fluxo completo de um eval. Os mesmos casos entram nos quatro níveis, cada nível responde a todos eles, as respostas viram uma tabela com três medidas e a tabela vira um registro. A ordem importa: o registro só faz sentido depois que as três medidas existem para os quatro níveis, e não para um só.

Repare na tela. Os casos saem do topo e se dividem em quatro setas com o mesmo rótulo, porque o ponto é que todos os níveis recebem exatamente a mesma entrada. A tabela central concentra qualidade, latência e custo na mesma linha, de modo que nenhuma medida aparece sozinha. Quando você for montar o seu, respeite essas duas regras: mesma entrada para todos e uma tabela única como saída.

3. Exemplos no plural

A mesma escolha muda de cara conforme a tarefa. Considere quatro produtos hipotéticos. Em todos eles, o modelo recebe uma entrada e devolve uma saída, mas o peso de errar muda muito.

Um classificador de tickets de suporte lê uma mensagem e escolhe uma de dez categorias. Milhares de mensagens chegam por dia, a resposta tem poucas palavras e um erro custa pouco, porque o ticket pode ser reclassificado por uma pessoa. Nesse caso, o nível menor tende a ser suficiente, e o ganho de qualidade do maior dificilmente compensa o custo de milhares de chamadas por dia. Esse é o caso típico do nível pensado para alto volume e tarefas sensíveis a latência, como classificação, extração e roteamento.

Um assistente que extrai campos de contratos em PDF lê documentos longos e devolve um JSON com datas, valores e partes. Aqui o erro silencioso é caro: uma data trocada pode gerar uma multa. O eval precisa cobrar exatidão campo a campo, e o nível intermediário costuma ser o ponto de partida, com teste no maior se o eval mostrar falhas em documentos complicados.

Um agente que corrige bugs em um repositório trabalha por muitos passos, lê arquivos, roda testes e decide o que mudar. Um erro no meio do caminho pode se espalhar pelo resto da tarefa, e a tarefa pode durar minutos. Esse é o cenário em que o nível de maior capacidade se justifica com mais frequência, porque a diferença de qualidade se acumula ao longo dos passos.

Um chat de atendimento responde ao cliente enquanto ele espera na tela. A latência aparece na experiência de cada turno, e um atraso de vários segundos já é percebido. Aqui o critério de latência pesa tanto quanto a qualidade, e o nível rápido pode ser a escolha certa mesmo que o maior responda um pouco melhor.

Os quatro produtos mostram o padrão. A capacidade extra só se paga quando o erro custa mais do que o preço da chamada extra, ou quando a tarefa exige passos que o modelo menor não sustenta. Sem um eval, você não sabe em qual dos quatro casos está.

Parte 2: os níveis da família Claude

4. Os níveis da família Claude

Na documentação oficial, a família atual tem quatro modelos. A tabela de comparação da Anthropic traz a descrição de cada um, a velocidade relativa, o preço, o identificador de API e o limite de contexto. Os nomes e preços abaixo foram lidos nessa página e na página de preços em 18 de outubro de 2026. Antes de copiar um número para o seu projeto, confira de novo, porque a própria página avisa que os preços podem mudar.

O primeiro nível é o Claude Fable 5.1, descrito pela documentação como voltado a “raciocínio exigente e trabalho agêntico de longo horizonte”. A página de escolha de modelo o chama de o modelo mais capaz aberto a todos os clientes. Ele é também o mais caro da tabela: US$ 10 por milhão de tokens de entrada e US$ 50 por milhão de tokens de saída, no preço padrão. A velocidade relativa que a tabela informa é “mais lenta”. Use esse nível como referência de teto, para perguntar se alguma tarefa do seu produto realmente precisa dele. Ele aparece na documentação como o caminho quando a avaliação no Opus 5.5 com esforço alto ainda não atinge a meta.

O segundo nível é o Claude Opus 5.5, descrito como voltado a “trabalho agêntico de código e conhecimento de longa duração”. A documentação o recomenda como ponto de partida para a maioria das cargas de trabalho na página de escolha de modelo. Ele custa US$ 4 por milhão de tokens de entrada e US$ 20 por milhão de saída, e a velocidade relativa é “moderada”. Esse nível é a escolha natural quando a tarefa é longa, tem vários passos e um erro custa caro.

O terceiro nível é o Claude Sonnet 5.5, descrito como “a melhor combinação de velocidade e inteligência”. Ele custa US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída, com velocidade relativa “rápida”. É o nível de equilíbrio: para uma parte grande dos produtos, ele entrega a qualidade necessária a um custo que permite escalar. Na página de escolha de modelo, a tabela o indica para geração de código, análise de dados, criação de conteúdo e uso de ferramentas no dia a dia.

O quarto nível é o Claude Haiku 5.5, descrito como voltado a “tarefas de alto volume e sensíveis a latência, como classificação, extração e roteamento”. Ele é o mais rápido da tabela, com velocidade relativa “mais rápida”. O preço base é de US$ 0,10 por milhão de tokens de entrada e US$ 0,50 por milhão de saída para prompts de até 100 mil tokens. Acima de 100 mil tokens de prompt, o preço sobe para US$ 0,50 de entrada e US$ 2,50 de saída. Esse detalhe pesa em projetos que mandam documentos longos para o Haiku, e volta na seção 10.

Todos os quatro têm janela de contexto de 1 milhão de tokens e limite de saída de 128 mil tokens na API de Mensagens síncrona, segundo a tabela de comparação. Isso significa que o limite de contexto não separa os níveis. O que separa são a qualidade medida, a velocidade e o preço. A documentação também diz que todos os modelos atuais aceitam texto e imagem como entrada, saída de texto, múltiplos idiomas e uso de ferramentas. A diferença entre eles está em quanto cada um acerta, quanto demora e quanto custa.

Duas observações sobre a tabela ajudam a não se perder. A primeira é que o preço de cada nível vem de uma tabela pública que mistura preço padrão, preço de lote e preço de cache. Na prática, a conta real depende de quais desses descontos o seu uso consegue aproveitar. A seção 10 faz essa conta com calma. A segunda é que o nível de capacidade e o preço andam juntos, mas não de forma linear: o salto de Haiku para Sonnet é de vinte vezes no preço de entrada, e o salto de Sonnet para Opus é de cerca de duas vezes. Essa diferença é a razão pela qual vale medir o degrau intermediário antes de pular para o topo.

5. Identificadores, aliases e versões

Antes de medir qualquer coisa, é preciso saber qual identificador o código envia. A documentação de versionamento de modelos diz que, a partir da geração 4.6, o identificador sem data, como claude-opus-5-5 ou claude-haiku-5-5, é o identificador canônico de uma versão. Ele aponta para um snapshot fixo. A Anthropic não altera os pesos nem a configuração de um identificador existente. Quando sai uma versão nova, ela chega sob um identificador novo.

Isso importa porque muita gente supõe que um nome sem data é um ponteiro que sempre leva à versão mais recente, como um atalho que se atualiza sozinho. Para os modelos da geração 4.6 em diante, a documentação diz que não é assim. Para modelos mais antigos, existem aliases que apontam para o snapshot datado mais recente daquela versão menor, e esses aliases podem mudar de destino. Por isso a regra prática é clara: fixe o identificador completo no código de produção e, quando for trocar de modelo, faça isso por uma decisão registrada, não por um alias que mudou sem você perceber.

A própria documentação lembra que a infraestrutura em volta do modelo, como roteador e classificadores de segurança, pode mudar mesmo sem troca de identificador. Diferenças pequenas de comportamento em um identificador estável são possíveis. Essa é mais uma razão para o eval rodar de novo quando algo muda, e não só quando o modelo muda de nome.

Cada identificador também tem sua própria data de aposentadoria. Na tabela de comparação, o Haiku 5.5 aparece com retirada “não antes de 7 de outubro de 2027”, o Sonnet 5.5 “não antes de 28 de setembro de 2027”, o Opus 5.5 “não antes de 22 de setembro de 2027” e o Fable 5.1 “não antes de 1 de setembro de 2027”. Essas são datas mínimas de compromisso, não datas definitivas, e elas entram no registro da decisão, como a seção 14 explica.

Parte 3: medir

6. Montar o conjunto de avaliação

Um conjunto de avaliação pequeno e representativo é uma lista de casos reais ou muito parecidos com os reais, cada um com a forma de checar se a resposta está certa. O adjetivo “pequeno” é honesto: um conjunto de trinta casos bem escolhidos já ensina muito mais do que trezentos casos copiados da mesma fonte. O adjetivo “representativo” é o que mais pesa. O conjunto precisa refletir a distribuição real do seu tráfego, com a mesma proporção de tipos de pedido, tamanhos de entrada e casos difíceis.

A página de definição de critérios e construção de avaliações da Anthropic diz que o conjunto deve espelhar a distribuição de tarefas do mundo real e que não se deve esquecer das bordas. Ela lista exemplos de bordas: entradas irrelevantes ou inexistentes, entradas muito longas, entradas ruins ou mal-intencionadas em um chat e casos ambíguos, em que pessoas teriam dificuldade de concordar entre si. A mesma página afirma que é melhor ter mais perguntas com sinal um pouco menor, pontuadas automaticamente, do que poucas perguntas de altíssima qualidade corrigidas à mão. A página não fixa um número mínimo de casos. Os exemplos que ela usa vão de 100 a 1.000 casos. A faixa de trinta a cem casos que aparece no diagrama desta aula é uma recomendação prática minha para começar, não um número da documentação.

Para montar o conjunto na prática, comece pelo tráfego real que você já tem. Se o produto ainda não existe, use exemplos escritos por quem conhece o problema, mas marque-os como sintéticos, porque eles tendem a ser mais limpos do que o uso verdadeiro. Depois, selecione casos de modo que cubram os tipos de pedido que aparecem com frequência, os que aparecem raramente mas custam caro e as bordas listadas acima. Guarde o conjunto em um arquivo versionado, com um identificador por caso e uma marca que diga a que categoria ele pertence. A categoria serve para perceber que um modelo vai bem na maioria e falha justamente numa classe de casos que você não pode perder.

Um conjunto mal montado engana. Se todos os casos forem fáceis, qualquer modelo passa e a comparação não diz nada. Se todos os casos vierem da mesma semana de suporte, o resultado vale só para aquela semana. E se o conjunto for escrito depois de olhar as respostas de um modelo, ele tende a favorecer o modelo que você já tinha em mente. A regra que evita esse viés é montar o conjunto antes de rodar qualquer modelo e congelá-lo depois.

7. Pontuar as respostas

Pontuar é transformar cada resposta em um número que possa ser comparado. A forma mais simples e mais confiável é a checagem automática. Se a resposta esperada é uma categoria, um valor de campo ou uma opção de múltipla escolha, basta comparar o texto com o gabarito, normalizando espaços e maiúsculas. A documentação mostra exatamente esse padrão, uma comparação que descarta espaços e diferenças de caixa, e recomenda estruturar as perguntas para permitir correção automática sempre que possível.

Quando a resposta é um texto livre, a correção automática fica mais difícil. Uma opção é usar outro modelo como juiz, com critérios escritos de forma explícita: “a resposta cita a cláusula certa? A data está no formato pedido? O tom é adequado?”. A documentação recomenda usar um modelo diferente para avaliar a saída de outro modelo, porque um modelo tende a favorecer as próprias respostas. A seção 8 de Avaliação de RAG trata do juiz em detalhe, com vieses e calibração contra pessoas. O que vale repetir aqui é o princípio: antes de usar um juiz, rode as checagens determinísticas que você consegue escrever, e deixe o juiz para o que não tem jeito de checar com regra.

Uma correção humana continua útil, mas em amostra pequena. A documentação diz que avaliações humanas são mais caras, mais lentas e de menor volume, e que devem ser reservadas para amostras pequenas e de alto valor. Use-as para calibrar o juiz automático e para checar, de vez em quando, se a pontuação automática ainda faz sentido.

8. Qualidade

Qualidade é o que o seu critério mede. Ela não é uma propriedade abstrata do modelo. Um modelo pode ser excelente para resumir e fraco para extrair datas, e a média dos dois esconde o fato. Por isso a comparação precisa separar a pontuação por categoria. A documentação de escolha de modelo fala em comparar os modelos quanto à exatidão das respostas, à qualidade da resposta e ao tratamento de casos de borda. Esses três eixos merecem colunas próprias na tabela de resultados.

Com o conjunto em mãos, rode cada modelo com as mesmas entradas, o mesmo prompt de sistema e os mesmos parâmetros, mudando só o identificador. Esse cuidado é o que torna a comparação justa. Se um modelo recebe um prompt otimizado e o outro recebe o prompt original, a diferença medida mistura modelo e prompt, e você não sabe o que causou o quê.

Quando dois modelos ficam com pontuações próximas, não conclua nada sem medir a incerteza. Um conjunto de cinquenta casos tem uma margem de erro grande: uma diferença de cinco pontos percentuais pode desaparecer se você repetir a execução ou trocar cinco casos. A seção 9 de Avaliação de RAG mostra com números como o tamanho da amostra e o ruído de medição determinam o que é possível afirmar. A regra prática é só declarar vencedor quando a diferença for maior que o ruído de uma execução para outra, e quando ela aparecer nos mesmos casos nos dois lados, o que se chama comparação pareada.

Por fim, a qualidade tem de ser medida com o esforço que você pretende usar em produção. A seção 12 explica o parâmetro de esforço. Um modelo rodado em esforço baixo e outro em esforço alto não se comparam justamente, porque estão gastando quantidades diferentes de raciocínio.

9. Latência

Latência é o tempo que a resposta leva para chegar. A documentação de redução de latência da Anthropic define o assunto com dois termos. O primeiro é a latência de base, o tempo que o modelo leva para processar o prompt e gerar a resposta. O segundo, mais útil para experiência de usuário, é o tempo até o primeiro token (TTFT, do inglês time to first token), que mede quanto tempo passa entre o envio do prompt e a chegada do primeiro token da resposta. O TTFT importa especialmente quando a resposta chega em fluxo (streaming), porque a pessoa começa a ler antes de a resposta terminar.

O tempo total é o intervalo entre o envio e o último token. Ele importa quando o produto espera a resposta inteira para fazer algo com ela, como um classificador que decide o próximo passo, ou um agente que só pode executar a ferramenta depois de ler a saída completa. Em uma resposta longa, o tempo total cresce com o número de tokens de saída, e é aí que o esforço e o tamanho da resposta pesam mais.

Os dois números podem contar histórias diferentes. Um modelo pode começar a responder rápido e ter uma resposta longa que demora para acabar. Outro pode demorar mais para começar e terminar cedo. Para um chat com streaming, o TTFT costuma mandar. Para um pipeline em lote, o tempo total e a vazão mandam. Para um agente com vários passos, o tempo total de cada passo, somado, define quanto tempo o usuário espera pela tarefa. Por isso a medição deve registrar os dois, e o registro deve dizer qual deles o produto precisa.

A documentação lista caminhos para reduzir latência, e três deles se conectam à escolha de modelo. O primeiro é escolher um modelo mais rápido, e a própria página recomenda o Haiku 5.5 para aplicações com exigências de velocidade. O segundo é encurtar o prompt e a saída, porque menos tokens para processar e para gerar significam resposta mais rápida. O terceiro é usar streaming, que melhora a percepção de velocidade sem mudar o tempo total. Outro caminho que a documentação de cache menciona é o cache de prompt, que pode melhorar o TTFT em prompts longos que se repetem. Não confirmei essa afirmação na página de cache nesta consulta, então trate-a como hipótese a medir. Trate cada um desses caminhos como uma variável a ser medida, e não como promessa.

Como medir, com honestidade. Escreva um script que, para cada caso do conjunto, registre o instante do envio, o instante em que chega o primeiro token de texto, o instante em que chega o último evento e o número de tokens de saída informado pela própria resposta. Rode cada caso várias vezes, em horários diferentes, porque a latência varia com a carga do serviço. Guarde a mediana e o percentil 95, não só a média, porque a média esconde as respostas lentas que o usuário realmente sente. Esta aula não traz números de latência. Eles dependem do seu prompt, do seu tamanho de saída e da sua rede, e nenhum número genérico serviria para decidir. Quando você tiver os seus, eles entram no registro da decisão, com a data e a forma de medição.

10. Custo

Custo é o que você paga pelos tokens que o modelo lê e escreve. A documentação de preços cobra por milhão de tokens, e a fórmula é direta: o custo de uma chamada é a quantidade de tokens de entrada vezes o preço de entrada por milhão, mais a quantidade de tokens de saída vezes o preço de saída por milhão, tudo dividido por um milhão. Essa fórmula é a mesma para os quatro níveis. O que muda é o preço de cada parcela e o tamanho das entradas e das saídas do seu produto.

O preço da tabela é o preço padrão. Existem três descontos ou acréscimos que mudam a conta. O primeiro é o lote (Batch API), com 50% de desconto sobre entrada e saída, para trabalho assíncrono que não precisa responder na hora. O segundo é o cache de prompt: a leitura de um prefixo já armazenado custa uma fração do preço de entrada, que varia por nível, e a escrita do cache custa um pouco mais do que a entrada normal. O terceiro é o caso especial do Haiku 5.5, cujo preço sobe quando o prompt passa de 100 mil tokens, e a documentação diz que o cache e o lote se aplicam sobre esses preços mais altos. Na prática, um mesmo projeto pode ter três custos diferentes conforme o formato da carga.

Para um exemplo concreto, imagine um sistema que processa 10.000 requisições por mês, com 2.000 tokens de entrada e 500 tokens de saída em cada uma. Isso dá 20 milhões de tokens de entrada, ou 20 MTok, e 5 milhões de tokens de saída, ou 5 MTok. Com os preços padrão confirmados em 18 de outubro de 2026, a conta fica assim, para cada nível:

• Haiku 5.5: 20 × US$ 0,10 mais 5 × US$ 0,50, total de US$ 4,50. Como o prompt tem menos de 100 mil tokens, vale o preço base.
• Sonnet 5.5: 20 × US$ 2 mais 5 × US$ 10, total de US$ 90.
• Opus 5.5: 20 × US$ 4 mais 5 × US$ 20, total de US$ 180.
• Fable 5.1: 20 × US$ 10 mais 5 × US$ 50, total de US$ 450.

Essa é uma conta de aritmética sobre preços confirmados, não uma medição. Ela não inclui cache nem lote, e supõe que todas as requisições têm o mesmo tamanho. O que ela mostra é a proporção: nesse volume, o Opus custa quarenta vezes o Haiku, e o Fable, cem vezes. Se o Haiku atingir a qualidade necessária, a diferença é dinheiro que o produto deixa de gastar. Se não atingir, a diferença precisa ser comparada com o custo de errar, que é o assunto da seção 13.

Vale notar que o custo por tarefa é diferente do custo por token. Um modelo mais caro por token pode resolver a tarefa em menos passos, com menos tentativas e menos reenvios, e sair mais barato no fim. Um modelo barato pode precisar de três tentativas para acertar o que o caro acerta de primeira. Por isso o eval deve medir o custo por caso concluído, somando as chamadas que cada caso realmente gastou, e não só o custo de uma chamada isolada.

11. Juntar os três eixos

Com a qualidade, a latência e o custo medidos no mesmo conjunto, o próximo passo é comparar os modelos no mesmo gráfico, com custo no eixo horizontal e qualidade no vertical, ou com latência no lugar do custo. Um modelo que está acima e à esquerda de outro, ou seja, mais barato e com mais qualidade, domina o outro. Um modelo que só é melhor por poucos pontos e custa muito mais precisa justificar a diferença. Essa leitura, de curva em vez de ponto isolado, é a que a documentação de otimização de custo e inteligência recomenda: comparar a curva de pontuação contra gasto de cada configuração, e não um ponto escolhido ao acaso.

Esse raciocínio tem uma consequência importante. Um modelo menor com esforço alto pode ficar à frente de um modelo maior com esforço baixo, e um modelo maior com esforço baixo pode ficar à frente de um menor com esforço alto. A escolha certa depende da curva inteira, e a documentação de cost e intelligence recomenda, antes de montar qualquer combinação de modelos, varrer o esforço no modelo que você já usa. Só depois disso faz sentido considerar um segundo modelo.

Uma tabela simples com uma linha por configuração resume o resultado. Ela deve ter a pontuação por categoria, a mediana e o percentil 95 de latência, o custo por caso concluído e a data da medição. Sem a data, a tabela envelhece sem aviso.

Parte 4: decidir

12. Effort antes de trocar de modelo

O parâmetro de esforço (effort) controla quanto o modelo gasta para responder. A documentação diz que o esforço afeta todos os tokens da resposta, incluindo o texto, as chamadas de ferramenta e o raciocínio quando ele está ativo. Esforço baixo reduz tokens, reduz latência e reduz custo, ao custo de alguma capacidade. Esforço alto faz o contrário. Os níveis, do mais baixo ao mais alto, são low, medium, high, xhigh e max, e nem todo modelo aceita todos eles.

O valor padrão varia por modelo. Segundo a tabela de comparação, o Haiku 5.5 e o Opus 5.5 vêm com esforço medium por padrão, e o Sonnet 5.5 e o Fable 5.1 com high. A documentação de esforço recomenda definir o esforço explicitamente, porque o padrão pode não ser o ponto certo para a sua carga. Para o Haiku 5.5, a página sugere começar em medium e usar low para chat, tarefas curtas com ferramenta e pedidos simples em volume alto, deixando high para trabalho de conhecimento e instruções que precisam ser seguidas com rigor.

Isso muda a ordem da decisão. Antes de trocar de nível, vale varrer o esforço no nível atual e ver a curva. A documentação de escolha de modelo diz exatamente isso: ajuste o esforço, porque muitas vezes é uma alavanca melhor do que trocar de modelo. Se o Sonnet em esforço medium atinge a qualidade exigida, você economiza sem mudar de nível. Se não atinge, a varredura mostra quanto de qualidade falta e se vale a pena subir de nível. O diagrama abaixo mostra essa ordem.

A figura lê de cima para baixo. Você começa pelo menor nível com o prompt já razoável. Se ele passa no limiar, a decisão está pronta e o registro é a última etapa. Se não passa, a primeira pergunta é se o prompt ou o esforço resolvem, e só depois se sobe para o Sonnet. A mesma lógica se repete no degrau seguinte. A seta vermelha no fim mostra o caso em que nem o maior nível compensa: o problema pode estar no tamanho da tarefa, e a saída é dividi-la ou criar um roteamento, não comprar mais capacidade. O diagrama mostra ainda uma regra que muitas equipes esquecem: a cada degrau, mude uma variável por vez, para saber o que causou a diferença.

13. Quando o menor basta e quando o maior se paga

A regra prática que separa os dois casos é comparar o custo de errar com o custo de acertar mais caro. O menor nível basta quando a tarefa tem resposta bem definida, poucos passos, erro barato e volume alto. Classificação de tickets, extração de campos com formato fixo e roteamento de mensagens são exemplos típicos. O maior nível se paga quando a tarefa é longa, tem muitos passos encadeados, o erro se propaga ou o erro custa mais do que a diferença de preço.

A documentação de otimização de custo e inteligência traz uma ideia útil para o meio do caminho: uma combinação de dois modelos, em que um menor faz a maior parte do trabalho e um maior entra só quando precisa. A página descreve dois padrões. No primeiro, o executor é um modelo menor que roda o laço de trabalho e consulta um conselheiro mais capaz quando trava. No segundo, um orquestrador mais capaz divide o trabalho entre vários trabalhadores mais baratos. A própria página avisa que essa combinação só vale se superar a curva do modelo único, e não basta ser combinação.

Os números que a Anthropic publica nessa página são internos e direcionais, e por isso devem ser lidos com cuidado. Em um benchmark interno de programação, um par com Opus 5.5 em esforço alto e Fable 5.1 como conselheiro ficou 1,7 ponto acima do executor sozinho, na borda do ruído entre execuções, a um custo de cerca de 2,1 vezes. Nesse caso, o conselheiro foi consultado em média 1,4 vez por tentativa. Em um benchmark de perguntas científicas, quando o executor quase nunca consultou o conselheiro, o resultado ficou dentro do ruído do executor sozinho e o custo subiu entre 12% e 25% por pergunta. A lição que a página tira é direta: o conselheiro só ajuda se o executor o consultar. Se a consulta não acontece, você paga o conselheiro sem receber nada.

Na prática, esse raciocínio pede três perguntas antes de subir de nível. A primeira é quanto custa um erro que chega ao usuário, em tempo, dinheiro ou confiança. A segunda é a diferença de qualidade medida no seu eval, e não a diferença que a propaganda promete. A terceira é quanto a diferença de custo pesa no volume real. Se o erro é caro e a diferença de qualidade é real, o maior se paga. Se o erro é barato e a diferença é pequena, o menor basta, e o dinheiro economizado pode financiar a revisão humana dos casos que de fato importam.

14. Registrar a decisão

Uma decisão de modelo que não está registrada vira folclore. Daqui a seis meses, alguém pergunta por que o produto usa Sonnet, ninguém lembra, e a resposta vira “porque sempre foi assim”. O registro existe para evitar isso. Ele deve caber em uma página e responder às perguntas que alguém faria ao reabrir a decisão.

O registro deve conter o identificador completo do modelo, como claude-sonnet-5-5, e não um alias. Deve conter o nível de esforço escolhido e o motivo da escolha. Deve trazer a data da medição, o tamanho do conjunto de avaliação, a pontuação por categoria, a mediana e o percentil 95 de latência, e o custo por caso concluído. Deve dizer qual critério foi o limiar, por exemplo “pontuação de no mínimo tanto na categoria de extração de datas”. Deve registrar as alternativas testadas e por que foram descartadas. E deve trazer o gatilho de revisão, que é o evento que obriga a reabrir a decisão.

O gatilho pode ser de três tipos. O primeiro é a chegada de um modelo novo, ou a aposentadoria do modelo atual, com a data mínima que a tabela oficial informa. O segundo é uma mudança no produto, como um novo tipo de pedido, um volume muito maior ou um requisito novo de latência. O terceiro é uma queda medida em produção, como uma pontuação que cai abaixo do limiar em uma categoria. Escrever o gatilho junto com a decisão é o que transforma o registro em ferramenta, e não em arquivo morto.

Guarde o registro no próprio repositório do projeto, junto do conjunto de avaliação e do script de medição. Assim, a próxima medição usa o mesmo conjunto e o mesmo caminho, e a comparação com a decisão antiga é direta.

15. Quando sai um modelo novo

Quando um modelo novo é lançado, a tentação é trocar o identificador no código e torcer. A disciplina que a aula propõe é outra: reabrir a decisão com o mesmo eval. Como o conjunto está congelado e o script está pronto, rodar o modelo novo leva minutos, e a comparação com o registro antigo é direta. Se o novo modelo atinge a qualidade exigida com custo ou latência melhores, a troca se justifica, e o registro ganha uma nova entrada com a data e os números. Se não atinge, a decisão antiga continua valendo e o registro documenta isso.

Há uma armadilha nessa etapa. Um modelo novo pode ser melhor em média e pior em uma categoria específica que o seu produto usa muito. Por isso a comparação deve olhar a tabela por categoria, e não só a média. Outra armadilha é trocar o modelo sem ajustar o esforço e o prompt. A documentação de esforço observa que os níveis do Sonnet 5.5 foram recalibrados em relação ao Sonnet 5, de modo que o mesmo nome de nível produz uma quantidade diferente de raciocínio, e recomenda rodar uma nova varredura de esforço em vez de reaproveitar a configuração anterior. Trate a troca de modelo como uma nova medição completa, não como uma substituição de texto.

Parte 5: prática

16. Erros comuns e boas práticas

O erro mais frequente é escolher o modelo pelo nome, pela reputação ou pela demonstração, sem medir. O motivo é que demonstrações mostram os casos bons, e reputação mede a média do mundo, não a do seu produto. A correção é montar o conjunto antes de qualquer comparação.

O segundo erro é montar um conjunto só com casos fáceis, ou só com os casos que a equipe lembra. O motivo é que o eval passa a medir a sensação da equipe, e não o comportamento do produto. A correção é incluir as bordas e a distribuição real do tráfego, e congelar o conjunto antes de rodar os modelos.

O terceiro erro é comparar modelos com prompts ou esforços diferentes e atribuir a diferença ao modelo. O motivo é que a diferença medida mistura três variáveis. A correção é mudar uma variável por vez e manter o resto igual.

O quarto erro é declarar vencedor com uma diferença menor que o ruído da medição. O motivo é que pontuações de conjuntos pequenos oscilam, e uma diferença de poucos pontos pode sumir na execução seguinte. A correção é repetir a execução e usar comparação pareada nos mesmos casos.

O quinto erro é usar a média de latência e esquecer a cauda. O motivo é que a média esconde as respostas lentas, que são justamente as que o usuário percebe. A correção é registrar a mediana e o percentil 95.

O sexto erro é usar alias no código de produção. O motivo é que o alias pode mudar de destino, e a decisão medida deixa de valer sem que ninguém perceba. A correção é fixar o identificador completo e tratar a troca como decisão registrada.

O sétimo erro é ignorar o preço de entrada de documentos longos no Haiku 5.5, que sobe acima de 100 mil tokens de prompt. O motivo é que o preço base é o que aparece em destaque, e a conta muda de forma silenciosa em cargas com contexto grande. A correção é calcular o custo com o tamanho real das entradas, e não com a média imaginada.

O oitavo erro é tratar o custo por token como o custo da tarefa. A correção é medir o custo por caso concluído, somando todas as chamadas que a tarefa precisou.

17. Exercícios

Primeiro exercício: pegue um produto que você conhece e escreva, em uma página, qual é o erro mais caro que ele pode cometer e qual é o erro mais barato. Com essas duas frases, diga se a escolha deve ser guiada por qualidade, por latência ou por custo, e por quê. Não precisa rodar nada ainda.

Segundo exercício: monte um conjunto de trinta casos para uma tarefa de classificação ou extração, com pelo menos cinco bordas, e escreva o critério de correção de cada caso. Congele o arquivo, anote a data e escreva em uma frase por que os casos foram escolhidos.

Terceiro exercício: calcule a conta de custo mensal do seu produto para os quatro níveis, com o volume, o tamanho médio de entrada e de saída que você estima. Depois refaça a conta para o caso em que as entradas passam de 100 mil tokens no Haiku 5.5 e veja o efeito. Confira os preços na página de preços antes de fechar a conta.

Quarto exercício, mais exigente: rode o seu conjunto de trinta casos em dois modelos com o mesmo prompt e o mesmo esforço. Calcule a pontuação de cada um por categoria e a diferença entre eles. Depois repita a execução e veja se a diferença se mantém. Se a diferença mudar de sinal, você acabou de medir o ruído, e isso é o resultado mais útil da semana.

Quinto exercício: escreva o registro de decisão de um produto hipotético, com todos os campos da seção 14, incluindo o gatilho de revisão. Troque o gatilho por outro e veja se a decisão muda.

18. Glossário

Eval: conjunto fixo de casos com critério de correção, usado para comparar sistemas de forma repetível.

Conjunto de avaliação: o mesmo que eval, quando o foco é a lista de casos em si.

Graduador: o mecanismo que dá nota a uma resposta. Pode ser uma checagem automática, um modelo como juiz ou uma pessoa.

TTFT: tempo até o primeiro token, o intervalo entre o envio do prompt e a chegada do primeiro token da resposta.

Tempo total: intervalo entre o envio do prompt e a chegada do último token da resposta.

p50 e p95: a mediana e o percentil 95 de uma distribuição de tempos. O p95 mostra a cauda lenta, que a média esconde.

Streaming: envio da resposta em partes, à medida que o modelo gera, para que a aplicação comece a mostrá-la antes do fim.

Token: unidade de texto que o modelo lê e escreve. A cobrança é feita por milhão de tokens, abreviado como MTok.

Esforço (effort): parâmetro que controla quanto o modelo gasta para responder, com níveis de low a max.

Snapshot: versão fixa de um modelo, que não muda com o tempo. Os identificadores sem data da geração 4.6 em diante são snapshots.

Alias: nome que aponta para um snapshot e pode mudar de destino ao longo do tempo. Para modelos anteriores à geração 4.6, a documentação descreve aliases desse tipo.

Batch (lote): modo assíncrono da API, com desconto de 50% sobre entrada e saída, para trabalho que não precisa de resposta imediata.

Cache de prompt: armazenamento de um prefixo do prompt para reuso. A leitura do cache custa uma fração do preço de entrada.

Conselheiro (advisor): modelo mais capaz consultado por um modelo menor que executa o laço de trabalho.

Navegação

Fontes

Consultadas em 18 de outubro de 2026, em platform.claude.com. Li as páginas pela ferramenta de leitura, e algumas são longas, por isso li as partes que tratam diretamente do assunto e não a página inteira.

• Claude: Models overview: descrição de cada nível, velocidade relativa, identificadores de API, janela de contexto de 1 milhão de tokens, limite de saída de 128 mil tokens, esforço padrão e datas mínimas de aposentadoria. Usei também a lista de modelos legados.
• Claude: Pricing: preços base por milhão de tokens, preços de escrita e leitura de cache, desconto de lote de 50% e a regra de preço do Haiku 5.5 acima de 100 mil tokens de prompt.
• Claude: Choosing the right model: critérios de escolha, a tabela de seleção por necessidade, a recomendação de começar pelo menor ou pelo maior, e a orientação de medir antes de subir de nível.
• Claude: Define success criteria and build evaluations: critérios mensuráveis, distribuição de tarefas, bordas, correção automática, uso de outro modelo como juiz e preferência por volume. A página não traz um número mínimo de casos, e a faixa de 30 a 100 casos é minha.
• Claude: Effort: níveis de esforço, valores padrão por modelo, efeito sobre todos os tokens e recomendações por modelo, incluindo o Haiku 5.5.
• Claude: Model IDs and versioning: identificadores sem data como snapshots fixos a partir da geração 4.6, diferença para aliases de modelos anteriores e a observação sobre a infraestrutura em volta do modelo.
• Claude: Reducing latency: definições de latência de base e de TTFT, caminhos para reduzir latência e a recomendação de escolher um modelo mais rápido para cenários sensíveis a tempo. A página foi encontrada por busca e lida no endereço indicado.
• Claude: Optimizing for cost and intelligence: padrões de executor com conselheiro e de orquestrador com trabalhadores, a orientação de varrer o esforço antes de combinar modelos, e os números internos citados na seção 13, que são direcionais e não foram verificados de forma independente.
• Nota interna Avaliação de RAG do vault: juiz, ruído estatístico e comparação pareada, usada como referência de método. Não é fonte oficial da Anthropic.

Não medi latência nem qualidade de nenhum modelo para esta aula. Não há chave de API configurada no ambiente em que a nota foi escrita, e não rodei nenhuma chamada. Todos os números de preço e de limite vêm das páginas listadas. O exemplo de custo da seção 10 é aritmética sobre esses preços, com volume hipotético. Os números de latência da seção 9 não aparecem porque não foram medidos.

Relacionados

• LLMs
• Avaliação de RAG
• Prompt e contexto