GPT-5.6 sem desperdício: modelo certo para cada tarefa Link para o cabeçalho

Três notebooks em uma bancada escura representam os modelos Sol, Terra e Luna: o maior exibe o Sol em luz alaranjada, o médio mostra a Terra em azul e o menor mostra a Lua em tons de cinza.

Escolher um modelo de IA deixou de ser uma pergunta de torcida. Não basta decidir entre “o GPT” e “o outro”. Com a família GPT‑5.6, a escolha tem dois controles independentes: o tamanho do modelo — Sol, Terra ou Luna — e o esforço de raciocínio. Esses controles mudam custo, latência, limite de uso e, principalmente, a chance de uma tarefa passar na validação na primeira vez.

A pergunta prática é qual combinação resolve o problema sem cobrar por inteligência que você não precisa. A boa resposta não é uma lista fixa. É um método: comece pela tarefa, observe como ela falha e suba capacidade apenas quando houver evidência de que isso reduz o custo total de entrega.

Este guia aprofunda a conversa com dados da OpenAI, do Artificial Analysis e dos próprios benchmarks. A conclusão não é que exista um “campeão absoluto”. É que Sol, Terra e Luna ocupam lugares diferentes dependendo do tipo de trabalho, do seu harness e de como você valida a saída.

Tamanho e esforço são duas decisões Link para o cabeçalho

Há uma distinção que costuma ser misturada: tamanho do modelo não é esforço de raciocínio. Sol, Terra e Luna são faixas de capacidade. O esforço determina quanto o modelo explora alternativas e verifica a resposta; os níveis variam por produto e modelo, mas incluem opções como low, medium, high e xhigh. max é a opção mais alta de raciocínio exposta nos produtos da OpenAI; ultra é outro mecanismo.

Isso produz combinações muito diferentes. Uma classificação de tickets pode funcionar com Luna em esforço baixo ou médio. Um bug que atravessa múltiplos serviços pode justificar Sol em esforço alto. Não é coerente tratar as duas tarefas como se a única variável fosse o nome do modelo.

Também importa distinguir os modos mais altos:

max dá mais margem para um único agente raciocinar, testar caminhos e revisar a estratégia;
ultra vai além: segundo a OpenAI, coordena quatro agentes em paralelo por padrão. É uma técnica de orquestração, não outro nível de esforço nem um botão mágico de “resposta certa”.

Em muitas situações, Luna com mais esforço ou Sol com esforço alto parecem ocupar os extremos mais atraentes, deixando Terra aparentemente “espremido”. Essa é uma hipótese operacional útil, mas não uma regra universal. Os benchmarks ajudam a entender por quê — e também mostram por que não se deve transformar essa hipótese em dogma.

O preço por token mostra a distância; o custo por tarefa decide a compra Link para o cabeçalho

Na API, a tabela oficial da OpenAI cobra por milhão de tokens: Sol custa US$ 5 de entrada e US$ 30 de saída; Terra, US$ 2,50 e US$ 15; Luna, US$ 1 e US$ 6. A página de lançamento traz preços, disponibilidade e detalhes de cache .

Uma conta ilustrativa ajuda a tornar a escala concreta. Em uma chamada com 10 mil tokens de entrada e 5 mil de saída, antes de cache e de qualquer custo de ferramentas, o preço de lista seria aproximadamente:

Sol: US$ 0,20;
Terra: US$ 0,10;
Luna: US$ 0,04.

É uma diferença de 5× entre Sol e Luna nesse perfil. Só que ela não responde à pergunta mais importante: quantas chamadas, correções e revisões humanas serão necessárias até a tarefa ficar aceitável? Uma execução barata que falha três vezes pode custar mais do que uma execução mais cara que passa em testes e segue para revisão uma única vez.

Por isso, use preço por token para formar uma hipótese, não para definir a política. O indicador que importa é custo por tarefa aceita: custo de modelo, ferramentas, espera e intervenção humana até a entrega cumprir o critério de aceite.

Benchmark de programação: o que os números medem de fato Link para o cabeçalho

O número mais citado no lançamento é o Artificial Analysis Coding Agent Index v1.1. No quadro publicado pela OpenAI, Sol atinge 80; Terra, 77,4; e Luna, 74,6. A diferença entre Sol e Terra é 2,6 pontos; entre Sol e Luna, 5,4 pontos. É uma vantagem real, mas não autoriza concluir que Luna seja incapaz ou que Terra seja irrelevante.

Captura do Artificial Analysis Coding Agent Index v1.1, que compara pontuação de agentes de programação por custo de API para as variantes Sol, Terra e Luna.

Captura de referência do Artificial Analysis Coding Agent Index v1.1. Leia os pontos junto com o método e o agente usado: o índice é composto e não é uma medida abstrata de “QI de código”. Fonte e metodologia .

O índice é mais útil do que uma prova curta de algoritmo porque reúne três avaliações de agentes:

DeepSWE: 113 tarefas originais de engenharia de software de longo horizonte. A proposta é testar exploração de repositório, mudanças em vários arquivos e verificação, reduzindo a dependência de issues públicas já conhecidas. A metodologia do DeepSWE explica esse desenho.
Terminal‑Bench v2: 84 tarefas na configuração usada pelo Artificial Analysis para o índice. O agente precisa operar um ambiente real de linha de comando e é avaliado por testes de conclusão; não basta escrever um trecho de código plausível. A revisão oficial 2.1 documenta 89 tarefas no conjunto atualizado. O projeto do Terminal‑Bench descreve o conjunto de tarefas e o harness de execução.
SWE‑Atlas‑QnA: 124 tarefas de perguntas e respostas técnicas, usadas como parte do composto pelo Artificial Analysis.

O índice é a média de pass@1 desses três blocos em três execuções. Isso é excelente para comparar agentes de programação em condições padronizadas, mas não mede diretamente seu ERP, sua política de segurança, seus testes ou a qualidade de uma PR no seu repositório. O próprio Artificial Analysis recomenda olhar também a abertura por avaliação: dois agentes podem empatar no índice e ainda ter forças muito diferentes em terminal, repositório e perguntas técnicas.

Como ler cada componente sem transformar o índice em oráculo Link para o cabeçalho

Coding Agent Index é uma síntese, não uma quarta prova. Ele responde: “qual configuração de agente teve melhor taxa média de conclusão nesse trio de cenários?”. Um 80 para Sol não é “80% de qualidade de programação em geral”; é uma forma compacta de comparar as taxas pass@1 publicadas para DeepSWE, Terminal‑Bench e SWE‑Atlas‑QnA. A vantagem da síntese é facilitar a lista curta. A desvantagem é esconder onde cada agente ganhou ou perdeu.

DeepSWE testa a etapa mais parecida com uma mudança de engenharia longa: entender um pedido curto, explorar uma base desconhecida, encontrar a superfície certa e implementar uma solução em vários arquivos. As 113 tarefas foram escritas do zero em 91 repositórios e cinco linguagens; seus verificadores funcionais aceitam soluções alternativas que cumprem o comportamento pedido. Leia uma pontuação alta como evidência de capacidade de resolver mudanças de repositório sob aquele harness, não como previsão de que toda PR será correta. O paper do DeepSWE também avisa que a posição no leaderboard não é uma avaliação global de qualidade de produto.

Terminal‑Bench 2.1 muda a pergunta: “o agente consegue concluir uma tarefa real em um terminal?”. Compilar, instalar, depurar, usar scripts e satisfazer o verificador fazem parte do trabalho. É por isso que o resultado é útil para agentes que operam CLI, mas não diz muito sobre uma análise de arquitetura ou uma resposta técnica sem execução. A própria revisão 2.1 corrigiu 28 tarefas da 2.0 por dependências externas instáveis, recursos insuficientes e instruções desalinhadas dos testes — uma demonstração prática de que o ambiente de avaliação também altera a pontuação. Veja as correções da versão 2.1 .

SWE‑Atlas‑QnA não pede uma correção de código. Ele mede compreensão profunda de uma base existente: o agente recebe um repositório em container, executa o sistema quando necessário, rastreia fluxos entre arquivos e responde a uma pergunta técnica. São 124 tarefas em 11 repositórios de produção, distribuídos entre Go, Python, C e TypeScript. É o componente mais próximo de investigação, onboarding e diagnóstico; uma nota alta aqui não prova que o agente também escreva uma boa implementação. A metodologia do SWE‑Atlas deixa explícita essa separação entre compreensão, escrita de testes e refatoração.

Três números que valem acompanhar Link para o cabeçalho

O quadro da OpenAI detalha o composto e seus dois componentes de engenharia mais fáceis de interpretar:

no DeepSWE v1.1, Sol marca 72,7%, Terra 69,6% e Luna 67,2%;
no Terminal‑Bench 2.1, Sol marca 88,8%, Terra 87,4% e Luna 84,7%;
no Coding Agent Index, os mesmos modelos marcam 80, 77,4 e 74,6.

Os valores de Terminal‑Bench são próximos: a escolha pode depender mais do seu custo e do seu fluxo do que de uma diferença de 1,4 ponto. DeepSWE abre uma distância um pouco maior, o que faz sentido: tarefas longas de engenharia acumulam dependências, contexto e oportunidades de erro. É aí que capacidade adicional costuma pagar o próprio preço.

Há um detalhe metodológico que muda a leitura dos gráficos: o Artificial Analysis mede modelo mais agente mais configuração. O resultado de Sol no Codex não é uma propriedade isolada dos pesos do modelo; inclui prompt, ferramentas, permissões, tempo de execução e estratégia de validação. Mude o harness e o mesmo modelo pode mudar bastante de posição. Essa é a razão para não copiar uma pontuação de benchmark e esperar a mesma taxa de sucesso em produção.

Comparativo direto: Sol contra Fable, Opus e Grok Link para o cabeçalho

Para transformar a discussão em decisão, vale comparar Sol com os concorrentes que aparecem no mesmo harness de agente de código. No Coding Agent Index v1.1, Sol em max registra 80; Claude Fable 5, 77,2; e Claude Opus 4.8, 72,5. O retrato se mantém nos dois testes de engenharia que compõem a parte mais operacional do índice:

no DeepSWE v1.1, Sol chega a 72,7%, contra 69,7% de Fable 5 e 59% de Opus 4.8;
no Terminal-Bench 2.1, Sol marca 88,8%, contra 83,1% de Fable 5 e 78,9% de Opus 4.8.

Isso é uma evidência forte de que, na configuração avaliada para agentes de código, Sol é a aposta mais capaz deste recorte. Não é uma licença para dizer que ele vence em tudo: na página corrente do Artificial Analysis Intelligence Index v4.1, Fable 5 — em raciocínio adaptativo máximo, com fallback para Opus 4.8 — marca 60; Sol marca 59 em max e 58 em xhigh. A tabela de lançamento da OpenAI registra um snapshot anterior de 59,9 e 58,9, respectivamente. Assim, Sol em max fica a um ponto de Fable; Sol em xhigh, a dois. Essa diferença é precisamente o motivo para separar “melhor agente de programação neste harness” de “melhor modelo para qualquer trabalho”. A comparação de Sol xhigh e Fable, no Artificial Analysis e a tabela comparativa da OpenAI permitem conferir os recortes.

Grok entra no comparativo com uma geração nova. Na ficha corrente do Artificial Analysis, Grok 4.5 em high marca 54 no Intelligence Index v4.1, enquanto Sol marca 59 em max e 58 em xhigh. Esse é um índice amplo — combina nove avaliações, incluindo tarefas agênticas, programação, terminal e raciocínio —, não o Coding Agent Index. Ainda assim, a distância deixou de ser a de um modelo periférico: o 4.5 passa a ser uma alternativa de fronteira para colocar na lista curta.

Desta vez há também um resultado de programação: Grok 4.5 em Grok Build marca 76 no Coding Agent Index, quatro pontos abaixo de Sol em max (80). O Artificial Analysis estima US$ 2,49 por tarefa para essa execução, contra US$ 5,07 para GPT‑5.5 no Codex e US$ 11,80 para Fable 5 no Claude Code. É um sinal forte de eficiência, não uma vitória financeira automática sobre Sol: cada número inclui modelo, agente, ferramentas e política de execução próprios. Perfil de Grok 4.5 e análise independente do lançamento .

O contraponto do CursorBench Link para o cabeçalho

O CursorBench 3.2 oferece uma comparação complementar: tarefas reais, ambíguas e de múltiplos arquivos executadas no agente do Cursor. Ele não substitui DeepSWE, Terminal-Bench ou a avaliação interna, mas ajuda a observar como as escolhas de modelo e esforço se comportam em outro harness.

Comparação no CursorBench	Pontuação	Custo médio por tarefa	Leitura prática
Sol `high` × Fable `low`	63,5% × 62,1%	US$ 2,79 × US$ 4,46	Sol entrega pontuação maior com custo menor.
Terra `max` × Sol `xhigh`	64,9% × 64,5%	US$ 2,89 × US$ 3,88	Terra é uma alternativa econômica muito próxima nesse conjunto.
Sol `max` × Fable `max`	67,2% × 70,5%	US$ 5,69 × US$ 17,32	Fable lidera, mas cobra cerca de três vezes mais por tarefa.
Luna `high` × Luna `xhigh`	56,8% × 57,7%	US$ 0,82 × US$ 1,14	Para volume, o ganho de subir esforço é pequeno nesse recorte.

Aqui, xhigh corresponde ao nível apresentado pelo Cursor como Extra High. Os custos são estimativas de API calculadas a partir dos tokens usados no próprio CursorBench; não são equivalentes a franquias ou limites dos planos mensais. O Cursor também alerta que diferenças pequenas podem não ser estatisticamente significativas. CursorBench 3.2 .

O contraste com o índice amplo é instrutivo. No CursorBench, Terra max fica levemente à frente de Sol xhigh e custa menos; no índice amplo do Artificial Analysis, Sol xhigh marca 58, contra 55 de Terra max. Não é contradição: tarefas, pesos, agentes e preços de execução são diferentes. É um exemplo concreto de por que um benchmark define uma lista curta, não uma política universal. Análise de custo × inteligência do Artificial Analysis .

Mapa de migração para quem vem do GPT‑5.5 Link para o cabeçalho

Esta é uma visão para se localizar, não uma matriz de roteamento. Para quem já conhece o “peso” de cada esforço do GPT‑5.5, ela indica a configuração GPT‑5.6 de menor custo que igualou ou superou aquela pontuação no CursorBench. A decisão de qual modelo usar em uma tarefa nova continua na matriz por tipo de trabalho, mais adiante.

GPT‑5.5	Menor GPT‑5.6 que iguala ou supera	Pontuação	Custo por tarefa	Economia
`low` — 46,6%	Luna `medium`	47,7%	US$ 0,39 vs. US$ 0,98	60%
`medium` — 53,8%	Luna `high`	56,8%	US$ 0,82 vs. US$ 1,51	46%
`high` — 58,4%	Terra `xhigh`	59,2%	US$ 1,44 vs. US$ 2,05	30%
`xhigh` — 58,4%	Terra `xhigh`	59,2%	US$ 1,44 vs. US$ 2,85	49%

O CursorBench não lista GPT‑5.5 em max; por isso, não há equivalência direta para esse nível. A tabela vale para tarefas de programação no agente do Cursor. Em um índice amplo, ou no harness da sua equipe, os pontos de troca podem ser outros — motivo pelo qual ela orienta a migração, mas não substitui a matriz por tarefa nem a avaliação interna. CursorBench 3.2 e comparações do Artificial Analysis .

Onde o custo muda a leitura do placar Link para o cabeçalho

Preço por token e custo por tarefa contam histórias diferentes, mas as duas favorecem Sol diante de Fable no cenário medido. Na API, Sol custa US$ 5 por milhão de tokens de entrada e US$ 30 de saída; a ficha de Fable 5 no Artificial Analysis informa US$ 10 e US$ 50, respectivamente. Essa comparação é só o ponto de partida: cache, tamanho das respostas, ferramentas e repetição de tentativas alteram a fatura final. Preços do GPT-5.6 e ficha de Fable 5 .

No índice amplo do Artificial Analysis, Sol em max alcança aproximadamente 59 pontos a US$ 1,04 por tarefa, perto de um ponto abaixo de Fable 5 e a aproximadamente um terço do custo. Essa relação de pontuação e custo é de Sol em max, não de Sol em xhigh. No índice de agentes de programação, a publicação estima para Sol no Codex custo por tarefa cerca de 40% menor que Fable 5 no Claude Code e 10% menor que Opus 4.8 no Claude Code. É uma comparação mais útil do que multiplicar tokens porque inclui o comportamento do agente, mas traz uma condição importante: cada modelo foi executado no seu harness de origem. O número compara a solução completa — modelo, agente, ferramentas e política de execução —, não apenas o preço do modelo isolado.

Para Grok 4.5, a separação entre preço de API e custo por tarefa é ainda mais importante. A API cobra US$ 2 por milhão de tokens de entrada e US$ 6 de saída; cache hits custam US$ 0,50 por milhão. É mais caro por token que o Grok 4.3, mas a avaliação do Artificial Analysis aponta eficiência de tokens e custo de US$ 0,31 por tarefa no índice amplo. Isso o torna atraente para testar, não uma estimativa de que resolverá o seu repositório por US$ 0,31: tamanho de resposta, cache, ferramentas, repetição, esforço e o agente escolhido mudam a conta. Há ainda uma ressalva factual: no AA‑Omniscience, a acurácia de Grok 4.5 sobe de 35% para 52% frente ao 4.3, mas a taxa de alucinação reportada também sobe de 25% para 54%. Para trabalho que exige fatos confiáveis, a validação externa continua obrigatória. Use o placar público para definir a lista curta; para decidir orçamento, rode as mesmas tarefas da sua equipe com a mesma política de ferramentas e meça custo por mudança aprovada.

Também não uso o SWE‑Bench Pro como confronto principal. O placar publicado é relevante — Fable 5 marca 80%, contra 64,6% de Sol —, mas uma auditoria publicada pela própria OpenAI estimou problemas em cerca de 30% do split público. Como a auditoria vem de uma empresa comparada, ela é motivo para cautela metodológica, não para apagar o resultado. DeepSWE e Terminal-Bench dão uma base mais útil para esta comparação, sem substituir a validação no repositório real.

Por que a prática pode ser bem diferente do benchmark Link para o cabeçalho

Benchmark é uma forma útil de reduzir a incerteza — mas não é uma simulação completa da sua operação. Ele responde a uma pergunta controlada: com este modelo, este agente, estas ferramentas e estas tarefas, qual foi a taxa de sucesso? Produção faz uma pergunta bem menos elegante: isso resolve o problema da minha equipe, dentro do prazo, com segurança e sem criar trabalho extra?

A diferença começa na distribuição das tarefas. Um benchmark reúne problemas projetados para medir capacidades específicas, como navegar em um repositório, usar o terminal ou corrigir uma falha verificável. No dia a dia, a fila mistura pedidos ambíguos, regras de negócio mal documentadas, dependências indisponíveis, sistemas legados e decisões que nem sempre têm um teste automático como árbitro. Um modelo pode ir muito bem em tarefas de terminal e ainda produzir uma alteração inadequada porque não conhece uma convenção interna que nunca apareceu no contexto.

Também existe o efeito do harness. O benchmark não avalia apenas os pesos do modelo: avalia o pacote inteiro — prompt de sistema, ferramentas permitidas, permissões, estratégia de busca, limite de tempo, capacidade de executar testes e forma de recuperar erros. Trocar Codex por outro agente, restringir acesso à rede ou remover permissão de escrita pode alterar radicalmente o resultado. Em outras palavras: não compramos um “80”; montamos um sistema que talvez consiga se aproximar dele.

A definição de sucesso também muda. Em DeepSWE ou Terminal-Bench, a tarefa passa quando o verificador aceita a saída. Em uma equipe real, uma mudança só está pronta quando respeita arquitetura, segurança, observabilidade, custo de manutenção e revisão de código. Às vezes, uma solução tecnicamente correta ainda é reprovada porque introduz acoplamento, não explica uma decisão ou amplia o risco operacional. Esse trabalho adicional quase nunca aparece no custo por tarefa do leaderboard.

Há ainda o custo das falhas parciais. Um modelo mais barato pode gerar uma primeira versão convincente, mas exigir duas rodadas de correção, uma revisão extensa e testes que alguém precisará depurar. Outro pode custar mais por chamada e, mesmo assim, ser mais econômico se reduzir retrabalho e chegar à PR aprovada com menos intervenções. Por isso, preço por token é uma medida de consumo; custo por mudança aprovada é uma medida de resultado.

Vale criar uma avaliação própria? Link para o cabeçalho

Sim — com uma mudança de nome e de expectativa: para a equipe, isso é uma avaliação interna; para o mercado, não é um novo leaderboard. Ela complementa o benchmark público ao reproduzir a distribuição de tarefas, o contexto e os critérios de aceite que realmente importam para o produto. A recomendação não é apenas intuitiva: o Google orienta que benchmarks gerais não medem uma pilha de IA com dados e critérios próprios, e o estudo de Ailem et al. mostra que alterar a distribuição e os pesos dos casos pode modificar rankings entre modelos. Google Developers e estudo sobre robustez de benchmarks .

Comece pequeno e com casos reais, sem segredos ou dados pessoais: selecione tarefas históricas já resolvidas, classifique-as por tipo e criticidade, e preserve um conjunto de retenção que não será usado para ajustar prompt ou ferramenta. Para cada caso, registre o critério de aceite, o ambiente, as ferramentas, o custo, a latência e o nível de intervenção humana. Sempre que possível, use testes determinísticos; onde a qualidade for subjetiva, aplique uma rubrica e revisão humana. Um avaliador não deve dar nota ao próprio trabalho: separar quem propõe a solução de quem a avalia reduz o incentivo de “jogar para a métrica”. A prática descrita pelo Google reforça essa separação.

A leitura correta não é “meu Sol fez 83, então é melhor do que todo mundo”. É: “neste fluxo, com estas restrições, esta configuração reduziu o custo por mudança aprovada sem piorar a qualidade”. Reexecute essa avaliação quando trocar modelo, prompt, ferramentas, permissões ou critérios de aceite. Assim o benchmark público continua sendo o radar; a avaliação interna passa a ser o painel de instrumentos.

A fronteira custo × inteligência explica o aperto do Terra Link para o cabeçalho

O gráfico abaixo é útil porque coloca desempenho e custo por tarefa no mesmo plano. Cada ponto representa uma combinação de modelo e esforço no Artificial Analysis Intelligence Index, uma avaliação mais ampla que agrega nove testes, incluindo trabalho agêntico, terminal, raciocínio científico e capacidades gerais.

Captura do gráfico Intelligence vs. Cost per Intelligence Index Task do Artificial Analysis, com as curvas de Sol, Terra e Luna por esforço de raciocínio.

Captura do gráfico Intelligence vs. Cost per Intelligence Index Task, do artigo do Artificial Analysis de 13 de julho de 2026. O verde indica o quadrante mais atraente naquele conjunto de tarefas. Fonte .

O que o índice amplo mede — e o que ele não mede Link para o cabeçalho

Na versão 4.1, o Intelligence Index combina nove avaliações e pesa mais tarefas agênticas (34%), seguidas por programação (24%), raciocínio científico (24%) e capacidade geral (18%). É uma suíte apenas de texto em inglês; visão, voz e desempenho multilíngue ficam fora desse número. A metodologia completa informa que o índice agregado teve intervalo de confiança de 95% inferior a ±1% em experimentos repetidos, mas avaliações individuais podem oscilar mais.

Assim, 59 para Sol, 55 para Terra e 51 para Luna são escores de um índice composto, não percentuais de acerto. Eles só devem ser comparados dentro da mesma versão metodológica, porque os pesos e os testes podem mudar. No eixo de custo, o Artificial Analysis usa os tokens reportados pelos provedores e o comportamento de cache observado. Ele mede custo de API por tarefa — não assinatura, infraestrutura, revisão humana, espera de fila ou o prejuízo de uma saída errada em produção.

Em otimização, uma opção está na fronteira de Pareto quando não existe outra que seja simultaneamente melhor e mais barata. Na análise publicada, Sol e Luna aparecem à frente de Terra em todas as combinações de esforço avaliadas: para cada ponto de Terra, há uma opção de Sol ou Luna com mais inteligência pelo mesmo custo, ou inteligência parecida por menor custo. Isso dá suporte quantitativo à hipótese de que o meio pode ficar sem espaço.

Os números resumidos pelo Artificial Analysis tornam a diferença legível:

Sol em max marca aproximadamente 59 no índice, a cerca de US$ 1,04 por tarefa do conjunto;
Terra em max chega a 55, com custo por tarefa cerca de 50% menor que Sol;
Luna em max chega a 51, com custo por tarefa cerca de 80% menor que Sol.

Mas atenção à parte que costuma sumir do recorte. Isso é uma fronteira para aquele índice, aquele preço de API e aquelas configurações de agente. Não é uma demonstração de que Terra seja sempre pior. Um modelo intermediário pode continuar sendo adequado quando sua distribuição de tarefas, suas janelas de contexto, seus limites de concorrência, seu SLA de latência ou sua taxa de aprovação humana forem diferentes dos avaliados.

Em outras palavras: a fronteira é um ótimo filtro para escolher o que testar primeiro. Ela não substitui um teste no seu trabalho.

Onde Luna deixa de ser o barato óbvio Link para o cabeçalho

O preço de Luna é muito atraente para volume, triagem, classificação, extração estruturada e tarefas com critério de aceite forte. O risco é assumir que esse ganho se mantém quando o contexto fica enorme ou a tarefa exige preservar muitos detalhes distantes.

Na tabela oficial, no teste OpenAI MRCR v2 de recuperação de oito informações em contextos de 256 mil a 512 mil tokens, Sol marca 91,5%, Terra 89,6% e Luna 41,3%. Para 512 mil a 1 milhão de tokens, Sol marca 73,8%, Terra 72,5% e Luna continua em 41,3%. Os resultados estão na seção de contexto longo da OpenAI .

MRCR significa multi-round co-reference resolution. Em uma conversa sintética muito longa, o teste insere duas, quatro ou oito solicitações idênticas entre muitos distratores semelhantes e pede a resposta da ocorrência exata — por exemplo, a terceira de várias respostas sobre o mesmo assunto. A métrica compara a sequência recuperada com a resposta correta. O conjunto aberto do MRCR foi criado justamente para tornar a busca menos trivial do que achar uma única “agulha” evidente em um texto enorme.

Isso não quer dizer que Luna “não tenha contexto longo”, nem que Sol automaticamente entenda melhor a arquitetura de qualquer repositório. O teste mede recuperação e desambiguação sob interferência. Ele é um sinal forte para tarefas que precisam preservar muitas referências parecidas em centenas de milhares de tokens; para lotes pequenos, entradas bem segmentadas e validações determinísticas, a equação muda completamente. O próprio dataset recebeu correções de exemplos com número incorreto de agulhas e respostas de referência erradas, outro lembrete de que até avaliações abertas e úteis precisam de manutenção.

Terra não desapareceu: ele muda de pergunta Link para o cabeçalho

O resultado de Pareto obriga uma pergunta melhor do que “Terra é bom?”. A pergunta é: Terra reduz meu custo total em relação a Luna sem exigir revisão extra, e reduz minha espera ou retrabalho em relação a Sol?

Há cenários plausíveis para isso:

automações internas com regras de negócio e formatos variados, em que Luna começa a errar de forma recorrente, mas o problema ainda não pede investigação profunda;
um agente que percorre uma base de código conhecida, com poucas dependências externas, mas precisa de consistência melhor do que a obtida com Luna;
atendimento técnico ou classificação de incidentes em que a qualidade precisa ser estável e o custo de Sol não se justifica;
uma empresa que prefira padronizar uma faixa intermediária por governança, limite de uso ou previsibilidade operacional.

O ponto não é defender Terra por simetria. É evitar que um gráfico de benchmark transforme uma política de roteamento em religião. Se Luna passa nos seus testes, use Luna. Se Sol evita revisões caras, use Sol. Se Terra ganha no seu conjunto de tarefas, ele ganhou a vaga — mesmo que não seja o ponto mais bonito da curva pública.

Matriz de roteamento: quais pares de modelo e esforço devem disputar a tarefa Link para o cabeçalho

Não existe uma escada universal do tipo “Luna, depois Terra, depois Sol”. Tamanho e esforço se combinam, e o benchmark público compara pontos dessa matriz, não uma sequência obrigatória. A tabela abaixo é uma política inicial de experimentação: ela aponta os pares que merecem disputar cada classe de trabalho; a avaliação interna decide o vencedor.

Situação	Pares a comparar primeiro	O que sustenta a indicação
Volume alto e saída objetiva	Luna: médio, alto ou máximo	Luna em máximo custa cerca de US$ 0,21 por tarefa no índice amplo — aproximadamente 80% menos que Sol. Use o menor esforço que passe.
Automação interna ou código rotineiro	Luna, Terra ou Sol; ajuste o esforço	Terra é candidato, não degrau obrigatório. SLA, limites de uso e revisão humana entram aqui.
Agente de programação, terminal e repositório	Luna, Terra ou Sol em máximo	No índice de agentes: Sol 80, Terra 77 e Luna 75. Terra e Luna custam cerca de 60% e 80% menos que Sol por tarefa.
Contexto longo com referências parecidas	Terra ou Sol em alto ou máximo	No MRCR, nessa configuração: Sol 91,5%, Terra 89,6% e Luna 41,3%. Testar mais esforço em Luna pode valer a pena, mas não é seguro presumir que fechará essa lacuna.
Problema crítico e paralelizável	Sol em `max`; depois `ultra`	`ultra` coordena quatro agentes. No Terminal-Bench 2.1, Sol `ultra` chega a 91,9%, contra 88,8% de Sol.

Uma política de partida para Codex e ChatGPT Work Link para o cabeçalho

Esta matriz se refere a Codex e ChatGPT Work, onde Plus e planos superiores podem escolher Sol, Terra e Luna. Ela não vale para a conversa padrão do ChatGPT, na qual Terra e Luna não são selecionáveis. Também não presume que o plano mensal seja equivalente ao custo de API: os valores do CursorBench são custos estimados por tarefa no harness do Cursor. Portanto, use a tabela como política inicial e ajuste-a com a avaliação interna da sua equipe. Disponibilidade oficial do GPT‑5.6 .

Plano	Daily driver	Tarefas difíceis	Alto volume
Plus US$ 20	Sol `medium`	Sol `high`; `xhigh` ou Terra `max` em exceções	Luna `medium`
Pro US$ 100	Sol `medium` ou `high`	Sol `xhigh` ou Terra `max`	Luna `high`
Pro US$ 200	Sol `high`	Sol `max`	Luna `high`

Plus US$ 20. Sol medium é o daily driver porque mantém a capacidade do modelo maior para tarefas cotidianas com alguma ambiguidade, código ou contexto; não se escolhe Terra high por reflexo, pois o índice amplo não o coloca como um degrau de eficiência obrigatório. Sol high é o padrão para tarefas difíceis. xhigh ou Terra max não estão ausentes por incapacidade no Codex/Work: são o escalonamento ocasional quando o custo de errar é alto ou Sol high falha na validação. Assim, eles não consomem a franquia do Plus em toda solicitação difícil. Luna medium fica no alto volume porque combina o menor custo da família com esforço suficiente para saídas bem especificadas, classificações, transformações e tarefas repetitivas.

Pro US$ 100. No dia a dia, Sol medium continua sendo o ponto de partida; Sol high entra quando a revisão humana recorrente mostra que o ganho de raciocínio compensa. Nas tarefas difíceis, Sol xhigh é a escolha para investigação, depuração e requisitos incertos; Terra max é a alternativa a experimentar quando a tarefa é de programação repetível e o seu harness confirma uma qualidade próxima por custo menor. Para volume, Luna high usa parte da franquia extra para reduzir erros sem carregar o preço e a latência de Sol em cada tarefa.

Pro US$ 200. Sol high vira o daily driver porque a franquia maior permite trocar parte do retrabalho por mais raciocínio nas solicitações comuns. Sol max fica reservado para tarefas difíceis com alto custo de erro, contexto confuso ou várias hipóteses técnicas; ultra não aparece porque é uma estratégia de paralelismo, não um padrão para toda tarefa complexa. Luna high permanece no alto volume: o plano maior não é motivo para usar Sol em lote quando Luna já passa nas validações com rapidez e custo menores.

O CursorBench 3.2 sustenta especialmente duas escolhas dessa tabela: Terra max fica muito próximo de Sol xhigh com custo menor; e Luna high entrega quase o mesmo resultado de Luna xhigh por menos. As diferenças pequenas podem não ser estatisticamente significativas, e o benchmark usa tarefas reais, ambíguas e de múltiplos arquivos executadas no ambiente do Cursor. CursorBench 3.2 .

Como os benchmarks levaram a esta matriz Link para o cabeçalho

1. O índice amplo impede tratar Terra como etapa obrigatória. No gráfico independente do Artificial Analysis, Luna e Sol ficam à frente de Terra em todos os esforços avaliados: para qualquer ponto de Terra há uma opção de Luna ou Sol tão inteligente por menor custo, ou mais inteligente pelo mesmo custo. Isso não torna Terra inútil no seu fluxo, mas remove a justificativa para adotá-lo por reflexo. A análise de fronteira de custo × inteligência sustenta a segunda linha da tabela.

2. Em programação, os três em max são alternativas sérias. O mesmo raciocínio não permite descartar Luna e Terra nas tarefas de agente. Eles ficam abaixo de Sol no índice composto, mas a diferença vem acompanhada de grande redução de custo por tarefa: 80 para Sol, 77 para Terra e 75 para Luna, com cerca de 60% e 80% de economia em relação a Sol. Se a taxa de aprovação interna permanecer aceitável, Luna ou Terra em max podem ser a decisão mais econômica. Os resultados detalhados do Artificial Analysis embasam a terceira linha.

3. Há lacunas que não se resolvem apenas com mais esforço. O contraste no MRCR é um alerta para contextos longos; já a melhoria de Sol ultra no Terminal-Bench mostra quando mais computação paralela pode valer a pena. Por isso a matriz sobe de tamanho para recuperação complexa de contexto e reserva ultra para tarefas que se beneficiem de agentes paralelos — não para toda pergunta difícil. Tabela de benchmarks e definição de ultra, OpenAI .

Como aplicar a matriz sem criar uma escada fixa Link para o cabeçalho

defina a saída e a validação antes de chamar o modelo;
selecione dois ou três pares da linha correspondente, em vez de subir tamanho por ritual;
execute as mesmas tarefas com o mesmo harness e compare taxa de aprovação, custo, latência e intervenção humana;
mantenha Terra quando ele vencer a sua avaliação operacional; se não vencer, não o force entre Luna e Sol;
use max quando a melhoria esperada superar explicitamente espera e custo; reserve ultra para trabalho raro, paralelizável e valioso.

Esse processo também evita um falso diagnóstico comum: culpa-se o modelo quando o problema real era uma instrução vaga, uma permissão ausente, um teste inexistente ou contexto demais sem estrutura. Mais raciocínio não conserta requisito mal definido.

Benchmarks são faróis; sua avaliação é o mapa da estrada Link para o cabeçalho

Além da diferença entre benchmark e produção, os próprios instrumentos também falham. A OpenAI argumentou que o SWE‑bench Verified deixou de fornecer sinal confiável por problemas de desenho e contaminação. Em seguida, ao auditar o SWE‑bench Pro — que havia sido proposto como alternativa mais realista —, encontrou, no split público de 731 tarefas, 200 (27,4%) sinalizadas como problemáticas pelo pipeline de análise e 249 (34,1%) na campanha de anotação humana. É uma auditoria publicada pela OpenAI, participante interessada no comparativo; não invalida toda avaliação, mas mostra por que uma única tabela não deve decidir uma compra ou uma política de engenharia. A análise de julho de 2026 explica o método.

Uma equipe precisa de três níveis de evidência:

benchmark público, para saber o que vale colocar na lista curta;
avaliação interna pequena, para verificar se o modelo funciona no seu harness;
telemetria de produção, para medir o custo por entrega aprovada ao longo do tempo.

Monte uma avaliação interna com 10 a 20 tarefas seguras e representativas. Misture bug localizado, refatoração, implementação com critérios de aceite, pesquisa com fontes primárias, extração estruturada e uma tarefa ambígua — esta última revela se o agente pede esclarecimento ou inventa confiança.

Para cada execução, registre modelo, esforço, versão do agente, duração, custo estimado, testes passados, necessidade de correção e motivo de rejeição. Rode mais de uma vez nas tarefas não determinísticas. Depois, compare não só a média, mas a distribuição: um modelo que quase sempre resolve e ocasionalmente custa mais pode ser preferível a outro barato que cria uma longa cauda de revisão.

Uma política simples que resiste ao próximo ranking Link para o cabeçalho

Uma política madura não precisa decorar a tabela inteira. Ela pode ser resumida assim:

Use o modelo mais barato que passe de forma confiável nas validações da tarefa. Suba esforço ou capacidade quando houver evidência de que isso reduz o custo total de entrega.

Essa frase protege contra dois desperdícios. O primeiro é pagar Sol para volume trivial. O segundo é economizar em uma tarefa que volta como incidente, retrabalho ou revisão interminável.

Sol, Terra e Luna não precisam competir pela mesma solicitação. Luna atende o volume bem especificado. Terra é uma hipótese para o meio-termo operacional. Sol entra quando contexto, incerteza e custo de erro aumentam. max entra quando o ganho de raciocínio justifica espera e custo; ultra, quando distribuir o trabalho entre agentes paralelos fizer sentido.

O melhor modelo, no fim, não é o que lidera a captura de tela. É o que resolve a tarefa certa, com evidência suficiente, no menor custo total aceitável.