GPT-6 Astra, Sol ou Luna: como escolher por tarefa e custo total

Você talvez já saiba que Luna é o mais barato e Astra o mais capaz, mas isso ainda não responde à pergunta principal: esta tarefa justifica pagar 20× ou 100× mais por tokens? Use esta regra inicial: Luna para trabalho frequente e verificável, Sol para programação complexa e fluxos agênticos comuns, e Astra para tarefas ponta a ponta ambíguas ou caras de errar. Ao final, você saberá por onde começar, quais sinais justificam escalar e como comparar a mesma carga de tokens no OpenAI Standard e no BetterToken.

Comece aqui: Luna para volume verificável, Sol para desenvolvimento complexo, Astra para erros caros

Escolha o ponto de partida pelos limites da tarefa e pelo custo da falha; depois ajuste a rota com seus próprios dados de aceitação.

Modelo	Posicionamento da OpenAI	Bons candidatos iniciais	Quando escalar
gpt-6-luna	Modelo eficiente para tarefas focadas e de alto volume	Pequenas alterações bem delimitadas, extração estruturada, classificação, conversão de formato, testes a partir de uma especificação clara e tarefas em lote com validação determinística	A validação falha repetidamente; é preciso raciocinar entre arquivos; a cadeia de ferramentas cresce; permanece uma ambiguidade crítica
gpt-6-sol	Criado para programação complexa e fluxos agênticos	Funcionalidades em vários arquivos, depuração, revisão de código, tarefas de repositório com várias chamadas de ferramenta e pesquisa ou documentação de complexidade média com limites claros	Um plano errado tem grande impacto; várias tentativas ignoram restrições importantes; são necessários trade-offs entre sistemas ou pesquisa difícil
gpt-6-astra	Modelo mais capaz da OpenAI para o trabalho ponta a ponta mais difícil	Decisões de arquitetura, migrações complexas, análise de incidentes entre sistemas, alterações de código de alto risco e fluxos longos com pesquisa, criação de documentos ou computer use	Astra já é o nível superior desta família; se ainda falhar, reduza o escopo, acrescente evidências ou introduza uma decisão humana em vez de escalar apenas pelo nome

O objetivo não é afirmar que Luna sempre deve executar qualquer tarefa “simples”. O objetivo é encontrar o modelo de menor custo que ultrapasse de forma consistente a barreira de qualidade exigida. Um modelo barato que gera muitas novas tentativas pode sair mais caro no total. Da mesma forma, iniciar toda tarefa bem especificada com Astra pode significar pagar por uma capacidade que o fluxo nunca usa.

A documentação pública ainda não traz uma comparação independente de Astra, Sol e Luna nas mesmas tarefas reais. Use a matriz como ponto de partida e registre aprovação na primeira tentativa, novas tentativas, tempo real até um resultado aprovado e custo total por tarefa aprovada.

Contextos parecidos não tornam os modelos intercambiáveis

Os três modelos têm envelopes de contexto e ferramentas parecidos, então o formato da tarefa, a configuração de raciocínio e o custo da falha importam mais que o tamanho da janela. A OpenAI posiciona Astra para raciocínio complexo, código, computer use, pesquisa e documentos; Sol para programação complexa e fluxos agênticos; e Luna para trabalho focado e de alto volume. Isso ajuda a escolher o primeiro candidato, mas seus resultados devem definir o padrão.

Os três modelos têm janela de contexto de 1.050.000 Token, entrada máxima de 922.000 Token e saída máxima de 128.000 Token. Assim, a capacidade de contexto, por si só, não é o principal diferencial. Na prática, vale observar:

• Astra aceita reasoning.effort em low, medium, high, xhigh e max.
• Sol e Luna também aceitam none, com medium como padrão. Em tarefas bem delimitadas, testar primeiro um nível menor de reasoning ajuda a separar o custo do modelo do custo de raciocínio desnecessário.
• Para fluxos agênticos com muitas ferramentas, prefira a Responses API. Em Sol e Luna, function calling no Chat Completions exige reasoning_effort igual a none.
• Modelo, contexto, reasoning, ferramentas, retrieval e cache afetam o consumo. O tamanho do Prompt, sozinho, não é uma estimativa confiável do custo da tarefa.

Uma comparação justa mantém iguais a interface, o contexto, as ferramentas, o reasoning effort, a saída máxima e os critérios de aprovação. Se várias variáveis mudarem ao mesmo tempo, a diferença observada pode vir da configuração, e não do modelo.

Com os mesmos tokens, compare BetterToken apenas com OpenAI Standard

Com o mesmo uso de tokens, as tarifas do BetterToken verificadas em 2026-09-24 eram 68% das tarifas correspondentes do OpenAI Standard. Isso não o torna a rota mais barata em todos os casos: OpenAI Batch e Flex são menores, enquanto novas tentativas, ferramentas e retrabalho humano determinam o custo completo. A tabela usa USD por um milhão de Token e mostra o nível de contexto de entrada de até 272K.

Model ID	Fonte	Entrada	Leitura de cache	Gravação de cache	Saída
gpt-6-astra	OpenAI Standard	$10.00	$1.00	$12.50	$50.00
gpt-6-astra	BetterToken	$6.80	$0.68	$8.50	$34.00
gpt-6-sol	OpenAI Standard	$2.00	$0.20	$2.50	$10.00
gpt-6-sol	BetterToken	$1.36	$0.136	$1.70	$6.80
gpt-6-luna	OpenAI Standard	$0.10	$0.01	$0.125	$0.50
gpt-6-luna	BetterToken	$0.068	$0.0068	$0.085	$0.34

Quando uma requisição ultrapassa 272K de contexto de entrada, os três GPT-6 passam para a faixa de contexto longo nos dois serviços: entrada, leitura de cache e gravação de cache passam a custar 2 vezes os valores da tabela, enquanto a saída passa a 1,5 vez, e a faixa maior vale para toda a requisição. Por exemplo, gpt-6-sol em contexto longo custa $4.00/$0.40/$5.00/$15.00 no OpenAI Standard e $2.72/$0.272/$3.40/$10.20 no BetterToken para entrada/leitura de cache/gravação de cache/saída.

Os preços são dinâmicos. Antes de colocar em produção, consulte os preços atuais e confirme novamente a disponibilidade do modelo, a moeda e a faixa aplicável. OpenAI Batch e Flex custam atualmente 50% do Standard e ficam abaixo das tarifas do BetterToken neste retrato; se a carga aceitar processamento assíncrono ou de menor prioridade, eles não devem ser misturados com OpenAI Standard na mesma comparação. A tabela também não inclui adicional regional, chamadas de ferramentas, contêineres ou novas tentativas.

O grupo GPT do BetterToken pode ser usado via API, Codex e ferramentas externas que aceitam Base URL personalizado. BetterToken não é um produto da OpenAI, e seu uso de API não equivale a mensagens, capacidade incluída ou credits de uma assinatura do ChatGPT ou Codex.

Já usa GPT-5.5? Preserve a referência antes de trocar

Se seu fluxo com GPT-5.5 é estável, não troque apenas porque surgiu uma família nova. Preserve a referência de qualidade, tempo e custo, e repita as mesmas tarefas em Sol, Luna e Astra. Os preços abaixo são USD por um milhão de Token, verificados em 2026-09-24.

Model ID	Fonte	Contexto	Entrada	Leitura de cache	Saída
gpt-5.5	OpenAI Standard	≤ 272K	$5.00	$0.50	$30.00
gpt-5.5	OpenAI Standard	> 272K	$10.00	$1.00	$45.00
gpt-5.5	BetterToken	Sem faixas	$3.40	$0.34	$20.40

O BetterToken não aplica uma faixa separada de contexto longo ao gpt-5.5; o OpenAI Standard aplica acima de 272K. O preço de escrita de cache não aparece porque a linha pública de preços do GPT-5.5 da OpenAI não fornece esse valor; ele fica em branco em vez de ser estimado.

Também existem duas perguntas diferentes sobre migração. A OpenAI informa que o GPT-5.5 será retirado do ChatGPT, ChatGPT Work e Codex em todos os planos em 2026-10-14, enquanto a API da OpenAI não será afetada. Usuários de planos do Codex precisam de uma rota alternativa antes dessa data. Cargas com API Key não precisam migrar apenas por causa da retirada no lado dos planos. Limites do plano Codex, credits adicionais e uso de API cobrado em USD são sistemas de contabilização distintos.

A métrica útil é o custo por tarefa aprovada

O preço de uma chamada não mostra qual modelo termina o trabalho por menos. Some tentativas falhas, novas tentativas, escritas de cache, ferramentas e retrabalho humano, e divida o total pelos resultados aprovados. O exemplo abaixo primeiro isola as duas formas de cobrança com a mesma combinação de tokens.

Suponha que uma execução aprovada use:

• 120.000 Token de entrada sem cache;
• 100.000 Token de entrada lidos do cache;
• 10.000 Token de saída;
• nenhuma nova gravação de cache nesta execução;
• 220K de contexto total de entrada, portanto na faixa curta.

Pela fórmula “Token ÷ 1.000.000 × tarifa correspondente”, a cobrança do modelo por essa execução é:

Model ID	OpenAI Standard	BetterToken
gpt-6-luna	$0.01800	$0.01224
gpt-6-sol	$0.36000	$0.24480
gpt-6-astra	$1.80000	$1.22400
gpt-5.5	$0.95000	$0.64600

O exemplo compara a cobrança para a mesma combinação de Token; ele não compara qualidade, velocidade ou valor final. Com os mesmos Token e a mesma modalidade de processamento, Sol custa 20 vezes Luna, e Astra custa 5 vezes Sol. Porém, tentativas malsucedidas, saídas maiores, mais ferramentas ou retrabalho humano podem reduzir ou inverter a diferença do custo total.

Uma fórmula mais útil é:

Custo de conclusão = cobrança de Token de todas as tentativas + gravações de cache + ferramentas + novas tentativas malsucedidas e retrabalho.

Divida o total pela quantidade de tarefas aprovadas para obter o custo por resultado aprovado. Essa métrica está muito mais próxima de uma decisão de produção do que o preço de uma única requisição bem-sucedida.

Escolha o primeiro modelo pelo cenário e defina a escalada

A rota inicial pode ser direta: trabalho de baixo risco com validação automática em Luna, desenvolvimento complexo em Sol e tarefas de alto risco ou muita ambiguidade em Astra.

Trabalho verificável e de alto volume: comece com Luna

Se um schema, linter, unit test ou outra regra determinística detecta falhas rapidamente, teste Luna primeiro. Bons candidatos incluem conversão de formato fixo, extração de campos conhecidos, renomeações locais, testes derivados de uma especificação precisa e outros resultados em lote com aceitação automatizada confiável.

Escale para Sol quando a validação falhar, surgir uma dependência não declarada ou for necessária uma decisão entre módulos. Não deixe um modelo menor repetir indefinidamente a mesma direção errada.

Programação multiarquivo e fluxos agênticos: comece com Sol

Quando a tarefa precisa entender vários arquivos, usar ferramentas em sequência ou mudar o plano após a execução, comece com Sol. Exemplos comuns são implementar uma função entre arquivos, diagnosticar falhas de testes, pesquisar o repositório antes de editar e continuar a partir de resultados de ferramentas.

Ainda assim, limite o escopo. Critérios como “analisar, alterar, executar os testes mais relevantes e relatar o que ficou sem solução” costumam ser mais úteis do que simplesmente elevar reasoning.effort. Passe para Astra quando Sol omitir repetidamente restrições arquiteturais em tarefas representativas.

Trabalho ponta a ponta ambíguo ou de alto risco: comece com Astra

Comece com Astra quando o custo de uma resposta errada for claramente maior que o prêmio do modelo. Migrações entre sistemas, incidentes difíceis de produção, limites críticos de segurança, decisões intensivas em pesquisa e fluxos que combinam código, computer use e uma longa cadeia de ferramentas pertencem a esse grupo.

Astra também precisa de validação. Divida o trabalho em pontos de controle para plano, evidências, mudanças e verificação, evitando que o modelo mais potente passe mais tempo seguindo uma premissa errada.

Ainda em dúvida? Compare os modelos nas mesmas tarefas reais

Você não precisa definir um número universal de exemplos. Precisa de um conjunto representativo com casos normais, de limite e de falha, usando as mesmas regras de aceitação para cada modelo.

1. Escolha um conjunto representativo. Inclua mudanças pequenas, desenvolvimento multiarquivo, depuração, uso de ferramentas e trabalho de conhecimento, não apenas demos bem apresentadas.
2. Defina a aceitação antes da execução. Use testes, lint, schemas, uma lista de fatos ou revisão humana. Mudar a regra depois de ver a resposta torna a comparação pouco confiável.
3. Mantenha as outras variáveis constantes. Use o mesmo contexto, ferramentas, API, esforço de raciocínio, saída máxima e ambiente. Trate outro reasoning.effort como experimento separado.
4. Registre cada tentativa. Salve aprovação na primeira tentativa, novas tentativas, tempo real até um resultado aprovado, Token de entrada/cache/saída, chamadas de ferramentas e gasto final.
5. Calcule o custo por resultado aprovado. Inclua tentativas falhas e retrabalho humano, não apenas a última execução correta.
6. Conclua por classe de tarefa. Um modelo pode passar em alterações de código e falhar em pesquisa ou agentes longos. Não esconda isso atrás de um único padrão global.
7. Revise a rota depois que cada classe acumular várias execuções reais. Se um nível superior não melhorar de forma repetível a aceitação ou o custo total, volte ao modelo menor ou mantenha o fluxo existente com GPT-5.5 API.

Compare pelo menos aprovação na primeira tentativa, aprovação final, custo total por resultado aprovado e mediana mais um percentil alto do tempo. Um modelo só deve virar padrão quando vence de forma consistente no seu limiar real de qualidade.

Escale por falhas repetidas e risco, não pelo prestígio do modelo

A escalada deve ser acionada por sinais observáveis de falha, não pela suposição de que um modelo mais caro será automaticamente melhor.

• Luna → Sol: a validação determinística falha repetidamente; a tarefa exige raciocínio entre arquivos ou módulos; os resultados das ferramentas mudam materialmente o plano; ou uma ambiguidade crítica permanece depois de esclarecer as condições.
• Sol → Astra: planos repetidos omitem restrições essenciais; um erro afeta produção, segurança ou uma migração importante; ou a tarefa combina raciocínio difícil, pesquisa, documentação e execução.
• Astra → reduzir a tarefa: se Astra ainda não passa na aceitação, adicione evidências, divida o fluxo ou peça uma decisão humana em vez de aumentar indefinidamente contexto e raciocínio.
• Modelo novo → voltar ao GPT-5.5: em fluxos de API, mantenha GPT-5.5 enquanto ele atender qualidade, latência e manutenção. Um nome mais novo não é motivo suficiente para migrar.

Use Luna → Sol → Astra como cadeia inicial: verificador confiável significa Luna, desenvolvimento complexo significa Sol e alto risco significa Astra. Mude a regra apenas quando seus dados de aceitação, novas tentativas, tempo e custo por resultado aprovado mostrarem que outra rota é melhor.