Deine Agenten lassen Prozesse zurück.
AgentsRoom findet sie.
Ein KI-Coding-Agent startet für jedes Werkzeug, das er aufruft, einen echten Systemprozess. Die meisten sind in Sekunden fertig. Manche nie, und die halten Gigabytes an Speicher fest, ohne auch nur einen Prozessortakt zu verbrauchen.
Der Prozess-Wächter durchsucht die Kindprozesse deiner Agenten, meldet die, die nicht mehr vorankommen, nennt den verantwortlichen Agenten und beendet sie mit einem Klick. Nichts wird hinter deinem Rücken beendet.
Was der Wächter wirklich anschaut: die Prozesse, die ein Agent gestartet hat, und welche davon aufgehört haben zu arbeiten.
Ein KI-Coding-Agent ist nicht ein Prozess. Jeder Werkzeugaufruf startet einen echten auf deiner Maschine: eine Suche, ein Build, eine Typprüfung, ein Testlauf, ein Skript. Multipliziere das mit ein paar Agenten, die parallel arbeiten, über einen ganzen Tag, und du bekommst Hunderte Prozesse, die geboren und beerdigt werden, ohne dass du je einen davon siehst.
Fast alle sind irgendwann fertig. Das Problem sind die anderen. Eine Suche, deren Muster die Regex-Engine explodieren lässt, stürzt nicht ab und wird nicht langsamer: sie alloziert, wandert in den komprimierten Speicher und verbringt danach ihr Leben mit Seitenfehlern bei 4 % CPU. Sie wird nie fertig. Niemand wird sie je beenden. Und wenn der Agent, der sie gestartet hat, geschlossen wird, hängt das System sie an den Init-Prozess um: ein verwaister Prozess, für den auf der Maschine niemand mehr zuständig ist.
Deshalb schleicht sich die Verlangsamung an. Es gibt keinen Moment, in dem etwas kaputtgeht, es gibt eine Anhäufung über den Arbeitstag, und genau diese Form führt dazu, dass die falsche Ursache beschuldigt wird: Überhitzung, zu viele Agenten, ein Speicherleck in der App. In der Sitzung, die wir gemessen haben, belegte die App selbst 2,8 GB über 91 Prozesse und die acht Agenten-CLIs zusammen 1,6 GB. Keines von beiden war das Problem.
Der Prozess-Wächter ist das Netz. Er beobachtet, was Agenten zurücklassen, sagt dir, welcher Prozess hängt und wer ihn gestartet hat, und lässt dich ihn beenden. Die Ursachen werden sich weiter ändern: ein anderes Werkzeug, ein anderes Muster, ein anderer Provider. Das Netz muss sich nicht ändern.
Warum eine Maschine mit KI-Agenten langsam wird
Die Zahlen unten stammen aus einer gemessenen Sitzung auf einem Laptop mit 16 GB und acht laufenden Agenten. Nichts davon ist geschätzt.
Die Maschine lief seit fünfeinhalb Stunden. Kein thermisches Problem: kein Throttling aufgezeichnet, Akku bei 30,6 C. Der Load Average lag zwischen 17 und 21 auf 8 Kernen, und die CPU verbrachte 56 % ihrer Zeit im Kernel bei 1,5 % Leerlauf. Dieses Verhältnis ist der Hinweis. Eine Maschine, die wirklich arbeitet, verbringt ihre Zeit in Anwendungscode; eine Maschine bei 56 % Systemzeit ist ein Kernel, der nur noch Speicher komprimiert, dekomprimiert und auslagert.
Sieben blockierte Suchprozesse belegten jeweils zwischen 3,9 und 8,0 GB, zusammen 41,8 GB auf einer Maschine mit 16 GB RAM. Der Swap lag bei 22,3 GB von 23,5, und seit dem Start waren rund 993 GB in den Swap geschrieben worden. Diese sieben Prozesse zu beenden gab sofort 15,5 GB zurück, ohne einen einzigen Agenten neu zu starten und ohne die App neu zu starten.
Dass das von Hand niemand mitbekommt, liegt daran, dass die üblichen Werkzeuge darüber lügen. Unter macOS kann ein blockierter Prozess 20 MB residenten Speicher anzeigen, während er in Wirklichkeit 8 GB belegt, weil alles, was er angefasst hat, durch den Speicherkompressor gegangen ist. Wir haben live einen mit 4,7 GB residentem Speicher bei einer tatsächlichen Belegung von 14 GB gemessen. Die virtuelle Größe hilft ebenso wenig: auf dieser Plattform meldet selbst launchd rund 440 GB virtuelle Größe, ein Filter darauf würde also die ganze Maschine melden.
Dieselbe Sitzung, Stunde für Stunde: die Speicherblöcke, die niemand mehr benutzt, und was passiert, wenn man sie freigibt.
Und diese Prozesse haben vier Eigenschaften, die garantieren, dass sie morgen noch da sind.
Sie werden nie fertig
Ihr eigener Speicher liegt im Swap, also verbringen sie ihre Zeit mit Seitenfehlern statt mit Rechnen. Eine gesunde Suche lastet einen Kern aus; diese hier liegen bei 4 %. Aus dieser Spirale führt kein Weg heraus, und Warten hilft kein bisschen.
Sie sterben nie
Für einen Werkzeugaufruf gibt es kein Zeitlimit. Nichts auf der Maschine hat eine Meinung zu einem Prozess, der seit fünfzig Minuten untätig ist. Er bleibt dort sitzen, bis ihn jemand beendet oder die Maschine neu startet.
Sie überleben ihren Agenten
Schließ den Tab des Agenten, und der Prozess kann überleben, umgehängt an den Init-Prozess. Ab diesem Moment verbindet ihn nichts mehr mit irgendetwas: er ist verwaist, und niemand wird ihn je zurückholen. Zwei der sieben, die wir gemessen haben, waren bereits in diesem Zustand.
Sie häufen sich an
Einer pro Prüflauf, einer pro unglücklicher Suche. Deshalb nimmt die Verlangsamung über den Tag streng monoton zu, und deshalb sieht es so aus, als würde ein Neustart das Problem lösen. Er löst nichts, er setzt nur den Zähler zurück.
Was der Prozess-Wächter macht
Er überwacht die Prozesse, die deine Agenten starten, und ist bewusst sehr eng darin, welche er überhaupt anfasst.
Misst den echten Speicher
Nicht die residente Größe, die einen blockierten Prozess um Gigabytes zu niedrig ausweist. Der Wächter liest die tatsächliche Belegung, komprimierte und in den Swap ausgelagerte Seiten inklusive, damit ein Prozess, der 20 MB anzeigt und 8 GB hält, als das gesehen wird, was er ist.
Schaut auf die CPU, nicht nur auf den RAM
Speicher allein würde jeden Build auf deiner Maschine melden. Der Wächter misst die Prozessorauslastung als Rate zwischen zwei Scans, also wird auch ein Prozess erwischt, der hart gearbeitet hat und dann hängengeblieben ist, während ein Build, der wirklich arbeitet, in Ruhe gelassen wird.
Erwischt verwaiste Prozesse
Ein Prozess, der den Agenten überlebt hat, der ihn gestartet hat, wird aus eigenem Recht gemeldet, weil ihn sonst nie jemand zurückholt. Die Zugehörigkeit wird gemerkt, solange der Prozess noch angehängt ist: das ist der einzige Moment, in dem sie sich feststellen lässt.
Ein Klick, und er ist weg
Ein Badge in der Statusleiste listet jeden blockierten Prozess mit dem Agenten, der ihn gestartet hat, seinem Speicher, seinem Alter und seiner CPU. Einen zu beenden beendet ihn und alles, was er selbst abgezweigt hat. Der Speicher kommt sofort zurück und deine Agenten laufen weiter.
macOS, Windows und Linux
Jedes System braucht eine andere Messung, damit die Speicherzahl die Wahrheit sagt: komprimierte Seiten unter macOS, resident plus ausgelagert unter Linux, Private Commit unter Windows. Alle drei sind implementiert, nicht geplant.
Kostet so gut wie nichts
Ein Prozess-Snapshot pro Minute, gemessen bei etwa 40 ms auf einer Maschine mit 824 laufenden Prozessen. Die teure Speichermessung läuft nur, wenn etwas schon blockiert aussieht, und solange kein Agent aktiv ist, läuft überhaupt kein Scan.
Die Regel, die ihn vom falschen Alarm abhält
Ein Wächter, der deine Builds meldet, ist ein Wächter, den du in einer Woche abschaltest. Deshalb wird ein Prozess nie allein wegen seines Speichers gemeldet. Er muss groß sein, er muss schon eine Weile leben, und er muss aufgehört haben, den Prozessor zu benutzen. Alle drei gleichzeitig.
Die dritte Bedingung ist die, die die Arbeit macht. Eine Typprüfung oder ein Bundler hält ebenfalls minutenlang Gigabytes, aber dabei lastet er einen Kern aus. Ein Prozess, der im Swap feststeckt, liegt bei rund 4 %, weil er sein Leben mit Warten auf Seitenfehler verbringt statt mit Rechnen. Dieser Abstand trennt eine Maschine, die arbeitet, von einer Maschine, die absäuft, und er ist das einzige Signal, das die beiden zuverlässig trennt.
Die Prozessorauslastung wird außerdem gemessen, nicht abgelesen. Der Wert, den ein Systemwerkzeug üblicherweise ausgibt, ist ein Durchschnitt über das gesamte Leben eines Prozesses, und der sieht immer noch beschäftigt aus für etwas, das zwanzig Minuten hart gearbeitet hat und dann hängengeblieben ist. Der Wächter vergleicht stattdessen die verbrauchte Prozessorzeit zwischen zwei Scans, er sieht also die letzte Minute, nicht die letzte Stunde.
So funktioniert es
Vier Schritte, einmal pro Minute, und der teure läuft so gut wie nie.
Ein billiger Schnappschuss der Maschine
Jede Minute macht der Wächter einen einzigen Schnappschuss aller laufenden Prozesse und geht den Baum unter jedem Agenten-Terminal durch. Gemessene Kosten auf einer Maschine mit 824 laufenden Prozessen: etwa 40 ms. Solange kein Agent läuft, passiert das überhaupt nicht.
Die Verdächtigen vorauswählen
Aus diesem Schnappschuss behält er nur die Kindprozesse von Agenten, die länger als deine Schwelle leben und den Prozessor nicht mehr benutzen. Im Normalbetrieb ist diese Liste leer, und hier hört alles auf.
Die messen, die blockiert aussehen
Nur für diese kurze Liste zahlt der Wächter den Preis der echten Speichermessung, komprimierte und ausgelagerte Seiten inklusive. Ein Prozess, den er nicht messen kann, wird nie gemeldet: eine Unbekannte ist kein Urteil.
Melden, und dich entscheiden lassen
In der Statusleiste erscheint ein Badge, und ein einziger Hinweis informiert dich einmal darüber. Du öffnest die Liste, siehst, was der Prozess ist, wie viel er belegt, wie lange er schon blockiert ist und welcher Agent ihn gestartet hat, und beendest ihn, wenn du willst.
Was er nie anfasst
Ein Werkzeug, das Prozesse beenden kann, muss sehr eng definieren, was es überhaupt angeht. Diese Grenzen sind strukturell, keine Optionen, an deren Aktivierung du denken musst.
- Das Agenten-CLI selbst. Welchen Provider du auch fährst, der Wächter schützt die Binary, mit der die App dieses Terminal gestartet hat. Er liest diesen Namen aus dem Start selbst statt aus einer fest verdrahteten Liste, deshalb ist auch ein Unterprozess desselben CLI geschützt, in beliebiger Tiefe.
- Deine Dev-Terminals. Ein Dev-Server im Leerlauf erfüllt jedes Kriterium eines entlaufenen Prozesses: fett, alt, keine Prozessorlast. Er ist gleichzeitig der eine Prozess, den du wirklich laufen haben willst. Überwacht werden nur Agenten-Terminals, dein Dev-Server kommt also gar nicht erst ins Bild.
- Die Shell und die Innereien der App. Der Terminal-Helper und die Shell, in der ein Agent läuft, sind per Konstruktion ausgeschlossen. Kandidaten sind immer nur die Werkzeugprozesse unterhalb des Agenten-CLI.
- Alles, was er nicht adoptiert hat. Der einzige Pfad, der einen Prozess beenden kann, verweigert jeden Prozess, den der Wächter nicht aus dem Baum eines Agenten aufgesammelt hat. Er kann nicht zu einem Weg werden, irgendetwas anderes auf deiner Maschine zu beenden.
Und nichts wird automatisch beendet, solange du es nicht verlangst. Standardmäßig meldet der Wächter, was er gefunden hat, und du entscheidest, denn du bist derjenige, der weiß, ob ein großer, stiller Prozess so gewollt war.
Wann er sich seinen Platz verdient
Jede dieser Situationen ist real, keine ist hypothetisch.
Die Maschine ist um 18 Uhr langsamer als um 9
Kein einzelner Moment, in dem etwas kaputtging, nur ein stetiges Abrutschen über den Tag. Diese Form sind fast immer angehäufte blockierte Prozesse, und sie ist von Hand am schwersten zu diagnostizieren, weil in keinem einzelnen Augenblick etwas falsch aussieht.
Mehrere Agenten arbeiten parallel
Je mehr Agenten du laufen lässt, desto mehr Werkzeugaufrufe passieren, und desto größer die Chance, dass einer davon hängenbleibt. Die Fehlerrate pro Aufruf ist winzig; multipliziert mit einem Tag Parallelarbeit hört sie auf, winzig zu sein.
Eine Suche, die nie zurückkommt
Ein Muster, das die Regex-Engine explodieren lässt, alloziert Gigabytes für eine Datei von ein paar hundert Kilobyte. Der Agent wartet auf sie, du wartest auf den Agenten, und die Maschine zahlt für beide.
Du hast den Agenten geschlossen, der Prozess blieb
Einen Tab zu schließen gibt nicht immer etwas frei. Ein Prozess, der sich bereits abgekoppelt hatte, behält seinen Speicher und verliert seine letzte Verbindung zu allem, was du in der App sehen kannst.
Ein Laptop mit 16 GB
Auf einer Maschine mit reichlich RAM verstecken sich ein paar blockierte Prozesse lange. Auf einem Laptop mit 16 GB erreichen sie schnell den Swap, und sobald das System anfängt, Speicher zu komprimieren, wird jeder einzelne Agent gleichzeitig langsamer.
Bevor du die App beschuldigst
Wenn eine Maschine kriecht, während AgentsRoom offen ist, ist die App der naheliegende Verdächtige. Die echten Zahlen zu haben, pro Prozess, mit dem Agenten, der jeden einzelnen gestartet hat, macht aus einem Verdacht etwas, das du tatsächlich überprüfen kannst.
Du legst die Grenzen fest
Die Voreinstellungen sind bewusst vorsichtig. Alles Folgende steht in den Einstellungen unter Terminal, und jede einzelne Einstellung kann auch von einem Agenten über die MCP-Werkzeuge von AgentsRoom gelesen und geändert werden.
- Kindprozesse von Agenten überwachen
- Standardmäßig an. Schalte es aus, und es läuft überhaupt kein Scan mehr, nie.
- Ab einer Speicherschwelle melden
- Standardmäßig zwei Gigabyte. Darunter ist ein blockierter Prozess es nicht wert, dich zu unterbrechen. Setz die Schwelle auf einer Workstation mit viel RAM höher, auf einem Laptop mit knappem Speicher niedriger.
- Nach einer Mindestlaufzeit
- Standardmäßig fünf Minuten. Das verhindert, dass eine langsame, aber legitime Aufgabe jemals gemeldet wird, denn fast nichts, was du wirklich willst, dauert fünf Minuten, ohne dabei irgendeinen Prozessor zu benutzen.
- Blockierte Prozesse automatisch beenden
- Standardmäßig aus, und das ist eine bewusste Produktentscheidung, keine Vorsicht. Der Wächter fällt ein Urteil, und nur du weißt, ob ein großer, stiller Prozess so gewollt war. Schalte es an, dann handelt er von selbst, mit einer Benachrichtigung im Nachhinein.
Die Prozessorschwelle wird absichtlich nicht angeboten. Sie ist die Messung, die einen arbeitenden Build von einem blockierten Prozess trennt, und das ist keine Geschmacksfrage.
Häufig gestellte Fragen
Heißt das, AgentsRoom macht meinen Rechner langsam?
Nein, und genau dafür gibt es die Funktion. In der Sitzung, die wir gemessen haben, belegte die App 2,8 GB über 91 Prozesse und die acht Agenten-CLIs zusammen 1,6 GB. Die 41,8 GB hielten Werkzeugprozesse, die hängengeblieben waren. AgentsRoom ist zufällig die einzige Stelle, die jeden Agenten und jeden von ihm gestarteten Prozess sieht, also die einzige Stelle, die entscheiden kann.
Beendet es meinen Build oder meinen Testlauf?
Nein. Ein Prozess wird nur gemeldet, wenn er groß UND alt ist UND aufgehört hat, den Prozessor zu benutzen. Ein Build, der wirklich arbeitet, lastet einen Kern aus, scheitert also an der dritten Bedingung und kommt nie infrage. Genau für diese Unterscheidung gibt es die Bedingung.
Überwacht es meinen Dev-Server?
Nein, und das wird es nie. Ein Dev-Server im Leerlauf erfüllt jedes Kriterium: er belegt viel Speicher, er läuft seit Stunden, und zwischen zwei Anfragen benutzt er keinen Prozessor. Überwacht werden nur die Kindprozesse von Agenten-Terminals, deine Dev-Kommandos liegen also per Konstruktion außerhalb.
Kann es den Agenten selbst beenden?
Nein. Das Agenten-CLI ist geschützt, egal welchen Provider du benutzt, und der Schutz stützt sich auf die Binary, mit der die App dieses Terminal gestartet hat, statt auf eine Liste bekannter Namen. Die Shell und der Terminal-Helper der App sind ebenfalls ausgeschlossen.
Was ist ein verwaister Prozess und warum wird er gesondert behandelt?
Ein Prozess, dessen Elternprozess sich beendet hat, wird an den Init-Prozess des Systems umgehängt. Ab diesem Moment verbindet ihn nichts mehr mit dem Agenten, der ihn gestartet hat, also räumt ihn niemand mehr auf. AgentsRoom merkt sich die Zugehörigkeit, solange der Prozess noch angehängt ist, denn das ist der einzige Moment, in dem sie sich feststellen lässt, und kann ihn deshalb auch danach noch melden.
Was kostet die Überwachung selbst?
Einen Prozess-Snapshot pro Minute, gemessen bei etwa 40 ms auf einer Maschine mit 824 laufenden Prozessen. Die teurere Speichermessung läuft nur auf Prozessen, die schon blockiert aussehen, was im Normalbetrieb heißt: sie läuft nicht. Und solange kein Agent aktiv ist, gibt es den Scan überhaupt nicht.
Warum nicht einfach in die Speicherspalte der Aktivitätsanzeige schauen?
Weil sie das Problem unter macOS um eine Größenordnung zu klein darstellt. Ein Prozess, der in den komprimierten Speicher gewandert ist, kann 20 MB resident anzeigen, während er 8 GB hält. Wir haben live einen mit 4,7 GB resident bei einer tatsächlichen Belegung von 14 GB gemessen. Die virtuelle Größe ist nicht besser: selbst Systemprozesse melden davon Hunderte Gigabytes.
Funktioniert es mit Claude Code, Codex und den anderen?
Ja. Der Wächter weiß nichts über ein bestimmtes Werkzeug oder einen bestimmten Provider. Er überwacht die Kindprozesse des Agenten-Terminals, das du gestartet hast, und das CLI, das er schützt, wird aus dem Start selbst gelesen. Einen Provider hinzuzufügen ändert hier nichts.
Funktioniert es unter Windows und Linux?
Ja. Jede Plattform braucht eine andere Messung, damit die Speicherangabe stimmt: komprimierte Seiten unter macOS, resident plus ausgelagert unter Linux, Private Commit unter Windows. Alle drei sind implementiert.
Beendet es Prozesse, ohne mich zu fragen?
Nicht, solange du das nicht einschaltest. Standardmäßig meldet es, was es gefunden hat, mit dem Agenten, dem Speicher, dem Alter und der Prozessorauslastung, und du entscheidest. Das automatische Beenden ist eine Einstellung, ab Werk aus.
Was passiert mit dem Agenten, wenn ich einen seiner Prozesse beende?
Der Agent läuft weiter. Sein Werkzeugaufruf bekommt einen Fehler zurück, statt ewig zu hängen, und das ist genau das gewünschte Ergebnis: der Prozess wäre ohnehin nie fertig geworden. Nichts wird neu gestartet und kein Kontext geht verloren.
Behebt es die eigentliche Ursache?
Nein, und das versucht es auch nicht. Die Ursachen wechseln: heute ein Werkzeug, morgen ein anderes Muster, nächsten Monat ein anderer Provider. Das hier ist ein Sicherheitsnetz, gebaut, um weiter zu funktionieren, wenn die Ursache eine ist, die noch niemand gesehen hat.
Das könnte dir auch gefallen
Context Canary
Die andere Frühwarnung: sie beobachtet den Kontext des Agenten statt der Maschine und sagt dir, dass ein Agent abdriftet, bevor er anfängt, Dateien und APIs zu erfinden.
Dev-Terminals
Lass deine Dev-Server und langen Kommandos in AgentsRoom laufen, mit einer Benachrichtigung, wenn ein langer Lauf fertig ist. Genau diese Terminals fasst der Prozess-Wächter per Konstruktion nie an.
Agentenstatus-Tracking
Sieh auf einen Blick, welche Agenten arbeiten, welche auf dich warten und welche im Leerlauf sind, ohne ein einziges Terminal zu lesen.
Token-Nutzung
Die andere Ressource, die einen Blick wert ist. Tokenverbrauch und Kontingent pro Agent, damit du weißt, wohin dein Verbrauch geht.
Split View
Mehrere Agenten nebeneinander in einem Fenster, jeder mit eigenem Bereich, eigener Farbe und Live-Status.
CLI Doctor
Wenn ein Agent nicht startet, sagt er dir warum und was zu tun ist, statt ein leeres Terminal zu hinterlassen.
Hör auf, für Prozesse zu bezahlen, die niemand benutzt
AgentsRoom ist kostenlos zum Herunterladen, und der Prozess-Wächter ist ab dem ersten Start aktiv.
Companion-App: Agenten auch unterwegs im Blick behalten
Nutzen Sie Claude, Codex, Antigravity CLI oder einen anderen KI-Anbieter.
Bugs und Wünsche direkt in dein öffentliches Backlog schicken.
Ein Blick auf AgentsRoom in Aktion.