OpenAI reduz o tamanho do contexto do modelo Codex de 372k para 272k

Artigo original ↗ Discussão no Hacker News ↗

A OpenAI reduziu temporariamente a janela de contexto do seu agente de programação Codex de 372k para 272k tokens, gerando debate sobre economia de custos versus capacidade para projetos de software grandes e de longa duração. Muitos usuários relatam que a “compactação” agressiva e opaca do histórico da conversa e do contexto do código pode atrapalhar fluxos de trabalho complexos, especialmente ao trabalhar em bases de código grandes, múltiplos repositórios ou arquivos de regras extensos, enquanto outros argumentam que bom planejamento, subagentes e memória externa em markdown compensam bastante janelas menores e evitam perda de qualidade em contextos muito longos. Comparações com modelos de um milhão de tokens da Anthropic e caching no estilo DeepSeek destacam uma tensão mais ampla: se as ferramentas de fronteira devem priorizar contexto bruto massivo ou uma gestão de contexto mais inteligente e controlável e um design de harness melhor.

Redução do Tamanho do Contexto e Justificativa

  • A janela de contexto do Codex foi reduzida de 372k para 272k tokens; o commit e os tweets sugerem que é uma medida temporária de controle de custo/uso, não uma mudança de capacidades.
  • Alguns observam que isso evita acionar níveis de contexto longo com preço mais alto, que antes atingiam os usuários de forma inesperada.
  • Um comentário observa que os modelos subjacentes conseguem lidar com até 1M de contexto, mas os limites do cliente do Codex são menores para manter o total (entrada + saída máxima) abaixo de um limite de cobrança.

Entendendo o Gráfico de Custo/Trajetória

  • Vários leitores acharam o gráfico de custo publicado confuso; outros o explicaram como um custo cumulativo subindo de forma aproximadamente quadrática com o número de turnos até a compactação, com contexto menor (por exemplo, 200k) dando uma trajetória consistentemente mais barata do que maior (300k).
  • Há discordância sobre se a curva reflete atenção quadrática ou apenas custos lineares cumulativos.

Impacto em Cargas de Trabalho Reais

  • Um grupo considerável diz que 272k é pequeno demais para bases de código grandes, engenharia reversa ou fluxos de trabalho com muitos planos, revisões e agentes de longa duração; eles frequentemente ficam perto do limite e sofrem compactações frequentes.
  • Outros argumentam que a maioria dos problemas pode e deve ser decomposta em partes abaixo de ~200–300k, com contextos menores produzindo melhor qualidade e menor custo.

Compactação: Qualidade, Controle e Alternativas

  • Muitos reclamam da compactação automática do Codex:
    • Dispara quando restam cerca de 10–20% do contexto, sem forma de desativar ou reverter.
    • Às vezes faz o modelo “esquecer” tarefas recentes ou código já lido, forçando novas varreduras e gastando tokens.
  • Outros relatam que a compactação do Codex melhorou significativamente desde versões anteriores e funciona bem para eles.
  • Estratégias comuns para mitigar:
    • Usar arquivos markdown de “plano”/“regras”/“relatório” como memória durável em vez de depender do histórico do chat.
    • Usar agressivamente subagentes, planejamento hierárquico e ferramentas externas que armazenam e reinjetam o contexto anterior.
    • Reiniciar sessões manualmente ou limpar o contexto em torno de 200–300k.

Comparações com Outros Modelos e Harnesses

  • Vários usuários dizem que vão continuar com ou migrar para modelos com ~1M de contexto (por exemplo, Anthropic, DeepSeek, outros), apesar de degradação semelhante após algumas centenas de milhares de tokens.
  • Outros afirmam que o marketing de contexto longo exagera o contexto realmente utilizável; eles veem uma “zona burra” começando em torno de 120–300k em muitos modelos.
  • Alguns preferem harnesses alternativos de código aberto ou de terceiros com compactação ajustável, árvores de histórico e maior controle do usuário.

Segurança e Design do Harness

  • O mesmo commit adiciona orientações mais rígidas no system prompt antes de ações destrutivas (por exemplo, não apagar recursivamente os diretórios home ou root), respondendo a casos reais de exclusão massiva acidental.
  • Há apoio para mais isolamento (containers, wrappers de rm com proteção) e ceticismo sobre permitir que agentes executem comandos destrutivos de qualquer forma.