Claude 5.5: Pare de pagar por tarefas malsucedidas

A configuração de Sonnet e Opus que realmente importa: effort, cache, verificação e custo por tarefa concluída

O modelo mais barato não é aquele com o menor preço por token

É aquele que entrega o trabalho, passa na validação e não te obriga a pagar pelo mesmo contexto mais cinco vezes

O Sonnet 5.5 e o Opus 5.5 tornam essa distinção especialmente importante. Um tem preço pensado para volume. O outro, para trabalhos mais pesados. Ambos trazem um novo comportamento de effort e podem sair surpreendentemente baratos dentro de um loop de agente bem otimizado com cache

Copie sua configuração antiga para qualquer um dos modelos e o resultado pode ser mais lento, mais caro ou um erro 400

Esta é a configuração que eu montaria no lugar

1TAREFA → SONNET 5.5 → VERIFICAÇÃO → OPUS 5.5 SE NECESSÁRIO → RESULTADO VALIDADO
2             ↘ effort ↗         ↘ cache + registro de uso ↗

Eu publico análises práticas sobre agentes de IA, fluxos de trabalho e sistemas em produção no Substack

Assine a newsletter aqui

O número que deve definir a sua stack

A maioria das comparações entre modelos começa com dólares por milhão de tokens

Seu agente não entrega tokens. Ele entrega tarefas concluídas

https://x.com/claudeai/status/2102435511222890900

Repetindo: são os testes deles. A sua arquitetura precisa dos seus próprios números

Isso significa que a verificação não pode ser um "joinha" genérico depois de ler uma resposta impressionante. Para código, use o teste que bloquearia o merge. Para extração, compare os campos obrigatórios com um conjunto rotulado. Para pesquisa, registre se a fonte citada realmente sustenta cada afirmação. Inclua o custo das tarefas que nunca passam, e não apenas os exemplos bonitinhos da sua demonstração

E analise a cauda difícil separadamente. Se a configuração mais barata resolve 90% das suas requisições, mas torra metade do orçamento nos 10% restantes, a média pode esconder justamente a parte do fluxo que exige outro modelo

O que a tabela de preços do 5.5 realmente diz

Em 3 de outubro de 2026, nas tarifas padrão da API do Claude, por milhão de tokens:

1SONNET 5.5
2Input novo   $2       Output  $10
3Leitura de cache   $0.20    Escrita de cache  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Input novo   $4       Output  $20
7Leitura de cache   $0.20    Escrita de cache  $5 / 5m, $8 / 1h

Ambos os modelos têm uma janela de contexto de 1M de tokens e um output máximo de 128K tokens. Esses são limites máximos, não um convite para preenchê-los.

Especificações e preços dos modelos

A linha estranha é a leitura de cache

O Opus custa o dobro no input e output novos, mas um prefixo em cache custa os mesmos $0.20 por milhão em ambos os modelos. Isso não torna uma execução no Opus igualmente barata: ele ainda paga mais por inputs novos, outputs e escritas de cache. Mas significa que a diferença de preço entre os modelos pode encolher em sessões com muitas leituras

Há uma segunda distinção que passa despercebida. Os "40% menos que o Opus 5" divulgados pela Anthropic são uma estimativa do \custo típico de execução\. Os preços de tokens novos do Opus 5.5 caíram 20%; o preço de leitura de cache caiu 60%. Esses números estão relacionados, mas não são intercambiáveis

Effort é uma decisão de roteamento, não um controle deslizante de qualidade

O Sonnet 5.5 suporta low, medium, high, xhigh e max. Na API, o padrão é high; nos aplicativos do Claude, a Anthropic diz que o padrão é medium. O Opus 5.5 usa medium como padrão na API. Esses níveis não foram calibrados para significar exatamente o que as mesmas palavras significavam nos modelos anteriores.

Meu mapa inicial:

• Sonnet low Para requisições estreitas e sensíveis à latência, com uma verificação barata
• Sonnet medium Para codificação bem especificada e trabalhos rotineiros de múltiplas etapas
• Sonnet high Quando a execução em medium falha em uma verificação real, ou a tarefa apresenta um padrão comprovado de complexidade
• Opus medium Para trabalhos ambíguos, que cruzam vários arquivos e de longo prazo, onde o Sonnet fica dando voltas no problema
• Xhigh/max Somente depois que suas avaliações mostrarem um ganho que justifique o tempo e os tokens extras

Esta é uma hipótese de partida, não uma hierarquia universal. Nos resultados do FrontierCode divulgados pela Anthropic para o Sonnet 5.5, xhigh pontuou acima de max. Mais esforço não é garantia de um resultado melhor

A nota de rodapé da Anthropic explica o resultado contraintuitivo: em max, o modelo iniciava revisões de código adicionais com mais frequência. Em dois casos analisados, isso gerou timeout ou edições fora do escopo da tarefa.

O modo de falha não foi "o modelo não pensou o suficiente". Foi gastar esforço no lugar errado. Se o seu agente já passa nas verificações, rodadas extras de revisão podem virar um custo e uma fonte de novos erros

https://x.com/edwinarbus/status/2104675431853248816

Além disso, não defina max_tokens baixo e chame isso de otimização. O limite cobre o raciocínio interno e o output visível. Se você cortá-lo no meio da tarefa, pode acabar comprando uma resposta truncada e uma segunda execução, em vez de economizar dinheiro

https://x.com/claudeai/status/2104633115620823187

É uma promessa de lançamento convincente. Mas uma configuração de produção ainda precisa superar a sua própria linha de base

Faça um pequeno varredura antes de inventar um roteador de modelos

Pegue de 10 a 30 tarefas com as quais você realmente se importa. Inclua trabalhos fáceis, ambíguos e aquelas falhas irritantes dos seus logs. Dê a cada tarefa um verificador: testes, uma comparação estruturada, uma resposta conhecida ou uma rubrica humana definida antes da execução

Aqui está a sondagem de API mais simples e útil. Ela registra os campos de uso que você precisa. Rode-a em cada modelo e nível de effort contra a mesma tarefa e, em seguida, aplique sua própria verificação de aprovação/reprovação. Não é um benchmark completo de agente

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # repita com claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # repita com high
8    messages=[{"role": "user", "content": "Substitua isto por uma tarefa real."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("novo", usage.input_tokens, "output", usage.output_tokens)
15print("leitura de cache", usage.cache_read_input_tokens)
16print("escrita de cache", usage.cache_creation_input_tokens)

Isso pressupõe o pacote Python oficial da Anthropic e uma variável de ambiente ANTHROPIC_API_KEY. É uma chamada isolada sem cache ativado, então espera-se zero leituras e escritas de cache. A próxima seção mostra o que muda isso

Para um agente real, some o uso de todas as chamadas de API sob um único ID de tarefa, incluindo retentativas e chamadas de ferramentas. Conte uma aprovação apenas quando o verificador disser que o trabalho foi concluído

Compare o total em dólares por aprovação antes de escolher seu padrão

Mantenha o teste honesto:

• Congele o conjunto de tarefas e o verificador antes de comparar configurações
• Use as mesmas ferramentas, permissões, contexto e requisitos de output em todos os candidatos
• Registre taxa de aprovação, gasto total, custo por aprovação, latência e as falhas mais longas ou caras
• Considere stop_reason: "max_tokens" como uma tentativa incompleta, não como um sucesso barato

O trecho de código acima usa um limite de output de 8K para uma sondagem de turno único. Não copie esse limite para um agente de codificação longo.

A Anthropic recomenda muito mais margem para trabalhos agentivos, porque o raciocínio oculto conta para o mesmo limite.

Defina o limite adequado para o trabalho e controle os gastos com effort, cache e um orçamento por tarefa, em vez de forçar a resposta a parar no meio do caminho

Coloque em cache a parte estável do trabalho

Agentes enviam repetidamente as mesmas instruções de sistema, definições de ferramentas, mapeamento de repositório e conversas anteriores. Se esse prefixo for estável, o prompt caching muda a economia muito mais do que uma pequena reescrita de prompt

Por exemplo, 200K tokens em cache lidos 50 vezes resultam em 10M de tokens de leitura de cache. A $0.20 por milhão, essas leituras custam $2 em qualquer modelo 5.5.

No Opus 5.5, enviar esses mesmos 10M de tokens como input novo custaria $40. A primeira escrita de cache de cinco minutos para 200K tokens é mais $1.

Esta é uma ilustração apenas das cobranças de prefixo: inputs novos, outputs, outras escritas, expiração de TTL e falhas reais de cache aumentam a conta

As regras práticas:

• Na API do Claude, ative o prompt caching com cache_control={"type": "ephemeral"} no nível superior ou com pontos de interrupção de cache explícitos. A sondagem acima não faz nenhum dos dois, então seus contadores de cache normalmente ficarão em zero
• Coloque instruções e ferramentas estáveis antes da requisição mutável do usuário
• Mantenha o prefixo compartilhado idêntico entre os turnos; verifique os cache_read_input_tokens reais
• Trate a troca de modelo como um novo orçamento de conversa, não como uma continuação gratuita. O cache é por modelo: uma requisição do Opus não consegue ler o prefixo que o Sonnet acabou de armazenar
• Evite mudar o effort de nível superior a cada turno; isso altera o prompt renderizado e invalida os prefixos em cache

Nos modelos compatíveis, uma mudança de effort por mensagem pode preservar o cache anterior, mas exige o header beta da Anthropic e não é o mesmo que alterar o output_config de nível superior.

O Sonnet 5.5 também tem uma ressalva para between_tools: o effort não pode mudar no meio da conversa nesse modo.

Documentação de prompt caching

Não deduza um acerto de cache por uma resposta rápida. Leia o objeto usage. Ele separa input novo, criação de cache e leituras de cache

Ambos os modelos 5.5 precisam de pelo menos 512 tokens em um prefixo armazenável em cache. Um system prompt minúsculo não vai gerar a economia do exemplo acima. O tempo de vida padrão do cache é de cinco minutos, o que se encaixa bem em um loop rápido de ferramentas.

Uma escrita de uma hora custa mais e só faz sentido quando sessões reais costumam pausar por tempo suficiente para perder a janela de cinco minutos. Meça essas pausas antes de pagar por um TTL maior

Escale após evidências, não por ansiedade

A maioria das equipes constrói o roteador de trás para frente: classifica uma tarefa como "difícil", manda para o modelo caro e nunca descobre se o caminho mais barato teria passado

Use o verificador como sinal de roteamento

11  Sonnet 5.5 · effort escolhido  → execute a tarefa
22  Verificador                    → aceite se passar
33  Opus 5.5 · medium              → tente novamente apenas com evidência de falha
44  Verificador                    → aceite ou encaminhe com evidências

A verificação pode ser uma suíte de testes, validação de schema, uma resposta conhecida ou um revisor. Ela deve explicar o que falhou.

"A resposta parece fraca" é um péssimo sinal de escalonamento; "o endpoint alterado falha em dois testes de integração" é útil

Não repita cegamente um prompt idêntico. Dê à próxima tentativa a verificação que falhou, os artefatos relevantes e uma instrução específica para corrigir a lacuna. Limite os degraus dessa escada para que o agente não torre o orçamento tentando consertar uma tarefa que exige decisão humana

Você pode testar uma retentativa com Sonnet high na sua varredura offline. Mantenha-a na rota em produção apenas se reduzir o custo por tarefa validada. Não há motivo para fazer cada falha pagar por duas execuções do Sonnet antes de ir ao Opus

A própria troca de modelo pode quebrar um prefixo em cache. Leve isso em conta ao comparar o caminho de resgate com uma rota que começa direto no Opus

O ponto de cruzamento é fácil de ignorar. Suponha que uma tentativa no Sonnet custe $0.06 e passe em 80% das suas tarefas.

Se cada tarefa que falhar custar $0.20 para ser concluída no Opus, sua média ilustrativa será de $0.10 por tarefa concluída: $0.06 mais um resgate de $0.20 em uma a cada cinco tarefas. Isso é melhor do que pagar $0.20 pelo Opus em todas as tarefas. Mas se o Sonnet custar $0.14 e passar apenas na metade, a mesma escada sai por $0.24, antes mesmo de precificar a troca de modelo. Nesse cenário, começar pelo Opus é mais barato e rápido

Esses valores são exemplos, não resultados medidos do Claude. O objetivo é tornar a regra de roteamento falseável. A escada só se justifica se as chamadas economizadas no Opus superarem as tentativas falhas no Sonnet, as falhas de cache e a latência adicional

Existe também um caminho intermediário: a ferramenta beta advisor da Anthropic. O Sonnet pode continuar executando a tarefa e pedir ajuda ao Opus em uma decisão difícil, em vez de entregar todo o trabalho para o Opus.

Isso não é automaticamente mais barato. Registre com que frequência o Sonnet realmente consulta o advisor, quanto essas chamadas custam e se elas melhoram a taxa de aprovação final. Se o executor raramente perguntar, o advisor será apenas um recurso inutilizado.

Com esses modelos 5.5, o próprio conselho é retornado criptografado para o cliente, então avalie o trabalho resultante em vez de fingir que você pode auditar o texto privado do conselho

Quatro vazamentos que inflacionam a conta antes mesmo da escolha do modelo importar

Nem todo problema de custo exige um novo roteador

Verifique isto primeiro:

• Output que não para de crescer Em ambos os modelos 5.5, os tokens de output custam cinco vezes mais que os tokens de input novos. Em uma conversa, uma resposta longa também pode voltar como contexto nos turnos seguintes. Peça o artefato e uma breve nota de conclusão, não uma narração transcrita de cada etapa. O raciocínio oculto também é cobrado como output, então uma resposta final curta sozinha não resolverá um problema de effort. Não suprima as evidências necessárias para validar o resultado
• Imagens maiores do que a tarefa exige O Sonnet 5.5 processa imagens de resolução mais alta que versões anteriores do Sonnet, o que pode aumentar a contagem de tokens de imagem. Se o agente só precisa do rótulo de um botão ou de um parágrafo, recorte ou redimensione antes. Se precisar de um gráfico denso ou detalhes minúsculos de UI, mantenha a resolução e meça o custo em vez de reduzi-la cegamente
• Contexto que ninguém usa Definições de ferramentas, logs desatualizados, resultados de busca antigos e um CLAUDE.md gigante podem acompanhar cada requisição. Coloque regras duradouras em um prefixo curto e estável; mantenha evidências temporárias perto da tarefa que precisa delas. Reduzir o contexto não deve apagar fatos que o modelo ainda precisa para concluir o trabalho corretamente
• Preço interativo para trabalhos que ninguém está esperando A Message Batches API oferece 50% de desconto em input e output em ambos os modelos. É útil para avaliações offline, backfills de documentos e outros jobs assíncronos. Não substitui um loop de ferramentas em tempo real onde alguém precisa do próximo passo agora

O padrão é o mesmo nos quatro casos: elimine o trabalho desnecessário para a tarefa antes de comprar mais inteligência ou reduzir o effort até a qualidade quebrar

As armadilhas de migração que transformam economia em erro 400

Corpos de requisição antigos são um péssimo ponto de partida para a família 5.5.

Em particular:

• O thinking do Opus 5.5 está sempre ativo Remova thinking: {"type": "disabled"} e configurações antigas fixas de budget_tokens; controle a profundidade com output_config.effort
• A escolha forçada de ferramenta falha em ambos os modelos 5.5

Os valores any e tool em tool_choice retornam 400. Use auto, especifique quando a ferramenta deve ser usada e valide o resultado dela no seu próprio código

• Blocos de thinking não são blocos de texto Leia o conteúdo por type, não por content[0]. Em loops de ferramentas, retorne os blocos de thinking inalterados junto com o turno do assistente
• Sua interface pode parecer travada No Opus 5.5, o progresso entre ferramentas pode chegar em blocos de thinking que ficam vazios na configuração de exibição padrão. Se você costumava renderizar essas notas para os usuários, solicite um modo de exibição de thinking suportado e renderize os blocos por tipo. Caso contrário, o agente pode estar trabalhando enquanto a interface parece congelada
• Versões antigas da ferramenta computer-use podem falhar Verifique a versão atual da ferramenta antes de migrar um agente de navegador/computador
• Um limite max_tokens menor pode interromper o trabalho

O thinking é contabilizado mesmo quando o texto está oculto

Estas são mudanças de comportamento da API, não truques de escrita de prompt.

Guia de migração do Opus e guia de migração do Sonnet

Coloque o contrato no Claude Code, não na sua cabeça

A API é onde você pode medir cada campo de uso. O Claude Code é onde muita gente vai sentir a mudança de modelo pela primeira vez. O mesmo princípio se aplica: dê ao agente uma definição limitada de "pronto" e faça-o mostrar as evidências

No Claude Code, /model seleciona o modelo e /effort seleciona o nível de effort suportado. Verifique as configurações ativas antes de comparar sessões. O padrão da API do Sonnet não descreve de forma confiável o que o seu aplicativo Claude ou sessão do Claude Code está usando no momento

Este é um bloco inicial completo e reutilizável de CLAUDE.md. Altere os comandos para adequá-los ao seu projeto

1# Contrato de trabalho
2
3Faça apenas a alteração solicitada. Preserve trabalhos não relacionados.
4Execute os testes relevantes após editar. Relate qualquer verificação que não puder executar.
5Pare quando o trabalho solicitado passar. Não adicione recursos extras ou loops de revisão.
6Termine com: Alterado / Verificado / Risco restante.
7Pergunte antes de ações destrutivas, publicações ou alterações fora deste repositório.

Esse bloco não vai magicamente tornar toda execução barata. Ele torna o sucesso e a falha visíveis. A partir daí, você pode comparar um fluxo começando pelo Sonnet com um começando pelo Opus nas mesmas tarefas

A mensagem da tarefa ainda precisa ser específica. Aqui está a diferença entre "corrija o código de pagamentos" e um trabalho que um agente consegue realmente terminar

1Alteração: migrar o endpoint de pagamento para o novo cliente
2Pronto: cliente antigo removido, testes do endpoint passando, diff limitado a este caminho
3Parar: perguntar antes de excluir dados ou alterar qualquer coisa fora do repositório
4Relatar: arquivos alterados, verificações exatas executadas, risco restante

Esse pequeno contrato dá ao verificador algo concreto para inspecionar. Também dá ao modelo um motivo para parar. Uma instrução aberta para "revisar até ficar perfeito" pode transformar uma alteração aprovada em mais um loop pago

Para projetos longos, mantenha o checklist em um arquivo que sobreviva à compactação. Para subagentes, peça ao agente principal que inspecione as evidências antes de aceitar os relatórios. E se você pediu apenas ideias, diga ao Claude para não começar a construir. Esses são limites de fluxo de trabalho, não prompts de "seja mais inteligente"

A configuração que eu colocaria em produção primeiro

• Escolha de 10 a 30 tarefas reais e defina uma verificação para cada uma
• Faça uma varredura com o Sonnet 5.5 em medium e high, depois com o Opus 5.5 em medium
• Registre input novo, output, escritas de cache, leituras de cache, latência, retentativas e aprovação/reprovação por tarefa
• Mantenha o prefixo estável armazenável em cache e confirme os acertos no usage
• Encaminhe apenas as falhas para cima, com as respectivas evidências anexadas
• Revise a escada quando o volume de trabalho mudar. Um benchmark salvo não é uma verdade permanente

Se os 10% difíceis forem repetidamente direto da falha no Sonnet para o sucesso no Opus, considere rotear essa classe reconhecível de tarefas para o Opus desde o início. Se o Sonnet high passar nesses mesmos casos por menos, mantenha-os lá. Um roteador é uma política medida, não uma opinião permanente sobre qual modelo é mais inteligente

A atualização para o 5.5 não é apenas "use o Sonnet para trabalho barato e o Opus para trabalho difícil"

É uma chance de parar de precificar o modelo e começar a precificar o trabalho concluído

Se você leu até aqui

-> Assine meu Substack

-> Entre no meu Telegram

-> Salve este artigo nos favoritos

-> Siga @0xwhrrari