Tus agentes dejan procesos atrás.
AgentsRoom los encuentra.
Un agente de IA lanza un proceso de sistema real por cada herramienta que llama. La mayoría termina en segundos. Algunos no terminan nunca, y esos retienen gigabytes de memoria sin gastar un solo ciclo de CPU.
El guardián barre los procesos hijo de tus agentes, señala los que han dejado de avanzar, nombra al agente responsable y los termina con un clic. Nada se mata a tus espaldas.
Lo que el guardián mira de verdad: los procesos que lanzó un agente, y cuáles de ellos dejaron de trabajar.
Un agente de IA no es un proceso. Cada llamada a una herramienta arranca uno real en tu máquina: una búsqueda, un build, una comprobación de tipos, una tanda de tests, un script. Multiplica eso por unos cuantos agentes trabajando en paralelo, a lo largo de un día entero, y te salen cientos de procesos que nacen y se entierran sin que tú veas ni uno.
Casi todos terminan. El problema son los que no. Una búsqueda cuyo patrón hace explotar el motor de expresiones regulares no se cae ni se ralentiza: reserva memoria, acaba empujada a la memoria comprimida y luego se pasa la vida en fallos de página al 4 % de CPU. No va a terminar nunca. Nadie la va a matar. Y si se cierra el agente que la lanzó, el sistema la reengancha al proceso init: se convierte en un huérfano del que ya nadie en la máquina es responsable.
Por eso la lentitud se instala poco a poco. No hay un momento en que algo se rompa, hay una acumulación a lo largo de la jornada, y esa es justo la forma que hace culpar a lo que no es: el calentamiento, demasiados agentes, una fuga de memoria de la app. En la sesión que medimos, la app ocupaba 2,8 GB repartidos en 91 procesos y los ocho CLI de agentes 1,6 GB entre todos. Ninguno de los dos era el problema.
El guardián de procesos es la red de seguridad. Vigila lo que los agentes dejan atrás, te dice cuál está bloqueado y quién lo lanzó, y te deja terminarlo. Las causas van a seguir cambiando: otra herramienta, otro patrón, otro proveedor. La red no tiene por qué cambiar.
Por qué se ralentiza una máquina que hace correr agentes de IA
Los números de abajo salen de una sesión medida en un portátil de 16 GB con ocho agentes en marcha. Aquí no hay ninguna estimación.
La máquina llevaba encendida cinco horas y media. Ningún problema térmico: cero throttling registrado, batería a 30,6 C. El load average estaba entre 17 y 21 sobre 8 núcleos, y la CPU pasaba el 56 % de su tiempo en el kernel para un 1,5 % de inactividad. Esa proporción es la que lo delata. Una máquina que trabaja de verdad pasa el tiempo en código de usuario; una máquina al 56 % de tiempo de sistema es un kernel que solo comprime, descomprime y manda memoria al swap.
Siete procesos de búsqueda bloqueados retenían entre 3,9 y 8,0 GB cada uno, 41,8 GB reclamados en total en una máquina con 16 GB de RAM. El swap estaba a 22,3 GB de 23,5, y se habían escrito unos 993 GB en swap desde el arranque. Terminar esos siete procesos devolvió 15,5 GB al instante, sin reiniciar ni un agente y sin reiniciar la app.
Si nadie pilla esto a mano es porque las herramientas de siempre mienten sobre ello. En macOS un proceso bloqueado puede mostrar 20 MB de memoria residente mientras retiene 8 GB de verdad, porque todo lo que tocó pasó por el compresor de memoria. Medimos uno en vivo con 4,7 GB de residente para una huella real de 14 GB. El tamaño virtual tampoco ayuda: en esa plataforma hasta launchd declara unos 440 GB de tamaño virtual, así que filtrar por ahí señala la máquina entera.
La misma sesión, hora a hora: los bloques de memoria que ya no usa nadie, y lo que pasa cuando se liberan.
Y estos procesos tienen cuatro propiedades que garantizan que mañana seguirán ahí.
No terminan nunca
Su propia memoria está en el swap, así que se pasan el tiempo en fallos de página en vez de calculando. Una búsqueda sana satura un núcleo; estos se quedan en el 4 %. De esa espiral no se sale, y esperar no sirve de nada.
No se mueren nunca
No hay ningún tiempo máximo para una llamada a herramienta. Nada en la máquina tiene una opinión sobre un proceso que lleva cincuenta minutos inactivo. Se quedará ahí hasta que alguien lo mate o la máquina se reinicie.
Sobreviven a su agente
Cierra la pestaña del agente y el proceso puede sobrevivir, reenganchado al proceso init. A partir de ahí ya nada lo relaciona con nada: es un huérfano, y nadie lo va a reclamar jamás. Dos de los siete que medimos ya estaban así.
Se acumulan
Uno por pasada de verificación, uno por búsqueda con mala suerte. Por eso la lentitud crece sin parar a lo largo del día y por eso parece que reiniciar lo arregla. No arregla nada, solo pone el contador a cero.
Qué hace el guardián de procesos
Vigila los procesos que lanzan tus agentes, y es deliberadamente estrecho con los que se permite tocar.
Mide la memoria real
No el tamaño residente, que se queda corto por gigabytes con un proceso bloqueado. El guardián lee la huella real, con las páginas comprimidas y las que se fueron al swap incluidas, así que un proceso que muestra 20 MB y retiene 8 GB se ve tal cual es.
Mira la CPU, no solo la RAM
La memoria por sí sola señalaría todos los builds de tu máquina. El guardián mide el uso de procesador como una tasa entre dos escaneos, así que un proceso que trabajó duro y luego se atascó también cae, y un build que está trabajando de verdad se queda tranquilo.
Pilla los procesos huérfanos
Un proceso que sobrevivió al agente que lo lanzó se reporta por derecho propio, porque nadie más lo va a reclamar. La pertenencia se memoriza mientras el proceso sigue enganchado, que es el único momento en el que se puede establecer.
Un clic para terminarlo
Un indicador en la barra de estado lista cada proceso bloqueado con el agente que lo lanzó, su memoria, su edad y su CPU. Terminar uno lo mata junto con todo lo que él mismo haya lanzado. La memoria vuelve de inmediato y tus agentes siguen corriendo.
macOS, Windows y Linux
Cada sistema necesita una medición distinta para decir la verdad sobre la memoria: páginas comprimidas en macOS, residente más swap en Linux, private commit en Windows. Las tres están implementadas, no previstas.
No cuesta casi nada
Una instantánea de procesos por minuto, medida en unos 40 ms en una máquina con 824 procesos en marcha. La medición de memoria cara solo se dispara cuando algo ya parece bloqueado, y mientras no haya ningún agente activo no corre ningún escaneo.
La regla que le impide dar falsas alarmas
Un guardián que te señala los builds es un guardián que desactivas en una semana. Por eso un proceso nunca se reporta solo por su memoria. Tiene que ser grande, tiene que llevar un rato vivo y tiene que haber dejado de usar el procesador. Las tres cosas a la vez.
Es la tercera condición la que hace todo el trabajo. Una comprobación de tipos o un bundler también retienen gigabytes durante minutos, pero mientras lo hacen saturan un núcleo. Un proceso atrapado en el swap se queda en torno al 4 %, porque se pasa la vida esperando fallos de página en lugar de calculando. Esa distancia es lo que separa una máquina que trabaja de una máquina que se ahoga, y es la única señal que las separa de forma fiable.
El uso de procesador además se mide, no se lee. La cifra que suele dar una herramienta del sistema es una media sobre toda la vida del proceso, y esa sigue pareciendo ocupada para algo que trabajó duro veinte minutos y luego se atascó. El guardián compara el tiempo de procesador consumido entre dos escaneos, así que lo que ve es el último minuto, no la última hora.
Cómo funciona
Cuatro pasos, una vez por minuto, y el caro casi nunca llega a ejecutarse.
Una instantánea barata de la máquina
Cada minuto el guardián toma una única instantánea de todos los procesos en marcha y recorre el árbol que cuelga de cada terminal de agente. Coste medido en una máquina con 824 procesos en marcha: unos 40 ms. Mientras no haya ningún agente corriendo, esto ni siquiera ocurre.
Preseleccionar a los sospechosos
De esa instantánea solo se queda con los procesos hijo de agentes que llevan vivos más que tu umbral y que ya no usan el procesador. En uso normal esta lista está vacía, y todo se para aquí.
Medir los que parecen bloqueados
Solo para esa lista corta paga el guardián la medición de memoria real, con las páginas comprimidas y las enviadas al swap incluidas. Un proceso que no consigue medir no se señala nunca: una incógnita no es un veredicto.
Reportar, y dejarte decidir
Aparece un indicador en la barra de estado y un único aviso te lo cuenta una vez. Abres la lista, ves qué es el proceso, cuánto retiene, cuánto lleva bloqueado y qué agente lo lanzó, y lo terminas si quieres.
Lo que nunca va a tocar
Una herramienta capaz de terminar procesos tiene que ser muy estricta con lo que considera asunto suyo. Estos límites son estructurales, no opciones que tengas que acordarte de activar.
- La propia CLI del agente. Sea cual sea el proveedor que uses, el guardián protege el binario con el que la app lanzó ese terminal. Lee ese nombre del propio lanzamiento en vez de una lista escrita a mano, así que un subproceso de esa misma CLI también queda protegido, a cualquier profundidad.
- Tus terminales de comandos dev. Un servidor de dev en reposo cumple todos los criterios: gordo, viejo, sin uso de procesador. Y es justo el proceso que quieres tener corriendo. Solo se vigilan los terminales de agentes, así que tu servidor de dev nunca entra en el cuadro.
- La shell y las tuberías internas de la app. El helper de terminal y la shell en la que corre un agente quedan excluidos por construcción. Los únicos candidatos son los procesos de herramientas que cuelgan por debajo de la CLI del agente.
- Todo lo que no haya adoptado. El único camino capaz de terminar un proceso rechaza cualquier proceso que el guardián no haya recogido del árbol de un agente. No puede convertirse en una vía para terminar otra cosa de tu máquina.
Y nada se termina automáticamente si tú no lo pides. Por defecto el guardián reporta lo que ha encontrado y decides tú, porque eres quien sabe si ese proceso grande y silencioso estaba previsto.
Cuándo se gana su sitio
Cada una de estas situaciones es real, ninguna es hipotética.
La máquina más lenta a las 18 h que a las 9
Ningún momento concreto en el que se rompiera, solo un descenso constante a lo largo del día. Esa forma casi siempre son procesos bloqueados acumulados, y es la más difícil de diagnosticar a mano porque en ningún instante concreto hay nada que parezca mal.
Varios agentes trabajando en paralelo
Cuantos más agentes tienes corriendo, más llamadas a herramientas hay, y más posibilidades de que una se atasque. La tasa de fallo por llamada es minúscula; multiplicada por un día de trabajo en paralelo deja de serlo.
Una búsqueda que no vuelve nunca
Un patrón que hace explotar el motor de expresiones regulares reserva gigabytes sobre un archivo de unos pocos cientos de kilobytes. El agente la espera, tú esperas al agente, y la máquina paga por los dos.
Cerraste el agente, el proceso se quedó
Cerrar una pestaña no siempre libera nada. Un proceso que ya se había desenganchado conserva su memoria y pierde su último vínculo con cualquier cosa visible en la app.
Un portátil con 16 GB
En una máquina con RAM de sobra, unos cuantos procesos bloqueados se esconden durante mucho tiempo. En un portátil de 16 GB llegan al swap enseguida, y en cuanto el sistema se pone a comprimir memoria todos tus agentes se ralentizan a la vez.
Antes de culpar a la app
Cuando una máquina se arrastra con AgentsRoom abierto, la app es el sospechoso obvio. Tener los números reales, proceso a proceso, con el agente que lanzó cada uno, convierte una sospecha en algo que puedes comprobar de verdad.
Los límites los pones tú
Los valores por defecto son deliberadamente prudentes. Todo lo que sigue vive en los ajustes, pestaña Terminal, y cada uno de ellos también lo puede leer y cambiar un agente a través de las herramientas MCP de AgentsRoom.
- Vigilar los procesos hijo de los agentes
- Activado por defecto. Desactívalo y no corre ningún escaneo, nunca.
- Reportar a partir de un umbral de memoria
- Dos gigabytes por defecto. Por debajo, un proceso bloqueado no merece que te interrumpan. Sube el umbral en una estación de trabajo con mucha RAM, bájalo en un portátil donde la memoria va justa.
- Después de un tiempo de vida mínimo
- Cinco minutos por defecto. Es lo que evita que una tarea lenta pero legítima acabe señalada alguna vez, porque casi nada de lo que quieres de verdad dura cinco minutos sin usar nada de procesador.
- Terminar automáticamente los procesos bloqueados
- Desactivado por defecto, y es una decisión de producto asumida más que prudencia. El guardián está emitiendo un juicio, y solo tú sabes si ese proceso grande y silencioso estaba previsto. Actívalo y actuará por su cuenta, con una notificación a posteriori.
El umbral de procesador no se expone, a propósito. Es la medición que separa un build que trabaja de un proceso bloqueado, y eso no es cuestión de gustos.
Preguntas frecuentes
¿Esto significa que AgentsRoom ralentiza mi ordenador?
No, y precisamente por eso existe la funcionalidad. En la sesión que medimos, la app ocupaba 2,8 GB repartidos en 91 procesos y los ocho CLI de agentes 1,6 GB entre todos. Los 41,8 GB los retenían procesos de herramientas que se habían atascado. AgentsRoom resulta ser el único sitio desde el que se ven todos los agentes y todos los procesos que han lanzado, así que el único sitio desde el que se puede arbitrar.
¿Va a matar mi build o mi tanda de tests?
No. Un proceso solo se señala cuando es grande Y viejo Y ha dejado de usar el procesador. Un build que está trabajando de verdad satura un núcleo, así que falla la tercera condición y nunca es candidato. Esa condición existe justo para hacer esa distinción.
¿Vigila mi servidor de dev?
No, y nunca lo hará. Un servidor de dev en reposo cumple todos los criterios: ocupa mucha memoria, lleva horas corriendo y no usa procesador entre petición y petición. Solo se vigilan los procesos hijo de los terminales de agentes, así que tus comandos dev quedan fuera del alcance por construcción.
¿Puede terminar al propio agente?
No. La CLI del agente está protegida sea cual sea el proveedor, y la protección se apoya en el binario con el que la app lanzó ese terminal, no en una lista de nombres conocidos. La shell y el helper de terminal de la app también quedan excluidos.
¿Qué es un proceso huérfano y por qué recibe un trato aparte?
Un proceso cuyo padre ha terminado queda reenganchado al proceso init del sistema. A partir de ahí ya nada lo relaciona con el agente que lo lanzó, así que nadie va a limpiarlo. AgentsRoom memoriza la pertenencia mientras el proceso sigue enganchado, que es el único momento en el que se puede establecer, y por eso puede reportarlo después igualmente.
¿Cuánto cuesta la propia vigilancia?
Una instantánea de procesos por minuto, medida en unos 40 ms en una máquina con 824 procesos en marcha. La medición de memoria más cara solo se aplica a procesos que ya parecen bloqueados, lo que en uso normal significa que no se aplica. Y el escaneo no existe en absoluto mientras no haya ningún agente activo.
¿Por qué no mirar sin más la columna de memoria del Monitor de Actividad?
Porque en macOS se queda corta en un orden de magnitud. Un proceso empujado a la memoria comprimida puede mostrar 20 MB de residente mientras retiene 8 GB. Medimos uno en vivo con 4,7 GB de residente para una huella real de 14 GB. El tamaño virtual no es mejor: hasta los procesos del sistema declaran cientos de gigabytes.
¿Funciona con Claude Code, Codex y los demás?
Sí. El guardián no conoce ninguna herramienta ni ningún proveedor en concreto. Vigila los procesos hijo del terminal de agente que hayas lanzado, y la CLI que protege se lee del propio lanzamiento. Añadir un proveedor no cambia nada aquí.
¿Funciona en Windows y Linux?
Sí. Cada plataforma necesita una medición distinta para que la memoria se cuente con honestidad: páginas comprimidas en macOS, residente más swap en Linux, private commit en Windows. Las tres están implementadas.
¿Va a terminar procesos sin preguntarme?
No mientras no lo actives. Por defecto reporta lo que ha encontrado, con el agente, la memoria, la edad y el uso de procesador, y decides tú. La terminación automática es un ajuste, desactivado de fábrica.
¿Qué le pasa al agente cuando termino uno de sus procesos?
El agente sigue corriendo. Su llamada a herramienta recibe un error en vez de quedarse colgada para siempre, que es justo el resultado deseable: ese proceso no iba a acabar nunca. No se reinicia nada y no se pierde ningún contexto.
¿Arregla la causa raíz?
No, y no lo pretende. Las causas cambian: una herramienta hoy, otro patrón mañana, otro proveedor el mes que viene. Esto es una red de seguridad, diseñada para seguir funcionando cuando la causa sea una que nadie ha visto todavía.
También te puede interesar
Canario de contexto
La otra alerta temprana: vigila el contexto del agente en lugar de la máquina, y te avisa de que un agente está derivando antes de que se ponga a inventar archivos y APIs.
Terminales dev
Haz correr tus servidores de dev y tus comandos largos dentro de AgentsRoom, con una notificación cuando uno largo termina. Estos terminales son justo los que el guardián de procesos está construido para no tocar nunca.
Seguimiento del estado de los agentes
Ve de un vistazo qué agentes están trabajando, cuáles te están esperando y cuáles están en reposo, sin leer ni un terminal.
Uso de tokens
El otro recurso que merece vigilancia. Consumo de tokens y cuota por agente, para saber a dónde se te va el uso.
Vista dividida
Varios agentes uno al lado del otro en una sola ventana, cada uno con su panel, su color y su estado en vivo.
CLI Doctor
Cuando un agente no consigue arrancar, te dice por qué y qué hacer, en vez de dejarte delante de un terminal en blanco.
Deja de pagar por procesos que no usa nadie
AgentsRoom es gratis de descargar, y el guardián de procesos está activo desde el primer arranque.
App complementaria: supervisa tus agentes en movimiento
Usa Claude, Codex, Antigravity CLI u otro proveedor de IA.
Envía bugs y peticiones directamente a tu backlog público.
Un vistazo a AgentsRoom en acción.