Codex no GPT-6.1 Sol reduz a janela para 828 400, mas deixou passar uma entrada de 888 mil tokens

Em ~/.codex/config.toml está definido model_context_window = 1000000, mas, em cada tarefa, o Codex com GPT-6.1 Sol informa uma janela de 828 400 tokens. O autor de uma análise publicada no Habr descobriu de onde vem esse número, elevou o valor para 900 000 com um catálogo de modelos próprio e rodou uma entrada sintética de 890 547 tokens com marcadores de controle. A principal conclusão veio do teste de controle: o mesmo texto, com 888 330 tokens, passou também na janela padrão de 828 400. No Codex, a janela não limita o tamanho de uma única mensagem de entrada.

De onde vem o 828 400

O Codex recebe os parâmetros do modelo do servidor e os guarda em cache em ~/.codex/models_cache.json. O registro do GPT-6.1 Sol contém context_window 500 000 (valor padrão), max_context_window 872 000 (o config não consegue elevar a janela acima disso) e effective_context_window_percent 95. Resultado: 872 000 × 0.95 = 828 400.

O autor não conferiu isso em uma única sessão. Nos logs de ~/.codex/sessions, ele pegou as últimas 40 tarefas: 39 com gpt-6.1-sol e uma do codex-auto-review, o modelo de serviço. Em todos os 39 eventos token_count aparece model_context_window: 828400. O valor fica no campo info.model_context_window, enquanto a entrada e a saída reais da última requisição ficam em last_token_usage. O formato do log não está documentado como estável, então o campo pode mudar de lugar após uma atualização do cliente.

Teste com 890 mil tokens e marcadores

Por meio do parâmetro model_catalog_json, o autor conectou uma cópia do catálogo do servidor em que o gpt-6.1-sol tem max_context_window de 1 000 000 e percentual de 90. O resultado foi 900 000. A margem de 10% veio de testes feitos em setembro com o GPT-6 Astra: lá, uma entrada de 900 089 tokens passou, enquanto um texto de enchimento a partir de 909 000 terminava em erro de estouro.

O texto de enchimento precisa ser denso em tokens: em setembro, um texto de 1 720 376 caracteres foi barrado pelo próprio cliente, que não deixou passar mensagens maiores que 1 048 576 caracteres. Por isso, o teste usou ideogramas aleatórios U+4E00–U+9FA4 com semente fixa 42, cerca de 1,9 token por caractere. Três marcadores, R7K2, Q9M4 e W3T8, foram inseridos em pontos diferentes do texto, e o modelo devia devolvê-los em ordem.

• «OK» curto, catálogo próprio, janela de 900 000: entrada de 57 187 tokens. É a parte de serviço da configuração do autor: instruções, regras, descrições de ferramentas e skills.
• Calibragem, 30 302 caracteres, catálogo próprio: 115 300 tokens, 3 de 3 marcadores.
• Execução grande, 434 302 caracteres, catálogo próprio: 890 547 tokens, 3 de 3 marcadores, 62 s, cached_input_tokens 9 216.
• Controle, mesmo texto, catálogo do servidor, janela de 828 400: 888 330 tokens, 3 de 3 marcadores, 60 s, sem cache.
• A diferença entre as duas últimas entradas é de 2 217 tokens. O texto de enchimento é o mesmo; a causa está na parte de serviço, mas o autor não apurou o motivo com precisão.

O que a janela realmente define

Na documentação de referência, o campo é descrito como «Context window tokens available to the active model». Thibault Sottiaux, da equipe do Codex, explicou que uma janela maior permite ao Codex manter mais código, saída de ferramentas e histórico antes de compactar o material antigo. Ou seja, o número define o momento da compactação automática. O limite é controlado por outro parâmetro, model_auto_compact_token_limit, e o model_auto_compact_token_limit_scope, no modo total, conta todo o contexto ativo; no modo body_after_prefix, conta apenas o acréscimo depois do prefixo transferido.

O teto real está na página do GPT-6.1 Sol na documentação da API: janela de 1 050 000 tokens, com entrada de no máximo 922 000. Isso é coerente com os erros de setembro. Na API, requisições com mais de 272 mil tokens de entrada custam o dobro. Segundo Sottiaux (post de 11.10.2026), na assinatura não há cobrança extra por contexto longo no GPT-6.1 Sol, e a janela padrão do Codex foi elevada de 272 para 500 mil. O autor não encontrou isso na documentação. Ele também não mediu quanto uma requisição de 890 mil tokens consome do limite da assinatura.

Catálogo próprio: o que quebra após a atualização

O model_catalog_json substitui o catálogo do servidor por um arquivo estático, e o próprio autor caiu nessa armadilha. Em setembro, ele elevou o limite apenas do gpt-6-astra; depois, o gpt-6.1-sol virou o modelo principal, e na cópia dele esse modelo continuou com os antigos 872 000 e 95%. O ganho até 900 000 desapareceu em silêncio, e todas as tarefas de trabalho rodaram com 828 400. A cópia também não inclui o gpt-6.1-terra, e a janela padrão do Sol ali é de 272 000, em vez dos 500 000 do servidor.

O gerenciamento experimental de contexto [features.context_management] está desativado desde 12.09.2026: Sottiaux escreveu que a equipe desligou o experimento opt-in, que podia causar paradas antecipadas ou respostas a mensagens antigas. Isso afetou de 4 a 5 mil usuários. No catálogo, GPT-6.1 Sol, GPT-6.1 Terra e GPT-6 Astra têm supports_experimental_context: false, e a flag no config não ativa nada.

A conclusão prática para quem trabalha com o Codex: não persiga o milhão no config, porque o que limita você é o max_context_window do servidor. Para ver a janela real, leia o model_context_window no log da tarefa. Se você conecta um catálogo próprio, recrie-o a partir de um models_cache.json recente após cada atualização do cliente e confira a janela em uma tarefa nova. Nas 39 tarefas de trabalho do autor, a maior entrada foi de 389 543 tokens, então 828 mil bastam com folga. O próximo teste é uma sessão longa até a compactação automática: em que volume ela dispara com janelas diferentes e quantos marcadores sobrevivem à compactação.