Sonnet 5.5 ou Opus 5.5: qual agente deve assumir a tarefa?

A Anthropic lançou o Claude Sonnet 5.5 em 28 de setembro, seis dias após o Opus 5.5. A US$ 2 por milhão de tokens de entrada e US$ 10 por milhão de saída, ele custa a metade dos US$ 4 e US$ 20 do Opus 5.5 e, na página de lançamento, fica a poucos pontos do Opus 5.5 na maioria das categorias e acima dele no Terminal-Bench 4.0, um benchmark executado pela própria Anthropic. Para uma equipe que opera vários agentes de código, a tentação é colocar todos os Agents no Sonnet e embolsar a diferença.

Os gráficos por nível de esforço na mesma página mostram o contrário. A pontuação em destaque no Terminal-Bench foi obtida com o esforço máximo do Sonnet, a US$ 12,54 por tentativa. Em configurações viáveis para rodar o dia todo, a ordem se inverte: o Opus 5.5 em medium atinge 57,6% por US$ 2,94; o Sonnet 5.5 em high atinge 43,0% por US$ 1,94; e o Sonnet só supera o Opus em medium na configuração xhigh, com 61,5% por US$ 5,30.

TL;DR

Use como padrão o Sonnet 5.5 em medium para tarefas bem delimitadas. Envie trabalhos longos, ambíguos ou transversais para o Opus 5.5 em vez de aumentar o Sonnet para xhigh: em todos os três gráficos de código por esforço publicados pela Anthropic, o Opus em high supera o Sonnet em xhigh praticamente pelo mesmo custo ou menos. Formalize isso como uma regra no Agent, e não como uma preferência na cabeça de alguém: um Agent por nível de modelo e esforço, condições claras de escalonamento e uma definição de concluído. O Sharkly não escolhe o modelo nem o esforço; ele registra qual Agent fez o quê na Task.

O que os números de lançamento sustentam

A tabela de lançamento, com o nível de esforço por trás de cada célula e quem executou o teste:

Duas ressalvas na linha do Terminal-Bench. O system card afirma que requisições sinalizadas afetaram 10% dos testes do Opus 5.5, contra 1,5% do Sonnet, e a avaliação independente da Artificial Analysis registrou o Sonnet 5.5 em 63,6%, não 70,6%. Enquanto isso, o SWE-Bench Pro mostra uma vantagem de 8,6 pontos a favor do Opus. O posicionamento da Anthropic reforça isso: Sonnet 5.5 para tarefas cotidianas bem delimitadas e correções de bugs, enquanto o Opus 5.5 “continua nitidamente superior em trabalhos complexos e abrangentes”.

Os números de destaque também ocultam o que uma regra de roteamento realmente precisa: os três benchmarks de código nos níveis de esforço que você de fato utilizaria, apresentados como pontuação e custo por tarefa.

O Sonnet 5.5 é a opção mais barata por tentativa em medium e high, onde suas pontuações também são as menores. Acima de high, as curvas se cruzam: o Sonnet em xhigh custa mais do que o Opus em medium em todas as três linhas e perde para o Opus em high nas três praticamente pelo mesmo valor ou menos. O modelo econômico deixa de ser barato exatamente quando você exige que ele se comporte como o modelo caro. Os custos do Sonnet no CursorBench são estimativas da Anthropic, e nenhuma dessas tarefas reflete o seu repositório específico; portanto, encare esse ponto de cruzamento como uma hipótese a ser confirmada.

A regra de roteamento formalizada

Artigos anteriores defenderam alinhar modelos a funções de Agent, decidir qual agente recebe uma tarefa pelo seu formato e formalizar os níveis como uma regra. O Sonnet 5.5 adiciona uma nova dimensão a isso. No Terminal-Bench, o mesmo modelo em medium e em max apresenta uma diferença de custo de cerca de 15 vezes por tentativa (US$ 0,83 contra US$ 12,54), portanto “rotear isso para o Sonnet” não é uma regra até que você especifique o esforço.

A linha de escalonamento é onde a regra mostra seu verdadeiro valor. Quando um Agent com Sonnet tem dificuldades, o reflexo imediato é aumentar o esforço. Os gráficos mostram que a solução é mudar o modelo: uma Task que exige Sonnet em xhigh é, com base nessas evidências, uma Task para o Opus em high. Defina suas próprias condições; estes exemplos ilustram a ideia:

• A mesma verificação falhou duas vezes. Uma pessoa transfere a Task para o Agent com Opus anexando o log; nada faz novas tentativas em silêncio em um nível mais alto.
• A alteração requer mais arquivos do que o permitido para um worker (por exemplo, oito) ou altera caminhos não especificados na Task.
• O Agent faz uma pergunta sobre arquitetura/design, e não sobre o enunciado da Task.
• Uma categoria inteira de Task só tem sucesso com o Sonnet acima de high. Migre essa categoria para o Agent com Opus na próxima Sprint.

A lógica inversa também se aplica: Tasks no Opus que são concluídas consistentemente na primeira tentativa e com diffs pequenos devem descer um nível.

O impacto de cada modelo na fila de revisão

Uma regra que especifica apenas modelo e esforço está incompleta. A outra metade é definir o que significa “concluído”, pois cada nível entrega algo diferente para quem revisa, e a revisão já era o gargalo antes de ambos os lançamentos. Execuções mais baratas geram mais diffs, não mais horas de revisores.

O guia de prompting da Anthropic para o Sonnet 5.5 é direto sobre o que um revisor encontrará:

• Em low e medium, ele pede feedback prematuramente em tarefas com agentes mais longas: em um quadro de tarefas, é aquela Task parada às 2 da manhã esperando resposta humana. Um comentarista do Hacker News atribuiu uma pontuação de 7,4% em um benchmark customizado (o Sonnet 5 atingiu 17,8%) exatamente a esse comportamento.
• Em low, ele pode ignorar a etapa de verificação e relatar o código como concluído sem rodar testes. O “concluído” de um Agent de triagem não vale nada sem a saída das verificações.
• Em qualquer nível de esforço, ele adiciona testes, documentação e pequenos arquivos que ninguém pediu. Parte disso é bem-vinda, mas tudo isso gera mais diffs para revisar.
• Em xhigh e max, ele adiciona rodadas de revisão ou subagentes revisores. A página de lançamento explica que foi por isso que o Sonnet 5.5 pontuou menos no FrontierCode em max do que em xhigh: ele acionou com mais frequência a habilidade de code-review do Claude Code, que dispara vários subagentes em paralelo, e em dois casos analisados pela Cognition isso gerou timeout ou edições fora do escopo. Essas alterações são as mais caras para um revisor, porque alguém precisa localizá-las linha por linha.

O Opus 5.5 cobra outro tipo de preço da fila. A Anthropic afirma que ele mantém o foco na tarefa por 18 horas ou mais, gerando até 128k tokens de saída; assim, o peso que ele impõe é de volume, não de ruído, e o pacote de transição necessário para o revisor se aplica a ele também.

Por isso, a definição de concluído deve constar nas instruções do Agent worker, que o Sharkly inclui em cada execução:

Agent: sonnet-worker  (Claude Code, claude-sonnet-5-5, effort medium)

Done means:
- The checks named in the Task ran. Paste each command and its exit
  code. "Tests pass" without output is not done.
- Changes stay inside the paths the Task names. List every file you
  created that the Task did not ask for, and why.
- New tests are welcome. New docs files only if the Task asks.

Keep working on long Tasks. Ask only when two readings of the Task
would produce different code; otherwise proceed and record the
assumption in your report.

Stop and return to the Task, without retrying, when a check has failed
twice, the change needs more than 8 files, or the question is about
design rather than the Task's wording.

Como rodar os dois níveis no Sharkly

O Sharkly não escolhe o modelo nem define o esforço. A documentação de Agents é explícita: “The Agent follows the Runtime’s default model. It does not promise or display a specific model name. Change models in the Runtime or Computer tool configuration, not on the Agent.” Também não há controle de profundidade de raciocínio no Agent. Um nível é uma configuração do Claude Code em um Computer; o Agent é a forma como a equipe atribui trabalho a ele.

Portanto: um Agent por nível. O sonnet-worker roda em um Computer cujo Claude Code está configurado para claude-sonnet-5-5, e o opus-lead em um configurado para claude-opus-5-5. Um Computer pode ser um container, de modo que um segundo nível não exige um segundo laptop. Três detalhes da documentação de configuração de modelos do Claude Code determinam se um nível corresponde de fato ao seu nome:

• Fixe o identificador completo. O alias sonnet aponta para o Sonnet 5.5 apenas na API da Anthropic (no Bedrock e no Google Cloud ele ainda aponta para o Sonnet 4.5), e o Sonnet 5.5 requer o Claude Code v2.1.284 ou posterior.
• O modelo default do Claude Code é o Opus 5.5 nos planos Pro, Max, Team, Enterprise e na API; portanto, um Computer que ninguém configurou já é, por padrão, um nível Opus.
• O esforço padrão do Sonnet 5.5 no Claude Code é medium, o nível de worker citado acima. A alteração deve ser feita no Computer, não no Agent.

Como o Sharkly não consegue identificar com precisão qual modelo um Runtime está usando, inclua o nível no nome do Agent e altere o nome e a configuração simultaneamente. O guia de configuração do Sonnet 5.5 detalha essas etapas.

Para tarefas que exigem os dois níveis na mesma Task, use uma Crew. Uma Crew é um grupo reutilizável de People e Agents coordenado por um Agent líder. Com o opus-lead como líder e workers Sonnet como membros, o líder lê a Task, executa-a ou menciona um membro para cuidar de uma parte, e os membros adicionam seus resultados à mesma Task. Essa é a arquitetura com o Opus como orquestrador sugerida nos comentários do Hacker News, com os repasses registrados onde uma pessoa pode acompanhá-los. Para demandas pequenas e bem delimitadas, dispense a Crew e atribua a tarefa diretamente ao sonnet-worker.

O alias opusplan do Claude Code implementa uma variação disso em uma única sessão: Opus no modo de planejamento e Sonnet para a execução. A parte do Sonnet só aponta para o Sonnet 5.5 na API da Anthropic; no Bedrock, Google Cloud ou Foundry, ela aponta para uma versão anterior do Sonnet. Utilize essa abordagem quando a mesma pessoa executar e revisar a sessão; use dois Agents quando outra pessoa precisar auditar quem planejou e quem executou.

Uma coisa nunca é transferida entre níveis: o raciocínio. Os blocos de pensamento do Sonnet 5.5 são vinculados exclusivamente ao modelo e à conversa. Nenhum outro modelo tem acesso a eles, e o Sonnet 5.5 não pode ler os do Opus 5.5. O reaproveitamento de diretórios na Crew compartilha arquivos, não a sessão do Agent anterior. O que o líder definiu só chega ao worker se estiver registrado na Task — tema que é discutido em detalhes em um artigo próprio.

Nada disso altera quem aprova o trabalho. Agents pesquisam, executam, testam e relatam. As pessoas definem a direção, concedem autorizações e aceitam o resultado. Os custos mencionados acima incidem na fatura do seu provedor, já que o consumo dos modelos ocorre por meio das assinaturas ou chaves de API configuradas nessas ferramentas. A atribuição, os logs de execução, as dúvidas, o resultado e a revisão humana ficam registrados na Task, qualquer que seja o modelo líder no próximo trimestre — e essa lógica é válida entre diferentes fornecedores, como demonstra a comparação entre o Sonnet 5.5 e o GPT-6 Sol. Se você deseja continuar usando múltiplos agentes de programação sem ficar preso a um único ecossistema, esse é exatamente o desafio que o Sharkly foi projetado para resolver.