Sonnet ou Opus: quando escolher o Claude Sonnet 5.5

Sonnet ou Opus: o que muda na família Claude 5.5

A família Claude 5.5 começou com o Opus 5.5 e recebeu o Sonnet 5.5 como segundo integrante. Segundo o guia oficial de desenvolvimento com o Claude Sonnet 5.5, o novo Sonnet é mais inteligente, mais eficiente e 30% mais veloz que o Sonnet 5.

Além disso, o preço por token continua igual ao da geração anterior. Como o modelo usa bem menos tokens para resolver a mesma tarefa, a conta final cai até 30% na maior parte dos cenários.

Na prática, a comparação entre Sonnet e Opus não segue a lógica simples de "bom contra melhor". O que define a escolha é o formato da tarefa, e não apenas a dificuldade dela.

O Opus 5.5 nasceu para trabalho complexo que exige julgamento cuidadoso ao longo de muitas etapas. Por outro lado, o Sonnet 5.5 brilha em tarefas bem delimitadas, com especificação clara e uma forma objetiva de conferir o resultado.

Vale lembrar também que o Claude Haiku 5.5 deve chegar nas próximas semanas. Ele vai ocupar o espaço de fluxos de alto volume e baixa latência, deixando a disputa entre Sonnet ou Opus concentrada no trabalho do dia a dia.

Quando escolher o Sonnet ao invés do Opus

A regra mais útil do guia oficial cabe em uma frase: o Sonnet se encaixa melhor quando a tarefa tem uma especificação clara e um jeito de verificar o resultado. Se essas duas condições existem, o Sonnet tende a entregar o mesmo nível do Opus gastando menos.

A Anthropic organiza essa decisão em uma tabela simples por tipo de carga de trabalho.

Com isso, quatro das seis linhas apontam para o Sonnet. Em outras palavras, o Sonnet virou o ponto de partida padrão, e o Opus passou a ser a escalada consciente.

Quando o Opus vale mais que o Sonnet

O próprio guia de prompts da Anthropic é direto: para o trabalho de horizonte longo mais difícil, um modelo Opus continua sendo a melhor escolha. Isso inclui agentes de código que trabalham sozinhos por horas e tarefas de conhecimento sem resposta óbvia.

Na prática, vale escalar do Sonnet para o Opus quando a ambiguidade persiste mesmo depois de esclarecer o pedido. O mesmo vale quando a tarefa atravessa muitas etapas dependentes entre si ou quando o custo de um erro é alto.

Comparativos independentes, como o da Codersera, também apontam uma diferença de conhecimento bruto. Segundo esse levantamento, o Opus acerta mais perguntas factuais, enquanto o Sonnet admite com mais frequência quando não sabe a resposta.

Outro sinal claro aparece quando o Sonnet falha repetidamente nos seus testes de aceite. Nessa situação, insistir no modelo mais barato costuma sair mais caro do que trocar de uma vez pelo Opus.

Preço do Sonnet e do Opus por milhão de tokens

A diferença de preço entre Sonnet e Opus é exatamente de duas vezes em entrada, saída e escrita de cache. A leitura de cache, por outro lado, custa o mesmo nos dois modelos.

Todos os preços do Sonnet 5.5, incluindo processamento em lote e cache de prompt, repetem os valores do Sonnet 5. Portanto, trocar apenas o ID do modelo não altera a sua fatura por token.

Já a inferência restrita aos Estados Unidos, ativada com inference_geo: "us", custa 1,1 vez o preço padrão. Se você precisa dessa garantia de residência, inclua esse acréscimo no cálculo.

Fique atento também às imagens. O Sonnet 5.5 usa a camada de alta resolução, com até 2576 pixels no lado maior, e uma imagem de 2000 por 1500 consome cerca de 2,5 vezes mais tokens do que no Sonnet 4.6.

Por isso, reduza a resolução antes de enviar quando o detalhe não for necessário. Esse cuidado simples evita surpresas na conta, seja no Sonnet ou no Opus.

Se você ainda está decidindo qual assinatura faz sentido para o seu uso pessoal, vale ler também o comparativo dos planos do Claude em 2026.

Ajustando o esforço do Sonnet 5.5

O Sonnet 5.5 pensa por padrão, usando raciocínio adaptativo. O parâmetro effort controla o quanto ele pensa e aceita os níveis low, medium, high, xhigh e max.

A primeira chamada já mostra uma mudança importante. Como a resposta pode começar com um bloco thinking, você precisa ler o conteúdo pelo tipo do bloco, e não pela posição.

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=4096,
    messages=[
        {
            "role": "user",
            "content": "Analyze the trade-offs between microservices and monolithic architectures",
        }
    ],
    output_config={"effort": "medium"},
)

# Lê os blocos pelo tipo, porque a resposta pode começar com um bloco de thinking
for block in response.content:
    if block.type == "text":
        print(block.text)

Código que lê content[0].text diretamente quebra com o Sonnet 5.5. Então, revise esse ponto antes de qualquer outra otimização.

# Antes: Claude Sonnet 5
client.messages.create(
    model="claude-sonnet-5",
    max_tokens=16000,
    thinking={"type": "disabled"},
    output_config={"effort": "xhigh"},
    messages=[{"role": "user", "content": "..."}],
)

# Depois: Claude Sonnet 5.5
client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=16000,
    thinking={"type": "between_tools"},
    output_config={"effort": "high"},
    messages=[{"role": "user", "content": "..."}],
)

Como combinar Sonnet e Opus no mesmo fluxo

A melhor resposta para o dilema entre Sonnet ou Opus muitas vezes é usar os dois. O padrão mais comum coloca o Opus no planejamento e o Sonnet na execução.

O Claude Code já oferece esse comportamento com o alias opusplan. Nele, o Opus cuida do modo de planejamento e das decisões de arquitetura, e depois o Claude Code troca para o Sonnet na geração de código.

Desde a versão 2.1.284, o alias sonnet aponta para o Sonnet 5.5 na API. O modelo padrão continua sendo o Opus 5.5, então você troca com /model sonnet quando a tarefa estiver bem delimitada.

Se você usa o Claude Code no dia a dia, entenda também por que o Opus 5.5 custa menos em sessões longas. O artigo mostra como proteger o cache, o que vale igualmente para o Sonnet.

Na sua própria aplicação, você pode criar um roteador simples. A ideia é classificar a tarefa e escolher o modelo com base em critérios objetivos.

from dataclasses import dataclass

SONNET = "claude-sonnet-5-5"
OPUS = "claude-opus-5-5"


@dataclass
class TaskProfile:
    has_clear_spec: bool
    has_automated_check: bool
    dependent_steps: int
    failed_attempts: int
    high_error_cost: bool


def choose_model(task: TaskProfile) -> tuple[str, str]:
    # Escala para o Opus quando o problema é longo, arriscado ou já falhou no Sonnet
    if task.failed_attempts >= 2 or task.high_error_cost:
        return OPUS, "high"

    if task.dependent_steps > 10:
        return OPUS, "medium"

    # Especificação clara e verificação automática: território do Sonnet
    if task.has_clear_spec and task.has_automated_check:
        return SONNET, "medium"

    return SONNET, "high"

Esse roteador segue a mesma lógica do guia oficial. Primeiro o Sonnet, e depois a escalada para o Opus quando os sinais de complexidade aparecem.

Repare também na regra de tentativas. Se o Sonnet falhou duas vezes no mesmo teste, a troca pelo Opus geralmente economiza tempo e tokens.

Cuidados ao migrar do Sonnet 5

Trocar o ID do modelo é só o primeiro passo. O Sonnet 5.5 traz cinco mudanças incompatíveis e uma alteração no formato da resposta.

• Forçar tool_choice do tipo any ou tool retorna erro 400, então use auto com a ferramenta marcada como strict: true.
• Os blocos de thinking ficam presos ao modelo e à conversa, por isso mantenha o histórico apenas com acréscimos.
• Computer use agora acontece pelo computer_toolset_20260801 na API do Claude e no Google Cloud.
• Com a ferramenta advisor, o executor Sonnet 5.5 rejeita Opus 4.8, Opus 4.7 e Sonnet 5 como advisors.
• As notas entre chamadas de ferramenta passam a vir em blocos thinking, que ficam vazios no display padrão.

Veja como fica a ferramenta estrita com tool_choice automático.

weather_tool = {
    "name": "get_weather",
    "description": "Get the current weather in a given location",
    "input_schema": {
        "type": "object",
        "properties": {"location": {"type": "string"}},
        "required": ["location"],
        "additionalProperties": False,
    },
    "strict": True,
}

client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    tools=[weather_tool],
    tool_choice={"type": "auto"},  # antes: {"type": "tool", "name": "get_weather"}
    messages=[
        {"role": "user", "content": "What's the weather in Paris? Use the get_weather tool."}
    ],
)

Antes de qualquer ajuste fino, remova os contornos que você criou para o Sonnet 5. Instruções contra preguiça, retentativas manuais de ferramenta e direcionamento de recusas tendem a atrapalhar o novo modelo.

Por fim, o Claude Code pode fazer a migração sozinho. Basta rodar /claude-api migrate this project to claude-sonnet-5-5 para aplicar a troca de ID e as mudanças de parâmetros em todo o projeto.

Verificações em esforço baixo e cache

Em geral, o Sonnet 5.5 confere o próprio trabalho antes de declarar uma alteração como concluída. No entanto, em esforço low, ele às vezes pula a verificação que realmente exercita a mudança.

Se você notar alterações marcadas como prontas sem saída de testes ou de build, adicione um parágrafo no prompt de sistema. Ele deve exigir a execução dos testes, do type checker ou do build antes de qualquer conclusão.

Quanto ao cache, o tamanho mínimo de prompt cacheável caiu para 512 tokens. Assim, prompts de sistema menores e definições de ferramentas curtas já se beneficiam do cache, que custa um décimo do preço de entrada.

Contudo, mudar o esforço global entre requisições invalida o cache. Para rodar um único turno em outro nível, use o esforço por mensagem, que ainda está em beta e preserva o cache.

Recusas e fallback entre modelos

O Sonnet 5.5 é o primeiro Sonnet com salvaguardas de cibersegurança parecidas com as dos modelos mais capazes da Anthropic. Mesmo assim, a maior parte do desenvolvimento rotineiro não sente diferença.

Quando o modelo recusa um pedido, a API devolve HTTP 200 com stop_reason: "refusal". O campo stop_details informa a categoria, que pode ser cyber, bio, frontier_llm, reasoning_extraction ou general_harms.

O fallback no servidor, ainda em beta, reenvia recusas cyber e frontier_llm para o Sonnet 5. As outras três categorias não passam por nova tentativa automática.

Também evite pedir que o modelo escreva o raciocínio na resposta, pois isso provoca recusas do tipo reasoning_extraction. Em vez disso, leia o thinking resumido com display: "summarized".

Conclusão: Sonnet ou Opus no dia a dia

A decisão entre Sonnet ou Opus ficou mais simples com a família Claude 5.5. Comece pelo Sonnet sempre que a tarefa tiver especificação clara e uma forma objetiva de verificação.

Escale para o Opus quando o problema for longo, ambíguo, caro de errar ou quando o Sonnet falhar repetidamente nos testes. Desse modo, você paga pela inteligência extra apenas onde ela realmente faz diferença.

Por fim, meça antes de decidir. Rode suas avaliações em esforço high, compare custo total por tarefa e deixe os números escolherem entre Sonnet e Opus para cada fluxo do seu produto.

FAQ

O Sonnet 5.5 é tão bom quanto o Opus 5.5?

Ele fica próximo do Opus em várias avaliações, principalmente em tarefas bem delimitadas. Em problemas longos e ambíguos, o Opus 5.5 continua à frente.

Quanto o Sonnet 5.5 custa em relação ao Opus 5.5?

O Sonnet custa US$ 2 por milhão de tokens de entrada e US$ 10 de saída, metade do Opus. A leitura de cache custa US$ 0,20 nos dois modelos.

Posso desligar o raciocínio do Sonnet 5.5?

Não da forma antiga, porque thinking: {"type": "disabled"} retorna erro 400. Use between_tools para pensar apenas entre chamadas de ferramenta.

Qual esforço devo usar no Sonnet 5.5?

Comece em high para uso geral e em medium para código agêntico bem especificado. Use xhigh ou max só quando suas avaliações mostrarem ganho real.

Como usar Sonnet e Opus juntos no Claude Code?

Use o alias opusplan, que coloca o Opus no planejamento e o Sonnet na execução. Você também pode trocar manualmente com /model sonnet.