Claude Opus 4.5 vs Claude Sonnet 4.5: quando pagar mais para corrigir incidentes de código — e quando não

A decisão não é qual modelo parece melhor, mas qual resolve cada incidente com o menor custo total

Comparar Claude Opus 4.5 e Claude Sonnet 4.5 para manutenção de software exige delimitar a pergunta. O preço por token, uma demonstração isolada ou um resultado de benchmark não respondem, por si só, qual opção convém a uma equipe. A unidade de decisão deve ser o incidente corretamente resolvido e aceito: uma alteração que reproduz o contexto da falha, passa nos testes-alvo e de regressão, não amplia indevidamente o escopo e exige uma revisão humana razoável.

Nesta comparação, um prêmio de preço para o Opus 4.5 só se justificaria se se traduzisse em um resultado operacional mensurável. Pode ser uma taxa maior de resolução completa, menos regressões, menos iterações de um engenheiro ou menos tempo até haver um patch aceitável. Se o Sonnet 4.5 atingir os mesmos limiares de aceitação com menor custo, pagar mais não acrescenta necessariamente valor para esse tipo de ticket.

A análise deve separar o custo de inferência do custo de trabalho. Um modelo barato que gera patches incompletos, obriga a depurar seu diagnóstico ou produz alterações fora de escopo pode acabar sendo mais caro após somar tentativas, execução de ferramentas e revisão. Por outro lado, um modelo com tarifa superior não deve receber crédito por um patch que parece plausível, mas não passa em uma bateria de testes representativa.

Este artigo não declara um vencedor geral. Ele propõe um teste local que permita a responsáveis de engenharia, equipes de plataforma de IA e compradores decidirem com evidências próprias. Também é compatível com o índice de comparações, com as fichas de Claude Opus 4.5 e Claude Sonnet 4.5 e com as informações da Anthropic sobre os modelos e seus canais de acesso.

Prepare um corpus congelado e reproduzível antes de executar os modelos

O teste começa pelo corpus, não pelo prompt. Cada incidente deve estar associado a um repositório, um commit-base imutável, um ambiente de execução e uma definição verificável da falha. Preserve o ticket original, mas redija uma versão da tarefa que remova informações posteriores ao momento que se quer simular, como o link para a correção já conhecida ou comentários que revelem a solução.

Para cada caso, crie uma reprodução mínima que falhe no commit-base e uma bateria que permita verificar a correção. A avaliação deve distinguir uma modificação cosmética de uma correção funcional. Uma prática sólida é definir testes que deveriam falhar antes da correção e testes que já passavam e devem continuar passando. Essa abordagem coincide com a lógica de validação usada para diferenciar resolução e regressão no SWE-bench Verified, embora os resultados de um corpus interno não devam ser misturados aos desse benchmark.

O SWE-bench é uma referência metodológica útil, não um substituto para o corpus local. O trabalho original descreve um conjunto de incidentes extraídos de repositórios Python reais; isso ajuda a entender as exigências de uma tarefa de edição de repositório. No entanto, sua distribuição de linguagens, dependências, antiguidade dos incidentes e regras de avaliação pode diferir daquelas da equipe. Um resultado interno deve ser publicado como resultado interno.

Exclua tickets sem reprodução razoavelmente estável, alterações que dependam de serviços externos não controlados, vulnerabilidades que exijam um processo específico de divulgação e tarefas cujo critério de aceitação seja puramente subjetivo. Registrar essas exclusões evita que a amostra final pareça mais representativa do que realmente é.

Mantenha condições equivalentes, mas não suponha que equivalente significa idêntico

Registre o identificador exato de cada modelo, a data e a hora da execução, o canal de acesso, a região ou endpoint, o provedor de infraestrutura, a configuração de contexto e as ferramentas concedidas. Para o Opus 4.5, a documentação da Anthropic identifica o modelo de API claude-opus-4-5-20251101. A documentação de ciclo de vida dos modelos deve ser consultada no início de cada campanha para confirmar que ambos os identificadores continuam ativos e antecipar descontinuações.

O anúncio do Sonnet 4.5 documenta seu acesso via API e seu preço de lançamento de entrada e saída. Esse dado não basta para calcular um custo definitivo: o faturamento pode depender do canal, do uso de cache, da região, das ferramentas e das condições comerciais vigentes. No Amazon Bedrock, por exemplo, a documentação do fornecedor descreve diferenças entre endpoints globais e regionais, além de condições específicas de disponibilidade. Não compare uma execução regional de um modelo a uma execução global do outro sem declarar a diferença.

Use o mesmo prompt de sistema, descrição da tarefa, formato de resposta, diretório de trabalho, permissões de leitura e escrita, comandos autorizados, acesso à rede e limite de iterações. Se um modelo dispuser de uma modalidade ou capacidade que o outro não tenha no canal escolhido, não a trate como um teste estritamente equivalente. É possível medi-la como um cenário operacional separado, mas ela deve ser identificada como tal.

A política de tentativas e os limites também devem ser fixados. Uma nova tentativa após um erro transitório de infraestrutura pode ser razoável; múltiplas reinicializações porque o primeiro resultado foi ruim alteram a intervenção disponível. A regra deve ser aplicada aos dois modelos, e todas as tentativas faturáveis devem ser contabilizadas.

Separe os tickets por dificuldade e por mecanismo de falha

Uma média global pode ocultar a informação que de fato determina a compra. Classifique os casos antes de executar os modelos. Um primeiro estrato pode reunir correções localizadas: uma validação incorreta, uma condição de borda ou uma transformação de dados limitada a um ou poucos arquivos. São tarefas nas quais um modelo mais econômico pode alcançar rapidamente o limiar de aceitação.

Um segundo estrato deve incluir falhas que exigem rastrear dependências entre módulos. Por exemplo, uma mudança em uma interface interna que quebra serialização, validação e consumidores remotos, ou um defeito em que o sintoma aparece em uma camada diferente da causa. Aqui é razoável investigar se uma capacidade maior de planejamento ou exploração reduz iterações, mas o resultado deve ser medido, e não inferido a partir da categoria do modelo.

O terceiro estrato corresponde a incidentes ambíguos ou difíceis de reproduzir. Eles podem envolver concorrência, estado compartilhado, configurações particulares ou requisitos incompletos. O objetivo não é premiar uma explicação extensa: é verificar se o modelo formula hipóteses testáveis, obtém evidências com as ferramentas permitidas e limita a mudança à causa mais bem sustentada.

Também rotule linguagem, tamanho do repositório, superfície modificada, tipo de teste e existência de dependências externas. Esses rótulos permitem descobrir se uma diferença decorre da dificuldade real ou de uma concentração acidental de tickets em uma linguagem ou módulo.

Defina sucesso completo antes de ver os resultados

O critério de sucesso deve combinar validação automática e revisão humana. Classifique como sucesso completo apenas um patch que passe nos testes-alvo, mantenha os testes de regressão pertinentes e cumpra a rubrica de escopo. Se o repositório dispuser de testes amplos viáveis dentro do orçamento, execute-os; caso contrário, declare qual cobertura ficou de fora e por quê.

A revisão humana deve ser cega em relação ao modelo. Entregue aos revisores o diff, o diagnóstico produzido, os resultados dos testes e o ticket, mas não o nome do modelo nem o custo. Peça uma decisão definida: aceitar, aceitar com pequenas alterações, rejeitar por correção incompleta, rejeitar por regressão, rejeitar por escopo excessivo ou outra categoria especificada previamente.

É conveniente preservar a categoria de sucesso parcial, mas não usá-la para inflar a taxa de resolução. Um patch que localiza corretamente o componente afetado, mas falha em uma condição de borda, pode ser útil para investigar a qualidade do diagnóstico. Ele não equivale a um incidente resolvido. Da mesma forma, uma correção correta que modifica arquivos alheios sem justificativa pode exigir intervenção suficiente para não contar como sucesso completo.

As instruções de revisão devem proibir a aceitação de alterações que desativem testes, reduzam asserções ou introduzam exceções genéricas apenas para fazer um erro desaparecer. Elas também devem indicar que um novo teste, por si só, não demonstra que a implementação está correta.

Meça custos, intervenção e tempo de ponta a ponta

A métrica principal pode ser expressa como o custo total do lote dividido pelo número de sucessos completos aceitos. No numerador, inclua entrada, saída, cache e qualquer conceito faturável aplicável ao canal. Some tentativas, chamadas que falharam, uso de ferramentas quando houver custo e tempo humano de revisão ou correção, se o objetivo for decidir o custo operacional, e não apenas o custo da API.

Também informe a taxa de sucesso completo, a taxa de sucesso parcial, as regressões detectadas, o número de intervenções humanas e a latência de ponta a ponta. A latência não equivale necessariamente ao tempo do modelo: um agente pode aguardar ferramentas, repetir testes ou bloquear recursos de integração contínua. Registre separadamente o tempo de inferência, o de ferramentas e o humano sempre que possível.

Para avaliar o diagnóstico, use uma rubrica simples: identificação dos sintomas, hipótese causal, evidência coletada, explicação da modificação e limitações conhecidas. Um diagnóstico pode ser útil mesmo em uma falha, mas deve ser avaliado sem confundir qualidade narrativa com correção. A pontuação deve ter exemplos de referência e, se houver vários revisores, uma regra para resolver divergências.

Reporte distribuições e resultados por estrato, não apenas médias. Um pequeno número de incidentes complexos pode dominar o custo médio. Além disso, repita parte ou todo o lote: a variabilidade entre execuções pode alterar a conclusão se a diferença entre os modelos for pequena.

Interprete o prêmio do Opus 4.5 com limiares, não com prestígio de modelo

O Opus 4.5 justificaria um prêmio em um estrato específico se sua melhora em resoluções completas compensasse seus custos adicionais e a revisão que ele evita. Isso poderia ocorrer em incidentes com relações entre módulos, diagnósticos ambíguos ou ciclos de teste caros, mas é uma hipótese que o experimento deve confirmar. A comparação deve mostrar quantos casos adicionais a revisão aceita e qual custo humano deixa de ser necessário.

O Sonnet 4.5 atinge o limiar operacional quando cumpre a taxa de aceitação, o limite de regressões, o prazo e o custo definidos pela equipe. Em correções localizadas, a decisão pode favorecê-lo mesmo que o Opus obtenha uma pontuação média maior, se a diferença não reduzir um custo relevante. Em tarefas mais difíceis, o resultado pode ser misto: Sonnet para triagem e correções delimitadas; Opus para uma fila definida de incidentes que ultrapassa um critério de complexidade.

Não transforme a segmentação em uma regra baseada apenas em intuição. Uma política inicial pode usar sinais como o número de módulos afetados, a ausência de reprodução clara ou a necessidade de analisar rastros extensos. Depois, ela deve ser validada contra os resultados. Se esses sinais não preverem uma melhora suficiente com o Opus, eles adicionam complexidade sem proporcionar uma decisão melhor.

Os anúncios e cartões técnicos do fornecedor podem fornecer informações sobre disponibilidade, configuração e avaliações internas. Eles não substituem este teste, porque as ferramentas, os repositórios, os prompts, o orçamento e a definição de sucesso podem não coincidir com os da sua equipe.

Aplique análise de sensibilidade e declare os limites

Repita a comparação com diferentes orçamentos de iteração, limites de contexto e permissões de ferramentas restritas. Um resultado que depende de um orçamento muito alto pode não ser aplicável a uma operação com limites rígidos. Da mesma forma, uma vantagem observada com acesso à rede ou com uma ferramenta proprietária não deve ser atribuída exclusivamente ao modelo.

Não agregue resultados do SWE-bench Verified, Terminal-Bench ou outras avaliações ao resultado interno. É válido apresentá-los como contexto metodológico se a diferença de corpus e harness for identificada, mas não como linhas comparáveis de uma mesma tabela. Alterar os testes, a política de ferramentas ou a definição de aceitação altera a tarefa medida.

Este teste também não comprova segurança de código, autorização para implantar, capacidade de manutenção contínua ou desempenho em todas as linguagens. Um patch aceito em um ambiente isolado pode introduzir riscos não cobertos pelo conjunto de testes. A decisão de produção deve preservar controles de revisão, integração contínua e gestão de mudanças.

Por fim, documente os casos perdidos: tickets excluídos, erros de infraestrutura, revisões sem consenso e testes instáveis. Ocultá-los pode fazer a conclusão parecer mais robusta do que realmente é. A transparência é especialmente importante se a diferença de custo ou aceitação entre os dois modelos for pequena.

Modelo final para tomar uma decisão repetível

Antes de escolher, estabeleça por escrito o objetivo: por exemplo, reduzir o custo por correção aceita de incidentes de manutenção sem ultrapassar um limite de regressões nem de tempo de revisão. Em seguida, execute ambos os modelos sobre o mesmo lote congelado e publique os parâmetros suficientes para repetir o cálculo internamente.

A conclusão deve assumir uma forma condicional. Por exemplo: o Sonnet 4.5 é a opção padrão para o estrato localizado porque atinge o limiar de aceitação com menor custo total; o Opus 4.5 fica reservado para o estrato intermodular se a repetição confirmar uma redução suficiente de rejeições ou intervenção humana. Se a diferença não persistir após repetir o lote, a conclusão responsável é que não há evidência suficiente para pagar um prêmio nesse ambiente.

Revise a decisão quando mudarem os identificadores dos modelos, os preços aplicáveis, o canal, as ferramentas disponíveis ou a composição da fila de incidentes. Uma avaliação reproduzível não é uma compra única: é um controle periódico sobre uma decisão que depende de sistemas e condições em evolução.

Continue a explorar

Correções e transparência

Se encontrar informação incorreta ou desatualizada, envie-nos a página e a fonte que devemos rever.