GPT-5.6 Luna ficou 80% mais barato: quando vale trocar Terra ou Sol?

O corte de 80% no preço do GPT-5.6 Luna muda a ordem de grandeza da comparação. Com os valores vigentes em 4 de agosto de 2026, uma chamada com a mesma quantidade de tokens custa no Luna um décimo do Terra e um vigésimo quinto do Sol. Isso significa que o Luna pode errar ou exigir retrabalho com mais frequência e ainda conservar vantagem financeira.

Essa vantagem, porém, não torna o modelo automaticamente melhor. O número relevante para uma operação real não é o preço por milhão de tokens, mas o custo por tarefa concluída e aprovada — incluindo raciocínio interno, novas tentativas, revisão humana, latência e impacto dos erros.

A conclusão prática é direta: Luna deve ser o primeiro candidato em tarefas bem definidas e de grande volume; Terra continua sendo a referência para cargas mistas; e Sol deve ser reservado às tarefas nas quais um ganho de qualidade ou confiabilidade compensa um custo muito maior. A decisão final precisa ser tomada com um teste do próprio fluxo, e não apenas com benchmarks gerais.

O que mudou em 30 de julho de 2026

O changelog oficial da API informa que, a partir de 30 de julho de 2026, o GPT-5.6 Luna passou a custar 80% menos e o Terra, 20% menos. O Sol não teve redução anunciada nessa atualização. Na mesma data, a OpenAI substituiu a denominação Priority Processing por Fast mode.

A página de lançamento do GPT-5.6, publicada em 9 de julho, registra os preços anteriores: US$ 1 por milhão de tokens de entrada e US$ 6 de saída no Luna; US$ 2,50 e US$ 15 no Terra; e US$ 5 e US$ 30 no Sol. A própria página recebeu uma nota sobre a redução em 30 de julho, embora a tabela textual de lançamento ainda mostre os valores antigos.

Os preços atuais para contexto curto são:

Os valores são cobrados em dólares e não incluem conversão cambial, impostos, ferramentas pagas ou eventuais acréscimos de processamento regional. Prompts com mais de 272 mil tokens de entrada passam a usar preços maiores para toda a requisição.

O corte tornou o Luna dez vezes mais barato que o Terra

A diferença não depende de a tarefa usar mais entrada ou mais saída. As duas tarifas do Luna correspondem a 10% das tarifas equivalentes do Terra. Em comparação com o Sol, correspondem a 4%.

Mantendo igual a quantidade de tokens por tentativa:

• uma chamada do Terra custa o equivalente a dez chamadas do Luna;
• uma chamada do Sol custa o equivalente a 25 chamadas do Luna;
• uma chamada do Sol custa o equivalente a duas chamadas e meia do Terra.

Isso produz um ponto de equilíbrio incomum. Se o Terra resolver uma tarefa na primeira tentativa, o Luna poderia consumir até dez tentativas equivalentes antes de igualar apenas o gasto da API. Contra o Sol, seriam até 25 tentativas.

Essa conta não autoriza aceitar 24 respostas ruins. Cada falha pode ocupar um revisor, atrasar o usuário ou produzir um erro operacional. Ela mostra apenas que, depois do corte, o preço dos tokens deixou de ser o principal obstáculo à adoção do Luna. O obstáculo real passa a ser o custo do retrabalho.

Preço não é qualidade: os resultados variam por tarefa

Os benchmarks publicados pela OpenAI não apontam uma distância uniforme entre os três modelos. Em algumas avaliações, Terra e Luna ficam muito próximos; em outras, o Luna perde uma parcela relevante de desempenho.

No Agents’ Last Exam e no SWE-Bench Pro, o Luna se aproxima do Terra. Já no Big Finance Bench, a diferença é de 15 pontos percentuais. Isso reforça que “modelo menor” não é uma classificação suficiente: o desempenho depende do domínio, da complexidade, da necessidade de ferramentas e do critério usado para considerar a tarefa concluída.

Esses números foram divulgados pelo próprio fornecedor e não substituem uma avaliação independente. Tampouco medem diretamente atendimento em português brasileiro, leitura de documentos públicos nacionais ou transformação de dados com formatos locais.

Três tarefas brasileiras para uma comparação reproduzível

Uma avaliação útil deve empregar entradas parecidas com as encontradas em produção e critérios binários de aprovação. O protocolo abaixo cobre três perfis de carga: classificação curta, síntese documental e transformação estruturada.

Tarefa 1: triagem de atendimento de comércio eletrônico

Monte 30 chamados sintéticos em português brasileiro envolvendo entrega, Pix, troca, cancelamento, endereço, prazo e produto avariado. Não use dados pessoais reais.

A resposta deve retornar:

• categoria pertencente a uma lista fechada;
• prioridade baixa, média ou alta;
• ação seguinte;
• justificativa curta;
• saída válida no esquema definido.

Aprovação: todos os campos válidos, categoria correta segundo o gabarito e nenhuma ação contrária à política apresentada no prompt.

Perfil de referência para cálculo: 1.500 tokens de entrada e 500 tokens totais de saída por tentativa.

Tarefa 2: síntese auditável de edital municipal

Selecione 30 trechos ou documentos públicos congelados para a rodada. Cada caso deve exigir a extração de datas, requisitos, impedimentos, documentos necessários e valores, sempre com indicação da página ou seção de origem.

Aprovação: todos os itens obrigatórios presentes, datas corretas, referências verificáveis e nenhuma afirmação que não esteja sustentada pelo documento.

Perfil de referência para cálculo: 8.000 tokens de entrada e 1.200 tokens totais de saída por tentativa.

Tarefa 3: transformação de pedidos em dados estruturados

Forneça 30 arquivos sintéticos com datas no formato brasileiro, valores com vírgula decimal, endereços incompletos, campos opcionais e identificadores mascarados. O modelo deve normalizar os registros conforme um esquema fixo e apontar inconsistências sem inventar valores.

Aprovação: JSON válido, todos os testes automatizados aprovados e ausência de dados fabricados.

Perfil de referência para cálculo: 4.000 tokens de entrada e 2.000 tokens totais de saída por tentativa.

Quanto cada tarefa custaria antes do retrabalho

A tabela abaixo aplica os preços vigentes aos perfis de tokens definidos. Os números são cenários matemáticos por mil tentativas, não medições de uso real. A saída total deve incluir os tokens visíveis e os tokens internos de raciocínio cobrados como saída.

A proporcionalidade permanece igual nos três casos: Terra custa dez vezes o Luna e Sol custa 25 vezes o Luna. O resultado real pode mudar se um modelo usar mais tokens de raciocínio, produzir respostas mais longas ou exigir novas chamadas.

Os tokens de raciocínio não ficam visíveis como texto, mas aparecem nos detalhes de uso e são cobrados como tokens de saída. Eles já fazem parte do total de saída e não devem ser somados uma segunda vez ao calcular a fatura.

A planilha que evita uma comparação enganosa

Cada chamada deve ocupar uma linha. No mínimo, registre estas colunas:

O alias gpt-5.6 direciona a chamada para o GPT-5.6 Sol. Portanto, usá-lo no lugar do identificador completo pode transformar acidentalmente um teste do Luna ou Terra em tráfego do modelo mais caro.

Como executar o teste

Use 30 casos por tarefa e por modelo, totalizando 270 chamadas na rodada inicial. Misture a ordem dos modelos para reduzir o efeito de alterações momentâneas de carga.

Mantenha constantes:

• o conteúdo e a versão do prompt;
• o endpoint;
• o limite máximo de saída por tarefa;
• o esforço de raciocínio;
• o conjunto de ferramentas disponível;
• o service tier;
• as regras de aprovação;
• a região de processamento;
• o número máximo de novas tentativas.

Comece com processamento Standard e um mesmo nível de raciocínio, como medium, para os três modelos. Depois de identificar o vencedor por tarefa, faça uma segunda rodada reduzindo o esforço em um nível. A orientação oficial de migração recomenda comparar os modelos com configurações representativas do fluxo real, incluindo a possibilidade de obter qualidade semelhante com menos raciocínio.

Na rodada principal, evite que diferenças de cache distorçam o resultado. Em GPT-5.6, escritas em cache custam 1,25 vez a tarifa normal de entrada, enquanto leituras recebem desconto. O teste pode desabilitar a escrita implícita ou medir separadamente uma segunda rodada com prefixos reutilizados.

A correção deve ser feita sem revelar ao avaliador qual modelo produziu a resposta. Critérios de aprovação ou reprovação tendem a ser mais confiáveis que notas vagas, e qualquer avaliador automatizado deve ser comparado com rótulos humanos antes de substituir a revisão.

As quatro métricas que decidem a migração

Taxa de conclusão na primeira tentativa

É o percentual de casos aprovados sem correção ou nova chamada.

Essa métrica mostra quanto trabalho o modelo entrega sem intervenção, mas não captura a possibilidade de recuperação barata.

Taxa de conclusão dentro do orçamento

Defina previamente um limite, como três tentativas ou determinado valor por caso. Conte quantas tarefas foram aprovadas antes de atingir esse limite.

Um modelo pode apresentar resultado inicial inferior e ainda vencer porque corrige seus próprios erros com baixo custo.

Custo por conclusão

Use:

Custo por conclusão = gasto total da API ÷ número de tarefas aprovadas

Para uma avaliação operacional mais completa:

Custo total por conclusão = API + revisão humana + infraestrutura + impacto esperado das falhas

É essa segunda conta que impede uma migração falsa. Economizar centavos em tokens não compensa transferir horas de conferência para a equipe.

Latência p50 e p95

A mediana mostra a experiência típica. O percentil 95 revela o comportamento nos casos mais lentos.

Registre separadamente o tempo até o primeiro token e o tempo até a conclusão. A documentação da OpenAI observa que a maior parte da latência costuma estar na geração da saída, motivo pelo qual respostas mais longas ou com mais raciocínio podem demorar mais.

O ponto de equilíbrio entre Luna, Terra e Sol

Quando a composição de tokens é semelhante, o custo esperado de uma tarefa pode ser simplificado como:

Custo esperado por sucesso = custo por tentativa ÷ probabilidade de sucesso

Disso surgem três limites matemáticos:

• Luna é mais barato que Terra se sua taxa de sucesso for superior a 10% da taxa do Terra;
• Luna é mais barato que Sol se sua taxa de sucesso superar 4% da taxa do Sol;
• Terra é mais barato que Sol se sua taxa de sucesso for superior a 40% da taxa do Sol.

Se o Terra concluir 90% dos casos, por exemplo, o Luna precisaria superar apenas 9% para conservar vantagem no gasto bruto da API. Esse resultado parece permissivo porque ainda não inclui o trabalho humano nem o prejuízo associado a uma resposta incorreta.

Na prática, a migração deve exigir que o modelo mais barato permaneça dentro de uma tolerância de qualidade, latência e revisão definida pela equipe. Uma operação com aprovação humana obrigatória pode tolerar mais erros baratos. Uma automação que publica, transfere valores ou altera sistemas precisa de limites muito mais rigorosos.

Quando escolher o GPT-5.6 Luna

O Luna deve ser o primeiro modelo testado quando a tarefa tiver:

• resposta curta e formato rígido;
• critérios objetivos de aprovação;
• alto volume;
• baixo custo de falha;
• possibilidade de validação automática;
• prompt e contexto bem delimitados;
• recuperação simples por uma segunda tentativa.

Classificação, extração, roteamento, normalização de dados e respostas baseadas em políticas fechadas são candidatas naturais. A orientação oficial descreve o Luna como o modelo da família otimizado para cargas sensíveis a custo e grande volume.

Quando o Terra continua fazendo sentido

Terra é o controle mais importante do teste porque representa o equilíbrio entre custo e capacidade. Ele custa dez vezes mais que o Luna, mas ainda custa 60% menos que o Sol.

Terra tende a justificar o prêmio quando:

• o Luna perde critérios importantes de forma recorrente;
• o conteúdo exige síntese de diversas instruções;
• há uso moderado de ferramentas;
• a resposta precisa combinar texto e estrutura;
• o retrabalho humano do Luna supera a economia da API;
• o fluxo mistura casos simples e difíceis sem um roteador confiável.

Uma arquitetura eficiente pode encaminhar a maior parte do volume ao Luna e reservar o Terra para casos reprovados por validadores ou identificados como mais complexos.

Quando pagar pelo Sol

O Sol custa 25 vezes o Luna e duas vezes e meia o Terra na mesma composição de tokens. Esse prêmio só deve ser aceito quando a capacidade adicional produzir valor mensurável.

Use-o como candidato para:

• tarefas complexas de várias etapas;
• programação e depuração de maior impacto;
• análise com diversas ferramentas;
• decisões difíceis de recuperar;
• documentos que exigem consistência global;
• casos nos quais uma falha custa muito mais que a chamada;
• avaliação ou revisão dos resultados de modelos menores.

A página de modelos posiciona o Sol como a opção de fronteira para trabalho profissional complexo, enquanto a documentação recomenda os modelos menores para reduzir custo e latência.

O Fast mode deve ser testado depois do modelo

O Fast mode custa o dobro do processamento Standard. Para contexto curto, os preços de entrada e saída passam a US$ 0,40 e US$ 2,40 no Luna; US$ 4 e US$ 24 no Terra; e US$ 10 e US$ 60 no Sol.

A OpenAI afirma que, no GPT-5.6 Sol, o modo pode chegar a 2,5 vezes a velocidade do processamento Standard e oferecer latência mais consistente. Esse número é um limite anunciado pelo fornecedor, não uma garantia para toda requisição nem uma promessa equivalente para Terra e Luna.

A sequência correta é:

1. escolher o modelo pela relação entre qualidade e custo;
2. medir a latência Standard;
3. definir o p95 máximo aceitável;
4. repetir os mesmos casos no Fast mode;
5. pagar o dobro somente se o ganho observado justificar o valor.

O serviço também pode rebaixar temporariamente requisições para a velocidade Standard quando o tráfego cresce de forma muito rápida. Nesses casos, a resposta informa o tier efetivamente usado e a cobrança segue a tarifa Standard. Por isso, o benchmark precisa registrar o service_tier retornado, não apenas o solicitado.

Veredito: não troque um modelo, distribua as tarefas

Depois do corte, o Luna deve entrar em praticamente todo teste de carga definida e alto volume. A diferença de preço é grande demais para ser ignorada, especialmente quando há validação automática e novas tentativas baratas.

Isso não significa substituir Terra ou Sol em bloco. A estratégia mais eficiente tende a ser um roteamento por tarefa:

• Luna para volume, estrutura e baixo risco;
• Terra para cargas mistas e complexidade intermediária;
• Sol para exceções difíceis, revisão de alto valor e falhas caras;
• Fast mode apenas onde a latência medida viola um objetivo de serviço.

“80% mais barato” responde quanto custa uma tentativa. A matriz responde o que realmente importa: quantas tentativas, quantos minutos e quantos dólares são necessários para entregar uma tarefa aprovada.

Salve esta matriz e repita a rodada sempre que preços, versões ou configurações mudarem. Assine a newsletter para receber a próxima rechecagem de valores e critérios. Eventuais links comerciais ou de afiliados devem ser identificados de forma explícita.