Claude Opus 5.5 vs Sonnet 5.5: Qual vale a pena pelo custo para programação e agentes?

Opus 5.5 vs Sonnet 5.5 em Resumo

Ambos os modelos aceitam texto e imagens e produzem texto. Seus limites correspondentes de contexto e saída não dão a nenhum deles uma vantagem automática para um repositório grande. A diferença está em quanto trabalho cada um realiza dentro dessa janela, com que rapidez termina e quanto custa a execução completa. Especificações e tarifas oficiais vêm da documentação do Sonnet 5.5 da Anthropic e da documentação do Opus 5.5. A linha GPT Proto usa as tarifas mostradas em suas páginas de modelo Sonnet 5.5 e Opus 5.5; verifique essas páginas para detalhes de cobrança atuais, incluindo cache.

A linha de esforço padrão merece atenção. Uma comparação feita com o padrão da API de cada modelo também compara Sonnet em alto com Opus em médio. Mantenha a configuração no seu registro de teste; caso contrário, o resultado é difícil de reproduzir.

O Sonnet 5.5 é Realmente Mais Barato que o Opus 5.5?

Para o mesmo número de tokens de entrada e saída não armazenados em cache nas tarifas publicadas da Anthropic, sim. Um milhão de tokens de entrada custa $2 no Sonnet e $4 no Opus; um milhão de tokens de saída custa $10 e $20. No GPT Proto, as respectivas tarifas de entrada/saída são $1.80/$9 para Sonnet e $3.60/$18 para Opus: 10% abaixo das tarifas oficiais de cada modelo. Gravações de cache de cinco minutos também custam metade no Sonnet nas tarifas da Anthropic. Leituras oficiais de cache são $0.20 por milhão de tokens em ambos os modelos, então um fluxo de trabalho dominado por contexto em cache repetido tem uma diferença de tarifa menor do que o título sugere. Verifique as tarifas de cache ao vivo do GPT Proto separadamente em vez de aplicar o desconto de entrada/saída a todas as categorias de cobrança.

Considere uma ilustração fixa: uma requisição com 20.000 tokens de entrada não armazenados em cache e 5.000 tokens de saída custaria cerca de $0.09 no Sonnet ou $0.18 no Opus nas tarifas de tabela da Anthropic. Usando as tarifas de entrada/saída exibidas pelo GPT Proto, as mesmas contagens fixas de tokens custariam cerca de $0.081 ou $0.162, antes de cache ou outras cobranças. Isto é aritmética, não uma medição do que qualquer modelo precisa para concluir uma tarefa real. Assim que os modelos fizerem números diferentes de chamadas de ferramentas, consumirem tokens de saída diferentes ou exigirem números diferentes de tentativas, a comparação muda.

Artificial Analysis fornece um contraexemplo impressionante. Com esforço máximo em suas tarefas do Intelligence Index, ele mediu o Sonnet 5.5 em $7,60 por tarefa com uma pontuação de índice de 56. O Opus 5.5 custou $5,98 por tarefa e pontuou 58 nessa avaliação. O Sonnet usou aproximadamente 193.000 tokens de saída por tarefa, cerca de 60% mais que o Opus no máximo. O avaliador observa que suas execuções do Sonnet usaram uma implantação de pré-lançamento com um problema de saída estruturada que foi corrigido depois, então eu não usaria esses números para prever uma fatura de produção ao centavo. Eles estabelecem que “tokens pela metade do preço” pode ser o atalho errado para uma execução de alto esforço.

A métrica útil para uma aplicação é o custo por tarefa aceita. Registre entrada não armazenada em cache, gravações de cache, leituras de cache, saída, tentativas e o trabalho humano necessário para corrigir falhas. Depois, pergunte se uma requisição mais cara reduziu o número de requisições ou a quantidade de revisão.

Qual é Melhor para Codificação? Depende da Tarefa

Para uma correção de bug ou pequeno recurso claramente especificado, o Sonnet 5.5 é a primeira execução sensata. Em um conjunto controlado de dez tarefas de codificação de um desenvolvedor, repetido três vezes por configuração em raciocínio alto, ambos os modelos passaram em todas as 30 tentativas no Claude Code. O Sonnet teve média de 53 segundos e cerca de $0.15 por tarefa; o Opus teve média de 108 segundos e cerca de $0.36. O autor diz que o conjunto se tornou fácil demais para os modelos mais novos. Eu tomo isso como evidência para escolher com base em custo e tempo quando ambos passam no seu teste de aceitação, não como evidência de que são igualmente bons em engenharia de software mais difícil.

Para um requisito pouco claro que abrange vários arquivos, o argumento a favor do Opus fica mais forte. A Anthropic o posiciona para codificação agêntica de longa duração e julgamento sustentado, enquanto coloca o Sonnet com trabalho cotidiano mais bem definido. Isso é orientação do fornecedor, não um substituto para testar seu repositório. Um modelo pode escrever os arquivos solicitados corretamente, mas entender mal o contrato da interface, omitir uma migração ou fazer alterações fora do escopo solicitado. Essas falhas importam mais do que o quão polida soa sua primeira resposta.

A revisão de código nos dá uma comparação de tarefa difícil mais concreta. O teste de mesmo caso do CodeRabbit descobriu que o Sonnet 5.5 capturou 6 de 13 problemas conhecidos por meio de comentários acionáveis. O Opus 5.5 capturou 8 em sua configuração Standard e 10 no Max. Treze casos são poucos para uma taxa de vitória universal, e as configurações diferem. Ainda assim, se um defeito não detectado em uma mudança de alto risco tiver um grande custo subsequente, o Opus merece sua própria avaliação em vez de ser descartado pelo preço de tabela.

E quanto à codificação frontend?

Eu começaria uma construção frontend bem especificada no Sonnet, depois avaliaria a página renderizada, interações, responsividade e verificações de acessibilidade — não apenas o diff de código. Para direção visual aberta, o Opus pode justificar um teste quando a primeira implementação não atende ao briefing de design. Anedotas publicadas lado a lado não podem estabelecer um vencedor geral “melhor em frontend”: o prompt, a imagem de referência, as verificações no navegador e o tempo de revisão permitido afetam todos o resultado.

O Que os Benchmarks Realmente Mostram?

Os resultados de lançamento do Sonnet 5.5 da Anthropic mostram um quadro misto:

Leia as configurações junto com as pontuações. A Anthropic relata o resultado do Opus no Terminal-Bench em xhigh; seu resultado do Sonnet no FrontierCode cai de 52,1% em xhigh para 46,2% em máximo. A empresa diz que a última configuração às vezes acionava subagentes de revisão adicionais, timeouts ou edições fora do escopo que o benchmark penalizava. Uma configuração de esforço mais alta não significava de forma confiável um resultado melhor naquele teste.

Há também incerteza de medição. A Anthropic relata um erro padrão de ±2,6 pontos para o Opus no Terminal-Bench 4.0 e ±1,6–2 pontos para outros modelos Claude. A lacuna observada de 4,2 pontos deve, portanto, ser descrita como um resultado naquela avaliação, não como prova de que o Sonnet é consistentemente mais forte em codificação de terminal. Esses números são mais úteis para escolher quais tarefas incluir em seus próprios testes.

Um Exemplo de Frontend Lado a Lado

O CodeRabbit publicou uma vitrine “Brick Studio” lado a lado usando o mesmo prompt longo de construção em duas sessões do Claude Code. Ambos produziram um designer de modelos de tijolos com uma demonstração de Chalé Alpino. O Sonnet terminou em 29 minutos e 27 segundos; o Opus levou 44 minutos e 50 segundos. Os testadores descreveram os resultados como próximos, com o Opus ligeiramente à frente em fidelidade. A página deles tem um link para um vídeo dos resultados.

Este é um exemplo ilustrativo, não um benchmark de frontend. As sessões inicialmente compartilhavam uma pasta de trabalho, o Sonnet mudou para uma subpasta isolada no meio do caminho, e nenhum recebeu a captura de tela de referência. Essas condições limitam o que uma comparação visual pode provar. Para uma comparação específica do GPT Proto, a adição útil seria duas capturas de tela renderizadas originais de um prompt idêntico, além da lista de verificação de aceitação e do uso de tokens registrado. Até que esse teste exista, a vitrine de terceiros deve permanecer claramente atribuída.

Qual Modelo Deve Executar Seu Fluxo de Trabalho Agêntico?

Um agente pode gastar muito de seu orçamento relendo instruções, arquivos do repositório e resultados de ferramentas. Ambos os modelos têm a mesma taxa publicada de leitura de cache, enquanto suas taxas de entrada não armazenada em cache, saída e gravação de cache diferem. Em uma sessão longa, inspecione a fatura por categoria de token antes de presumir que uma troca para o Sonnet reduzirá os gastos pela metade.

Minha política inicial seria enviar etapas delimitadas — classificar um problema, editar um componente conhecido, redigir testes contra um contrato declarado — para o Sonnet. Escalone uma verificação de aceitação falha, uma decisão de arquitetura ambígua ou uma revisão sensível para o Opus. Esta é uma recomendação de design de aplicação, não uma afirmação de que o GPT Proto roteia automaticamente requisições entre os dois. Isso também tem um custo: sua aplicação precisa de uma verificação de aceitação clara e uma regra para quando tentar novamente ou escalonar.

Teste ambos os modelos no mesmo conjunto de tarefas. Mantenha prompts, ferramentas, contexto e critérios de aprovação o mais semelhantes possível; registre o modelo e o esforço realmente usados. Julgue o resultado após a execução, incluindo falhas de ferramentas e quaisquer edições humanas. Uma primeira passagem barata que repetidamente precisa do Opus para repará-la pode ser uma rota cara para a mesma resposta.

Como Comparar Ambos pelo GPT Proto

A página do modelo Opus 5.5 do GPT Proto mostra uma requisição de chat-completions no estilo OpenAI para https://gptproto.com/v1/chat/completions usando uma chave de API bearer e a string de modelo claude-opus-5-5. A página do modelo Sonnet 5.5 também está disponível. Abra Uso da API ou Experimente este modelo em cada página para confirmar a string de modelo ativa e o formato da requisição antes de executar uma comparação.

Este exemplo em Python envia o mesmo prompt simples para ambos os IDs de modelo. Ele deliberadamente omite controles de esforço específicos do provedor porque o suporte para passar esses controles pelo GPT Proto não foi verificado aqui. Defina GPTPROTO_API_KEY no seu ambiente primeiro:

import json
import os
from urllib.request import Request, urlopen

api_key = os.environ["GPTPROTO_API_KEY"]
url = "https://gptproto.com/v1/chat/completions"
prompt = "Explique a correção segura mínima para uma função Python que divide por zero."

for model in ("claude-sonnet-5-5", "claude-opus-5-5"):
    payload = json.dumps({
        "model": model,
        "messages": [{"role": "user", "content": prompt}],
    }).encode("utf-8")
    request = Request(
        url,
        data=payload,
        headers={
            "Authorization": f"Bearer {api_key}",
            "Content-Type": "application/json",
        },
        method="POST",
    )
    with urlopen(request, timeout=120) as response:
        result = json.load(response)
    print(model, result["choices"][0]["message"]["content"])
    print("usage:", result.get("usage"))

Esse prompt apenas verifica acesso e formato de resposta; ele não pode resolver a comparação de codificação. Para uma decisão, substitua-o por uma tarefa representativa e inspecione o trabalho contra sua própria suíte de testes. O código segue o formato público de requisição da página do modelo, mas não foi autenticado nem executado contra uma conta paga para este artigo.

Qual Deles Você Deve Escolher?

O Sonnet é a hipótese econômica padrão mais forte para uma tarefa bem definida: seus tokens de entrada e saída não armazenados em cache custam metade do que os do Opus, incluindo nas tarifas exibidas do GPT Proto de $1.80/$9 versus $3.60/$18. O Opus é a hipótese de qualidade mais forte para uma tarefa aberta cujos erros são caros. Nenhuma das hipóteses substitui um teste curto no seu próprio trabalho. Verifique os preços ao vivo nas duas páginas de modelo e na página de preços antes de projetar o gasto mensal.