Opus 5.5 x GPT-6 Sol E Luna: Qual Escolher Pra Cada Tarefa (Com A Conta De API)

Na segunda-feira passada, 22 de setembro, a Anthropic e a OpenAI lançaram modelo novo no mesmo dia. De manhã veio o Claude Opus 5.5; poucas horas depois, o GPT-6 Sol e o GPT-6 Luna. No fim do dia a pergunta que chegou até mim num canal do time foi bem menos épica: "tá, e qual a gente usa?".

É uma pergunta justa e, ao mesmo tempo, mal formulada. Ela pressupõe um modelo certo para tudo, e os próprios fornecedores desmentem isso. A Anthropic vendeu o Opus 5.5 como fronteira mais barata e mais econômica em tokens. A OpenAI lançou dois modelos de propósito diferente: o Sol para o grosso do trabalho sério, o Luna para tarefa rotineira de alto volume.

Este post fecha uma trilogia. No dia 28 escrevi só sobre o lançamento do Claude Opus 5.5, com benchmarks e preços, e no dia 29 fiz o mesmo com o GPT-6 Sol e o GPT-6 Luna. Aqui o foco é decisão. Não testei nenhum dos três em workload real; o que segue é leitura das páginas oficiais e da cobertura da imprensa, mais uma conta de API hipotética com premissas explícitas, que você pode refazer com os seus números.

Vou passar pela tabela de preço lado a lado, pelo que os benchmarks permitem (e não permitem) comparar, pela conta de API, por uma régua de escolha por tipo de tarefa, pelo padrão de roteamento e, no fim, por uma reflexão de liderança sobre o que acontece quando modelo fica barato e parecido.

A Tabela De Preço Lado A Lado

Começo pelo menos discutível. Todos os números abaixo são de lista, por milhão de tokens, publicados pelos fornecedores em 22 de setembro. Não são preços promocionais nem negociados em contrato enterprise.

A leitura óbvia: o Sol custa metade do Opus 5.5 em input e output, e o Luna custa um quadragésimo do Opus 5.5 e um vigésimo do Sol. Essa proporção de 2x entre Opus 5.5 e Sol vai aparecer em toda planilha que circular nas próximas semanas, e justamente por isso merece desconfiança: ela assume que os dois gastam a mesma quantidade de tokens para resolver o mesmo problema.

A leitura menos óbvia é sobre cache. Com o desconto de 90% da OpenAI em leituras, o cache read do Sol cai para US$0,20, o mesmo valor do Opus 5.5. Em workload dominado por contexto repetido (agente que relê o repositório, prompt de sistema enorme, RAG com documentos fixos), a diferença entre os dois encolhe, porque a parte do input que mais pesa passa a custar igual. A Anthropic cobra prêmio na escrita de cache (US$5 contra US$4 do input normal); a OpenAI não detalha isso no material que li, então na conta abaixo trato como premissa.

O fast mode do Opus 5.5 dobra o preço em troca de geração até 2,5x mais rápida. Para agente interativo, com humano esperando, latência é custo de gente parada, mas só dá para justificar sabendo quanto vale o minuto do seu time.

Vale o contexto maior. Em março escrevi sobre como os preços de API caíram cerca de 80% de um ano para o outro. Setembro continua a curva: o Opus 5.5 é 20% mais barato que o Opus 5, e a OpenAI cortou pela metade os preços da geração anterior.

O Que Os Benchmarks Permitem E Não Permitem Comparar

Aqui mora a maior armadilha deste lançamento duplo. Cada fornecedor publicou a sua tabela, com números rodados nas suas próprias configurações. A Anthropic compara o Opus 5.5 com o GPT-6 Astra (topo de linha da OpenAI) e com o GPT-5.6 Sol. A OpenAI compara o GPT-6 Sol com o Claude Opus 5 e o Fable 5, da geração anterior. Nenhum dos dois publicou comparação direta entre Opus 5.5 e GPT-6 Sol, o que é compreensível para modelos lançados no mesmo dia.

O benchmark que os dois usam como vitrine para os modelos novos é o AutomationBench. A Anthropic reporta 40,0% para o Opus 5.5; a OpenAI reporta 33,2% para o Sol no esforço xhigh e acrescenta que isso sai a 9% do custo do Claude Opus 5. O OSWorld 2.0 também aparece nas duas tabelas, com o mesmo problema. Concluir "o Opus 5.5 é sete pontos melhor em automação" é exatamente a leitura que recomendo evitar.

O motivo é mecânico. Benchmark de agente depende do harness que conecta o modelo às ferramentas, do número de tentativas, do orçamento de tokens, do nível de esforço, do timeout e da versão do conjunto de tarefas. Quando cada fornecedor roda o próprio modelo, escolhe a configuração em que ele vai melhor. Mas significa que os dois números não estão na mesma régua, e ninguém de fora auditou nenhum deles até agora.

Com as lacunas visíveis, dá para ver o que cada um quis mostrar. A Anthropic escolheu coding agêntico longo e trabalho de conhecimento, onde o Opus 5.5 aparece à frente até do Astra. A OpenAI escolheu desempenho por dólar: quase toda afirmação sobre o Sol vem com "a X% do custo de".

Há ainda um problema que discuti ao analisar o leaderboard do SWE-bench Pro de agosto: mesmo benchmark público e independente sofre com contaminação e tarefas quebradas. Se nem ranking de terceiros é veredito limpo, número de página de lançamento é menos ainda. Serve como sinal de direção (o Opus 5.5 provavelmente é forte em coding agêntico, o Sol provavelmente é muito eficiente por dólar), não como resposta.

Eu usaria essa tabela para montar a lista curta de candidatos, não para escolher. Ela diz que os três merecem entrar na avaliação e sugere onde cada um tem mais chance.

A Conta De API Num Cenário Hipotético

Para sair da abstração, um cenário inventado com preços de tabela. Imagine um time que roda um agente de código e alguns fluxos internos de análise de documentos, consumindo 400 milhões de tokens de input e 40 milhões de output por mês. A proporção de 10 para 1 é comum em agente, que relê muito contexto e escreve pouco. As premissas, simplificadas de propósito:

Volume mensal (hipotético)
  Input total ............ 400M tokens
  Output total ...........  40M tokens

Cenário "com cache" (hipotético)
  Input lido do cache .... 300M tokens (75% do input)
  Input escrito em cache .  20M tokens (5%)
  Input sem cache ........  80M tokens (20%)

Premissa para GPT-6: escrita de cache cobrada ao preço normal de input
Premissa geral: os três modelos gastam a MESMA quantidade de tokens

Sem cache, é multiplicação direta. O Opus 5.5 sai por 400 × US$4 = US$1.600 de input mais 40 × US$20 = US$800 de output, total de US$2.400. O Sol, 400 × US$2 = US$800 mais 40 × US$10 = US$400, total de US$1.200. O Luna, 400 × US$0,10 = US$40 mais 40 × US$0,50 = US$20, total de US$60.

Com cache, o input se divide em três faixas. No Opus 5.5: 300 × US$0,20 = US$60 de leitura, 20 × US$5 = US$100 de escrita, 80 × US$4 = US$320 de input normal, mais US$800 de output, somando US$1.280. No Sol: US$60 + 20 × US$2 = US$40 + 80 × US$2 = US$160, mais US$400, somando US$660. No Luna: 300 × US$0,01 = US$3, mais US$2, mais US$8, mais US$20 de output, somando US$33.

Repare: com cache, o input do Opus 5.5 cai de US$1.600 para US$480, e o output passa a ser quase dois terços da fatura. Em workload bem cacheado, quem manda é o preço de output. A pergunta muda de "qual é mais barato por token" para "qual escreve menos para resolver o mesmo problema".

É aí que a premissa de tokens iguais desmorona. A Anthropic diz que o Opus 5.5 usa menos tokens e publicou depoimentos nessa linha: a Box fala em um terço dos tokens do Opus 5; a Optiver, na mesma qualidade em cerca de metade dos turnos, com custo 40% a 50% menor. Do outro lado, o Sol reporta seus melhores números nos esforços xhigh e max, que gastam mais tokens de raciocínio. Isso não diz quanto cada um gasta no seu workload, mas permite achar o ponto de equilíbrio: com cache, o Opus 5.5 empata com o Sol se consumir cerca de 48% menos tokens (US$660 / US$1.280 = 0,52). Com 30% a menos, ainda sai uns 36% mais caro (US$896 contra US$660).

A correção mais importante é outra: custo por tarefa resolvida, não por token. Falha gera retentativa, revisão humana e, no pior caso, bug em produção. Com taxas de sucesso inventadas, 80% para um e 60% para o outro, a conta fica US$1.280 / 0,8 = US$1.600 contra US$660 / 0,6 = US$1.100. O Sol ainda ganha, mas a diferença cai de quase 2x para cerca de 1,45x, antes de contar o tempo de quem revisa. Qual é a sua taxa, só a sua avaliação vai dizer.

Uma Régua De Escolha Por Tipo De Tarefa

Com preços e ressalvas na mesa, dá para propor uma régua. É ponto de partida para decidir o que avaliar primeiro, não veredito.

Agentic coding longo, a sessão que roda por horas, mexe em dezenas de arquivos e precisa manter coerência, é o terreno que a Anthropic escolheu para o Opus 5.5. Os números dela em Terminal-Bench 4.0 (66,4%) e CursorBench 4.0 (57,8%) apontam nessa direção, assim como os casos citados: migração de 680 mil linhas em menos de um dia e reescrita do HAProxy de C para Rust em 9,5 horas, com custo 51% menor que o Fable 5.1. São números do fornecedor, mas é o tipo de tarefa em que erro no meio do caminho custa caro e eficiência de tokens pesa. Eu começaria pelo Opus 5.5 e usaria o Sol como controle de custo; o DeepSWE de 68,8% reportado pela OpenAI justifica a chance.

Knowledge work, como análise de documento, relatório e síntese que depende de julgamento, é onde entra o GDPval-AA. A Anthropic reporta Elo 1846 para o Opus 5.5 contra 1542 do GPT-6 Astra, mas o Sol não aparece nessa tabela. A OpenAI diz que o Sol comete cerca de metade dos erros factuais do antecessor. Minha leitura: onde erro é caro (parecer jurídico, análise financeira, documento para cliente), avalie os dois; na rotina interna, o Sol provavelmente basta pela metade do preço.

Triagem e extração em volume, como classificar tickets, extrair campos de nota fiscal ou resumir conversas de suporte, é o caso declarado do Luna. A OpenAI diz que ele, em esforço alto, equivale ao GPT-5.6 Sol a um centésimo do custo. Mesmo que seja otimista, a diferença de preço é tão grande que o Luna deveria ser o primeiro avaliado em qualquer tarefa de volume com saída bem definida. No cenário hipotético, ele custa US$33 por mês contra US$1.280 do Opus 5.5. Dá para rodar o Luna duas vezes, comparar respostas, mandar só as divergentes para um modelo maior e ainda gastar uma fração.

Computer use, o agente que opera interface gráfica e sistema legado, é onde os números são mais difíceis de ler. A Anthropic reporta 81,8% no OSWorld 2.0 para o Opus 5.5; a OpenAI reporta 60,5% para o Sol em xhigh. Mas a própria OpenAI posiciona o GPT-6 Astra, e não o Sol, para computer use e tarefas críticas. A comparação justa talvez seja Opus 5.5 contra Astra, e o Sol fica para fluxos simples e bem delimitados.

O Padrão De Roteamento: Modelo Caro Orquestra, Barato Executa

A régua trata cada tarefa como de um tipo só, mas sistemas reais misturam tudo. Um agente de código planeja (julgamento), lê arquivos e resume (volume), escreve código (qualidade) e interpreta saída de teste (rotina). É aqui que o roteamento entra.

Em agosto escrevi sobre como subagentes baratos mudam o cálculo da orquestração multiagente: quando o subagente custa uma fração do orquestrador, o fan-out deixa de ser o vilão da fatura. O Luna leva isso ao extremo. Custando 40 vezes menos que o Opus 5.5 em input, abre espaço para um sistema em camadas: o modelo caro planeja, decompõe e revisa; o intermediário faz o trabalho que exige qualidade; o barato faz o braçal.

Voltando ao cenário com cache, redistribuo os mesmos tokens: 10% para o Opus 5.5 como orquestrador, 20% para o Sol como executor de qualidade, 70% para o Luna como executor de volume. A conta fica em US$128 (10% de US$1.280) mais US$132 (20% de US$660) mais US$23,10 (70% de US$33), cerca de US$283 por mês. Menos da metade de usar só o Sol, pouco mais de um quinto de usar só o Opus 5.5.

O número é sedutor e tem duas pegadinhas. Roteamento entre fornecedores cobra o que não aparece na fatura de tokens: dois SDKs, dois formatos de tool calling, duas políticas de rate limit, dois contratos, dois conjuntos de logs. E a divisão 10/20/70 é inventada: no seu sistema, a fatia que o Luna faz sem erro pode ser 90% ou 30%, e cada erro dele que escapa custa uma chamada ao modelo caro para consertar. Roteamento bom depende de classificar bem a tarefa e de uma avaliação que diga, por tipo, qual o modelo mais barato que ainda passa.

A alternativa conservadora é rotear dentro de um fornecedor só. A Anthropic diz que Sonnet 5.5 e Haiku 5.5 vêm "em breve", e aí a família Claude terá a mesma estrutura em camadas. Para quem já tem contrato, compliance e integração prontos com um fornecedor, esperar algumas semanas pode valer mais que a economia extra de misturar.

Quando Modelo Fica Barato E Parecido, O Diferencial Muda De Lugar

Agora a parte que me parece mais importante para quem lidera time. Nos benchmarks em que dá para comparar alguma coisa, os modelos de fronteira dos dois fornecedores estão a poucos pontos de distância, e a cada trimestre um passa o outro. Na tabela de preço, os dois cortaram no mesmo dia. Quando o produto fica mais barato e mais parecido ao mesmo tempo, o nome disso é commoditização.

Os modelos não são idênticos, mas para a maior parte do que um time de produto faz, escolher entre dois modelos de fronteira está deixando de ser a decisão que define o resultado. Quando o insumo principal vira commodity, o diferencial migra para o que você constrói em volta. Vejo três lugares.

O primeiro é arquitetura. O time que desenhou o sistema para trocar de modelo com uma mudança de configuração, com abstração, roteamento por tipo de tarefa e fallback entre fornecedores, captura cada corte de preço no dia em que ele sai. O time que acoplou prompt, tool calling e parsing a um modelo específico precisa de um projeto de migração a cada lançamento.

O segundo é avaliação própria. Se benchmark de fornecedor não compara e benchmark público tem contaminação, sobra o seu conjunto: algumas centenas de casos reais do seu domínio, com critério de correção, rodados contra cada modelo novo em uma tarde. Poucos times têm isso organizado, e acho que é o investimento de maior retorno para um tech lead agora.

O terceiro é contexto de negócio. O modelo sabe programar e redigir; não sabe quais regras do seu domínio são inegociáveis, qual cliente tem contrato especial, qual parte do legado ninguém pode tocar. Quem organiza esse conhecimento em documentação, prompts, ferramentas e dados acessíveis ao agente tem um ativo que não se deprecia a cada lançamento. Se os fornecedores seguem investindo pesado e cortando preço ao mesmo tempo, parte do valor vai parar em quem usa bem os modelos, não necessariamente em quem os fabrica.

Conclusão

Se eu tivesse que responder à pergunta do canal em uma linha: nenhum dos três ganha em tudo, e a conta muda com o tipo de tarefa. O Opus 5.5 custa o dobro do Sol na tabela, mas a diferença real depende de quantos tokens cada um gasta e de quantas tarefas resolve de primeira. O Luna é tão barato que toda tarefa de volume com formato fechado deveria passar por ele primeiro. E os benchmarks publicados, inclusive o AutomationBench dos dois anúncios, foram medidos por cada fornecedor no próprio quintal e não servem como comparação independente.

Por isso a recomendação prática é quase entediante: antes de migrar qualquer coisa, rode uma avaliação própria no seu workload. Separe algumas centenas de casos reais, meça qualidade, tokens e custo por tarefa resolvida nos três modelos, e refaça a conta deste post com os seus números. Uma semana de avaliação custa muito menos que um trimestre pagando pelo modelo errado, ou economizando com um modelo que gera retrabalho que ninguém mede.

O que eu não sei, e acho que ninguém sabe ainda, é por quanto tempo essa dinâmica se sustenta. Dois fornecedores cortando preço no mesmo dia pode ser competição saudável ou subsídio que vai ser cobrado depois. Enquanto isso não se resolve, a aposta mais segura para quem lidera time é a que não depende da resposta: arquitetura que troca de modelo com facilidade, avaliação que diz quando trocar e contexto de negócio que nenhum modelo traz de fábrica.

Fontes:

• Anthropic — Claude Opus 5.5
• OpenAI — Introducing GPT-6 Sol and Luna
• Fortune — What AI slowdown? OpenAI and Anthropic release dueling, more affordable models as AI price wars heat up
• SiliconANGLE — Anthropic releases Claude Opus 5.5 and OpenAI counters with two cheaper GPT-6 models
• CNBC — Anthropic and OpenAI release cheaper AI models