MemMux governa memória de frotas de agentes de código

O que aconteceu

O paper arXiv:2610.07257v1, submetido em 5 de outubro de 2026, descreve o MemMux como um runtime local que converte governança de recursos em sinais que um operador ou auditor pode checar enquanto os agentes rodam. A lista inclui atribuição de memória por agente, recuperação completa de processos, visibilidade de processos filhos que escaparam, pegada limitada sob overcommit e custo de monitoramento.

O MemMux foi comparado em benchmark contra o tmux, contra um multiplexador de agentes feito sob medida e contra uma linha de base de processos crus, todos rodando as mesmas cargas. Em um host Linux com orçamento de memória vinculante, o MemMux manteve a frota abaixo do teto de 7,5 GiB com zero swap, admitindo um subconjunto de agentes e recuperando memória sob pressão. As ferramentas sem governança rodaram todos os agentes, cravaram a máquina no teto de RAM, o equivalente ao dobro do orçamento, e derramaram cerca de 2 GiB em swap.

Nos testes de encerramento, o MemMux recuperou 100% da subárvore de processos de um agente terminado, enquanto a linha de base de processos crus deixou metade dela presa. O sistema também foi o único a expor processos filhos que escaparam do agente controlador, detectando 10 de 10 casos.

O custo aparece nas medições de CPU. A varredura de atribuição, executada a 1 Hz, consome perto de 0,6% de CPU com um agente e 2,7% com dez agentes, acima da meta de 2% declarada pelos próprios autores. Rodando o harness em sessões reais do Claude Code, o MemMux manteve 100% de atribuição e overhead baixo em árvores de agentes ao vivo. O código do motor, o benchmark e um reprodutor de comando único foram liberados.

Contexto

O problema nasce de um hábito recente entre desenvolvedores: rodar vários agentes de código lado a lado em uma única workstation. Quando dez agentes disparam, cada um, servidores de linguagem, executores de teste e navegadores, as ferramentas disponíveis não conseguem dizer quanto de memória pertence a cada agente.

As opções mais usadas vieram de outra era. O tmux e a nova geração de gerenciadores de agentes foram construídos para organizar janelas, não para governar memória. É por isso que nenhuma delas confirma se os descendentes de um agente encerrado sumiram de fato, nem percebe um processo filho que escapou do controle.

O paper enquadra tudo isso como problemas de verificação em tempo de execução. A tese é que o substrato que hospeda agentes deveria emitir sinais observáveis de forma contínua, em vez de deixar o operador descobrir o consumo depois que a máquina já está no limite.

Por que importa

O risco concreto é o swap. Quando o sistema operacional precisa liberar RAM e o Linux dispara um OOM kill, o trabalho ainda não commitado de um agente pode ser descartado em silêncio. Sem atribuição por agente, não há como saber qual sessão foi sacrificada nem quanto cada agente consumia.

Para quem roda frotas de agentes em servidores de desenvolvimento ou estações de trabalho, o MemMux propõe uma alternativa mensurável: em vez de aceitar todos os agentes e travar, admite um subconjunto dentro do orçamento e vai recuperando memória conforme a pressão sobe. O ganho é previsibilidade, e o preço é a CPU gasta na varredura de atribuição.

Impacto

A diferença de comportamento entre os dois cenários é grande. De um lado, uma máquina com o dobro do orçamento em uso e 2 GiB em swap. Do outro, a frota contida em 7,5 GiB e sem swap. Em ambientes de CI, notebooks de pesquisa e servidores compartilhados, essa margem decide se a máquina continua respondendo ou se perde trabalho.

A detecção de processos escapados, com 10 de 10 casos identificados, ataca um problema recorrente em frotas: o processo órfão que continua consumindo recursos depois que o agente que o criou já morreu. A recuperação de 100% da subárvore encerrada ataca o mesmo ponto por outro ângulo, evitando que metade dos processos fique pendurada.

O que muda

O trabalho desloca a discussão de gerenciamento visual de terminais para verificação de recursos. O MemMux não se apresenta como um organizador de janelas, e sim como um substrato que emite provas checáveis sobre o que cada agente consome e o que sobrou depois que ele termina.

A meta de overhead não foi atingida. Com dez agentes, a varredura consome 2,7% de CPU contra o alvo de 2%. Esse número fica registrado no próprio paper, junto com as demais medições, como parte da disciplina de alegações que os autores descrevem no benchmark.

O que vem agora

O motor, o benchmark e o reprodutor de comando único já estão disponíveis. O paper não anuncia adoção por empresas, integração com gerenciadores de agentes comerciais nem cronograma para reduzir o custo da varredura de atribuição.

Os testes com sessões reais do Claude Code indicam que a atribuição de 100% e o overhead baixo se mantêm em árvores de agentes ao vivo, o que aponta o próximo passo natural de avaliação. Faltam dados sobre outros hosts além do Linux usado no experimento e sobre cargas diferentes daquelas do benchmark.

Fontes

• arXiv cs.AI: MemMux: Runtime Verification and Honest Resource Attribution for Fleets of Parallel Coding Agents (https://arxiv.org/abs/2610.07257)