Como o Codex resolve o problema de compactação

Se você usou o Claude Code em qualquer sessão séria de programação, já viu isso: “Compacting conversation…” aparece no terminal, e a partir daí algo começa a parecer errado. O modelo começa a esquecer coisas que você discutiu dez minutos atrás. A latência das respostas sobe. Você pergunta sobre uma função que acabou de refatorar juntos, e ele responde como se estivesse ouvindo falar dela pela primeira vez.

Isso acontece porque a janela de contexto de 200K tokens do Claude Code se esgota mais rápido do que a maioria das pessoas espera. Uma sessão grande de refatoração, algumas leituras de arquivo, chamadas de ferramentas com output verboso, e você já está no limite. Quando esse threshold é atingido (em torno de 75-92% da janela, embora eu já tenha visto disparar com 65%), o Claude Code sumariza a conversa, descarta as mensagens originais e continua apenas com o resumo. O que não entrou no resumo está perdido.

Ouvia muito que o Codex da OpenAI lidava com isso de forma diferente, então passei um tempo desmontando toda análise pública que consegui encontrar. O trabalho mais interessante veio de Kangwook Lee, CAIO da Krafton, que usou injeção de prompt para fazer engenharia reversa do pipeline real.

O que a compactação perde e por que isso importa

O problema central é direto. Sumarização é compressão com perda. Quando o Claude Code compacta, ele executa uma sumarização em background da conversa completa, cria um bloco de compactação e descarta tudo que veio antes. Arquivos CLAUDE.md sobrevivem porque são relidos do disco, mas qualquer coisa que você disse apenas na conversa desaparece, a menos que o sumarizador tenha capturado.

Os resultados de chamadas de ferramentas são onde isso mais dói. Quando você pede ao Claude Code para ler um arquivo, o conteúdo completo entra no contexto. Quando você executa um comando, o output completo entra no contexto. Esses resultados de ferramentas são frequentemente as partes mais densas em informação da conversa, e são exatamente o que é achatado durante a sumarização. Uma leitura de arquivo com 500 linhas vira uma única frase como “leu o arquivo de configuração e anotou as configurações do banco de dados.” Os valores específicos, os edge cases que você discutiu, os números de linha que você referenciou: tudo perdido.

Já vi isso acontecer dezenas de vezes. Após a compactação, pergunto “qual era o tipo de retorno daquela função auxiliar que vimos?” e recebo uma resposta errada com confiança. O modelo não está alucinando no sentido usual. Está trabalhando a partir de um resumo que genuinamente não contém o que estou perguntando.

Após 9 ou mais compactações em uma sessão longa, o problema se agrava. Cada resumo comprime ainda mais o resumo anterior. A justificativa de decisões tomadas no início da sessão se deteriora completamente. Na décima hora de uma sessão, o modelo não tem memória de por que você escolheu a abordagem A em vez da B, mesmo que você tenha passado vinte minutos discutindo os trade-offs.

Por dentro do pipeline de compactação criptografada do Codex

A análise de Kangwook Lee foi engenhosa. Ele usou duas injeções de prompt encadeadas para extrair o comportamento interno do sistema de compactação do Codex.

A primeira injeção mirou o próprio LLM compactador. Quando o Codex dispara a compactação, ele não apenas sumariza localmente. Ele envia a conversa para um LLM separado nos servidores da OpenAI, que produz um resumo. A injeção de Lee enganou esse compactador para incluir seu próprio system prompt no output do resumo. O servidor então criptografou esse resumo (agora contendo o prompt vazado) com AES e o retornou como um blob opaco.

A segunda injeção explorou a etapa de decriptação. Ao passar o blob criptografado mais uma mensagem de usuário criada de volta para a Responses API, o servidor decriptou o blob e montou o contexto do modelo. Como a primeira injeção tinha embutido o system prompt do compactador dentro do resumo, o contexto decriptado revelou como o pipeline inteiro funciona.

Eis o que ele descobriu: quando você chama a API compact() do Codex, um LLM separado sumariza a conversa, e o resultado volta criptografado com AES. No próximo turno, o servidor decripta esse blob, prepende um prompt de handoff (“aqui está um resumo da conversa anterior”) e alimenta tudo isso ao modelo. A chave de criptografia vive nos servidores da OpenAI. O cliente nunca vê o resumo em texto claro.

O prompt de compactação em si se revelou quase idêntico ao template de compactação do Codex CLI open-source para modelos não-Codex. Nenhum molho secreto na engenharia de prompt. A parte interessante é a arquitetura: criptografia de resumos no lado do servidor, decriptação e injeção no lado do servidor, e um blob opaco que o cliente passa adiante sem conseguir inspecionar ou modificar.

Por que criptografar? A análise de Lee não respondeu definitivamente a isso. Uma teoria é que o blob criptografado contém mais do que apenas um resumo de texto: dados de restauração de chamadas de ferramentas, marcadores de estado interno ou metadados estruturados que a OpenAI não quer expor. Outra possibilidade é simplesmente que blobs criptografados impedem usuários de adulterar o resumo para manipular o comportamento do modelo. Acho a segunda explicação mais provável, mas nenhuma está confirmada.

A OpenAI também suporta isso no lado do servidor através da Responses API. Defina um valor de compact_threshold e, quando a contagem de tokens cruzar esse limite, o servidor executa a compactação inline. O item de compactação é transmitido de volta dentro da resposta, e você o acrescenta às requisições subsequentes. Itens anteriores ao item de compactação mais recente podem ser descartados com segurança.

Contraste isso com a abordagem do Claude Code: o bloco de compactação é legível por humanos. Você pode inspecioná-lo, e pode customizar o comportamento de compactação através do parâmetro instructions ou adicionando diretivas de compactação personalizadas ao CLAUDE.md. Mais transparente, mas a mesma perda fundamental de informação se aplica.

O padrão de session handover

Deixando de lado a mecânica de compactação, o problema mais interessante é o que acontece quando você precisa iniciar uma nova sessão sem perder contexto. Foi aqui que vi a automação de um desenvolvedor que mudou como eu penso sobre o problema.

O padrão funciona assim. Logo antes da compactação disparar, um hook pré-compactação bloqueia todas as ferramentas de escrita. Isso impede o modelo de fazer alterações no código enquanto está em um estado parcialmente consciente, que é um modo de falha que já enfrentei várias vezes: a compactação dispara no meio de uma refatoração, o modelo perde o controle de quais arquivos já alterou e escreve edições conflitantes.

Com as escritas bloqueadas, o sistema extrai apenas mensagens do usuário e blocos de thinking do log de sessão JSONL. Todo o resto (chamadas de ferramentas, conteúdos de arquivos, respostas do assistente) é descartado. Isso reduz o log para cerca de 2% do seu tamanho original.

Em seguida, três sub-agentes rodam em paralelo, cada um pesquisando os logs JSONL originais não comprimidos em busca de informações que a extração perdeu. Eles procuram lacunas: decisões arquiteturais que foram discutidas mas não capturadas nas mensagens do usuário, padrões de erro que apareceram apenas no output de ferramentas, justificativa para abordagens que foram rejeitadas. Esses agentes compilam suas descobertas em um arquivo resume-prompt.md que contém o resumo da sessão, os resultados da análise de lacunas e uma lista de arquivos modificados.

Um file watcher do VS Code detecta o novo resume-prompt.md e abre uma sessão nova que o carrega como contexto inicial. A nova sessão começa com uma visão clara e completa de onde a sessão anterior parou.

A melhoria relatada foi de 10x em eficiência de build. Esse número é difícil de verificar independentemente, mas a arquitetura faz sentido. Em vez de um resumo cada vez mais degradado, você tem uma janela de contexto nova com um documento de handover curado e com análise de lacunas.

Tentei implementar uma versão mais simples disso por conta própria. A etapa de análise de lacunas é onde o valor se concentra. Sem ela, você está apenas fazendo o que a compactação já faz, mas em um formato diferente. Com ela, você está ativamente recuperando informações que a sumarização perdeu. Minha versão usa um único sub-agente em vez de três, e os resultados são visivelmente melhores do que a compactação bruta, mas provavelmente não tão completos quanto a abordagem completa com três agentes.

KV cache como alavanca oculta de custo

Há uma dimensão de performance nisso que a maioria das discussões ignora completamente. KV cache (os pares chave-valor computados durante a atenção) pode ser reutilizado entre requisições quando o prefixo do prompt é idêntico. Duas requisições compartilhando os mesmos tokens iniciais pulam a recomputação para esses tokens.

Os números são significativos. Em um teste controlado comparando system prompts estáveis versus perturbados, prefixos estáveis alcançaram 85% de taxa de hit de cache com mediana de time-to-first-token de 953ms. Prefixos perturbados: 0% de hits de cache, 2.727ms de TTFT. O custo por requisição caiu de $0,033 para $0,009. Isso é uma redução de 65% na latência e 71% no custo apenas por manter o prefixo do prompt consistente.

Isso tem implicações diretas para o padrão de session handover. Se o seu resume-prompt.md sempre começa com o mesmo prefixo estrutural (system prompt, instruções de handoff, depois conteúdo variável), a parte fixa é cacheada. Toda requisição subsequente na nova sessão se beneficia desse cache. Se você randomiza a estrutura do prefixo ou injeta conteúdo variável no início, toda requisição recomputa do zero.

Projetei a estrutura de pastas de sessão em torno dessa percepção. Arquivamento baseado em session-id mantém os documentos de handover organizados, e a convenção de prefixo fixo para resume prompts significa que os primeiros 40-50K tokens de cada nova sessão acertam o KV cache. A pré-indexação de arquivos de sessão com QMD (uma ferramenta que abordei separadamente) acelera a etapa de recuperação quando sub-agentes precisam pesquisar sessões históricas.

O que realmente importa aqui

A conclusão real não é que a abordagem do Codex é melhor ou pior do que a do Claude Code. Ambos perdem informação durante a compactação. Ambos têm dificuldades com sessões longas. A diferença arquitetural (blob opaco criptografado versus bloco de compactação legível por humanos) reflete filosofias de design diferentes, mas a limitação fundamental é a mesma: janelas de contexto são finitas, e sumarização tem perda.

O que importa é o que você constrói em torno dessa limitação. O padrão de session handover, análise de lacunas, recuperação baseada em JSONL, otimização de KV cache: essas são soluções de engenharia para um problema que nenhuma melhoria de modelo vai resolver completamente. Uma janela de contexto de 500K ou 1M tokens adia o problema, mas não o elimina.

O gargalo nas ferramentas de programação com IA não é a inteligência do modelo. É a gestão de contexto. Já vi isso em primeira mão: um resumo medíocre com boa recuperação supera um resumo excelente sem recuperação todas as vezes. Construir sistemas que recuperam informações esquecidas de forma confiável importa mais do que construir sistemas que sumarizam com mais precisão.

Detalhes técnicos obtidos da análise de Kangwook Lee e da documentação pública da API da OpenAI e da Anthropic.