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 basta um punhado deles rodando ao mesmo tempo para encher a memória de uma máquina.
O guardião de processos varre os processos filhos dos seus agentes, sinaliza os que estão comendo sua memória, um a um ou em grupo, nomeia o agente responsável e deixa você interrompê-lo. 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 enquanto o kernel manda gigabytes para o swap por causa dela. Ela nunca vai terminar. Nada nunca vai matá-la. E se o agente que a iniciou for fechado, ela 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. E não ficam parados enquanto isso: os processos desgovernados que medimos queimavam cada um entre 10 e 19% de um núcleo, e quanto mais deles se acumulam, menos sobra para cada um. 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. Cada sistema quebra o vínculo de um jeito: o Unix clássico reanexa o processo ao init, um desktop Linux ao seu gerenciador de usuário do systemd, e o Windows não reanexa nada e deixa o processo apontando para um pai que não existe mais. Por isso o guardião nunca olha para os pais. Ele lembra o que adotou enquanto o vínculo ainda existia, e trata como órfão tudo o que falta na árvore de processos viva, igual nos três sistemas. Dois dos sete que medimos já estavam nesse estado.
Eles se acumulam
Um por rodada de verificação, um por busca azarada, e mais um toda vez que um agente confunde um comando lento com um comando travado e o inicia de novo. Medimos doze verificações de tipos rodando ao mesmo tempo, iniciadas por seis agentes, dois deles com três em andamento cada. É 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 é.
Mede o processador, nunca confia nele
O uso do processador é lido como uma taxa entre duas varreduras, não como a média de vida inteira que uma ferramenta de sistema reporta, então um processo que trabalhou muito e depois travou continua sendo pego. O que isso traz é um critério mais exigente para algo que ainda está trabalhando, nunca um passe livre: um processo desgovernado queimando um quinto de um núcleo é exatamente o que a primeira versão deste guardião deixava escapar.
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.
Vê o grupo, não só o caso extremo
Doze verificações de tipos de 1,4 GB cada uma dão 16,8 GB numa máquina de 16 GB, e cada uma delas sozinha fica abaixo de um limite sensato. Quando os processos que seus agentes iniciaram enchem juntos metade da memória física da máquina, o tamanho deixa de ser julgado um de cada vez.
Nomeia o agente responsável
Dois ou mais comandos sinalizados do mesmo agente são agrupados sob o avatar dele, com o que seguram juntos e um aviso explicando o ciclo em que estão presos. Um comando é um acidente; vários ao mesmo tempo são um comportamento.
Interrompe o agente, não só o processo
Terminar um processo enquanto o agente está no meio do turno entrega a esse agente um erro ao qual ele reage, muitas vezes rodando o comando de novo. Em vez disso, um botão envia Ctrl+C para o terminal do agente: o turno dele acaba, nada é relançado, e o agente continua aberto.
As regras que impedem o alarme falso
Um guardião que sinaliza seus builds é um guardião que você desliga em uma semana, então o critério é propositalmente exigente. Todo processo filho de um agente que esteja vivo há mais tempo que o seu limite tem a memória real medida, e é reportado assim que segura mais do que você permitiu. Um processo que ainda usa o processador precisa segurar o dobro disso, e é isso que mantém um build longo e legítimo fora do caminho.
O uso do processador define esse critério; ele não é um filtro de entrada. A primeira versão deste guardião exigia que um processo estivesse ocioso antes de sequer olhar para a memória dele, e isso estava errado. Uma busca cujo padrão faz o motor de expressões regulares explodir não está ociosa: ela queima um quinto de um núcleo enquanto o kernel manda gigabytes para o swap por causa dela. Pior: quanto mais deles se acumulam, menos processador sobra para cada um, então o ponto cego era maior logo no começo, justamente quando terminar um saía mais barato.
A segunda regra existe porque um critério por processo não consegue enxergar um grupo. Doze verificações de tipos segurando 1,4 GB cada uma são razoáveis sozinhas e fatais em conjunto numa máquina de 16 GB. Então, quando tudo o que os agentes iniciaram soma metade da memória física da máquina, tudo isso é reportado, não importa o quanto cada peça pese sozinha. Nada desse grupo é terminado automaticamente: está abaixo do limite que você definiu, e só foi sinalizado por causa dos vizinhos.
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 todo processo filho de um agente que esteja vivo há mais tempo que o seu limite. Esse é o filtro inteiro, e nada é excluído por ainda estar usando o processador: fazer isso é exatamente como a versão anterior deste guardião deixava escapar os processos desgovernados. Em uso normal essa lista fica vazia, já que as chamadas de ferramenta de um agente terminam em segundos.
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. Mesmo ligada, a terminação automática deixa em paz tudo o que ainda usa o processador, e também tudo o que foi sinalizado apenas por causa do que os vizinhos seguram.
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. Abaixo disso nada é sequer medido, e é isso que mantém as chamadas de ferramenta comuns de um agente, as que terminam em segundos, completamente fora do quadro.
- 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, e o ponto a partir do qual a máquina conta como saturada também não. Os dois já estiveram errados e foram corrigidos medindo incidentes reais em vez de decidir por gosto, então um controle deslizante para qualquer um deles seria principalmente um jeito de trazer o ponto cego de volta.
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?
Ele nunca vai terminar um sem perguntar. Reportar, ele pode: um build precisa segurar o dobro do seu limite, quatro gigabytes por padrão, ou fazer parte de um grupo de processos de agentes que enche metade da memória da sua máquina. Mas a terminação automática nunca toca em um processo que ainda usa o processador, nem em um que foi sinalizado só por causa do que os vizinhos seguram. Nos dois casos você recebe uma linha, os números reais e um botão, e nada acontece até você apertá-lo.
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 perde o vínculo com o agente que o iniciou, e ninguém nunca vai limpá-lo. Como esse vínculo se rompe depende do sistema: o Unix clássico reanexa o processo ao init, um desktop Linux ao seu gerenciador de usuário do systemd, e o Windows não reanexa nada e deixa para trás um id de pai morto. Por isso o AgentsRoom nunca examina os pais. Ele registra a propriedade enquanto o processo ainda está anexado, que é o único momento em que dá para estabelecê-la, e trata como órfão tudo o que falta na árvore de processos viva, igual nos três sistemas.
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.
Doze processos, nenhum deles acima do meu limite. Ele vai dizer alguma coisa?
Vai, e foi justamente esse caso que mudou a regra. Medido numa máquina de 16 GB: doze verificações de tipos iniciadas por seis agentes, de 0,84 a 1,72 GB cada uma, todas bem abaixo de um limite de 2 GB, 15,4 GB no total, swap cheio e a máquina inutilizável. Julgada uma de cada vez, cada uma estava perfeitamente bem. Assim que o total passa de metade da sua memória física, todas são reportadas, agrupadas sob o agente que as iniciou.
O que o botão Interromper o agente faz exatamente?
Ele envia Ctrl+C para o terminal daquele agente, a mesma tecla que você apertaria. O turno em andamento do agente acaba e ele fica esperando por você: ele não é fechado, a sessão dele continua intacta, e nada mais na sua máquina é tocado. Isso existe porque terminar um processo enquanto o agente ainda está trabalhando nele só trata o sintoma: o agente recebe um erro e muitas vezes simplesmente roda o comando de novo.
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.