OpenAI's GPT-5.1-Codex-Max e a abordagem de compaction para agentes de execução longa

O que a compaction realmente altera

A afirmação central do system card é específica e técnica: o GPT-5.1-Codex-Max é o primeiro modelo da OpenAI "nativamente treinado para operar em várias janelas de contexto através de um processo chamado compaction, trabalhando de forma coerente ao longo de milhões de tokens numa única tarefa."

Isto é uma aposta diferente de simplesmente aumentar uma janela de contexto. A compaction implica que o modelo aprende a resumir e transportar o seu próprio estado de trabalho à medida que esgota uma janela e avança para a seguinte, em vez de depender de um sistema externo para costurar o contexto.

Para quem constrói agentes de codificação de execução longa, esta é a parte que vale a pena observar. O modo de falha típico dos agentes multi-etapa raramente é o raciocínio em si — é perder o fio da tarefa ao longo de milhares de chamadas a ferramentas. Treinar esse comportamento diretamente no modelo, em vez de o acrescentar por fora com recuperação e resumo manual, é uma afirmação sobre onde a OpenAI acredita que essa responsabilidade deve residir.

Treinado no trabalho real, não apenas no benchmark

O documento é explícito ao afirmar que o modelo foi treinado em "tarefas reais de engenharia de software, como criação de PRs, revisão de código, codificação de frontend e Q&A," partindo de um modelo fundacional de raciocínio atualizado, treinado em engenharia de software, matemática, investigação, medicina e utilização de computador.

Esse enquadramento — criação de PRs e revisão de código como objetivos de treino de primeira linha — indica o tipo de utilização pretendida. Não é apresentado como um motor de autocompletar, mas como algo destinado a participar no fluxo de trabalho em torno de uma alteração: propô-la, revê-la, responder a perguntas sobre ela.

As mitigações também residem na camada de produto

A OpenAI divide o seu trabalho de segurança em duas categorias, e a segunda é a que as equipas que aplicam o modelo devem ler com atenção. Além do treino ao nível do modelo contra tarefas prejudiciais e injeções de prompt, o documento lista "mitigações ao nível do produto, como sandboxing de agentes e acesso à rede configurável."

Para um agente que executa código, o acesso à rede é o verdadeiro raio de impacto. Torná-lo configurável é um reconhecimento de que um modelo treinado para resistir a injeções de prompt continua a não substituir a limitação daquilo a que o agente pode aceder. Essa divisão de trabalho — resistência ao nível do modelo mais contenção ao nível do produto — é a postura prática adotada pelo documento.

Onde se situa na Preparedness Framework

O documento posiciona o modelo com precisão na escala de capacidade da OpenAI. É "muito capaz no domínio da cibersegurança, mas não atinge capacidade elevada em cibersegurança," e não atinge capacidade elevada em autoaperfeiçoamento de AI (mantém-se a sigla inglesa). É tratado como de capacidade elevada em biologia e implementado com o mesmo conjunto de salvaguardas usado para o GPT-5.

Esperamos que as tendências atuais de rápido aumento de capacidade continuem, e que os modelos ultrapassem o limiar de risco elevado em cibersegurança num futuro próximo.Montana Labs

Esta frase é a afirmação mais prospetiva do documento. A OpenAI está a dizer que um modelo de codificação situado pouco abaixo do limiar de cibersegurança é um estado transitório, não um estado estável.

A implicação: a contenção de agentes é agora o problema de engenharia

Lidas em conjunto, a capacidade de compaction e os controlos de acesso à rede apontam para a mesma conclusão. Um modelo capaz de conduzir uma tarefa de forma coerente ao longo de milhões de tokens é um modelo capaz de dar muitos passos autónomos antes que um humano veja o resultado — o que torna o sandboxing e a configuração de rede as alavancas que efetivamente limitam o seu comportamento.

Para as equipas que adotam o GPT-5.1-Codex-Max, o trabalho passa menos por formular bons prompts e mais por decidir o que o modelo pode tocar durante uma execução longa. O system card trata isso como responsabilidade da OpenAI ao nível do produto; na prática, as decisões de implementação recaem sobre quem integra o agente nos seus próprios sistemas.