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 il suffit d'une poignée d'entre eux en même temps pour remplir la mémoire d'une machine.
Process Guard balaie les process enfants de tes agents, signale ceux qui dévorent ta mémoire, un par un ou en meute, nomme l'agent responsable et te laisse l'interrompre. Rien n'est terminé 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. Ceux qui ne se terminent pas sont le problème. 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 en mémoire compressée, puis passe sa vie en défauts de page pendant que le noyau swappe des gigaoctets pour elle. Elle ne finira jamais. Rien ne la tuera jamais. Et si l'agent qui l'a lancée est fermé, elle devient 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. Ils ne sont pas inactifs pour autant : ceux que nous avons mesurés brûlaient chacun entre 10 et 19 % d'un cœur, et plus il y en a, moins chacun en obtient. Il n'y a pas de sortie de 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. Chaque système casse le lien différemment : un Unix classique le rattache à init, un Linux de bureau à ton gestionnaire systemd utilisateur, et Windows ne rattache rien du tout et le laisse pointer vers un parent qui n'existe plus. Le garde-fou ne regarde donc jamais les parents. Il se souvient de ce qu'il a adopté tant que le lien existait, et traite comme orphelin tout ce qui manque à l'arbre vivant, à l'identique sur les trois systèmes. Deux des sept que nous avons mesurés étaient déjà dans cet état.
Ils s'accumulent
Un par passe de vérification, un par recherche malchanceuse, et un de plus chaque fois qu'un agent prend une commande lente pour une commande bloquée et la relance. Nous avons mesuré douze vérifications de types en même temps, lancées par six agents, dont deux en avaient trois en vol. C'est pour ça que le ralentissement augmente strictement au fil de la journée, et pourquoi un redémarrage semble 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.
Mesure le processeur, ne s'y fie jamais
L'usage processeur est lu comme un taux entre deux scans, pas comme la moyenne de vie que renvoient les outils système, donc un process qui a travaillé dur puis s'est bloqué est quand même attrapé. Ce que ça achète, c'est une barre plus haute pour ce qui travaille encore, jamais un laissez-passer : un process parti en vrille qui brûle un cinquième de cœur est exactement ce que la première version de ce garde-fou laissait passer.
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, private commit 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.
Voit la meute, pas seulement l'exception
Douze vérifications de types à 1,4 Go chacune font 16,8 Go sur une machine de 16 Go, et chacune d'elles reste sous un seuil raisonnable. Quand les process lancés par tes agents remplissent à eux tous la moitié de la mémoire physique de la machine, la taille cesse d'être jugée une par une.
Nomme l'agent responsable
Deux commandes signalées ou plus venant du même agent sont regroupées sous son avatar, avec ce qu'elles occupent ensemble et un avertissement qui explique la boucle dans laquelle elles sont prises. Une commande est un accident, plusieurs à la fois est un comportement.
Interrompt l'agent, pas seulement le process
Terminer un process pendant que son agent est en plein tour lui rend une erreur à laquelle il réagit, souvent en relançant la commande. Un bouton envoie Ctrl+C dans le terminal de l'agent à la place : son tour s'arrête, plus rien ne relance, et l'agent reste ouvert.
Les règles qui l'empêchent de crier au loup
Un garde-fou qui signale tes builds est un garde-fou que tu désactives en une semaine, donc la barre est volontairement haute. Tout process enfant d'un agent qui vit depuis plus longtemps que ton seuil se fait mesurer sa mémoire réelle, et il est signalé dès qu'il occupe plus que ce que tu as autorisé. Un process qui utilise encore le processeur doit en occuper le double, et c'est ce qui garde un build long et légitime hors du chemin.
L'usage processeur place cette barre, il ne filtre pas. La première version de ce garde-fou exigeait qu'un process soit inactif avant même de regarder sa mémoire, et c'était faux. Une recherche dont le motif fait exploser le moteur d'expressions régulières n'est pas inactive : elle brûle un cinquième de cœur pendant que le noyau swappe des gigaoctets pour elle. Pire, plus il y en a, moins chacune obtient de processeur, donc l'angle mort était maximal tout au début, quand en terminer une coûtait le moins cher.
La deuxième règle existe parce qu'une barre par process ne voit pas une meute. Douze vérifications de types qui occupent 1,4 Go chacune sont raisonnables individuellement et fatales collectivement sur une machine de 16 Go. Donc quand tout ce que les agents ont lancé atteint la moitié de la mémoire physique de la machine, l'ensemble est signalé, quel que soit le poids de chaque morceau. Rien dans ce groupe n'est jamais terminé automatiquement : c'est en dessous de la limite que tu as fixée, et ça n'a été signalé qu'à cause du voisinage.
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 ce cliché il ne garde que les process enfants d'agents qui vivent depuis plus longtemps que ton seuil. C'est tout le filtre, et rien n'est écarté parce qu'il utilise encore le processeur : c'est précisément comme ça que la version précédente de ce garde-fou ratait des process partis en vrille. En usage normal cette liste est vide, puisque les appels d'outils d'un agent se terminent en quelques secondes.
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 rapporte ce qu'il a trouvé et c'est toi qui décides, parce que toi seul sais si un gros process silencieux était attendu. Même activée, la terminaison automatique laisse tranquille tout ce qui utilise encore le processeur, et tout ce qui n'a été signalé qu'à cause de ce que retiennent ses voisins.
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. En dessous, rien n'est même mesuré, et c'est ce qui garde les appels d'outils ordinaires d'un agent, ceux qui se terminent en quelques secondes, complètement hors du champ.
- 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é, et le point à partir duquel la machine est considérée saturée non plus. Les deux ont déjà été faux une fois et ont été corrigés en mesurant de vrais incidents, pas au goût : un curseur sur l'un ou l'autre serait surtout un moyen de remettre l'angle mort en place.
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 ?
Il n'en terminera jamais un sans demander. Il peut en signaler un : un build doit occuper le double de ton seuil, quatre gigaoctets par défaut, ou faire partie d'un groupe de process d'agents qui remplit la moitié de la mémoire de ta machine. Mais la terminaison automatique ne touche jamais un process qui utilise encore le processeur, ni un process signalé uniquement à cause de ce que retiennent ses voisins. Dans les deux cas tu obtiens une ligne, les vrais chiffres et un bouton, et rien ne se passe tant que tu ne l'as pas pressé.
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é perd le lien avec l'agent qui l'a lancé, et plus personne ne le nettoiera. La façon dont ce lien casse dépend du système : un Unix classique le rattache à init, un Linux de bureau à ton gestionnaire systemd utilisateur, et Windows ne rattache rien et laisse derrière un numéro de parent mort. AgentsRoom ne teste donc jamais les parents. Il enregistre la propriété tant que le process est encore rattaché, le seul moment où elle peut être établie, et traite comme orphelin tout ce qui manque à l'arbre vivant, à l'identique sur les trois systèmes.
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, private commit 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.
Douze process, pas un seul au-dessus de mon seuil. Est-ce qu'il dira quelque chose ?
Oui, et c'est ce cas qui a fait changer la règle. Mesuré sur une machine de 16 Go : douze vérifications de types lancées par six agents, de 0,84 à 1,72 Go chacune, toutes confortablement sous un seuil de 2 Go, 15,4 Go à elles toutes, le swap plein et la machine inutilisable. Jugée une par une, chacune allait bien. Dès que le total dépasse la moitié de ta mémoire physique, l'ensemble est signalé, regroupé sous l'agent qui les a lancées.
Que fait exactement « Interrompre l'agent » ?
Il envoie Ctrl+C dans le terminal de cet agent, la même touche que tu presserais toi-même. Le tour en cours de l'agent s'arrête et il t'attend : il n'est pas fermé, sa session est intacte, et rien d'autre sur ta machine n'est touché. Ce bouton existe parce que terminer un process pendant que l'agent travaille encore dessus ne traite que le symptôme : l'agent reçoit une erreur et relance fréquemment la commande.
Ç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.