IA

    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

    Vitor Bruno Dalmaz

    Fundador & CEO

    07 de out. de 20265 min de leitura
    Compartilhar:
    Capa do artigo "GPT-6 Sol e Luna: roteamento de modelos para pagar menos por token": Composição abstrata em 3D de um fluxo de partículas luminosas se dividindo em dois caminhos, em tons de azul-marinho e ciano da VONBZ.

    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 SolGPT-6 Luna
    Entrada, por milhão de tokensUS$ 2,00US$ 0,10
    Entrada em cache, por milhão de tokensUS$ 0,20US$ 0,01
    Saída, por milhão de tokensUS$ 10,00US$ 0,50
    Janela de contexto1,05 milhão de tokens1,05 milhão de tokens
    Saída máxima128 mil tokens128 mil tokens
    Posicionamento oficialCódigo complexo e fluxos agênticosTarefas 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.

    📊 A conta que importa: US$ 10 contra US$ 0,50 na saída é uma razão de 20 para 1. Um fluxo que manda tudo para o modelo maior paga até 20 vezes mais por token em tarefas que o modelo menor resolveria.

    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

    1. 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.
    2. 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.
    3. Classificador de entrada. Um passo leve, que pode rodar no próprio modelo menor, avalia a complexidade do pedido e decide o destino.
    💡 Dica: a mesma lógica vale dentro de um mesmo modelo. Os dois modelos da OpenAI aceitam níveis de esforço de raciocínio, de none a max, com medium como padrão. Ajustar o esforço por etapa é outra alavanca de custo, e a Anthropic adotou a mesma lógica no parâmetro effort do Claude.

    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

    1. Mapeie as chamadas de LLM do seu produto por etapa, com volume mensal e custo atual.
    2. Marque as etapas de alto volume e baixa complexidade. Essas são as candidatas imediatas ao modelo menor.
    3. Monte um conjunto de avaliação por etapa, com 50 a 100 exemplos reais e um critério objetivo de acerto.
    4. Rode as duas opções e compare qualidade e custo. Só mantenha no modelo maior o que perder qualidade de forma relevante no menor.
    5. Isole a escolha do modelo em configuração, e não espalhada pelo código, para poder ajustar sem novo deploy.
    6. 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.

    🚀 Próximo passo: quer reforçar o time com devs que já trabalham com IA e chegam acostumados a pesar custo e qualidade em cada etapa? Converse com a VONBZ.

    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
    Vitor Bruno Dalmaz
    Vitor Bruno Dalmaz

    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