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 basta con un puñado de ellos a la vez para llenar la memoria de una máquina.
El guardián de procesos barre los procesos hijo de tus agentes, señala los que se están comiendo tu memoria, uno a uno o en grupo, nombra al agente responsable y te deja interrumpirlo. 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 mientras el kernel manda gigabytes al swap por ella. No va a terminar nunca. Nadie la va a matar. Y si se cierra el agente que la lanzó, 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. Y no están parados mientras lo hacen: los procesos desbocados que medimos consumían cada uno entre el 10 y el 19 % de un núcleo, y cuantos más se acumulan menos le toca a cada uno. 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. Cada sistema rompe el vínculo a su manera: el Unix clásico lo reengancha a init, un escritorio Linux a tu gestor de usuario de systemd, y Windows no lo reengancha a nada y lo deja apuntando a un padre que ya no existe. Por eso el guardián nunca mira a los padres. Recuerda lo que adoptó mientras el vínculo seguía en pie, y trata como huérfano todo lo que falta en el árbol de procesos vivo, igual en los tres sistemas. Dos de los siete que medimos ya estaban así.
Se acumulan
Uno por pasada de verificación, uno por búsqueda con mala suerte, y uno más cada vez que un agente confunde un comando lento con uno colgado y lo vuelve a lanzar. Medimos doce comprobaciones de tipos corriendo a la vez, lanzadas por seis agentes, dos de los cuales tenían tres en marcha cada uno. 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.
Mide el procesador, nunca se fía de él
El uso de procesador se lee como una tasa entre dos escaneos, no como la media de toda la vida del proceso que da una herramienta del sistema, así que un proceso que trabajó duro y luego se atascó también cae. Lo que aporta es un listón más alto para algo que sigue trabajando, nunca un salvoconducto: un proceso desbocado que consume una quinta parte de un núcleo es justo lo que se le escapaba a la primera versión de este guardián.
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.
Ve el grupo, no solo el caso extremo
Doce comprobaciones de tipos a 1,4 GB cada una son 16,8 GB en una máquina de 16 GB, y cada una de ellas por separado queda por debajo de un umbral sensato. Cuando los procesos que han lanzado tus agentes llenan entre todos la mitad de la memoria física de la máquina, el tamaño deja de juzgarse de uno en uno.
Nombra al agente responsable
Dos o más comandos señalados del mismo agente se agrupan bajo su avatar, con lo que retienen entre todos y un aviso que explica el bucle en el que están atrapados. Un comando es un accidente; varios a la vez son una conducta.
Interrumpe al agente, no solo al proceso
Terminar un proceso mientras su agente está a mitad de turno le entrega a ese agente un error al que reacciona, muchas veces volviendo a lanzar el comando. Un botón envía en su lugar Ctrl+C al terminal del agente: su turno acaba, no se relanza nada, y el agente sigue abierto.
Las reglas que le impiden dar falsas alarmas
Un guardián que te señala los builds es un guardián que desactivas en una semana, así que el listón está deliberadamente alto. A todo proceso hijo de un agente que lleve vivo más que tu umbral se le mide la memoria real, y se reporta en cuanto retiene más de lo que has permitido. Un proceso que sigue usando el procesador tiene que retener el doble, y eso es lo que mantiene fuera de juego a un build largo y legítimo.
El uso de procesador fija ese listón; no es una condición de entrada. La primera versión de este guardián exigía que un proceso estuviera inactivo antes de mirar siquiera su memoria, y eso estaba mal. Una búsqueda cuyo patrón hace explotar el motor de expresiones regulares no está inactiva: consume una quinta parte de un núcleo mientras el kernel manda gigabytes al swap por ella. Peor aún, cuantos más se acumulan menos procesador le toca a cada uno, así que el punto ciego era más grande justo al principio, cuando terminar uno salía más barato.
La segunda regla existe porque un listón por proceso no puede ver un grupo. Doce comprobaciones de tipos reteniendo 1,4 GB cada una son razonables por separado y letales en conjunto en una máquina de 16 GB. Así que cuando todo lo que han lanzado los agentes suma la mitad de la memoria física de la máquina, se reporta todo, pese lo que pese cada pieza por su cuenta. Nada de ese grupo se termina nunca de forma automática: está por debajo del límite que tú pusiste, y solo se señaló por culpa de sus vecinos.
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 se queda con todos los procesos hijo de un agente que lleven vivos más que tu umbral. Ese es el filtro entero, y no se excluye nada por seguir usando el procesador: hacer eso es justo como la versión anterior de este guardián se dejaba escapar los procesos desbocados. En uso normal la lista está vacía, porque las llamadas a herramientas de un agente terminan en segundos.
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. Incluso activada, la terminación automática deja en paz todo lo que siga usando el procesador, y también todo lo que se haya señalado solo por lo que retienen sus vecinos.
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. Por debajo de eso no se mide nada en absoluto, y eso es lo que deja completamente fuera del cuadro las llamadas a herramientas corrientes de un agente, las que terminan en segundos.
- 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, y el punto a partir del cual la máquina cuenta como saturada tampoco. Los dos estuvieron mal alguna vez y se arreglaron midiendo incidentes reales en lugar de decidir por gusto, así que un deslizador para cualquiera de los dos sería sobre todo una forma de devolver el punto ciego.
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?
Nunca va a terminar ninguno sin preguntar. Reportarlo sí puede: un build tiene que retener el doble de tu umbral, cuatro gigabytes por defecto, o formar parte de un grupo de procesos de agentes que llena la mitad de la memoria de tu máquina. Pero la terminación automática nunca toca un proceso que sigue usando el procesador, ni uno señalado solo por lo que retienen sus vecinos. En los dos casos recibes una fila, los números reales y un botón, y no pasa nada hasta que lo pulses.
¿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 pierde el vínculo con el agente que lo lanzó, y nadie lo va a limpiar jamás. Cómo se rompe ese vínculo depende del sistema: el Unix clásico lo reengancha a init, un escritorio Linux a tu gestor de usuario de systemd, y Windows no lo reengancha a nada y deja atrás un identificador de padre muerto. Por eso AgentsRoom nunca examina a los padres. Registra la pertenencia mientras el proceso sigue enganchado, que es el único momento en el que se puede establecer, y trata como huérfano todo lo que falta en el árbol de procesos vivo, igual en los tres sistemas.
¿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.
Doce procesos, ninguno por encima de mi umbral. ¿Me va a decir algo?
Sí, y ese caso es justo el que cambió la regla. Medido en una máquina de 16 GB: doce comprobaciones de tipos lanzadas por seis agentes, de 0,84 a 1,72 GB cada una, todas holgadamente por debajo de un umbral de 2 GB, 15,4 GB entre todas, el swap lleno y la máquina inservible. Juzgada de una en una, cada una estaba bien. En cuanto el total pasa de la mitad de tu memoria física, se reportan todas, agrupadas bajo el agente que las lanzó.
¿Qué hace exactamente el botón Interrumpir el agente?
Envía Ctrl+C al terminal de ese agente, la misma pulsación de teclas que harías tú. El turno en curso del agente termina y el agente se queda esperándote: no se cierra, su sesión sigue intacta, y no se toca nada más en tu máquina. Existe porque terminar un proceso mientras el agente sigue trabajando en él solo trata el síntoma: el agente recibe un error y a menudo se limita a volver a lanzar el comando.
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.