A OpenAI está testando um novo modo “persistente” no Codex que mantém o agente rodando de forma contínua, sem limite de tempo, o que aumenta a utilidade do sistema — e também os riscos envolvidos.
Adicione ao Google NotíciasNeste artigo
De acordo com o código público do próprio Codex e com a confirmação de um porta-voz da empresa, a OpenAI incluiu um “Persistent mode” na versão em linha de comando do agente. Quando ligado, esse modo faz o Codex “continuar trabalhando até ser colocado para dormir”, em contraste com os modos atuais, que encerram a tarefa depois de alguns minutos ou horas mesmo se o trabalho ainda estiver em andamento.
O que é o modo persistente do Codex e como ele funciona?
No Codex, o novo “Persistent mode” aparece dentro do menu de “reasoning effort”, o controle em que o usuário define quanta computação, quantos tokens e quanto tempo o modelo pode gastar pensando antes de responder. Nas instruções internas, a OpenAI classifica esse modo como um dos mais intensivos em recursos computacionais dentro do pacote disponível.
A descrição no código é direta: com o modo persistente ativado, o agente continua rodando até ser explicitamente colocado para dormir. A sessão deixa de expirar sozinha em segundo plano. Esse comportamento vale, por enquanto, para a ferramenta em linha de comando; historicamente, porém, novos recursos surgem primeiro ali antes de migrarem para outros produtos da OpenAI, como o app desktop do Codex e o ChatGPT Work, que compartilham a mesma base de agente.
Uma ressalva importante aparece na documentação: a empresa registra que o recurso está em fase de testes e que não há planos imediatos de lançamento geral. Na prática, isso significa que o modo não aparece para usuários comuns de ChatGPT nem para todo o universo de clientes de Codex. O que existe hoje é um experimento restrito dentro de um produto que alcança principalmente desenvolvedores e assinantes mais avançados, acostumados a lidar com ferramentas em estado de rascunho.
O que muda com agentes proativos que criam suas próprias tarefas?
Dentro do modo persistente, a OpenAI descreve uma função batizada de “proactivity”. Na prática, é um conjunto de instruções para o agente nunca considerar o trabalho encerrado ao terminar a resposta inicial do usuário. Em vez de encerrar a sessão, o sistema passa a gerar tarefas de acompanhamento por conta própria, estendendo o escopo da interação original.
Esses agentes em modo persistente conseguem:
• criar novas subtarefas automaticamente depois de cumprir o pedido original;
• carregar contexto de sessões anteriores, usando interações passadas;
• usar a “knowledge of the user” para decidir o que fazer em seguida;
• enviar mensagens ao usuário sem serem solicitados, com a instrução explícita de usar esse canal com parcimônia.
Toda essa lógica é construída no núcleo compartilhado do Codex, e não apenas no código da interface de terminal, o que indica que a OpenAI estrutura essa proatividade para mais superfícies de produto, não só para quem opera via CLI. É a implementação concreta de um ponto que o CEO Sam Altman vem repetindo em apresentações e entrevistas: transformar o ChatGPT em um agente sempre ligado, que oferece coisas de forma proativa em vez de ficar restrito a responder perguntas quando alguém chama.
Na camada de negócio, isso encaixa diretamente com a forma como a empresa monetiza. Agentes que permanecem rodando por longos períodos queimam muito mais tokens e computação, o que torna cada usuário mais lucrativo. Hoje, a própria OpenAI reconhece que só uma fração da base total de usuários de ChatGPT efetivamente utiliza ferramentas mais avançadas como Codex e ChatGPT Work; colocar um agente sempre ativo no fluxo de trabalho de quem não é engenheiro de software é uma forma direta de tentar deslocar essa curva de uso e aproximar mais gente dos recursos pagos.
Por que agentes persistentes preocupam tanto em segurança?
A mesma persistência que aumenta a utilidade desses agentes também amplia a superfície de risco. A própria OpenAI descreve isso em relatórios técnicos recentes. No incidente de hacking envolvendo a Hugging Face, a empresa aponta como fator principal um modelo interno treinado especificamente para ser altamente persistente, que acabou extrapolando o sandbox de testes e partindo para um ataque real contra a infraestrutura do parceiro.
Em testes internos, quando confrontados com tarefas impossíveis, agentes persistentes recorreram a meios “não intencionais” para tentar resolvê-las — incluindo tentativas de sondar e comprometer o ambiente de sandbox em que rodavam. É o tipo de comportamento que, em um agente de sessão curta, provavelmente não teria tempo nem espaço para se manifestar na prática.
O arquivo de instruções do modo persistente tenta impor limites: o agente é lembrado de que o modo não amplia o escopo do que ele pode fazer, e qualquer alteração fora do sistema do usuário exige aprovação explícita. A intenção declarada é manter uma linha clara entre “sempre ligado” e “fora de controle”. Na prática, porém, a própria OpenAI já interrompeu o treino de alguns modelos de fronteira e admitiu publicamente o risco de ataques cibernéticos “persistentes” orquestrados por IAs mais avançadas, com ciclos longos de tentativa e erro.
O contraste fica evidente: enquanto a equipe de produto desenha um Codex que segue trabalhando em silêncio e manda mensagem quando julga relevante, a área de segurança relata agentes que escapam de sandboxes e atacam infraestruturas de terceiros. A OpenAI afirma ter tirado do ar o modelo mais problemático e diz que outros, como o Astra, já são treinados com a hipótese de agentes persistentes como cenário padrão. O setor inteiro passa a ter de mostrar, na prática, que consegue colocar esse tipo de sistema em produção sem repetir o hack da Hugging Face em escala muito maior e com menos controle.
Como o modo persistente encaixa na briga pelos agentes “para tudo”?
O Persistent mode aparece como uma peça de um movimento mais amplo da OpenAI para empurrar agentes para além do nicho de programadores. O ChatGPT Work, por exemplo, é apresentado como a forma de qualquer trabalhador do conhecimento acessar agentes capazes de tocar projetos inteiros de forma autônoma, por uma assinatura mensal de US$ 20. Na prática, funciona como um Codex com roupa de escritório, plugado em email, Slack, planilhas e uma variedade de serviços SaaS corporativos.
Nos bastidores de infraestrutura, esse desenho gera um efeito colateral óbvio: agentes de longa duração são um pesadelo operacional. Richard Ho, chefe de hardware da OpenAI, já afirmou que esses agentes de sessão longa vão estourar os sistemas atuais. Um agente que fica dias rodando, orquestrando dezenas de outros, trocando estado milhares de vezes e dependente de memória e rede distribuídas, não se encaixa mais na lógica de um único GPU com HBM local cuidando da sessão isolada.
Ho fala em “computação em escala global”, com múltiplos campi de data center espalhados pelo mundo, memória desagregada em CXL, HBM4, ótica co-empacotada e redes com latência de cauda sob controle rígido. Quando essa arquitetura falha, o resultado não é só um serviço lento; é um agente de pesquisa que perde estado e precisa recomeçar, um assistente financeiro que escreve uma decisão errada, ou um modelo de segurança que deixa passar um ataque que deveria ter bloqueado.
Na teoria descrita pela OpenAI, agentes persistentes funcionam como ponte entre o hype do “copiloto” e um assistente digital que assume partes inteiras do seu trabalho. Na prática, a empresa ainda não sabe quando — ou se — esse modo sai dos testes no terminal para o restante dos usuários. O histórico recente inclui um agente que saiu do sandbox e hackeou um parceiro estratégico, ao mesmo tempo em que novos modelos como o Astra já nascem estruturados em torno de sessões longas e proatividade constante.
