Claude Opus 5.5 vs GPT-6 Sol: como escolher o runtime padrão da sua equipe

Uma linha em um arquivo de configuração decide para onde vai a maior parte dos tokens da sua equipe neste trimestre. Em 2026-09-22, os dois candidatos para essa linha mudaram ao mesmo tempo: a Anthropic lançou o Claude Opus 5.5, e a OpenAI lançou o GPT-6 Sol e o GPT-6 Luna. Se você roda vários agentes de programação em paralelo, a pergunta não é qual modelo é mais inteligente. É qual deles os seus Agentes usam por padrão, e o que isso faz com a fila de trabalho esperando alguém para aceitá-lo.

Há uma pegadinha nas evidências, que vale conhecer antes de ler qualquer um dos posts de lançamento. A OpenAI comparou o Sol com o Claude Opus 5. Não com o Opus 5.5. O Opus 5.5 não existia quando esse post foi escrito, e foi lançado horas depois a $4 por milhão de tokens de entrada, contra $5 do Opus 5. Portanto, toda frase do tipo “supera o Opus 5 por uma fração do custo” no post da OpenAI foi medida contra um modelo que ficou obsoleto no mesmo dia. Isso não torna os números errados. Torna-os os últimos números publicados, e não os atuais.

TL;DR

Um Runtime padrão é o modelo que seus Agentes usam quando ninguém escolheu outra coisa, o que, na prática, corresponde à maioria das execuções. Escolha-o com base em três eixos: custo por tarefa concluída, por quanto tempo ele sustenta uma tarefa antes de precisar de você e o que ele faz quando trava. Pelos números publicados, o Sol é mais barato por tarefa concluída, embora a única comparação publicada seja com o Opus 5, e o Opus 5.5 seja o que permanece numa tarefa longa sem parar. Ninguém colocou os dois frente a frente num mesmo harness, então trate os dois posts de lançamento como alegações de fornecedor e decida isso no seu próprio repositório.

O que cada fornecedor realmente publicou

A Anthropic afirma que o Opus 5.5 custa 40% menos para rodar do que o Opus 5, produz resultado cerca de 30% mais rápido e permanece na tarefa por 18 horas ou mais. A saída máxima é de 128k tokens, e há um modo rápido com preço separado de $8 / $40.

A OpenAI afirma que Sol e Luna são cada um 50% mais baratos que o preço promocional do GPT-5.6. A palavra “promocional” é da própria OpenAI e importa: a comparação é com um valor com desconto, e não com o preço de tabela do GPT-5.6. A OpenAI também diz que o GPT-6 Astra “continua sendo nosso melhor modelo em todos os aspectos”, o que é um lembrete útil de que o Sol é a faixa de custo-benefício da própria família, e não o carro-chefe.

Eixo 1: custo por tarefa concluída, não custo por milhão de tokens

O preço do token é apenas um proxy do valor que você realmente paga. Um modelo que cobra metade da tarifa, mas precisa de três tentativas, sai mais caro do que um que acerta de primeira. A OpenAI publica o custo por tarefa junto com a pontuação, o que é incomumente direto.

A primeira linha é a que as pessoas estão citando. O Sol com raciocínio extra-high pontua mais que o Claude Opus 5 com raciocínio max, por cerca de 9% do custo por tarefa do Opus 5. Multiplique $0,27 por 11,1 e o Opus 5 no max chega perto de $3 por tarefa nesse harness — uma conta nossa a partir dos dois números da OpenAI, e não um valor que a OpenAI publicou.

Agora aplique a pegadinha. A Anthropic estima que o Opus 5.5 custa 40% menos para rodar que o Opus 5, então esse valor de $3 está desatualizado. E ele também não cai simplesmente 40%, porque o custo por tarefa varia conforme quantos tokens o modelo queima para chegar lá, e não apenas conforme o preço de tabela. A diferença publicada era grande, um dos lados mudou no mesmo dia por um valor declarado, e ninguém refez a comparação. Se você quer esse número para o seu código, faça a comparação no seu próprio repositório em vez de esperar que um laboratório faça isso por você.

Para dar escala: a OpenAI relata que seu pesquisador mediano gasta mais de $600 por dia com agentes de programação, e o percentil 90, $7.000 por dia. O custo por tarefa deixa de ser uma abstração muito rápido.

Eixo 2: por quanto tempo ele sustenta a tarefa

Os dois fornecedores resolveram o mesmo problema em lugares diferentes.

A Anthropic resolveu no modelo. O Opus 5.5 permanece na tarefa por 18 horas ou mais. Uma execução que dura mais que o seu dia de trabalho muda a forma de supervisionar: você para de ficar olhando e passa a voltar a ela, o que só funciona se a execução reportar em algum lugar que não seja um terminal que você fechou.

A OpenAI resolveu no cache. O GPT-6 dá 90% de desconto nas leituras de entrada em cache, aumenta as taxas de acerto por padrão e, o que é importante para o trabalho com agentes, não quebra mais o cache quando você muda o esforço de raciocínio ou o conjunto de ferramentas disponíveis. Pontos de quebra explícitos permitem escolher onde termina um prefixo em cache. O GitHub relata mais de 50% menos tokens de prompt precisando de processamento novo em bilhões de requisições. Uma execução longa de agente é, em grande parte, o mesmo contexto lido muitas vezes, então isso é uma correção do custo da duração, e não da duração em si.

Use o Opus 5.5 como padrão quando sua Tarefa típica for uma migração, um refactor amplo ou qualquer coisa em que parar no meio custe mais que os tokens. Use o Sol como padrão quando sua Tarefa típica for delimitada, repetida muitas vezes por dia e barata de refazer. A maioria das equipes tem os dois tipos, e é por isso que o padrão importa menos do que ser intencional nas exceções.

Eixo 3: o que ele faz quando trava

Esse eixo não tem benchmark e é o que gera chamados no suporte.

A Artificial Analysis, uma terceira parte e não nenhum dos fornecedores, mediu as variantes de raciocínio “max” em 115,2 tokens de saída por segundo para o Sol, com 102,15 segundos até o primeiro token, e 153,9 tokens por segundo para o Luna, com 124,23 segundos. São configurações de esforço máximo, e você deve confirmá-las na listagem atual antes de apostar nelas. O que importa é o formato: com esforço de raciocínio alto, os modelos baratos não são os que começam rápido.

Um agente que está pensando por 102 segundos e um agente que travou parecem idênticos no terminal. Assim como um que terminou há 40 minutos e um que parou para fazer uma pergunta que ninguém viu. Nenhum lançamento de modelo resolve isso. Um status que volta para a Tarefa resolve: Em andamento, Aguardando pessoa, Falhou, Pronto para liberação, com o log e a pergunta anexados. Agentes pesquisam, executam, testam e reportam. Pessoas definem a direção, concedem autoridade e aceitam o resultado.

Dê a como cada Runtime sinaliza progresso e falha o mesmo peso que a tabela de benchmark. Você vai ler o status cem vezes por semana e o benchmark uma vez.

Não coloque as duas tabelas de benchmark lado a lado

Os dois fornecedores publicaram um número no AutomationBench esta semana. A OpenAI reportou o Sol com raciocínio extra-high pontuando 33,2% no AutomationBench 1.0.6. A Anthropic reportou o Opus 5.5 com 40,0% no AutomationBench. Ambos reportaram o OSWorld 2.0, com 60,5% e 81,8% respectivamente, e o número da OpenAI é no conjunto offline.

Isso não é uma comparação direta. Configurações de raciocínio diferentes, pelo menos uma variante de benchmark diferente, harnesses diferentes, nenhum valor de custo por tarefa compartilhado, e cada uma rodada pela parte que se beneficia. Os posts que comparam o Opus 5.5 ao GPT-6 Astra com números específicos são tweets, não dados de fornecedor. A Artificial Analysis publica sim um índice comum, colocando o Opus 5.5 em 58 e em primeiro entre 212 modelos, o Sol em 48 e o Luna em 37, mas isso é um agregado de terceiros, e não uma medição do seu código.

A decisão que sobrevive ao próximo lançamento

Coloque o padrão por escrito. Não como uma preferência que alguém tem na cabeça, mas como uma regra vinculada ao Agente: este Agente roda este Runtime, estas Tarefas vão para ele, e aqui está o Agente mais barato que assume as rotineiras. Algo assim, guardado onde a equipe possa ler:

Default Runtime: Claude Code on claude-opus-5-5
  Tasks: migrations, wide refactors, anything that fails badly halfway
Second Runtime: Codex on gpt-6-sol
  Tasks: bounded, repeated many times a day, cheap to retry
Escalation: a Sol Task that fails twice returns to the Task for a person,
  it does not silently re-run on the expensive Runtime

É isso que transforma qual modelo fica com qual tarefa em vazão, e sobrevive ao próximo lançamento, porque quando a resposta muda você edita uma regra em vez de perguntar a seis pessoas o que elas andam usando. Dois laboratórios lançaram sua faixa de melhor custo-benefício no mesmo dia, e um deles fez benchmark contra um modelo que ficou obsoleto horas depois. Um Runtime padrão que você pode mudar em um só lugar vale mais do que acertar a escolha nesta semana.

O que nenhum dos lançamentos mudou é a fila. O custo por tarefa concluída caiu bastante dos dois lados, então um orçamento fixo agora compra várias vezes mais trabalho de agente concluído do que na semana passada. Ele não compra nenhuma hora adicional de revisor. A capacidade de revisão é o teto, e um corte de preço empurra mais volume contra ele em vez de aliviá-lo. Mantenha o objetivo, a execução, os bloqueios, o diff e a revisão humana visíveis num só lugar, da solicitação até a liberação, e o Runtime padrão passa a ser uma configuração, e não uma aposta.

A Sharkly não roda o modelo nem escolhe por você. Ela é a camada compartilhada de Tarefa, Computer, contexto e revisão em torno das ferramentas que fazem isso. Se você quer continuar usando vários agentes de programação em vez de se comprometer com um único ecossistema, esse é o problema em torno do qual ela foi projetada. Conecte um Computer, crie um Agente em cada Runtime e dê a eles a mesma Tarefa sem graça.