GPT-6 Sol e Luna: roteamento de modelos para pagar menos por token
Com 20 vezes de diferença de preço entre os dois modelos, escolher o modelo por etapa virou decisão de arquitetura.

Vitor Bruno Dalmaz
Fundador & CEO

Em 22 de setembro de 2026, a OpenAI lançou o GPT-6 em dois tamanhos: o GPT-6 Sol e o GPT-6 Luna. Os dois têm a mesma janela de contexto, mas a diferença de preço entre eles é de 20 vezes. Com uma distância dessas, a pergunta "qual é o melhor modelo?" perde o sentido. A pergunta que importa passa a ser "qual modelo para qual etapa do meu produto?". Este artigo compara os dois modelos e mostra como aplicar roteamento de modelos para não pagar caro em tarefas que não precisam disso.
Sol e Luna, lado a lado
Os números abaixo vêm da documentação da API da OpenAI:
| GPT-6 Sol | GPT-6 Luna | |
|---|---|---|
| Entrada, por milhão de tokens | US$ 2,00 | US$ 0,10 |
| Entrada em cache, por milhão de tokens | US$ 0,20 | US$ 0,01 |
| Saída, por milhão de tokens | US$ 10,00 | US$ 0,50 |
| Janela de contexto | 1,05 milhão de tokens | 1,05 milhão de tokens |
| Saída máxima | 128 mil tokens | 128 mil tokens |
| Posicionamento oficial | Código complexo e fluxos agênticos | Tarefas focadas em alto volume |
Segundo a DataNorth, os dois custam cerca de metade do que custavam os equivalentes da geração GPT-5.6. Desde 28 de setembro, os dois modelos também estão disponíveis no Amazon Bedrock, o que facilita a adoção para quem já opera na AWS.
O que é roteamento de modelos
Roteamento é a prática de encaminhar cada tipo de tarefa para o modelo mais barato que a resolve com a qualidade necessária. Em vez de um único modelo atendendo tudo, o produto passa a ter uma regra de decisão, simples ou sofisticada, que escolhe o modelo por etapa.
A regra mais comum para começar:
- Para o modelo menor: classificar, extrair campos, resumir, normalizar texto, triar tickets, gerar respostas curtas em volume.
- Para o modelo maior: refactor grande, bug difícil, agente de várias etapas, planejamento de tarefas longas, revisão de código complexa.
- Na dúvida: comece pelo menor e suba só onde a qualidade pedir, com dados.
Três formas de implementar
- Roteamento estático por etapa. Cada etapa do pipeline tem o seu modelo fixo. É o mais simples e já captura a maior parte da economia.
- Escalonamento por falha. A tarefa vai primeiro para o modelo menor; se a validação falhar (esquema inválido, teste quebrado, baixa confiança), ela é refeita no maior.
- Classificador de entrada. Um passo leve, que pode rodar no próprio modelo menor, avalia a complexidade do pedido e decide o destino.
Por que isso é decisão de arquitetura, e não de compra
Escolher o modelo por etapa exige conhecer o produto em detalhe: onde está o volume, onde está o risco e onde um erro é barato ou caro. Uma extração errada numa triagem interna custa pouco; uma alteração errada num módulo de pagamento custa muito. Por isso a decisão não cabe no departamento de compras: cabe em quem desenha o fluxo.
Também exige instrumentação. Sem medir a qualidade por etapa e o custo por requisição, o roteamento vira palpite. E o mercado muda rápido: no mesmo dia do GPT-6, a Anthropic lançou o Claude Opus 5.5. Uma arquitetura que isola a escolha do modelo numa camada própria permite trocar de fornecedor ou de versão sem reescrever o produto.
O que fazer na segunda-feira
- Mapeie as chamadas de LLM do seu produto por etapa, com volume mensal e custo atual.
- Marque as etapas de alto volume e baixa complexidade. Essas são as candidatas imediatas ao modelo menor.
- Monte um conjunto de avaliação por etapa, com 50 a 100 exemplos reais e um critério objetivo de acerto.
- Rode as duas opções e compare qualidade e custo. Só mantenha no modelo maior o que perder qualidade de forma relevante no menor.
- Isole a escolha do modelo em configuração, e não espalhada pelo código, para poder ajustar sem novo deploy.
- Acompanhe custo por requisição no mesmo painel em que você acompanha latência e erro.
Times que fazem isso bem tendem a entregar mais com estruturas menores, uma tendência que discutimos em por que os melhores times de engenharia de 2026 vão ter menos devs e entregar mais.
Quem desenha o fluxo
Roteamento de modelos não é uma feature que se compra pronta: é um hábito de engenharia. Ele depende de devs que já trabalham com IA no dia a dia e sabem pesar custo e qualidade em cada decisão. Na VONBZ, os devs de outsourcing trabalham com IA na rotina, com licença do Claude, e chegam ao projeto com esse olhar.
Fontes e Referências
- GPT-6 Sol Model, OpenAI API Docs, setembro/2026, developers.openai.com
- GPT-6 Luna Model, OpenAI API Docs, setembro/2026, developers.openai.com
- AWS Weekly Roundup: GPT-6 Sol and Luna, Claude Opus 5.5 on Amazon Bedrock, Strands harness, and more, AWS News Blog, setembro/2026, aws.amazon.com
- OpenAI launches GPT-6 Sol and Luna, DataNorth, setembro/2026, datanorth.ai
Precisa escalar seu time tech?
A VONBZ monta squads dedicados para acelerar sua operação.
Falar com a VONBZ
Fundador & CEO
Engenheiro de software e empreendedor com mais de 15 anos de experiência em arquitetura de sistemas distribuídos, cloud (AWS) e liderança técnica. CoFundador do Juca e Fundador da VONBZ consultoria de tecnologia que conecta empresas a profissionais de alta performance via hunting, squads dedicados e outsourcing especializado. Tenho a visão de quem constrói sistemas críticos no dia a dia com a de quem lidera operações tech em escala, sempre com foco em eficiência, automação e adoção responsável de IA.
Pronto para escalar seu time tech?
Converse com nossos especialistas e descubra como squads dedicados podem acelerar suas entregas.
Agendar conversa

