GPT-6 Sol liberado para o time: o que definir antes de sair usando

Modelo novo liberado sem regra combinada é retrabalho marcado na agenda

Fala aí, beleza? A OpenAI anunciou o GPT-6 Sol e o GPT-6 Luna em 22 de setembro de 2026, os dois complementando o GPT-6 Astra na linha da empresa

E o Sol não ficou esperando: já entra em ChatGPT Work e em Codex

Ou seja, alguém do teu time vai encostar nele essa semana, com ou sem política escrita

Então bora resolver a parte chata primeiro: quem acessa, o que pode ser delegado, o que nunca entra no prompt e como registrar o que a IA gerou…

O que a OpenAI lançou e onde o modelo já está disponível

São dois modelos com papéis diferentes, e isso importa MUITO na hora de escrever a regra

O Sol é voltado a trabalho complexo de código e fluxos agênticos

O Luna é indicado para tarefas de alto volume com objetivo claro: resumir documentos, extrair informação, responder pergunta rápida

Na disponibilidade do lançamento, segundo o anúncio oficial e os canais da empresa:

• GPT-6 Sol e Luna entram em ChatGPT Work e Codex para usuários Plus, Pro, Business, Enterprise e Edu
• os dois também estão na API, com os identificadores gpt-6-sol e gpt-6-luna
• usuários Free e Go podem testar o GPT-6 Luna no app desktop
• no anúncio para desenvolvedores, a OpenAI informou que nenhum dos dois estava disponível ainda no Chat, e que a liberação seguiria gradual ao longo do dia

Guarda esse último ponto, ele explica metade dos tickets que tu vai receber depois 🙂

As especificações do Sol na API: janela de contexto de 1.050.000 tokens, saída máxima de 128.000 tokens, corte de conhecimento em 20 de abril de 2026 e suporte a tokens de raciocínio

E tem o número de confiabilidade que a OpenAI declarou: na avaliação interna de factualidade, baseada em conversas reais desidentificadas em que usuários sinalizaram erros, o GPT-6 Sol comete cerca de metade dos erros do antecessor

Metade dos erros continua sendo erro, beleza? Isso muda a expectativa, não a necessidade de revisão

GPT-6 Sol ou GPT-6 Luna: qual entregar para cada tipo de trabalho

Antes de discutir qualidade, olha o custo, porque é ele que vira política de uso

E tem os modificadores por modo de processamento na API, que valem pro cálculo inteiro:

• Batch e Flex custam 50% das taxas Standard
• Fast mode custa 2x as taxas aplicáveis
• tokens de entrada em cache custam 10% da taxa de entrada não cacheada

Leitura prática pra quem vai escrever a política: o preço padrão caiu em relação à geração anterior, mas a faixa de contexto longo do Sol sobe a conta pra US$ 4,00 e US$ 15,00 e se aplica à requisição inteira, não só ao excedente

Ou seja, o prompt gordo não encarece um pedacinho, ele encarece tudo

O que pode ser delegado ao Sol e o que é desperdício de orçamento

O corte mais honesto é o próprio posicionamento da OpenAI, sem invenção:

• Vai pro Sol: trabalho complexo de código e fluxos agênticos, aquilo que precisa de várias etapas, decisão no meio do caminho e ferramenta sendo chamada
• Vai pro Luna: resumir documento, extrair informação estruturada, responder pergunta rápida, tudo que é alto volume com objetivo claro

Mandar triagem de ticket e resumo de reunião pro Sol é queimar orçamento à toa, olha a diferença de US$ 0,10 pra US$ 2,00 na entrada

Agora os dois padrões que costumam estourar a conta na primeira semana

O primeiro é o prompt gigante: alguém joga o repositório inteiro ou vinte PDFs no contexto, passa de 272 mil tokens de entrada e a requisição INTEIRA vai pra faixa longa

O segundo é Fast mode ligado por default, que custa 2x as taxas aplicáveis

Isso vira regra escrita em duas linhas: Fast mode só em caso combinado, e contexto longo só quando a tarefa justifica, com Batch ou Flex (50% das taxas) pra lote que não tem pressa

E antes de soltar o Sol dentro do fluxo de código, vale ter definido o critério de aprovação que o time já usa pra julgar saída de modelo, senão a discussão volta em cada PR

Checklist de governança em 6 decisões antes de abrir o acesso

Nada aqui é fórmula mágica, é só a sequência que evita conversa chata depois

1. Defina quem tem acesso, por papel e por plano

O Sol está em ChatGPT Work e Codex para Plus, Pro, Business, Enterprise e Edu, e na API

Erro comum deste passo: achar que configurar um modelo inicial libera o modelo pra todo mundo. Um default inicial não concede acesso a modelo ou recurso indisponível para o papel do membro, e também não sobrescreve requisitos impostos no workspace

2. Configure o modelo inicial em Workspace settings > Models

Donos e admins definem ali o modelo inicial, o nível de raciocínio, a velocidade, a disponibilidade do Fast Mode e o comportamento de novo chat para Work & Codex

Erro comum deste passo: mexer só aqui e achar que resolveu tudo. O Chat usa um default separado, então mudar o de Work & Codex não muda o modelo inicial de uma conversa comum

3. Escreva os requisitos gerenciados do Codex e distribua por grupos

Requisitos impostos pelo admin (que o usuário não pode sobrescrever) constrangem approval policy, revisor de aprovações, política de revisão automática, sandbox mode, perfis de permissão, modo de busca na web, hooks gerenciados, quais servidores MCP podem ser habilitados e quais fontes de marketplace de plugins são permitidas

Isso vale pro app desktop do ChatGPT, pro Codex CLI e pra extensão de IDE, então é a decisão de maior alcance da lista

Codex Admins publicam políticas requirements.toml pela página Codex Policies, sem precisar distribuir arquivo no dispositivo antes

Erro comum deste passo: mandar o arquivo no Slack pedindo pra galera colocar na máquina. Publica pela página e pronto

4. Combine a precedência com quem vai dar suporte

A ordem é essa: requisitos gerenciados via requirements.toml vencem os defaults iniciais do workspace, que vencem a escolha inicial local do membro

Erro comum deste passo: dois admins configurando camadas diferentes pro mesmo grupo e ninguém sabendo qual ganhou

5. Decida o que NUNCA entra no prompt

Aqui o fato ajuda a calibrar o medo do jurídico: por padrão, a OpenAI não usa dados de ChatGPT Enterprise, Business, Edu, ChatGPT for Healthcare, ChatGPT for Teachers nem da plataforma de API (entradas ou saídas) para treinar ou melhorar modelos

Mas treino é uma coisa, retenção é outra: salvo endpoints e recursos listados na documentação da plataforma, a OpenAI pode reter entradas e saídas da API por até 30 dias para prestar o serviço e identificar abuso, e organizações qualificadas podem configurar o prazo, incluindo zero data retention

Erro comum deste passo: escrever "não colar dado sensível" e parar por aí. Lista o que é dado sensível no teu contexto, com exemplo, senão cada pessoa inventa a própria régua

6. Valide o acesso real de uma pessoa antes do anúncio interno

No Admin Console, em Models > Test, dá pra buscar um membro por nome ou e-mail e inspecionar quais modelos ele acessa e quais configurações explicam esse acesso

O teste não concede acesso nem altera limites, é só inspeção

Erro comum deste passo: anunciar no canal geral e descobrir pelo suporte que metade do time não enxerga o modelo

Três atritos previsíveis na primeira semana (e como prevenir)

Sintoma 1: a pessoa não vê o GPT-6 Sol depois que você mudou o default

Causa provável: o papel dela não tem acesso ao modelo, ou a conta ainda está no rollout, já que a OpenAI avisou que a liberação seria gradual ao longo do dia do anúncio

Prevenção: roda Models > Test com o e-mail da pessoa antes de prometer qualquer coisa

Sintoma 2: mudou o default e a conversa comum continua com outro modelo

Causa: o Chat usa um default separado do de Work & Codex

Prevenção: no comunicado interno, diz explicitamente em qual superfície a mudança vale

Sintoma 3: a configuração da máquina do dev não bate com a do time

Causa: precedência. O requirements.toml vence os defaults do workspace, que vencem a escolha local, então a config pessoal dele simplesmente não ganha

Prevenção: publica a política pela página Codex Policies e avisa quais itens são impostos, não sugeridos

Como registrar o que foi gerado por IA sem virar discussão depois

A parte que ninguém faz no começo e todo mundo precisa no fim: trilha de auditoria

A Compliance Platform está disponível para workspaces ChatGPT Enterprise e Edu, e dá acesso a logs e metadados: conversas, arquivos enviados, configuração e metadados de GPTs do workspace, memórias e usuários

Esses dados conectam em ferramenta de eDiscovery, DLP ou SIEM, então cai no processo que a empresa já tem, sem inventar fluxo novo

Pra liberar, um dono ou admin do workspace precisa criar uma Admin key com escopo do workspace e as permissões necessárias

E se liga nisso: apenas o dono do workspace pode conceder acesso amplo de compliance ou a permissão de Conversation messages

Ou seja, não adianta o time de segurança pedir na sexta à tarde se a pessoa dona da conta está de férias haha

O resto é convenção interna, não recurso do produto: marcar PR e documento como gerado com apoio de IA, dizendo qual modelo e qual foi o papel da pessoa na revisão

Isso não vem pronto em lugar nenhum, é combinado de time mesmo, igual ao hábito de olhar o dashboard do data agent antes de mostrar qualquer número pra liderança

Conclusão

O modelo é novo, a regra é sua

A OpenAI entregou o GPT-6 Sol e o GPT-6 Luna, definiu o posicionamento de cada um, derrubou o preço padrão em relação à geração anterior e deixou as alavancas de admin na mão de quem administra o workspace

O que ela não faz é decidir quem do teu time acessa o quê 🙂

Próximo passo concreto, na ordem: define o acesso por papel, publica a política do Codex pela página Codex Policies e roda o teste em Models > Test antes do anúncio interno

Depois de duas ou três semanas de uso real, volta na conta e olha o que caiu na faixa de contexto longo e o que rodou em Fast mode, porque é ali que o orçamento some

Até o próximo post!