A OpenAI publicou um guia da família GPT-6 em 2 de outubro de 2026. O guia reúne a escolha de modelos, instruções, tarefas longas e verificações de implementação. Uma equipa de software tem ainda de encontrar a combinação que passe nos seus próprios testes, respeitando os limites de custo e de tempo de resposta.

As opções atuais da família apresentadas no guia são GPT-6 Astra, GPT-6.1 Sol e GPT-6 Luna. Consultámos a documentação da API e os preços da OpenAI em 3 de outubro. O método de seleção e a folha de cálculo abaixo são propostas; não executámos os modelos nem medimos uma carga de trabalho em produção.

A grande mudança

  • O que mudou: A OpenAI apresenta atualmente a família GPT-6 como um conjunto de opções de acordo com a carga de trabalho, com níveis de esforço de raciocínio ajustáveis e ferramentas para tarefas que abrangem várias etapas. As equipas podem configurar cada parte de um fluxo de trabalho, em vez de usarem uma única configuração de modelo para todas as tarefas.
  • Por que isso importa: Uma equipa pode avaliar se o modelo Luna é adequado a uma etapa de extração focada, se uma etapa de programação ou pesquisa justifica o Sol e em que casos a capacidade adicional do Astra compensa o preço. A resposta depende das tarefas concluídas, da latência e do custo total do fluxo, incluindo a utilização de ferramentas e as tentativas falhadas.
  • O que acompanhar: As execuções longas exigem transferências e verificações explícitas. É possível atualizar as instruções durante uma execução, mas os resultados assíncronos das ferramentas e o trabalho delegado têm de ser conciliados antes de aceitar a resposta final.

Escolha por tarefa e avalie o fluxo inteiro

Comece com um conjunto representativo de tarefas reais e um critério de aceitação para cada uma. A OpenAI recomenda a Responses API para consultar o comportamento atual dos modelos, as chamadas de ferramentas e o trabalho com estado. São necessários um projeto de API, credenciais, acesso à faturação e um modelo disponível para esse projeto. As páginas dos modelos não indicam a existência de um plano gratuito; os limites de pedidos dependem do nível de utilização. Verifique o acesso e os limites efetivos da conta antes de dimensionar a implementação.

Trabalho atribuído ao modelo

Modelo candidato inicial

Esforço inicial

Promova ou altere quando

Extração, classificação ou resumo estruturado recorrente com resposta bem definida

gpt-6-luna

Low para tarefas rotineiras; compare com o nível predefinido Medium

A taxa de erros ou o tempo de revisão exceder o limite da equipa

Programação, pesquisa, uso de ferramentas ou uma etapa de avaliação profissional

gpt-6.1-sol

Nível predefinido Medium; teste High nos casos difíceis

As tarefas representativas falham mesmo com dados de entrada e instruções adequados

A etapa mais difícil de raciocínio ou revisão, quando a qualidade é decisiva

gpt-6-astra

Compare Medium e High nos mesmos casos

Mantenha apenas se o ganho medido justificar o custo e o tempo adicionais

A tabela transforma as orientações da OpenAI sobre os modelos e as páginas dos modelos em pontos de partida para a avaliação. Confirme os IDs dos modelos na API e os níveis de esforço compatíveis: Astra e GPT-6.1 Sol suportam de Low a Max; Luna também suporta None. GPT-6.1 Sol não suporta None nem Minimal. A OpenAI recomenda experimentar Extra High ou Max, quando disponíveis, se High não for suficiente. Compare os níveis de esforço com o mesmo conjunto de tarefas, porque a qualidade, a duração e o consumo de tokens podem variar em conjunto.

No modo de processamento Standard e para prompts com até 272.000 tokens de entrada, as tarifas atuais por milhão de tokens são:

Modelo

Entrada

Entrada em cache

Gravação em cache

Saída

GPT-6 Luna

US$ 0,10

US$ 0,01

US$ 0,125

US$ 0,50

GPT-6.1 Sol

US$ 2,00

US$ 0,10

US$ 2,50

US$ 10,00

GPT-6 Astra

US$ 10,00

US$ 1,00

US$ 12,50

US$ 50,00

Fontes de preços: páginas dos modelos GPT-6 Luna, GPT-6.1 Sol e Astra foram consultadas. Um pedido com mais de 272.000 tokens de entrada tem tarifas mais elevadas para todo o pedido. Outros modos de processamento, o processamento regional, quando disponível, e algumas ferramentas alteram a faturação. As três páginas indicam uma janela de contexto de 1.050.000 tokens e uma saída máxima de 128.000 tokens; uma janela grande é um limite de capacidade, não um motivo para enviar todos os documentos disponíveis.

Estime o custo do percurso completo da tarefa: entrada, entrada em cache, gravações em cache, saída, custos das ferramentas, novas tentativas e qualquer acréscimo por contexto longo. Divida o total pelo número de tarefas aceites segundo o mesmo critério de revisão. Depois, compare a latência na etapa apresentada ao utilizador e no fluxo de trabalho completo. Os preços unitários, por si só, não permitem saber qual é a opção mais barata por resultado bem-sucedido.

Especifique a tarefa e a saída antes de adicionar ferramentas

Defina para cada etapa uma entrada clara, o leitor pretendido ou consumidor seguinte, as fontes e ferramentas permitidas, as restrições e a condição de conclusão. O guia da OpenAI também recomenda indicar quais as decisões que o modelo pode tomar e quais exigem aprovação de uma pessoa. Mantenha coerentes os limites definidos nas instruções do projeto, nas competências e nos prompts.

Para saídas legíveis por máquina, defina antecipadamente os campos e os valores válidos; depois, use o guia de Saídas Estruturadas quando um esquema for adequado à tarefa. Considere a validade do formato apenas uma das verificações: um campo pode respeitar o esquema e, ainda assim, conter um erro factual. Se a saída for uma entrega a uma pessoa, exija o resultado, as evidências utilizadas, as verificações realizadas e as questões por resolver. Compare o resultado com os dados de entrada originais e o critério de aceitação da equipa.

Coloque instruções estáveis e material de referência partilhado antes de alterar os detalhes da tarefa ao avaliar o cache de prompts. A reutilização pode reduzir o custo recorrente das entradas, mas as gravações em cache e o contexto posterior também devem ser incluídos na estimativa. O guia anterior da BIG CHANGE sobre cache de prompts detalha o diagnóstico do cache.

Mantenha o trabalho de longa duração fácil de inspecionar

O guia de 2 de outubro descreve a orientação durante a execução, as chamadas assíncronas de ferramentas e os subagentes em paralelo para trabalho independente. Uma correção enviada através da API WebSocket da Responses fica em fila; não anula ações concluídas nem interrompe uma ferramenta que já esteja em execução. Uma ferramenta assíncrona permite que o trabalho não relacionado prossiga, mas as etapas dependentes têm de aguardar pelo resultado. O suporte multiagente do GPT-6.1 Sol na API Responses está atualmente em beta.

Numa execução com várias etapas, registe o ID da tarefa, o modelo e o nível de esforço escolhidos, a etapa atual, os IDs das chamadas de ferramentas e dos respetivos resultados, as aprovações e as evidências que sustentam a resposta final. Decida antecipadamente o que fazer em caso de tempo limite, falha numa chamada de ferramenta, alteração das instruções ou resultado duplicado. Quando o contexto se expande, a compactação pode reduzir o conteúdo levado adiante; inspecione o que a execução continuada realmente preserva. O modo em segundo plano é outra opção documentada para tarefas que ultrapassam um único pedido. Escolha estes controlos de acordo com a duração do trabalho e as necessidades de recuperação.

O guia da OpenAI recomenda uma API direta ou uma ferramenta ligada quando esta puder executar a etapa, e interação com o ecrã quando for necessária. O guia da BIG CHANGE sobre tarefas de navegação com a Agents API aborda a interface de utilização do computador e o respetivo processo de supervisão.

Uma folha de cálculo para uma decisão que a equipa possa reproduzir

Use os mesmos casos e o mesmo critério de revisão para cada opção. Esta folha de cálculo é um método de avaliação proposto; a BIG CHANGE não introduziu nem testou resultados.

Registo por caso e opção

Elemento a registar

Tarefa e resultado esperado

ID de uma entrada real, requisitos da saída, ferramentas permitidas e critério de aceitação

Configuração

ID do modelo de API, esforço, modo de processamento, versão do prompt e esquema ou contrato de saída

Resultado

Aceite, rejeitado ou a necessitar de revisão; motivo da falha; revisor

Tempo

Duração de ponta a ponta e duração na etapa voltada ao utilizador

Utilização e custos

Tokens de entrada, entrada em cache, gravação em cache e saída; tarifas de ferramentas; novas tentativas; adicional por contexto longo ou processamento regional

Decisão

Tarefas aceites divididas pelo total de tarefas tentadas; custo total dividido pelo número de tarefas aceites; tipos de falha por resolver

Inclua os casos fáceis e difíceis, as entradas malformadas e as etapas de ferramentas interrompidas que surjam no fluxo de trabalho real. Mantenha os casos fixos ao comparar modelos e repita a avaliação depois de alterar os prompts ou as permissões das ferramentas. Analise as falhas por tipo: falta de evidências, campo incorreto, erro de ferramenta, instrução não cumprida ou resposta que exija correção humana. Só mude uma etapa para outro modelo quando o mesmo critério de aceitação demonstrar um ganho útil. Um modelo mais barato que exija mais retrabalho pode custar mais por tarefa aceite; um modelo mais lento pode ser adequado a uma etapa em segundo plano, mas não a uma etapa interativa.

Antes do lançamento, compare os limites efetivos de utilização e de despesa do projeto, os controlos de dados, os tempos limite, o comportamento de novas tentativas, a monitorização e os limites de aprovação humana com a lista de verificação de implementação da OpenAI. Mantenha um processo de revisão por amostragem após o lançamento e repita a avaliação sempre que mudar um alias de modelo, um prompt, uma ferramenta ou a carga de trabalho. Use os dados obtidos nas tarefas para decidir o encaminhamento.

Fontes e leituras complementares