Como pedir uma refatoração grande no GPT-6 Sol sem a resposta cortar no meio

Você seleciona o módulo inteiro, escreve um prompt caprichado pedindo a refatoração completa, manda ver

O modelo começa lindo, reescreve o primeiro arquivo, entra no segundo… e para no meio de uma função

Aí você pergunta "continua" e vem um pedaço remendado que não encaixa com o anterior, beleza? Clássico 😛

A raiz disso não é preguiça do modelo, é matemática. O GPT-6 Sol lê até 1.050.000 tokens de contexto, mas devolve no máximo 128.000 tokens de saída por resposta. Ou seja: ele consegue ENGOLIR o seu projeto inteiro, só que não consegue cuspir o seu projeto inteiro de volta numa tacada

Essa assimetria entre entrada gigante e saída limitada é o que corta a resposta no meio. E ela se resolve com particionamento, não com prompt mágico

Bora ver como fatiar direito?

O que você precisa antes de começar

Primeiro, onde o bicho roda hoje. O GPT-6 Sol foi lançado em 22 de setembro de 2026 junto com o GPT-6 Luna, na sequência do GPT-6 Astra

A disponibilidade no dia do lançamento anunciado pela OpenAI ficou assim:

• ChatGPT Work e Codex para usuários Plus, Pro, Business, Enterprise e Edu
• API com o identificador gpt-6-sol (e gpt-6-luna)
• Free e Go acessam o GPT-6 Luna no app de desktop

• GitHub Copilot também já lista GPT-6 Sol e GPT-6 Luna

O passo a passo daqui pra frente é de API, porque é lá que você tem os parafusos na mão. São três que importam pro nosso problema:

• max_output_tokens: o teto de tokens gerados naquele request
• reasoning.effort: quanto o modelo pensa antes de escrever
• truncation: o que fazer quando a entrada não cabe na janela

E tem o detalhe que dói no bolso: na API o GPT-6 Sol custa US$ 2,00 por 1M de tokens de entrada e US$ 10,00 por 1M de tokens de saída

Por que eu já jogo o preço aqui em cima? Porque tentativa cortada também é cobrada. Você paga a entrada e paga os tokens de raciocínio mesmo quando a resposta volta pela metade (ou não volta nada visível). Refatorar no chute sai caro 😀

Passo a passo: como fatiar a refatoração para o GPT-6 Sol entregar arquivos completos

1. Meça o alvo antes de pedir qualquer coisa

Antes de escrever o prompt, olhe o tamanho do que você quer DE VOLTA, não do que vai mandar

A conta é grosseira e serve: pegue o número de caracteres dos arquivos que o modelo vai reescrever e divida por algo entre 3 e 4 pra ter uma estimativa de tokens. Se o resultado chegar perto dos 128.000 tokens de saída, já era, vai cortar

E lembre que a saída não é só o código: comentários, explicação antes e depois, marcação de bloco, tudo entra na mesma conta

O erro comum deste passo: olhar só pro contexto de 1.050.000 tokens e achar que cabe tudo. Contexto grande é o quanto ele LÊ. Saída é outro balde, muito menor

2. Reserve folga pro raciocínio

Esse aqui pega muita gente de surpresa

O max_output_tokens não limita só o texto que você vê. Ele cobre tokens de raciocínio, tokens visíveis de saída e tokens de formatação não visíveis. E os tokens de raciocínio ocupam espaço na janela de contexto e são cobrados como saída

Tradução: se você pedir um arquivo de 20 mil tokens e setar max_output_tokens em 22.000, o modelo pode queimar a cota inteira pensando e te entregar… nada

A própria documentação da OpenAI recomenda reservar pelo menos 25.000 tokens para raciocínio e saídas quando você está começando a experimentar com modelos de reasoning. Use isso como piso, não como teto

{
  "model": "gpt-6-sol",
  "max_output_tokens": 48000,
  "reasoning": { "effort": "medium" }
}

O erro comum deste passo: calcular max_output_tokens colado no tamanho do arquivo esperado. Sempre sobra menos do que você imagina

3. Defina o corte: um arquivo por request

Aqui é o coração da coisa

A unidade de trabalho que funciona pra refatoração grande é o arquivo, não o módulo. Um request, um arquivo, entregue inteiro

Parece burocrático, mas é o mesmo raciocínio de quem divide a refatoração em etapas revisáveis: cada pedaço tem começo, meio, fim e pode ser conferido sozinho

Se um arquivo específico for monstruoso e sozinho já ameaçar o teto de saída, quebre por classe ou por grupo de funções e diga isso explicitamente no prompt

O erro comum deste passo: pedir "refatora a pasta src/services" e torcer. Modelo nenhum negocia com o limite de tokens, ele simplesmente para

4. Escreva o contrato de entrega no prompt

Fatia pequena sem contrato ainda dá ruim, porque o modelo resolve economizar e devolve aquele // resto do arquivo permanece igual

Então o prompt precisa fechar a porta. Uma base que funciona:

CONTRATO DE SAÍDA (obrigatório):
1. Reescreva APENAS o arquivo src/services/pagamento.ts
2. Devolva o arquivo COMPLETO, do primeiro import ao último export
3. Proibido usar reticências, "resto igual", "...", ou qualquer placeholder
4. Nenhuma explicação antes ou depois do bloco de código
5. Se o arquivo não couber inteiro na resposta, NÃO comece:
   responda apenas com CORTE_NECESSARIO e a sugestão de divisão

A regra 5 é a mais subestimada. Você está dando ao modelo uma saída honesta em vez de empurrar ele pra entregar meia coisa

A regra 4 é dinheiro puro: explicação bonita gasta token de saída que era do seu código

O erro comum deste passo: pedir "código completo" e, na mesma frase, pedir "explique as mudanças". Você acabou de vender metade da sua cota de saída pra prosa 😅

5. Ajuste o reasoning.effort por fatia

O reasoning.effort do gpt-6-sol aceita seis níveis: none, low, medium (padrão), high, xhigh e max

A lógica prática é direta: quanto mais o modelo pensa, mais tokens de raciocínio ele queima dentro do mesmo max_output_tokens

• fatia mecânica (renomear, extrair função, trocar import): low ou none
• fatia de decisão (redesenhar interface, mudar contrato entre camadas): high pra cima

E tem uma pegadinha de API: no Chat Completions, o gpt-6-sol só suporta function calling com reasoning_effort definido como none

Se o seu pipeline de refatoração usa tools pra ler e gravar arquivo por function calling nesse endpoint, você está preso no none ali. Vale saber antes de debugar às 2 da manhã

O erro comum deste passo: subir tudo pro max "pra garantir qualidade" e ver a cota de saída evaporar em raciocínio antes do código aparecer

6. Controle a entrada com truncation e fique abaixo de 272K

Dois assuntos diferentes, mesma seção, porque ambos são sobre o lado da entrada

O parâmetro truncation da Responses API tem dois valores:

• auto: descarta itens do início da conversa pra caber na janela
• disabled (padrão): o request falha com erro 400 se a entrada exceder a janela de contexto

Em refatoração longa com várias fatias na mesma conversa, disabled é o comportamento mais previsível: melhor estourar e você saber do que o modelo perder silenciosamente o arquivo de tipos que você mandou lá atrás

O segundo ponto é preço. Prompts acima de 272 mil tokens de entrada entram numa faixa majorada: 2x nas taxas de input e de cache e 1,5x no output, aplicado ao request completo

Repare no detalhe cruel: é o request INTEIRO que fica mais caro, não só o excedente. Passar de 272K por descuido é o tipo de coisa que dobra a fatura do dia

O erro comum deste passo: empurrar o repositório inteiro no contexto "pro modelo entender melhor". Ele entende, e cobra por isso

7. Feche o loop conferindo o status

Último passo, e é o que separa fatiamento de esperança

Quando a geração bate no limite, a resposta volta com status: incomplete e um incomplete_details com reason: max_output_tokens

Então nunca cole código no projeto sem olhar isso:

{
  "status": "incomplete",
  "incomplete_details": { "reason": "max_output_tokens" }
}

Se veio incomplete, descarte a saída e refatie. Não tente remendar com "continue de onde parou": você vai gerar um arquivo Frankenstein e descobrir o problema em produção

E se você usa streaming, atenção: no streaming da Responses API o max_output_tokens vem como null quando você não informa o parâmetro. Ou seja, não tem número mágico defendendo você ali, o teto do modelo é quem manda

O erro comum deste passo: validar só se o código "parece completo" batendo o olho. Arquivo cortado num ponto de chave fechada engana fácil

Cortou mesmo assim? Diagnóstico rápido dos 4 sintomas mais comuns

Sintoma 1: a resposta voltou vazia, mas veio cobrada

Causa: o modelo consumiu todo o orçamento de max_output_tokens em raciocínio antes de produzir qualquer token visível. Isso pode acontecer antes de UM caractere aparecer, gerando custo de entrada e de raciocínio sem resposta visível

Como prevenir: suba o max_output_tokens com folga real (lembre do piso de 25.000 recomendado pra raciocínio e saídas) e baixe o reasoning.effort na mesma proporção em que a tarefa é mecânica

Sintoma 2: status incomplete com reason max_output_tokens

Causa: a fatia é maior que o que cabe na resposta. Simples assim

Como prevenir: volte no passo 1 e recalcule o tamanho esperado da saída. Se um único arquivo se aproxima dos 128.000 tokens de saída, ele precisa ser dividido por classe ou por bloco de funções, com âncoras claras de onde começa e onde termina

Sintoma 3: erro 400 de contexto excedido

Causa: truncation está no padrão disabled e a entrada passou da janela de contexto. O request falha em vez de cortar sozinho

Como prevenir: ou você reduz o que manda (mandando só os arquivos que a fatia toca), ou aceita auto sabendo que itens do início da conversa vão ser descartados. Numa refatoração multi-turno, descartar o começo costuma ser pior do que o erro, porque é lá que estão as regras que você definiu

Sintoma 4: o custo do request explodiu do nada

Causa: você passou de 272 mil tokens de entrada. Acima disso, 2x nas taxas de input e de cache e 1,5x no output, no request completo

Como prevenir: monitore o tamanho da entrada acumulada da conversa, não só do último prompt. Conversa longa de refatoração cresce sozinha a cada turno e atravessa essa linha sem avisar. Tome cuidado! 😀

Três formatos de fatiamento que funcionam para refatoração grande

Não existe um jeito certo único. Existe o corte que cabe no seu caso

Fatiamento por arquivo

Um request, um arquivo completo. É o mais previsível e o mais fácil de revisar em code review

Quando vale: refatoração ampla e rasa (renomear conceito, trocar biblioteca, padronizar tratamento de erro em vários arquivos)

Custo: você reenvia contexto comum (tipos, interfaces, convenções) a cada request. Gasta mais entrada, mas entrada custa US$ 2,00 por 1M e saída custa US$ 10,00 por 1M, então repetir entrada é o lado barato da conta

Fatiamento por camada

Tipos primeiro, depois implementação, depois testes

A sacada aqui é que o resultado da fatia 1 vira o contrato das fatias seguintes. Você gera types.ts refatorado, valida, e ele entra como entrada da próxima etapa

Quando vale: refatoração profunda, onde a assinatura das coisas muda. Se você mandar implementação e tipos juntos, o modelo inventa tipo no meio do caminho e a implementação do arquivo seguinte não bate

Custo: mais turnos, mais cuidado com o tamanho acumulado da conversa (olho nos 272K)

Fatiamento por diff dirigido

Em vez do arquivo inteiro, o modelo devolve só os trechos alterados, cada um com uma âncora de localização (a linha exata antes e depois do trecho)

Quando vale: arquivo grande com mudança cirúrgica. É o formato que MAIS economiza tokens de saída, e saída é o recurso escasso aqui

Custo: é o mais perigoso de aplicar, porque você (ou seu script) vira responsável por colar no lugar certo. Já me ferrei com merge de trecho aplicado duas vezes, então: âncora única e explícita, sempre

A mesma lógica de fatiar por tamanho de resposta já valia no limite de saída do GPT-6 Astra, o que muda de modelo pra modelo é quanto você consegue empurrar em cada fatia

O que muda com o GPT-6 Sol em relação ao GPT-5.6 Sol

Não é review, é só o contexto que interessa pro nosso problema

Ou seja: preço pela metade do antecessor, e um pouquinho acima no índice de agente de código

O número mais interessante pra quem refatora não está na tabela: a Artificial Analysis registrou redução de cerca de 3x no uso de tokens em max effort em relação ao GPT-5.6 Sol. Na avaliação do Intelligence Index, onde o GPT-6 Sol (max) marcou 48 pontos, ele gerou 77M de tokens contra uma mediana de 88M

E a OpenAI afirma que o modelo comete cerca de metade dos erros do GPT-5.6 Sol nos testes internos dela

Conecta com o tema assim: se o modelo pensa gastando menos token pra chegar no mesmo lugar, sobra mais do seu max_output_tokens pro código de verdade

Sobra mais orçamento de saída por fatia, e cada fatia pode ser um pouco maior

Mas repare no que NÃO mudou: o teto continua sendo 128.000 tokens de saída por resposta. Eficiência maior não revoga o limite, ela só te dá mais espaço dentro dele 🙂

Conclusão

O princípio que resolve a maior parte do problema cabe numa linha: contexto grande não é saída grande

1.050.000 tokens de leitura e 128.000 de escrita são coisas diferentes, e é ignorar essa diferença que faz a resposta parar no meio da função

O próximo passo prático é montar seu template de prompt com o contrato de entrega (arquivo completo, zero placeholder, zero explicação, e a cláusula do CORTE_NECESSARIO)

Aí roda UMA fatia só, confere o status da resposta, mede quanto de saída aquilo consumiu de verdade

Com esse número na mão você calibra o tamanho das fatias seguintes e escala pro módulo inteiro sem susto

Faça o teste e me conta como foi, até o próximo post! =)