Tes agents laissent des process derrière eux.
AgentsRoom les retrouve.
Un agent IA lance un vrai process système à chaque outil qu'il appelle. La plupart se terminent en quelques secondes. Certains jamais, et ceux-là retiennent des gigaoctets de mémoire sans utiliser le moindre cycle de processeur.
Le garde-fou balaie les process enfants de tes agents, signale ceux qui ne progressent plus, nomme l'agent responsable, et te laisse les terminer d'un clic. Rien n'est tué dans ton dos.
Ce que le garde-fou regarde vraiment : les process qu'un agent a lancés, et lesquels ont cessé de travailler.
Un agent IA, ce n'est pas un process. Chaque outil qu'il appelle en démarre un vrai sur ta machine : une recherche, un build, une vérification de types, une suite de tests, un script. Multiplie ça par quelques agents en parallèle, sur une journée entière, et tu obtiens des centaines de process nés et enterrés sans que tu en voies un seul.
Presque tous se terminent. Le problème, ce sont les autres. Une recherche dont le motif fait exploser le moteur d'expressions régulières ne plante pas et ne ralentit pas : elle alloue, se fait pousser dans la mémoire compressée, et passe ensuite sa vie en défauts de page à 4 % de CPU. Elle ne finira jamais. Personne ne la tuera. Et si l'agent qui l'a lancée est fermé, elle se retrouve rattachée au process d'init : un orphelin dont plus personne sur la machine n'est responsable.
C'est pour ça que le ralentissement s'installe en douce. Il n'y a pas de moment où ça casse, il y a une accumulation sur la journée, et c'est exactement la forme qui fait accuser la mauvaise cause : la surchauffe, le nombre d'agents, une fuite mémoire de l'app. Sur la session qu'on a mesurée, l'app tenait dans 2,8 Go pour 91 process et les huit CLI d'agents dans 1,6 Go à eux tous. Ni l'un ni l'autre n'était le problème.
Le garde-fou est le filet. Il surveille ce que les agents laissent derrière eux, te dit lequel est bloqué et qui l'a lancé, et te laisse le terminer. Les causes vont continuer de changer : un autre outil, un autre motif, un autre fournisseur. Le filet, lui, n'a pas besoin de changer.
Pourquoi une machine qui fait tourner des agents IA ralentit
Les chiffres ci-dessous viennent d'une session mesurée sur un portable de 16 Go avec huit agents actifs. Rien ici n'est une estimation.
La machine tournait depuis cinq heures et demie. Aucun problème thermique : aucun throttling enregistré, batterie à 30,6 C. Le load average était entre 17 et 21 sur 8 cœurs, et le processeur passait 56 % de son temps dans le noyau pour 1,5 % d'inactivité. C'est ce rapport qui trahit tout. Une machine qui travaille vraiment passe son temps en code utilisateur ; une machine à 56 % de temps système, c'est un noyau qui ne fait plus que compresser, décompresser et swapper de la mémoire.
Sept process de recherche bloqués occupaient entre 3,9 et 8,0 Go chacun, soit 41,8 Go réclamés sur une machine qui en a 16. Le swap était à 22,3 Go sur 23,5, et environ 993 Go avaient été écrits en swap depuis le démarrage. Terminer ces sept process a rendu 15,5 Go instantanément, sans redémarrer un seul agent et sans redémarrer l'app.
Si personne n'attrape ça à la main, c'est parce que les outils habituels mentent dessus. Sur macOS, un process bloqué peut afficher 20 Mo de mémoire résidente alors qu'il en occupe 8 Go, parce que tout ce qu'il a touché est passé par le compresseur mémoire. On en a mesuré un en direct à 4,7 Go de résident pour une empreinte réelle de 14 Go. La taille virtuelle n'aide pas davantage : sur cette plateforme, même launchd affiche environ 440 Go de taille virtuelle, donc filtrer dessus revient à signaler la machine entière.
La même session, heure par heure : les tranches de mémoire que plus personne n'utilise, et ce qui se passe quand on les libère.
Et ces process ont quatre propriétés qui garantissent qu'ils seront encore là demain.
Ils ne finissent jamais
Leur propre mémoire est dans le swap, donc ils passent leur temps en défauts de page au lieu de calculer. Une recherche saine sature un cœur ; ceux-là sont à 4 %. Il n'y a aucune sortie à cette spirale, et attendre n'y change rien.
Ils ne meurent jamais
Il n'y a aucun délai maximum sur un appel d'outil. Rien sur la machine n'a d'avis sur un process inactif depuis cinquante minutes. Il restera là jusqu'à ce que quelqu'un le tue ou que la machine redémarre.
Ils survivent à leur agent
Ferme l'onglet de l'agent et le process peut survivre, rattaché au process d'init. À ce moment-là plus rien ne le relie à quoi que ce soit : c'est un orphelin, et personne ne le réclamera. Deux des sept qu'on a mesurés étaient déjà dans cet état.
Ils s'accumulent
Un par passe de vérification, un par recherche malchanceuse. C'est pour ça que le ralentissement est strictement croissant sur la journée, et pourquoi un redémarrage a l'air de régler le problème. Il ne règle rien, il remet juste le compteur à zéro.
Ce que fait le garde-fou
Il surveille les process que tes agents lancent, et il est volontairement très étroit sur ceux auxquels il touche.
Mesure la vraie mémoire
Pas la taille résidente, qui sous-estime un process bloqué de plusieurs gigaoctets. Le garde-fou lit l'empreinte réelle, pages compressées et pages parties en swap comprises, donc un process qui affiche 20 Mo et en occupe 8 Go est vu tel qu'il est.
Regarde le processeur, pas seulement la RAM
La mémoire seule signalerait tous les builds de ta machine. Le garde-fou mesure l'usage processeur comme un taux entre deux scans, donc un process qui a travaillé dur avant de se bloquer est quand même attrapé, et un build qui travaille vraiment est laissé tranquille.
Attrape les process orphelins
Un process qui a survécu à l'agent qui l'a lancé est signalé sur son seul mérite, parce que personne d'autre ne le réclamera. La propriété est mémorisée pendant que le process est encore rattaché, seul moment où elle peut être établie.
Un clic pour le terminer
Une puce dans la barre de statut liste chaque process bloqué avec l'agent qui l'a lancé, sa mémoire, son âge et son CPU. En terminer un le tue avec tout ce qu'il a lui-même lancé. La mémoire revient immédiatement et tes agents continuent de tourner.
macOS, Windows et Linux
Chaque système demande une mesure différente pour dire la vérité sur la mémoire : pages compressées sur macOS, résident plus swap sur Linux, engagement privé sur Windows. Les trois sont implémentées, pas prévues.
Ne coûte quasiment rien
Un instantané des process par minute, mesuré à environ 40 ms sur une machine qui en fait tourner 824. La mesure mémoire coûteuse ne se déclenche que si quelque chose a déjà l'air bloqué, et aucun scan ne tourne tant qu'aucun agent n'est actif.
La règle qui l'empêche de crier au loup
Un garde-fou qui signale tes builds est un garde-fou que tu désactives en une semaine. Donc un process n'est jamais signalé sur sa seule mémoire. Il doit être gros, il doit être vieux, et il doit avoir cessé d'utiliser le processeur. Les trois en même temps.
C'est la troisième condition qui fait tout le travail. Une vérification de types ou un bundler occupent eux aussi des gigaoctets pendant plusieurs minutes, mais ils saturent un cœur pendant ce temps. Un process pris dans le swap tourne autour de 4 %, parce qu'il passe sa vie à attendre des défauts de page au lieu de calculer. Cet écart est ce qui sépare une machine qui travaille d'une machine qui coule, et c'est le seul signal qui les sépare de façon fiable.
L'usage processeur est d'ailleurs mesuré, pas lu. Le chiffre que donnent les outils système est une moyenne sur toute la vie du process, qui a encore l'air occupée pour quelque chose qui a travaillé vingt minutes avant de se bloquer. Le garde-fou compare le temps processeur consommé entre deux scans, donc ce qu'il voit, c'est la dernière minute, pas la dernière heure.
Comment ça marche
Quatre étapes, une fois par minute, et la coûteuse ne se déclenche quasiment jamais.
Un instantané pas cher de la machine
Chaque minute, le garde-fou prend un seul instantané de tous les process et parcourt l'arbre sous chaque terminal d'agent. Coût mesuré sur une machine qui fait tourner 824 process : environ 40 ms. Tant qu'aucun agent ne tourne, ça n'a même pas lieu.
Retenir les suspects
De cet instantané il ne garde que les process enfants d'agents qui vivent depuis plus longtemps que ton seuil et n'utilisent plus le processeur. En usage normal cette liste est vide, et tout s'arrête là.
Mesurer ceux qui ont l'air bloqués
C'est uniquement pour cette courte liste que le garde-fou paie la vraie mesure mémoire, pages compressées et swap comprises. Un process qu'il n'arrive pas à mesurer n'est jamais signalé : une inconnue n'est pas un verdict.
Signaler, et te laisser décider
Une puce apparaît dans la barre de statut et une notification unique t'en informe. Tu ouvres la liste, tu vois ce qu'est le process, combien il occupe, depuis combien de temps il est bloqué et quel agent l'a lancé, et tu le termines si tu veux.
Ce à quoi il ne touchera jamais
Un outil capable de terminer des process doit être très strict sur ce qui le regarde. Ces limites sont structurelles, pas des options qu'il faut penser à activer.
- Le CLI de l'agent lui-même. Quel que soit le fournisseur que tu utilises, le garde-fou protège le binaire avec lequel l'app a lancé ce terminal. Il lit ce nom dans le lancement lui-même plutôt que dans une liste codée en dur, donc un sous-process du même CLI est protégé aussi, à n'importe quelle profondeur.
- Tes terminaux de commandes dev. Un serveur de dev au repos coche tous les critères : gros, vieux, aucun usage processeur. C'est aussi le seul process que tu veux vraiment voir tourner. Seuls les terminaux d'agents sont surveillés, donc ton serveur de dev n'entre jamais dans le cadre.
- Le shell et la plomberie de l'app. Le helper de terminal et le shell dans lequel tourne un agent sont exclus par construction. Seuls les process d'outils situés sous le CLI de l'agent sont candidats.
- Tout ce qu'il n'a pas adopté. Le seul chemin capable de terminer un process refuse tout process que le garde-fou n'a pas ramassé dans l'arbre d'un agent. Il ne peut pas devenir un moyen de terminer autre chose sur ta machine.
Et rien n'est terminé automatiquement sans que tu le demandes. Par défaut le garde-fou signale ce qu'il a trouvé et tu décides, parce que c'est toi qui sais si un gros process silencieux était attendu.
Quand il justifie sa place
Chacune de ces situations est réelle, aucune n'est hypothétique.
La machine plus lente à 18 h qu'à 9 h
Aucun moment précis où ça a cassé, juste une descente régulière sur la journée. Cette forme, c'est presque toujours des process bloqués accumulés, et c'est la plus difficile à diagnostiquer à la main parce qu'à aucun instant donné rien n'a l'air anormal.
Plusieurs agents en parallèle
Plus tu fais tourner d'agents, plus il y a d'appels d'outils, et plus il y a de chances que l'un se bloque. Le taux d'échec par appel est minuscule ; multiplié par une journée de travail en parallèle, il cesse de l'être.
Une recherche qui ne revient jamais
Un motif qui fait exploser le moteur d'expressions régulières alloue des gigaoctets sur un fichier de quelques centaines de kilo-octets. L'agent l'attend, tu attends l'agent, et la machine paie pour les deux.
Tu as fermé l'agent, le process est resté
Fermer un onglet ne libère pas toujours quelque chose. Un process déjà détaché garde sa mémoire et perd son dernier lien avec quoi que ce soit de visible dans l'app.
Un portable avec 16 Go
Sur une machine avec beaucoup de RAM, quelques process bloqués se cachent longtemps. Sur un portable de 16 Go ils atteignent le swap vite, et dès que le système se met à compresser la mémoire, tous tes agents ralentissent en même temps.
Avant d'accuser l'app
Quand une machine rame avec AgentsRoom ouvert, l'app est le suspect évident. Avoir les vrais chiffres, process par process, avec l'agent qui a lancé chacun, transforme un soupçon en quelque chose de vérifiable.
C'est toi qui fixes les limites
Les valeurs par défaut sont volontairement prudentes. Tout ce qui suit se trouve dans les réglages, onglet Terminal, et chacun de ces réglages peut aussi être lu et modifié par un agent via les outils MCP d'AgentsRoom.
- Surveiller les process enfants des agents
- Activé par défaut. Désactive-le et plus aucun scan ne tourne, jamais.
- Signaler au-delà d'un seuil mémoire
- Deux gigaoctets par défaut. En dessous, un process bloqué ne vaut pas la peine qu'on t'interrompe. Monte le seuil sur une station de travail bien fournie en RAM, baisse-le sur un portable où la mémoire est comptée.
- Après une durée de vie minimale
- Cinq minutes par défaut. C'est ce qui évite qu'une tâche lente mais légitime soit un jour signalée, puisque quasiment rien de ce que tu veux vraiment ne dure cinq minutes sans utiliser le moindre processeur.
- Terminer automatiquement les process bloqués
- Désactivé par défaut, et c'est un choix produit assumé plutôt que de la prudence. Le garde-fou rend un jugement, et toi seul sais si un gros process silencieux était attendu. Active-le et il agit tout seul, avec une notification a posteriori.
Le seuil processeur n'est pas exposé, volontairement. C'est la mesure qui sépare un build qui travaille d'un process bloqué, et ce n'est pas une affaire de goût.
Questions fréquentes
Ça veut dire qu'AgentsRoom ralentit mon ordinateur ?
Non, et c'est précisément pour ça que la fonctionnalité existe. Sur la session mesurée, l'app tenait dans 2,8 Go pour 91 process et les huit CLI d'agents dans 1,6 Go à eux tous. Les 41,8 Go étaient occupés par des process d'outils qui s'étaient bloqués. AgentsRoom se trouve être le seul endroit d'où on voit tous les agents et tous les process qu'ils ont lancés, donc le seul endroit d'où on peut arbitrer.
Est-ce que ça va tuer mon build ou mes tests ?
Non. Un process n'est signalé que s'il est gros ET vieux ET qu'il a cessé d'utiliser le processeur. Un build qui travaille vraiment sature un cœur, donc il échoue à la troisième condition et n'est jamais candidat. Cette condition existe exactement pour faire cette distinction.
Est-ce qu'il surveille mon serveur de dev ?
Non, et il ne le fera jamais. Un serveur de dev au repos coche tous les critères : il occupe beaucoup de mémoire, il tourne depuis des heures, et il n'utilise pas le processeur entre deux requêtes. Seuls les process enfants des terminaux d'agents sont surveillés, donc tes commandes dev sont hors périmètre par construction.
Est-ce qu'il peut terminer l'agent lui-même ?
Non. Le CLI de l'agent est protégé quel que soit le fournisseur, et la protection s'appuie sur le binaire avec lequel l'app a lancé ce terminal plutôt que sur une liste de noms connus. Le shell et le helper de terminal de l'app sont exclus également.
C'est quoi un process orphelin et pourquoi un traitement à part ?
Un process dont le parent s'est terminé est rattaché au process d'init du système. À partir de là, plus rien ne le relie à l'agent qui l'a lancé, donc personne ne le nettoiera. AgentsRoom mémorise la propriété pendant que le process est encore rattaché, seul moment où elle peut être établie, ce qui lui permet de le signaler quand même ensuite.
Combien coûte la surveillance elle-même ?
Un instantané des process par minute, mesuré à environ 40 ms sur une machine qui en fait tourner 824. La mesure mémoire plus coûteuse ne s'applique qu'aux process qui ont déjà l'air bloqués, ce qui en usage normal veut dire qu'elle ne s'applique pas. Et le scan n'existe pas du tout tant qu'aucun agent n'est actif.
Pourquoi ne pas juste regarder la colonne mémoire du moniteur d'activité ?
Parce que sur macOS elle sous-estime le problème d'un ordre de grandeur. Un process poussé dans la mémoire compressée peut afficher 20 Mo de résident tout en occupant 8 Go. On en a mesuré un en direct à 4,7 Go de résident pour une empreinte réelle de 14 Go. La taille virtuelle ne vaut pas mieux : même les process système en affichent des centaines de gigaoctets.
Ça marche avec Claude Code, Codex et les autres ?
Oui. Le garde-fou ne connaît aucun outil ni aucun fournisseur en particulier. Il surveille les process enfants du terminal d'agent que tu as lancé, et le CLI qu'il protège est lu dans le lancement lui-même. Ajouter un fournisseur ne change rien ici.
Ça marche sur Windows et Linux ?
Oui. Chaque plateforme demande une mesure différente pour que la mémoire soit dite honnêtement : pages compressées sur macOS, résident plus swap sur Linux, engagement privé sur Windows. Les trois sont implémentées.
Est-ce qu'il va terminer des process sans me demander ?
Pas tant que tu ne l'as pas activé. Par défaut il signale ce qu'il a trouvé, avec l'agent, la mémoire, l'âge et l'usage processeur, et tu décides. La terminaison automatique est un réglage, désactivé à la sortie de la boîte.
Qu'arrive-t-il à l'agent quand je termine un de ses process ?
L'agent continue de tourner. Son appel d'outil reçoit une erreur au lieu de rester suspendu pour toujours, ce qui est exactement le résultat souhaitable : ce process n'allait de toute façon jamais aboutir. Rien n'est relancé et aucun contexte n'est perdu.
Est-ce que ça corrige la cause racine ?
Non, et ce n'est pas le but. Les causes changent : un outil aujourd'hui, un autre motif demain, un autre fournisseur le mois prochain. C'est un filet de sécurité, conçu pour continuer de fonctionner quand la cause est une que personne n'a encore vue.
Ça pourrait aussi t'intéresser
Canari de contexte
L'autre alerte précoce : elle surveille le contexte de l'agent plutôt que la machine, et te prévient qu'un agent dérive avant qu'il ne se mette à inventer des fichiers et des API.
Terminaux dev
Fais tourner tes serveurs de dev et tes commandes longues dans AgentsRoom, avec une notification quand une commande longue se termine. Ces terminaux sont précisément ceux auxquels le garde-fou est conçu pour ne jamais toucher.
Suivi de statut des agents
Vois d'un coup d'œil quels agents travaillent, lesquels t'attendent et lesquels sont au repos, sans lire un seul terminal.
Consommation de tokens
L'autre ressource qui mérite un œil. Consommation et quota par agent, pour savoir où part ton usage.
Vue divisée
Plusieurs agents côte à côte dans une seule fenêtre, chacun avec son panneau, sa couleur et son statut en direct.
CLI Doctor
Quand un agent n'arrive pas à démarrer, il te dit pourquoi et quoi faire, au lieu de te laisser devant un terminal vide.
Arrête de payer pour des process que personne n'utilise
AgentsRoom est gratuit à télécharger, et le garde-fou est actif dès le premier lancement.
App companion : suivez vos agents en déplacement
Utilisez Claude, Codex, Antigravity CLI ou un autre fournisseur IA.
Remontez bugs et demandes directement dans votre backlog public.
Aperçu d'AgentsRoom en action.