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

• A OpenAI atualizou os metadados do modelo empacotado do Codex e fez backport para o branch release/0.144 da mudança que reduz o tamanho do contexto do modelo de 372k para 272k
• O PR #33972 transfere as alterações do branch agent/hotfix-0.144-model-metadata para a versão Codex 0.144
• O escopo da mudança é 1 arquivo JSON, e as estatísticas do diff são 64 linhas adicionadas e 54 linhas removidas
• Foi mesclado com 1 commit e 36 verificações, sem conversas ou conteúdo de revisão separados
• Na página fornecida, o diff do arquivo não foi carregado, então não é possível confirmar mudanças específicas de metadados além da redução do contexto

---

Objetivo e escopo da mudança

• O título do PR indica um backport dos metadados atualizados do modelo empacotado para o Codex 0.144
• Segundo o título no Hacker News, o tamanho do contexto do modelo foi reduzido de 372k para 272k
• O branch de destino é openai:release/0.144, e o branch de origem é sayan-oai:agent/hotfix-0.144-model-metadata

Resultado do merge

• O PR #33972 é composto por 1 commit, b06f4fa
• O título do commit é Backport refreshed bundled model metadata
• Foi mesclado em 18 de julho de 2026, com 36 verificações e 1 arquivo alterado exibidos
• O volume da mudança é de 64 linhas adicionadas e 54 linhas removidas, e o formato do arquivo é JSON

Limites do que é possível confirmar

• As áreas de arquivos e comentários da página mostram erro de carregamento, portanto o diff JSON real não pode ser verificado no conteúdo fornecido
• Procedimentos de reprodução, motivo da mudança, impacto de compatibilidade e feedback de revisão não estão incluídos no texto

[GN⁺]

Comentários do Hacker News

• Dizem que compactar resolve, mas no tipo de trabalho que faço há detalhes demais que se perdem na compactação
  Pode até servir se o planejamento for simples ou não houver discussões muito detalhadas, mas a falta de contexto longo faz com que eu acabe continuando com a Anthropic
  Quando preciso manter na memória vários artigos ou materiais grandes e complexos por completo, o contexto vive ficando em 16%. Depois de uns 5 minutos de conversa ele é compactado, e o processo de fazer o modelo reler o material até chegar de novo a 16% se repete
  O contexto de 372k também não era perfeito, mas ajudava muito ao aumentar a folga de algo entre 12~20% para cerca de 40%

  • Como não dá para desligar a compactação automática nem voltar ao histórico anterior à compactação, não dá para usar o Codex em codebases com mais de 5 mil linhas
    Ele dispara aleatoriamente quando restam 10~20% de contexto, então na prática só dá para usar 80% dos 272k. Depois da compactação as alucinações pioram tanto que fica pior do que começar do zero, e você entra num ciclo de reler a codebase e ser compactado de novo
  • Meu processo de design é diferente. O plan.md que reviso várias vezes é a própria memória, e reiniciar a sessão para reler e revisar o plano ajuda a obter novas perspectivas
  • A compactação é tão ruim que criei uma ferramenta para deixar o LLM apagar seletivamente partes do contexto e restaurá-las quando necessário. Se você bate com frequência no limite da compactação automática, talvez valha testar o context bonsai
    https://github.com/Vibecodelicious/context-bonsai-agents
  • Os modelos da Anthropic oferecem contexto de 1 milhão de tokens. Eu ia migrar para a OpenAI no mês que vem, mas se ela ainda está parada em cerca de 300k, acho que vou ter de me adaptar à nova realidade
  • Em geral recomendo que o agente crie ou atualize arquivos .md de vez em quando para lembrar informações importantes que surgiram. Mas se o agente soubesse exatamente o que é realmente importante, então o /compact também deveria funcionar bem

• Por causa da janela de contexto grande, deixei de selecionar o que colocar nela, e a compactação aplica uma compressão com perdas ao conjunto inteiro de uma vez, fazendo até os detalhes necessários se perderem
  Acho que o problema fundamental é reenviar a conversa inteira toda vez. Com um plugin de memória/contexto que fiz, eu esvazio o contexto a cada rodada e reinjeto só as informações relevantes, então, em vez de ler um histórico de conversa com 200 mil tokens, o modelo lê apenas alguns milhares de tokens de estado selecionado, e o contexto pequeno deixou de ser um problema
  Ainda não resolvi isso para agentes de programação, mas acho que a solução real é uma política de retenção que mantenha só o necessário para concluir a tarefa ou para a próxima tarefa e descarte o resto, algo que pode ser implementado com um LLM dedicado

  • Muitos especialistas em NLP que pesquisaram LSTM, GRU e afins também viam o reenvio da conversa inteira como um problema fundamental, mas empiricamente os Transformers venceram
    É interessante pensar se arquiteturas futuras voltarão a considerar esse problema. Se tomarmos humanos como referência, o que ainda falta é a capacidade de transferir informações de forma eficiente da memória de curto prazo para a de longo prazo, e o fine-tuning faz algo parecido em princípio, mas não de forma eficiente

• Não sei se esse foi o motivo dessa mudança, mas desde o começo acho que usar um contexto maior do que isso quase sempre é um erro
  As pessoas subestimam o quanto o desempenho do modelo cai e o custo em tokens aumenta conforme o contexto cresce. O Claude não usa mais de 300k e, em vez de compactar, divide o trabalho, mantendo a documentação e a codebase modular concisas
  Em tarefas pontuais um contexto grande pode ser útil, mas se você ultrapassa 300k constantemente, há uma boa chance de estar perdendo muita coisa ou de a arquitetura da sua codebase não ser boa

  • Eu também compacto ou reinicio em 250k. Como o tamanho de contexto necessário é proporcional ao tamanho do projeto, quem precisa de janelas maiores provavelmente só está lidando com projetos maiores
  • Minha percepção é a mesma, e eu colocaria o limite mais para 100~150k. Mesmo que o modelo suporte contexto longo, o desempenho real não é bom
  • Minha percepção não bate com a parte de que o modelo fica visivelmente mais burro quando o contexto aumenta. Ele fica mais lento e mais caro, mas em tarefas complexas esse é um custo que vale a pena pagar
    Faço o agente principal pedir para subagentes pesquisarem o que é necessário e escreverem um plano, depois outros subagentes fazem uma revisão adversarial para reforçá-lo. No final, 30~40% de uma janela de 1 milhão de tokens fica ocupada, e esse fluxo é impossível com 272k
    No 5.6 Sol tive de reduzir bastante esse processo, e provavelmente essa também é a razão de os resultados serem piores

• Quando essa mudança aconteceu, o Tibo publicou uma explicação junto: https://x.com/thsottiaux/status/2076543065045795309

  • As respostas podem ser vistas aqui: https://xcancel.com/thsottiaux/status/2076543065045795309
    O tuíte linkado é uma resposta não oficial às informações oficiais do Tibo, e ele corrige o conteúdo nas respostas
  • Não entendo este gráfico. Gostaria de saber por que a linha continua subindo mesmo com a compactação, ou se há algum significado de “overall trajectory size” que eu desconheço
  • Não sei se o comprimento total da trajetória pode ser o mesmo mesmo com intensidades de raciocínio diferentes. Mesmo excluindo os tokens de raciocínio do comprimento da trajetória, isso não parece possível

• Não gostam dessa compressão de contexto e acham que agora deveriam oferecer pelo menos 1 milhão de tokens
  GPT 5.5 e 5.6 engasgam sempre que são comprimidos até retomarem o ritmo, e às vezes também se fixam demais em mensagens antigas de instrução que restaram no contexto comprimido

  • O GPT-5.6-Sol é cerca de 2x mais eficiente em tokens que o Opus/Fable, então o máximo de 258k equivale a cerca de 516k no Claude
    A corrupção de contexto ainda é um problema[1][2], e também há evidências de que, em tarefas de agente, a compressão é equivalente ou até melhor que um contexto longo[3]. O ideal seria que o modelo raciocinasse em um contexto de 1 milhão da mesma forma que em 256k, mas isso ainda não é possível
    [1] https://arxiv.org/abs/2605.12366
    [2] Comparação de F1 entre GraphWalks 256K e 1M no System Card do Opus 4.8: https://www-cdn.anthropic.com/0b4915911bb0d19eca5b5ee635c80f...
    [3] https://context-folding.github.io/
  • Ao contrário de outras ferramentas de programação, é frustrante que não dê para desativar a compressão automática. Como ela roda de forma irregular quando resta 10~20% do contexto, a capacidade garantida é só 80% de 272k
    Em uma base de código grande, quando o trabalho já está quase terminando e faltam só umas 2 mil tokens de resposta, se cair abaixo de 20% ele processa por um bom tempo e então aparece Context compacted. Não dá para voltar ao estado anterior à compressão, então ele reinspeciona a base de código, é comprimido de novo, e no fim consome todos os tokens
  • Espero que a redução de tokens não seja uma manobra para aumentar o uso, mas principalmente por corte de custos. Na empresa também, o pessoal responsável por custos limitou o contexto de forma tão severa que transformou um LLM interno que no começo era útil em algo quase inútil
    Parece até que existe um encontro onde executivos compartilham as piores práticas
  • A memória de trabalho pode ser salva em arquivos Markdown, então não é preciso um contexto tão grande. À medida que o contexto cresce, a atenção se dispersa e o desempenho do LLM piora, então manter isso pequeno favorece a qualidade

• Uso Opus no dia a dia e executo /clear com frequência. Mesmo com contexto de 1 milhão, quando chega perto de 50% o desempenho cai rápido, então normalmente reiniciar em 30~40% dá resultados bem melhores
  Em vez de compressão, funciona melhor começar de novo e inserir desde o início o contexto necessário. Organizar documentos Markdown por funcionalidade em várias coleções técnicas e, no carregamento inicial, indicar onde encontrar as informações relevantes para a tarefa é uma abordagem eficaz

• No Codex, nunca senti que o tamanho do contexto fosse um problema. Não sei como funciona a compressão, mas ele continua como se não houvesse limite

  • Parece que você começou a usar Codex recentemente. No começo, os erros de model context size exceeded que nem a compressão conseguia recuperar eram graves, e só desapareceram há poucos meses
    Agora está muito melhor, mas depois da compressão ele não mostra o que entrou no concise summary, então é difícil saber se o conteúdo importante foi preservado
    O Codex parece estar indo na direção de esconder o máximo possível do usuário, e, assim como recentemente criptografou os prompts entre agentes e subagentes, também parece capaz de criptografar todo o log da sessão. É uma pena, mas ainda é a melhor combinação de ferramenta e modelo que já usei
  • O Codex frequentemente esquece de concluir a última tarefa quando ocorre compressão, especialmente quando a mensagem foi enviada logo antes da compressão
  • A maior parte dos problemas pode ser resolvida com dividir para conquistar, então a diferença entre 300k e 400k quase nunca importa. Um agente de programação não é uma conversa infinita

• Por melhor que a compressão seja, em projetos grandes é preciso ler muitos arquivos. Os primeiros 200 mil tokens se esgotam muito rápido, mas depois o ritmo desacelera
  As sessões do Fable na maioria das vezes não passam de 500 mil tokens, então não precisam de compressão, mas no Codex é preciso continuar comprimindo dentro da mesma sessão

  • Acho que a razão para precisar ler tantos arquivos é que o agents.md é fraco. Basta ler os arquivos reais do trabalho e alguns arquivos relacionados; o resto deveria estar organizado na documentação

• Para o meu trabalho, isso é um tamanho bem pequeno. Tento ficar abaixo de 200k, mas ao forçar as iterações finais em sessões com DeepSeek e MiMo, às vezes isso sobe até 350k tokens antes de comprimir
  Fico me perguntando se a OpenAI não poderia adotar a tecnologia de cache K/V do DeepSeek apresentada em artigo público para reduzir bastante os custos

  • Ninguém faz caching tão bem quanto a DeepSeek, então imagino que seja difícil acompanhar por causa das diferenças de implementação
    Se usar DeepSeek com Reasonix, há um método adicional e dedicado ajustado à estrutura de cache, então em sessões longas 97~98% dos tokens ficam em cache. Um modelo que já é barato fica ainda mais barato
  • Em modelos abertos locais baseados em llamacpp, o agente instrui a comprimir entre 55k~85k, e, a menos que um contexto grande seja realmente necessário, como em rastreamento complexo de logs, é raro chegar a 120k
    Também ajustei o prompt do sistema para que, de acordo com o orçamento de inferência e as mensagens do llamacpp, o agente crie subagentes e depois comprima o conteúdo. Com a poda dinâmica de contexto do opencode, ele mantém a direção sem aumentar o volume e, no geral, funciona bem para desenvolver repetidamente vários subcomponentes

• Nos últimos dois meses, para o meu uso, isso tem sido muito melhor, então migrei do Claude para a OpenAI. Fico curioso se esta mudança vai gerar uma diferença perceptível na qualidade da saída