Sonnet 5.5 encosta na Opus e corta custo de code

Opus está caro demais para o dia a dia

Claude Sonnet 5.5 chegou justo quando minha conta de API estourou de novo por causa do uso pesado da Opus 5.5. Quem vive de coding agent conhece bem essa dor: você quer qualidade máxima para resolver um bug chato, entender um gráfico ou revisar um pull request, mas não quer pagar taxa de modelo flagship em toda chamada simples. A promessa inicial é direta, desempenho quase de Opus em código com preço e latência de Sonnet. Se for verdade, muda a conta no fim do mês e muda o jeito de montar pipeline. Eu fui testar a ideia com ceticismo saudável, porque versão .5 da Anthropic sempre cria barulho, mas dessa vez os relatos parecem consistentes.

O timing não é coincidência. O lançamento caiu bem no dia do DevDay da OpenAI, com rumor de novidade grande vindo do Sam Altman e todo mundo de olho em browser use e agentes que operam computador. A Anthropic respondeu sem evento gigante, só soltando o modelo e deixando os benchmarks e o boca a boca fazerem o trabalho. É uma jogada clássica de quem confia no produto: não briga por palco, briga por custo por tarefa resolvida. Para quem opera, isso importa mais que keynote.

O fato sem enfeite

A Anthropic liberou o Claude Sonnet 5.5 como um modelo intermediário forte, posicionado entre velocidade e inteligência. Nos benchmarks divulgados, ele aparece muito próximo da Opus 5.5 em tarefas de programação e com um salto claro em compreensão de imagens, gráficos e documentos visuais. Na prática, os primeiros usuários dizem que ele aguenta bem raciocínio longo quando colocado em modo de thinking alto, mesmo no plano de 20 dólares. Não é uma nova arquitetura anunciada, é uma evolução da linha Sonnet que historicamente acerta na versão ponto cinco.

O recado da comunidade foi rápido: vale trocar parte das chamadas que hoje vão para a Opus por Sonnet 5.5 com thinking alto. Muita gente que tinha abandonado o Sonnet depois da Opus 4.5 está voltando a testar, principalmente fora do Claude Code, em harnesses como Pi e Droid e em fluxos próprios via API. Não há ainda uma tabela oficial detalhada de preço e latência para todos os provedores nesta cobertura, mas o posicionamento é o de sempre: Sonnet custa uma fração da Opus e responde mais rápido. O teste real agora é ver se essa economia se mantém sem queda perceptível na taxa de acerto.

Como funciona na visão de quem opera

Pensa no Sonnet 5.5 como o modelo do meio que tenta entregar 90 por cento do resultado com 30 a 40 por cento do custo. Em termos de arquitetura, tudo indica que é o mesmo transformer denso otimizado da família Claude, com melhorias em pós treinamento para código, tool use e visão, além de uma janela de contexto longa para lidar com repo inteiro e documento pesado. O modo de thinking alto funciona como cadeia de raciocínio interna mais longa antes da resposta final, o que aumenta tokens de saída e latência, mas melhora разбор de problema complexo. É aqui que mora o ajuste fino: você paga mais tokens para pensar, porém paga menos por token do que pagaria na Opus.

Em latência, a expectativa plausível é de primeira resposta em poucos segundos em prompts médios, contra um tempo maior e mais variável na Opus sob carga. Para API, isso muda o desenho do retry e do paralelismo. Dá para colocar Sonnet 5.5 como default no roteador e deixar a Opus só como escalonamento quando o teste unitário falha duas vezes ou quando o agente marca baixa confiança. Em visão, o salto em gráficos e tabelas sugere um encoder visual melhor alinhado ao texto, o que reduz alucinação em leitura de dashboard, print de erro e diagrama. Ainda é inferência, não dado oficial, mas bate com o comportamento relatado.

Tem um ponto que ninguém comenta muito: harness importa tanto quanto modelo. O mesmo Sonnet 5.5 pode parecer mediano no Claude Code e ótimo em outro agente, porque muda como o sistema injeta contexto, roda ferramenta e faz loop de correção. Se você vai avaliar, avalia o conjunto inteiro, não só o nome do modelo. Roda o mesmo task set nos dois harnesses, mede taxa de sucesso, tokens por tarefa e tempo até verde no CI. Sem isso, você só está comparando sensação.

O que isso muda na prática

Quem ganha primeiro é quem roda muito código todo dia: time de produto com agente no PR, indie hacker com pipeline de geração e quem usa IA para analisar documento visual. A troca de Opus para Sonnet 5.5 em tarefas de rotina pode cortar bem o custo mensal sem dor visível, desde que você mantenha uma rede de segurança. Quem perde é quem vendeu diferenciação só em cima de wrapper fino para código, porque a barra de qualidade do modelo intermediário subiu de novo. Se seu produto só funcionava com Opus cara, agora o concorrente faz parecido com Sonnet barata.

Ação prática para ajustar hoje

Não migra tudo de uma vez. Separa teu tráfego em três faixas e mede por uma semana. Coloca geração simples, autocomplete, explicação de erro e leitura de gráfico direto no Sonnet 5.5. Mantém refatoração grande, debug multietapa e mudança arquitetural na Opus 5.5 por enquanto. E cria uma regra de fallback automático: se o Sonnet falhar no teste ou retornar confiança baixa, reenvia para Opus com o histórico do erro. Essa é a ação que mais economiza sem quebrar entrega.

• Define thinking alto só para tarefa difícil, deixa thinking baixo ou desligado para tarefa trivial para controlar latência.
• Loga tokens por tarefa resolvida, não por chamada, e compara Sonnet 5.5 contra Opus no mesmo dataset interno.
• Testa visão com teus prints reais, não com demo bonita, porque gráfico de produto real tem ruído, legenda cortada e escala estranha.

Outro ajuste: revisa teu prompt de sistema. Modelo .5 costuma responder melhor a instrução curta e teste explícito do que a super prompt cheia de regras. Tira peso morto, deixa critério de pronto claro e pede para o agente rodar ferramenta em vez de adivinhar. Muita gente vai culpar o modelo quando o problema é contexto inchado e loop mal feito.

A tensão que fica

A dúvida real é se esse quase Opus escala quando o repo é sujo de verdade. Benchmark limpo é uma coisa, monorepo com 400 mil linhas, teste flaky e dependência quebrada é outra. O Sonnet 5.5 parece forte em entender código e imagem, mas agentes bons vivem ou morrem no tool use longo: chamar terminal, navegar, voltar atrás sem se perder. E é curioso que justamente em uso de computador e browser os modelos da OpenAI ainda pareçam na frente no dia a dia, pelo relato de quem usa os dois lados. Ou seja, a Anthropic pode ter vencido a rodada do código estático, mas não necessariamente a do agente que clica e opera sistema.

Tem também a conta do thinking alto. Se você precisa ligar o raciocínio máximo para encostar na Opus, será que a economia continua tão grande depois de somar tokens extras e latência maior? Para tarefa isolada, sim. Para loop de agente com dez iterações, talvez a diferença aperte. Isso não invalida o modelo, só move o gargalo do preço por token para engenharia de loop. No fim, a pergunta honesta é: ele resolve mais tarefa sozinho ou só barateia a tentativa? Minha leitura inicial é que barateia bem e resolve um pouco melhor, o que já justifica o teste, mas não justifica reescrever tua stack em cima dele amanhã.

Conclusão direta

Sonnet 5.5 é o melhor custo benefício da Anthropic em muito tempo e merece virar teu default para código e visão, com Opus como rede de segurança. A pergunta que fica é simples: quantas tarefas tuas de hoje realmente precisam de Opus, e quantas só estavam lá por preguiça de rotear?