Seus agentes deixam processos para trás.
O AgentsRoom os encontra.
Um agente de IA inicia um processo de sistema de verdade a cada ferramenta que chama. A maioria termina em segundos. Alguns nunca terminam, e esses seguram gigabytes de memória sem usar nada de CPU.
O guardião varre os processos filhos dos seus agentes, sinaliza os que pararam de progredir, nomeia o agente responsável, e deixa você terminá-los com um clique. Nada é encerrado nas suas costas.
O que o guardião realmente olha: os processos que um agente iniciou, e quais deles pararam de trabalhar.
Um agente de IA não é um processo. Cada chamada de ferramenta que ele faz inicia um processo de verdade na sua máquina: uma busca, um build, uma verificação de tipos, uma rodada de testes, um script. Multiplique isso por alguns agentes trabalhando em paralelo, ao longo de um dia inteiro, e você tem centenas de processos que nascem e são enterrados sem que você veja um único deles.
Quase todos terminam. O problema são os que não terminam. Uma busca cujo padrão faz o motor de expressões regulares explodir não quebra e não fica lenta: ela aloca, é empurrada para a memória comprimida, e passa o resto da vida em falhas de página a 4% de CPU. Ela nunca vai terminar. Nada nunca vai matá-la. E se o agente que a iniciou for fechado, ela é reanexada ao processo de init e vira um órfão pelo qual ninguém na máquina é mais responsável.
É por isso que a lentidão chega de fininho. Não é um evento dramático, é um acúmulo lento ao longo do dia de trabalho, e esse é exatamente o formato que faz as pessoas culparem a coisa errada: superaquecimento, agentes demais, um vazamento de memória no app. Na sessão que medimos, o próprio app usava 2,8 GB em 91 processos e as oito CLIs de agentes 1,6 GB entre todas. Nenhum dos dois era o problema.
O guardião de processos é a rede de segurança. Ele vigia o que os agentes deixam para trás, diz qual processo está travado e quem o iniciou, e deixa você terminá-lo. As causas raiz vão continuar mudando: outra ferramenta, outro padrão, outro fornecedor. A rede não precisa mudar.
Por que uma máquina que roda agentes de IA fica lenta
Os números abaixo vêm de uma sessão medida em um notebook de 16 GB com oito agentes rodando. Nada aqui é estimativa.
A máquina estava ligada havia cinco horas e meia. Nenhum problema térmico: nenhum throttling registrado, bateria a 30,6 °C. O load average ficava entre 17 e 21 em 8 núcleos, e a CPU passava 56% do tempo dentro do kernel para 1,5% de ociosidade. É essa proporção que entrega tudo. Uma máquina que faz trabalho de verdade passa o tempo em código de usuário; uma máquina com 56% de tempo de sistema é um kernel que só faz comprimir, descomprimir e mandar memória para o swap.
Sete processos de busca travados seguravam entre 3,9 e 8,0 GB cada um, 41,8 GB reivindicados no total em uma máquina com 16 GB de RAM. O swap estava em 22,3 GB de 23,5, e cerca de 993 GB tinham sido escritos em swap desde o boot. Terminar esses sete processos devolveu 15,5 GB na hora, sem reiniciar um único agente e sem reiniciar o app.
O motivo de ninguém pegar isso na mão é que as ferramentas de sempre mentem sobre o assunto. No macOS um processo travado pode mostrar 20 MB de memória residente enquanto segura 8 GB de verdade, porque tudo que ele tocou passou pelo compressor de memória. Medimos um ao vivo com 4,7 GB de residente para uma pegada real de 14 GB. O tamanho virtual também não ajuda: nessa plataforma até o launchd reporta uns 440 GB de tamanho virtual, então filtrar por ele sinaliza a máquina inteira.
A mesma sessão, hora a hora: os blocos de memória que ninguém usa mais, e o que acontece quando eles são liberados.
E esses processos têm quatro propriedades que garantem que eles ainda vão estar aí amanhã.
Eles nunca terminam
A memória deles está no swap, então passam o tempo em falhas de página em vez de calcular. Uma busca saudável satura um núcleo; esses ficam em 4%. Não existe saída dessa espiral, e esperar não adianta nada.
Eles nunca morrem
Não existe timeout em uma chamada de ferramenta. Nada na máquina tem opinião sobre um processo parado há cinquenta minutos. Ele vai ficar ali até alguém matá-lo ou a máquina reiniciar.
Eles sobrevivem ao próprio agente
Feche a aba do agente e o processo pode sobreviver, reanexado ao processo de init. A partir daí nada mais o liga a coisa alguma: ele é um órfão, e ninguém nunca vai recuperá-lo. Dois dos sete que medimos já estavam nesse estado.
Eles se acumulam
Um por rodada de verificação, um por busca azarada. É por isso que a lentidão só aumenta ao longo do dia e por isso que reiniciar parece resolver. Não resolve nada, só zera a contagem.
O que o guardião de processos faz
Ele vigia os processos que seus agentes iniciam, e é deliberadamente estreito sobre quais deles vai tocar.
Mede a memória real
Não o tamanho residente, que subestima um processo travado em vários gigabytes. O guardião lê a pegada real, com páginas comprimidas e páginas mandadas para o swap incluídas, então um processo que mostra 20 MB e segura 8 GB é visto pelo que é.
Olha a CPU, não só a RAM
Só a memória sinalizaria todos os builds da sua máquina. O guardião mede o uso do processador como uma taxa entre duas varreduras, então um processo que trabalhou muito e depois travou ainda é pego, e um build que está trabalhando de verdade é deixado em paz.
Pega processos órfãos
Um processo que sobreviveu ao agente que o iniciou é reportado por mérito próprio, porque ninguém mais vai recuperá-lo. A propriedade é memorizada enquanto o processo ainda está anexado, que é o único momento em que dá para estabelecê-la.
Um clique para terminar
Uma pastilha na barra de status lista cada processo travado com o agente que o criou, sua memória, sua idade e sua CPU. Terminar um encerra ele e tudo o que ele mesmo tiver criado. A memória volta imediatamente e seus agentes continuam rodando.
macOS, Windows e Linux
Cada sistema precisa de uma medida diferente para dizer a verdade sobre a memória: páginas comprimidas no macOS, residente mais swap no Linux, private commit no Windows. Os três estão implementados, não planejados.
Custa quase nada
Um snapshot dos processos por minuto, medido em cerca de 40 ms em uma máquina rodando 824 processos. A sondagem de memória cara só roda quando algo já parece travado, e nenhuma varredura roda enquanto nenhum agente estiver ativo.
A regra que impede o alarme falso
Um guardião que sinaliza seus builds é um guardião que você desliga em uma semana. Então um processo nunca é reportado só pela memória. Ele precisa ser grande, precisa estar vivo há um tempo, e precisa ter parado de usar o processador. Os três ao mesmo tempo.
É a terceira condição que faz o trabalho. Uma verificação de tipos ou um bundler também seguram gigabytes por minutos, mas saturam um núcleo enquanto fazem isso. Um processo preso no swap fica em torno de 4%, porque passa a vida esperando falhas de página em vez de calcular. Essa diferença é o que separa uma máquina que está trabalhando de uma máquina que está afundando, e é o único sinal que separa as duas de forma confiável.
O uso do processador também é medido, não lido. O número que uma ferramenta de sistema costuma reportar é uma média sobre a vida inteira do processo, que ainda parece ocupada para algo que trabalhou vinte minutos e depois travou. O guardião compara o tempo de processador consumido entre duas varreduras, então o que ele vê é o último minuto, não a última hora.
Como funciona
Quatro etapas, uma vez por minuto, e a etapa cara quase nunca roda.
Um snapshot barato da máquina
A cada minuto o guardião tira um único snapshot de todos os processos em execução e percorre a árvore abaixo de cada terminal de agente. Custo medido em uma máquina rodando 824 processos: cerca de 40 ms. Enquanto nenhum agente estiver rodando, isso nem acontece.
Separar os suspeitos
Desse snapshot ele guarda só os processos filhos de agentes que estão vivos há mais tempo que o seu limite e não usam mais o processador. Em uso normal essa lista fica vazia, e tudo para por aí.
Medir os que parecem travados
Só para essa lista curta o guardião paga a medição de memória real, com páginas comprimidas e mandadas para o swap incluídas. Um processo que ele não consegue medir nunca é sinalizado: uma incógnita não é um veredito.
Reportar, e deixar você decidir
Uma pastilha aparece na barra de status e um único aviso te conta sobre ela uma vez. Você abre a lista, vê o que é o processo, quanto ele segura, há quanto tempo está travado e qual agente o iniciou, e termina ele se quiser.
No que ele nunca vai tocar
Uma ferramenta capaz de terminar processos precisa ser bem estreita sobre o que considera da sua conta. Esses limites são estruturais, não opções que você precisa lembrar de ligar.
- A própria CLI do agente. Seja qual for o fornecedor que você usa, o guardião protege o binário com o qual o app iniciou aquele terminal. Ele lê esse nome do próprio lançamento em vez de uma lista fixa no código, então um subprocesso da mesma CLI também está protegido, em qualquer profundidade.
- Seus terminais de comandos dev. Um servidor de dev parado marca todos os critérios de processo travado: gordo, antigo, sem uso de processador. Ele também é justamente o processo que você quer ver rodando. Só os terminais de agentes são vigiados, então seu servidor de dev nunca entra no quadro.
- O shell e o encanamento do próprio app. O helper de terminal e o shell em que um agente roda são excluídos por construção. Só os processos de ferramentas abaixo da CLI do agente chegam a ser candidatos.
- Qualquer coisa que ele não tenha adotado. O único caminho capaz de terminar um processo recusa qualquer processo que o guardião não tenha recolhido da árvore de um agente. Ele não pode virar um jeito de encerrar outra coisa na sua máquina.
E nada é terminado automaticamente sem que você peça. Por padrão o guardião reporta o que encontrou e você decide, porque é você quem sabe se um processo grande e silencioso era esperado.
Quando ele justifica o lugar dele
Cada uma dessas situações é real, nenhuma é hipotética.
A máquina mais lenta às 18h do que às 9h
Nenhum momento exato em que quebrou, só uma descida constante ao longo do dia. Esse formato é quase sempre processos travados acumulados, e é o mais difícil de diagnosticar na mão porque em nenhum instante nada parece errado.
Vários agentes trabalhando em paralelo
Quanto mais agentes você roda, mais chamadas de ferramenta acontecem, e mais chances de uma delas travar. A taxa de falha por chamada é minúscula; multiplicada por um dia de trabalho em paralelo ela deixa de ser minúscula.
Uma busca que nunca volta
Um padrão que faz o motor de expressões regulares explodir aloca gigabytes em cima de um arquivo de algumas centenas de kilobytes. O agente espera por ela, você espera pelo agente, e a máquina paga pelos dois.
Você fechou o agente, o processo ficou
Fechar uma aba nem sempre libera alguma coisa. Um processo que já estava desanexado mantém a memória dele e perde o último vínculo com qualquer coisa visível no app.
Um notebook com 16 GB
Em uma máquina com bastante RAM alguns processos travados se escondem por muito tempo. Em um notebook de 16 GB eles chegam ao swap rápido, e assim que o sistema começa a comprimir memória todos os agentes ficam mais lentos ao mesmo tempo.
Antes de culpar o app
Quando a máquina se arrasta com o AgentsRoom aberto, o app é o suspeito óbvio. Ter os números reais, processo por processo, com o agente que iniciou cada um, transforma uma suspeita em algo que dá para conferir.
Você define os limites
Os padrões são deliberadamente cautelosos. Tudo abaixo fica nas configurações, na aba Terminal, e cada um desses ajustes também pode ser lido e alterado por um agente pelas ferramentas MCP do AgentsRoom.
- Vigiar os processos filhos dos agentes
- Ligado por padrão. Desligue e nenhuma varredura roda, nunca.
- Reportar acima de um limite de memória
- Dois gigabytes por padrão. Abaixo disso, um processo travado não vale a interrupção. Aumente o limite em uma workstation com bastante RAM, diminua em um notebook onde a memória é contada.
- Depois de um tempo de vida mínimo
- Cinco minutos por padrão. É o que impede que uma tarefa lenta mas legítima seja sinalizada algum dia, já que quase nada do que você realmente quer leva cinco minutos sem usar nada de processador.
- Terminar processos travados automaticamente
- Desligado por padrão, e isso é uma decisão de produto assumida, não cautela. O guardião está emitindo um julgamento, e só você sabe se um processo grande e silencioso era esperado. Ligue e ele age sozinho, com uma notificação depois do fato.
O limite de processador não é exposto, de propósito. É a medição que separa um build que trabalha de um processo travado, e não é questão de gosto.
Perguntas frequentes
Isso quer dizer que o AgentsRoom deixa meu computador lento?
Não, e é exatamente por isso que o recurso existe. Na sessão que medimos, o app usava 2,8 GB em 91 processos e as oito CLIs de agentes 1,6 GB entre todas. Os 41,8 GB estavam nas mãos de processos de ferramentas que tinham travado. O AgentsRoom por acaso é o único lugar de onde dá para ver todos os agentes e todos os processos que eles criaram, então é o único lugar de onde dá para arbitrar.
Isso vai matar meu build ou minha rodada de testes?
Não. Um processo só é sinalizado quando é grande E antigo E parou de usar o processador. Um build que está trabalhando de verdade satura um núcleo, então falha na terceira condição e nunca é candidato. Essa condição existe justamente para fazer essa distinção.
Ele vigia meu servidor de dev?
Não, e nunca vai vigiar. Um servidor de dev parado marca todos os critérios: segura muita memória, está rodando há horas, e não usa processador entre as requisições. Só os processos filhos de terminais de agentes são vigiados, então seus comandos dev estão fora do escopo por construção.
Ele pode terminar o próprio agente?
Não. A CLI do agente é protegida seja qual for o fornecedor que você usa, e a proteção se baseia no binário com o qual o app iniciou aquele terminal, não em uma lista de nomes conhecidos. O shell e o helper de terminal do próprio app também estão excluídos.
O que é um processo órfão e por que ele recebe um tratamento à parte?
Um processo cujo pai já terminou é reanexado ao processo de init do sistema. A partir desse momento nada mais o liga ao agente que o iniciou, então ninguém nunca vai limpá-lo. O AgentsRoom memoriza a propriedade enquanto o processo ainda está anexado, que é o único momento em que dá para estabelecê-la, e por isso ele consegue reportar o processo mesmo depois.
Quanto custa a própria vigilância?
Um snapshot dos processos por minuto, medido em cerca de 40 ms em uma máquina rodando 824 processos. A medição de memória mais cara só roda em processos que já parecem travados, o que em uso normal quer dizer que ela não roda. E a varredura não existe enquanto nenhum agente estiver ativo.
Por que não olhar só a coluna de memória do Monitor de Atividade?
Porque no macOS ela subestima o problema em uma ordem de grandeza. Um processo empurrado para a memória comprimida pode mostrar 20 MB de residente enquanto segura 8 GB. Medimos um ao vivo com 4,7 GB de residente para uma pegada real de 14 GB. O tamanho virtual não é melhor: até processos de sistema reportam centenas de gigabytes dele.
Funciona com Claude Code, Codex e os outros?
Sim. O guardião não sabe nada sobre nenhuma ferramenta ou fornecedor específico. Ele vigia os processos filhos de qualquer terminal de agente que você tenha iniciado, e a CLI que ele protege é lida do próprio lançamento. Adicionar um fornecedor não muda nada aqui.
Funciona no Windows e no Linux?
Sim. Cada plataforma precisa de uma medição diferente para a memória ser honesta: páginas comprimidas no macOS, residente mais swap no Linux, private commit no Windows. Os três estão implementados.
Ele vai terminar processos sem me perguntar?
Não, a menos que você ligue isso. Por padrão ele reporta o que encontrou, com o agente, a memória, a idade e o uso do processador, e você decide. A terminação automática é uma configuração, desligada de fábrica.
O que acontece com o agente quando eu termino um dos processos dele?
O agente continua rodando. A chamada de ferramenta dele recebe um erro em vez de ficar pendurada para sempre, que é justamente o resultado que você quer: o processo não ia terminar de jeito nenhum. Nada é reiniciado e nenhum contexto é perdido.
Isso corrige a causa raiz?
Não, e nem tenta. As causas mudam: uma ferramenta hoje, outro padrão amanhã, outro fornecedor mês que vem. Isso é uma rede de segurança, feita para continuar funcionando quando a causa for uma que ninguém viu ainda.
Você também pode gostar
Canário de contexto
O outro alerta precoce: ele vigia o contexto do próprio agente em vez da máquina, e te avisa quando um agente está derivando antes que ele comece a inventar arquivos e APIs.
Terminais dev
Rode seus servidores de dev e seus comandos longos no AgentsRoom, com uma notificação quando um comando longo termina. Esses terminais são exatamente os que o guardião de processos foi feito para nunca tocar.
Acompanhamento de status dos agentes
Veja de relance quais agentes estão trabalhando, quais estão esperando por você e quais estão ociosos, sem ler um único terminal.
Consumo de tokens
O outro recurso que vale a pena vigiar. Consumo de tokens e cota por agente, para você saber para onde vai seu uso.
Vista dividida
Vários agentes lado a lado em uma janela só, cada um com seu painel, sua cor e seu status ao vivo.
CLI Doctor
Quando um agente não consegue iniciar, ele te diz por quê e o que fazer, em vez de deixar um terminal em branco.
Pare de pagar por processos que ninguém está usando
O AgentsRoom é gratuito para baixar, e o guardião de processos fica ligado desde o primeiro lançamento.
App complementar: acompanhe seus agentes em qualquer lugar
Use Claude, Codex, Antigravity CLI ou outro provedor de IA.
Envie bugs e pedidos direto para o seu backlog público.
Uma visão do AgentsRoom em ação.