{"id":755,"date":"2026-10-02T18:33:13","date_gmt":"2026-10-02T21:33:13","guid":{"rendered":"https:\/\/yellowkode.com\/blog\/guia-tecnico-familia-gpt-6-astra-sol-luna\/"},"modified":"2026-10-02T18:33:13","modified_gmt":"2026-10-02T21:33:13","slug":"guia-tecnico-familia-gpt-6-astra-sol-luna","status":"publish","type":"post","link":"https:\/\/yellowkode.com\/blog\/guia-tecnico-familia-gpt-6-astra-sol-luna\/","title":{"rendered":"Guia T\u00e9cnico da Fam\u00edlia GPT-6: Astra, Sol e Luna e o Ajuste de Reasoning Effort"},"content":{"rendered":"

No dia 2 de outubro de 2026, a OpenAI publicou A model guide for the GPT-6 family<\/em>, um guia pr\u00e1tico voltado para quem est\u00e1 construindo em cima da fam\u00edlia GPT-6. O documento explica como escolher um modelo GPT-6, dar instru\u00e7\u00f5es efetivas, administrar trabalho de longa dura\u00e7\u00e3o e preparar para produ\u00e7\u00e3o. \u00c9 menos an\u00fancio de modelo e mais manual de uso: ensina a decidir entre Astra, 6.1 Sol e Luna, a ajustar o reasoning effort<\/em> por tarefa, e a coordenar ferramentas.<\/p>\n

Este artigo passa pelo mecanismo descrito no guia e na documenta\u00e7\u00e3o da API, mostra onde a coisa quebra e aponta um caminho para voc\u00ea testar.<\/p>\n

Os tr\u00eas modelos da fam\u00edlia e o que diferencia um do outro<\/h2>\n

A fam\u00edlia GPT-6, hoje, tem tr\u00eas cartas na mesa, com pre\u00e7os e posicionamentos distintos. GPT-6 Astra \u00e9 o modelo mais inteligente para melhores resultados, a 10 d\u00f3lares de input, 50 de output e 1 d\u00f3lar de input em cache; GPT-6.1 Sol tem intelig\u00eancia pr\u00f3xima da Astra por um quinto do pre\u00e7o, a 2 d\u00f3lares de input, 10 de output e 0,10 de cache; GPT-6 Luna \u00e9 r\u00e1pido e eficiente para trabalho di\u00e1rio em escala, a 0,10 de input, 0,50 de output e 0,01 de cache (todos por milh\u00e3o de tokens).<\/p>\n

O posicionamento de cada um, segundo o pr\u00f3prio guia e a documenta\u00e7\u00e3o de prompting:<\/p>\n

    \n
  • Astra<\/strong>: reservado para o trabalho de racioc\u00ednio mais dif\u00edcil, que exige intelig\u00eancia m\u00e1xima. \u00c9 o modelo que voc\u00ea paga para errar menos.<\/li>\n
  • 6.1 Sol<\/strong>: projetado para coding complexo, pesquisa e tarefas de uso de computador. \u00c9 o cavalo de trabalho para agentes.<\/li>\n
  • Luna<\/strong>: foca em tarefas repetidas e em escala, como extrair campos de notas fiscais ou classificar requests.<\/li>\n<\/ul>\n

    Vale notar: todos os tr\u00eas compartilham uma janela de contexto de 1.050.000 tokens, at\u00e9 128.000 tokens de output, suporte a imagens, Structured Outputs, computer use, code tools, MCP, web search, file search e outras ferramentas hospedadas. Trocar entre eles muda custo e capacidade de racioc\u00ednio, n\u00e3o o formato de entrada.<\/p>\n

    O que \u00e9 reasoning effort e como ele muda o comportamento do modelo<\/h2>\n

    Antes de entrar no mecanismo, uma analogia \u00fatil. Imagine que voc\u00ea pede para algu\u00e9m revisar um contrato. Voc\u00ea pode dizer “d\u00e1 uma olhada r\u00e1pida” ou “senta e l\u00ea linha por linha”. O conte\u00fado que voc\u00ea entrega \u00e9 o mesmo, mas o tempo gasto e a profundidade da an\u00e1lise mudam. Reasoning effort<\/em> \u00e9 esse controle, aplicado ao modelo, separado do que voc\u00ea escreve no prompt. A analogia quebra num ponto importante: a pessoa decide sozinha quando parar, o modelo n\u00e3o. Voc\u00ea precisa escolher o n\u00edvel antes.<\/p>\n

    No mecanismo real, o par\u00e2metro reasoning_effort controla quanto o modelo pensa antes de responder, e os valores suportados variam por modelo, incluindo none, minimal, low, medium, high, xhigh e max. Nem todo modelo aceita todos os valores:<\/p>\n

      \n
    • GPT-6 Astra n\u00e3o suporta reasoning effort none; definir reasoning.effort (Responses) ou reasoning_effort (Chat Completions) como none retorna HTTP 400.<\/li>\n
    • GPT-6.1 Sol n\u00e3o suporta none nem minimal e tem padr\u00e3o medium.<\/li>\n
    • GPT-6 Sol e GPT-6 Luna suportam none.<\/li>\n<\/ul>\n

      Existe tamb\u00e9m uma distin\u00e7\u00e3o que o guia faz quest\u00e3o de separar: modo e esfor\u00e7o. Reasoning mode e reasoning effort s\u00e3o independentes. O modo seleciona execu\u00e7\u00e3o standard ou pro, enquanto reasoning.effort controla quanto racioc\u00ednio o modelo aplica dentro daquele modo. Em outras palavras, modo \u00e9 o onde<\/em> o modelo roda, esfor\u00e7o \u00e9 o quanto<\/em> ele pensa.<\/p>\n

      Como isso aparece em c\u00f3digo<\/h3>\n
      const response = await client.responses.create({\n model: \"gpt-6-astra\",\n reasoning: {\n effort: \"high\"\n },\n input: prompt\n});\n<\/code><\/pre>\n
      Esse \u00e9 o padr\u00e3o da Responses API. A documenta\u00e7\u00e3o recomenda usar Responses: Astra e 6.1 Sol suportam Chat Completions, mas tool calling exige Responses. Se voc\u00ea est\u00e1 construindo agente, essa decis\u00e3o \u00e9 feita por voc\u00ea: Responses ou nada.<\/p>\n
      Caching, compaction e o que acontece com contexto longo<\/h3>\n
      Dois mecanismos ajudam a manter custo e coer\u00eancia sob controle em sess\u00f5es longas. Para rodar efetivamente em produ\u00e7\u00e3o, use caching e compaction para administrar contexto e custo. Caching aproveita o prefixo repetido entre chamadas (da\u00ed os pre\u00e7os de “cached input”, bem menores). Compaction comprime conversas longas para o modelo n\u00e3o precisar reconstruir contexto do zero a cada volta.<\/p>\n
      Um detalhe importante quando o agente muda de esfor\u00e7o durante uma sess\u00e3o: se sua aplica\u00e7\u00e3o muda effort entre respostas, use itens configuration_update em requests padr\u00e3o single-agent, e mantenha o reasoning.effort de n\u00edvel de request inalterado para preservar o prefixo do prompt para caching. Mudar effort no lugar errado quebra o cache e voc\u00ea paga pre\u00e7o cheio.<\/p>\n
      O que isso significa na pr\u00e1tica: montando um roteador por tarefa<\/h2>\n
      A pergunta operacional que esse guia tenta responder n\u00e3o \u00e9 “qual \u00e9 o melhor modelo”. \u00c9 “qual modelo para qual tarefa, a que esfor\u00e7o, com que fallback”. Um roteador \u00fatil, baseado no que o guia e documenta\u00e7\u00f5es relacionadas sugerem:<\/p>\n
        \n
      • Luna, effort low ou none<\/strong>: classifica\u00e7\u00e3o de ticket, extra\u00e7\u00e3o de campos de documento, normaliza\u00e7\u00e3o de registros. Tarefa estreita, crit\u00e9rio de sucesso claro, volume alto.<\/li>\n
      • 6.1 Sol, effort medium<\/strong>: tarefa com v\u00e1rias etapas dependentes, uso de ferramenta, contexto amb\u00edguo. \u00c9 o default razo\u00e1vel.<\/li>\n
      • Astra, effort high ou xhigh<\/strong>: debug dif\u00edcil, planejamento complexo, trabalho onde errar sai caro.<\/li>\n<\/ul>\n
        Quando eu constru\u00ed uma extens\u00e3o de navegador que escrevia direto num CRM, aprendi na marra que escolher o modelo \u00e9 s\u00f3 metade do problema. Na falha o sistema tenta de novo com prompt corretivo, depois cai para rascunho sinalizado para revis\u00e3o humana, nunca escrita parcial. Chamada de API bem sucedida n\u00e3o diz nada sobre o payload fazer sentido. Vale para qualquer modelo da fam\u00edlia: um Astra com reasoning max ainda pode retornar JSON v\u00e1lido com conte\u00fado errado. O que te protege \u00e9 a valida\u00e7\u00e3o depois da chamada, n\u00e3o o pre\u00e7o do token antes.<\/p>\n
        Um esqueleto de router<\/h3>\n
        function pickModel(task) {\n if (task.type === \"classify\" || task.type === \"extract\")\n return { model: \"gpt-6-luna\", effort: \"low\" };\n if (task.type === \"agent_step\" || task.type === \"code_edit\")\n return { model: \"gpt-6.1-sol\", effort: \"medium\" };\n if (task.type === \"deep_debug\" || task.type === \"plan\")\n return { model: \"gpt-6-astra\", effort: \"high\" };\n return { model: \"gpt-6.1-sol\", effort: \"medium\" }; \/\/ default\n}\n<\/code><\/pre>\n
        Isso \u00e9 um ponto de partida, n\u00e3o uma receita. O ajuste real sai de rodar o mesmo conjunto de tarefas de produ\u00e7\u00e3o pelos tr\u00eas e medir.<\/p>\n
        Onde isso quebra<\/h2>\n
        Alguns pontos em que vale ter cuidado:<\/p>\n
          \n
        • Chat Completions com tool calling<\/strong>: Chat Completions n\u00e3o suporta function calling com GPT-6 Astra ou GPT-6.1 Sol. Se seu c\u00f3digo legado chama Chat Completions e espera function calling, ele n\u00e3o vai funcionar com os modelos de topo. Migre para Responses.<\/li>\n
        • Par\u00e2metros antigos de amostragem<\/strong>: o guia de migra\u00e7\u00e3o da OpenAI diz que quando reasoning effort n\u00e3o \u00e9 none, par\u00e2metros como temperature, top_p e top_logprobs devem ser removidos. Como 6.1 Sol n\u00e3o suporta none, voc\u00ea n\u00e3o deve passar esses controles.<\/li>\n
        • Mudar effort errado quebra cache<\/strong>: j\u00e1 comentado acima, mas repito porque custa dinheiro.<\/li>\n
        • Lat\u00eancia de reasoning alto<\/strong>: effort high, xhigh e max geram muito token de reasoning invis\u00edvel antes da resposta. Em UX interativo, isso \u00e9 percebido como lentid\u00e3o. Para batch e async, n\u00e3o importa.<\/li>\n
        • Validar antes de escrever custa<\/strong>: validar antes de escrever custa lat\u00eancia e obriga a desenhar o que fazer quando o modelo insiste em errar. N\u00e3o \u00e9 opcional em escrita em sistema de terceiro.<\/li>\n<\/ul>\n
          O que n\u00e3o d\u00e1 para afirmar a partir deste material<\/h2>\n
          S\u00f3 consegui capturar o resumo e o TL;DR do guia da OpenAI diretamente, o restante vem da documenta\u00e7\u00e3o da API, de refer\u00eancias do Microsoft Foundry e de guias de prompting de terceiros. Por isso evito afirmar como funciona por dentro:<\/p>\n
            \n
          • O que exatamente \u00e9 “mid-turn steering” e como ele se comporta em erro. O guia menciona, mas o resumo n\u00e3o detalha.<\/li>\n
          • Como funciona a delega\u00e7\u00e3o multi-agente na pr\u00e1tica: 6.1 Sol suporta workflows multi-agente que delegam subtarefas independentes para subagentes, atualmente em beta, mas beta significa que a interface pode mudar.<\/li>\n
          • O comportamento real de Fast e Ultrafast em throughput sustentado. Ultrafast mode acelera a gera\u00e7\u00e3o de tokens independentemente do reasoning effort e est\u00e1 dispon\u00edvel para GPT-6 Astra em Codex e na API, mas n\u00e3o testei n\u00fameros.<\/li>\n
          • Se o roteador que sugeri acima bate com os seus dados. N\u00e3o bate at\u00e9 voc\u00ea medir.<\/li>\n<\/ul>\n
            Como testar isso voc\u00ea mesmo<\/h2>\n
            Um caminho pequeno para come\u00e7ar:<\/p>\n
              \n
            1. Pegue 20 a 50 exemplos reais do seu fluxo, com crit\u00e9rio de sucesso definido por humano.<\/li>\n
            2. Rode o mesmo prompt nos tr\u00eas modelos (Luna, 6.1 Sol, Astra), em effort low, medium e high onde suportado.<\/li>\n
            3. Para cada combina\u00e7\u00e3o, registre: acerto, lat\u00eancia, tokens de input, tokens de output, erros de ferramenta.<\/li>\n
            4. Monte uma tabela e escolha o menor combo (modelo + effort) que passa seu crit\u00e9rio de sucesso em pelo menos 95 por cento dos casos. Esse \u00e9 seu default.<\/li>\n
            5. Para os 5 por cento restantes, defina um fallback expl\u00edcito: subir de modelo, subir de effort, ou cair para revis\u00e3o humana.<\/li>\n<\/ol>\n
              \u00c9 um protocolo chato e manual, e \u00e9 o \u00fanico jeito honesto de escolher. Pre\u00e7o e marketing de modelo n\u00e3o decidem isso por voc\u00ea.<\/p>\n","protected":false},"excerpt":{"rendered":"
              Como funciona a fam\u00edlia GPT-6 (Astra, 6.1 Sol, Luna), o que \u00e9 reasoning effort, quando usar cada modelo e como montar um roteador por tarefa.<\/p>\n","protected":false},"author":2,"featured_media":754,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-755","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/755","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=755"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/755\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/754"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=755"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=755"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=755"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}