Twoi agenci zostawiają po sobie procesy.
AgentsRoom je znajduje.
Agent AI uruchamia prawdziwy proces systemowy przy każdym wywołaniu narzędzia. Większość kończy się w kilka sekund. Niektóre nigdy, a wystarczy garstka takich naraz, żeby zapełnić pamięć maszyny.
Strażnik przeczesuje procesy potomne Twoich agentów, oznacza te, które zjadają Twoją pamięć, pojedynczo albo całym tłumem, wskazuje odpowiedzialnego agenta i pozwala Ci go przerwać. Nic nie jest kończone za Twoimi plecami.
Na co strażnik naprawdę patrzy: na procesy uruchomione przez jednego agenta i na to, które z nich przestały pracować.
Agent AI to nie jeden proces. Każde wywołanie narzędzia uruchamia na Twojej maszynie prawdziwy proces: wyszukiwanie, build, sprawdzenie typów, przebieg testów, skrypt. Pomnóż to przez kilku agentów pracujących równolegle, przez cały dzień, a dostaniesz setki procesów, które rodzą się i giną, a Ty nie zobaczysz ani jednego.
Prawie wszystkie się kończą. Problemem są te, które się nie kończą. Wyszukiwanie, którego wzorzec rozsadza silnik wyrażeń regularnych, nie wysypuje się i nie zwalnia: alokuje pamięć, ląduje w pamięci skompresowanej, a potem spędza resztę życia na błędach stron, podczas gdy jądro przerzuca dla niego gigabajty do swapu. Nigdy się nie skończy. Nic go nigdy nie zabije. A jeśli zamkniesz agenta, który go uruchomił, staje się sierotą, za którą nikt na maszynie już nie odpowiada.
Dlatego spowolnienie wkrada się po cichu. Nie ma jednego dramatycznego momentu, jest powolna kumulacja przez cały dzień pracy, a to dokładnie ten kształt, przez który ludzie obwiniają nie to, co trzeba: przegrzewanie, zbyt wielu agentów, wyciek pamięci w aplikacji. W sesji, którą zmierzyliśmy, sama aplikacja zajmowała 2,8 GB w 91 procesach, a osiem CLI agentów 1,6 GB łącznie. Żadne z nich nie było problemem.
Strażnik procesów jest siatką bezpieczeństwa. Pilnuje tego, co agenci zostawiają po sobie, mówi Ci, który proces się zawiesił i kto go uruchomił, i pozwala go zakończyć. Przyczyny źródłowe będą się dalej zmieniać: inne narzędzie, inny wzorzec, inny dostawca. Siatka nie musi się zmieniać.
Dlaczego maszyna z agentami AI zwalnia
Liczby poniżej pochodzą z jednej zmierzonej sesji na laptopie z 16 GB, na którym pracowało ośmiu agentów. Nic tu nie jest szacunkiem.
Maszyna działała od pięciu i pół godziny. Żadnego problemu termicznego: brak zarejestrowanego throttlingu, bateria przy 30,6 °C. Load average wynosił od 17 do 21 na 8 rdzeniach, a CPU spędzał 56% czasu w jądrze przy 1,5% bezczynności. To ta proporcja wszystko zdradza. Maszyna, która naprawdę pracuje, spędza czas w kodzie użytkownika; maszyna z 56% czasu systemowego to jądro, które nie robi nic poza kompresowaniem, dekompresowaniem i przerzucaniem pamięci do swapu.
Siedem zawieszonych procesów wyszukiwania trzymało po 3,9 do 8,0 GB każdy, łącznie 41,8 GB na maszynie z 16 GB RAM. Swap był na 22,3 GB z 23,5, a od startu systemu zapisano do niego około 993 GB. Zakończenie tych siedmiu procesów natychmiast oddało 15,5 GB, bez restartowania choćby jednego agenta i bez restartowania aplikacji.
Nikt nie wyłapuje tego ręcznie, bo zwykłe narzędzia kłamią na ten temat. Na macOS zawieszony proces może pokazywać 20 MB pamięci rezydentnej, trzymając w rzeczywistości 8 GB, bo wszystko, czego dotknął, przeszło przez kompresor pamięci. Zmierzyliśmy jeden na żywo: 4,7 GB rezydentnej przy rzeczywistym śladzie 14 GB. Rozmiar wirtualny też nie pomaga: na tej platformie nawet launchd raportuje około 440 GB rozmiaru wirtualnego, więc filtrowanie po nim oznacza całą maszynę.
Ta sama sesja, godzina po godzinie: bloki pamięci, których nikt już nie używa, i to, co się dzieje, gdy zostaną zwolnione.
A te procesy mają cztery właściwości, które gwarantują, że jutro nadal tu będą.
Nigdy się nie kończą
Ich własna pamięć jest w swapie, więc spędzają czas na błędach stron zamiast liczyć. I wcale nie są przy tym bezczynne: każdy ze zmierzonych przez nas procesów, które wyrwały się spod kontroli, zjadał od 10 do 19% rdzenia, a im więcej się ich nazbiera, tym mniej dostaje każdy z nich. Z tej spirali nie ma wyjścia, a czekanie nic nie daje.
Nigdy nie umierają
Wywołanie narzędzia nie ma limitu czasu. Nic na maszynie nie ma zdania o procesie, który od pięćdziesięciu minut nic nie robi. Będzie tam siedział, dopóki ktoś go nie zabije albo maszyna się nie zrestartuje.
Przeżywają swojego agenta
Zamknij kartę agenta, a proces może przetrwać. Każdy system zrywa to połączenie inaczej: klasyczny Unix przypisuje proces do init, pulpit Linux do Twojego menedżera użytkownika systemd, a Windows nie przypisuje go nigdzie i zostawia wskazanie na rodzica, który już nie istnieje. Dlatego strażnik nigdy nie patrzy na rodziców. Zapamiętuje to, co przygarnął, dopóki połączenie jeszcze istniało, i traktuje jako sierotę wszystko, czego brakuje w żywym drzewie procesów, identycznie na wszystkich trzech systemach. Dwa z siedmiu, które zmierzyliśmy, były już w tym stanie.
Kumulują się
Jeden na przebieg weryfikacji, jeden na pechowe wyszukiwanie i jeszcze jeden za każdym razem, gdy agent bierze wolne polecenie za zawieszone i uruchamia je ponownie. Zmierzyliśmy dwanaście sprawdzeń typów działających naraz, uruchomionych przez sześciu agentów, z których dwaj mieli po trzy w toku. Dlatego spowolnienie przez cały dzień tylko rośnie i dlatego restart wydaje się je naprawiać. Nic nie naprawia, tylko zeruje licznik.
Co robi strażnik procesów
Pilnuje procesów uruchamianych przez Twoich agentów i jest celowo bardzo wąski w tym, czego dotyka.
Mierzy rzeczywistą pamięć
Nie rozmiar rezydentny, który zaniża zawieszony proces o gigabajty. Strażnik czyta rzeczywisty ślad pamięciowy, ze stronami skompresowanymi i wyrzuconymi do swapu włącznie, więc proces pokazujący 20 MB i trzymający 8 GB jest widziany takim, jaki jest.
Mierzy procesor, nigdy mu nie ufa
Użycie procesora jest odczytywane jako tempo między dwoma skanami, a nie jako średnia z całego życia procesu podawana przez narzędzie systemowe, więc proces, który ciężko pracował, a potem się zawiesił, i tak zostanie złapany. Daje to wyżej postawioną poprzeczkę dla czegoś, co wciąż pracuje, a nigdy przepustki: proces, który wyrwał się spod kontroli i zjada piątą część rdzenia, to dokładnie to, co pierwsza wersja tego strażnika przepuszczała.
Łapie procesy osierocone
Proces, który przeżył agenta uruchamiającego go, jest zgłaszany sam z siebie, bo nikt inny go już nie posprząta. Właściciel jest zapamiętywany, dopóki proces jest jeszcze podpięty, bo to jedyny moment, w którym da się go ustalić.
Jedno kliknięcie, żeby zakończyć
Plakietka na pasku stanu wypisuje każdy zawieszony proces razem z agentem, który go uruchomił, jego pamięcią, wiekiem i CPU. Zakończenie jednego zamyka go wraz ze wszystkim, co sam odpalił. Pamięć wraca natychmiast, a Twoi agenci działają dalej.
macOS, Windows i Linux
Każdy system wymaga innego pomiaru, żeby powiedzieć prawdę o pamięci: strony skompresowane na macOS, pamięć rezydentna plus swap w systemie Linux, private commit w systemie Windows. Wszystkie trzy są zaimplementowane, nie zaplanowane.
Kosztuje prawie nic
Jedna migawka procesów na minutę, zmierzona na około 40 ms na maszynie z 824 działającymi procesami. Kosztowny pomiar pamięci uruchamia się tylko wtedy, gdy coś już wygląda na zawieszone, a gdy żaden agent nie jest aktywny, nie działa żaden skan.
Widzi tłum, nie tylko wyjątek
Dwanaście sprawdzeń typów po 1,4 GB to 16,8 GB na maszynie z 16 GB, a każde z nich z osobna mieści się pod rozsądnym progiem. Kiedy procesy uruchomione przez Twoich agentów wypełniają razem połowę fizycznej pamięci maszyny, rozmiar przestaje być oceniany pojedynczo.
Wskazuje odpowiedzialnego agenta
Dwa lub więcej oznaczonych poleceń tego samego agenta trafia pod jego awatar, razem z tym, ile trzymają łącznie, i z ostrzeżeniem tłumaczącym pętlę, w której utknęły. Jedno polecenie to wypadek; kilka naraz to zachowanie.
Przerywa agenta, nie tylko proces
Zakończenie procesu w trakcie tury jego agenta wręcza temu agentowi błąd, na który on reaguje, często uruchamiając polecenie jeszcze raz. Jeden przycisk wysyła zamiast tego Ctrl+C do terminala agenta: jego tura się kończy, nic nie startuje od nowa, a agent zostaje otwarty.
Zasady, które nie pozwalają mu wszczynać fałszywych alarmów
Strażnik, który oznacza Twoje buildy, to strażnik, którego wyłączysz w tydzień, więc poprzeczka jest celowo wysoko. Każdy proces potomny agenta, który żyje dłużej niż Twój próg, ma mierzoną rzeczywistą pamięć i jest zgłaszany, gdy tylko trzyma więcej, niż mu pozwoliłeś. Proces, który wciąż używa procesora, musi trzymać dwa razy tyle, i to właśnie trzyma z dala od zgłoszeń długi, uzasadniony build.
Użycie procesora ustawia tę poprzeczkę, nie jest warunkiem wstępu. Pierwsza wersja tego strażnika wymagała, żeby proces był bezczynny, zanim w ogóle spojrzała na jego pamięć, i to było błędem. Wyszukiwanie, którego wzorzec rozsadza silnik wyrażeń regularnych, wcale nie jest bezczynne: zjada piątą część rdzenia, podczas gdy jądro przerzuca dla niego gigabajty do swapu. Co gorsza, im więcej się ich nazbiera, tym mniej procesora dostaje każde z nich, więc martwe pole było najszersze na samym początku, kiedy zakończenie takiego procesu kosztowało najmniej.
Druga zasada istnieje dlatego, że poprzeczka ustawiona osobno dla każdego procesu nie widzi tłumu. Dwanaście sprawdzeń typów trzymających po 1,4 GB jest z osobna rozsądne, a razem zabójcze na maszynie z 16 GB. Dlatego gdy wszystko, co uruchomili agenci, sumuje się do połowy fizycznej pamięci maszyny, zgłaszane jest wszystko, niezależnie od tego, ile waży każdy element z osobna. Nic z tej grupy nie jest nigdy kończone automatycznie: to jest poniżej ustawionego przez Ciebie limitu i zostało oznaczone tylko z powodu sąsiadów.
Jak to działa
Cztery kroki, raz na minutę, a ten kosztowny prawie nigdy się nie uruchamia.
Jedna tania migawka maszyny
Co minutę strażnik robi jedną migawkę wszystkich działających procesów i przechodzi drzewo pod każdym terminalem agenta. Zmierzony koszt na maszynie z 824 działającymi procesami: około 40 ms. Dopóki żaden agent nie działa, w ogóle się to nie dzieje.
Wyłonić podejrzanych
Z tej migawki zostawia każdy proces potomny agenta, który żyje dłużej niż Twój próg. To cały filtr, i nic nie jest wykluczane z powodu tego, że wciąż używa procesora: dokładnie w ten sposób wcześniejsza wersja tego strażnika przepuszczała procesy, które wyrwały się spod kontroli. W normalnym użyciu ta lista jest pusta, bo wywołania narzędzi agenta kończą się w kilka sekund.
Zmierzyć te, które wyglądają na zawieszone
Tylko za tę krótką listę strażnik płaci rzeczywistym pomiarem pamięci, ze stronami skompresowanymi i wyrzuconymi do swapu włącznie. Proces, którego nie da się zmierzyć, nigdy nie jest oznaczany: niewiadoma to nie wyrok.
Zgłosić i zostawić decyzję Tobie
Na pasku stanu pojawia się plakietka, a jedno powiadomienie mówi Ci o tym raz. Otwierasz listę, widzisz, czym jest ten proces, ile trzyma, od jak dawna jest zawieszony i który agent go uruchomił, i kończysz go, jeśli chcesz.
Czego nigdy nie tknie
Narzędzie, które potrafi kończyć procesy, musi być wąskie w tym, co uznaje za swoją sprawę. Te granice są strukturalne, a nie są opcjami, o których włączeniu trzeba pamiętać.
- Samo CLI agenta. Niezależnie od tego, jakiego dostawcę uruchamiasz, strażnik chroni plik binarny, którym aplikacja uruchomiła ten terminal. Czyta tę nazwę z samego uruchomienia, a nie z listy zapisanej na sztywno, więc podproces tego samego CLI też jest chroniony, na dowolnej głębokości.
- Twoje terminale z komendami dev. Bezczynny serwer dev spełnia wszystkie kryteria zawieszonego procesu: gruby, stary, zero użycia procesora. Jest też dokładnie tym procesem, który chcesz widzieć w działaniu. Pilnowane są tylko terminale agentów, więc Twój serwer dev nigdy nie wchodzi w grę.
- Powłoka i wewnętrzna instalacja samej aplikacji. Helper terminala i powłoka, w której działa agent, są wykluczone z założenia. Kandydatami są wyłącznie procesy narzędzi znajdujące się pod CLI agenta.
- Wszystko, czego sam nie przygarnął. Jedyna ścieżka, która potrafi zakończyć proces, odrzuca każdy proces, którego strażnik nie podniósł z drzewa jakiegoś agenta. Nie może się stać sposobem na zamykanie czegokolwiek innego na Twojej maszynie.
I nic nie jest kończone automatycznie, dopóki o to nie poprosisz. Domyślnie strażnik zgłasza to, co znalazł, a Ty decydujesz, bo to Ty wiesz, czy duży, cichy proces był spodziewany. Nawet włączone, automatyczne kończenie zostawia w spokoju wszystko, co wciąż używa procesora, oraz wszystko, co zostało oznaczone tylko przez to, ile trzymają jego sąsiedzi.
Kiedy zarabia na swoje miejsce
Każda z tych sytuacji jest prawdziwa, żadna nie jest hipotetyczna.
Maszyna wolniejsza o 18 niż o 9 rano
Nie ma jednego momentu, w którym coś się zepsuło, jest tylko równy zjazd przez cały dzień. Ten kształt to niemal zawsze nagromadzone zawieszone procesy i najtrudniej go zdiagnozować ręcznie, bo w żadnej pojedynczej chwili nic nie wygląda źle.
Kilku agentów pracujących równolegle
Im więcej agentów uruchamiasz, tym więcej wywołań narzędzi się dzieje i tym większa szansa, że jedno się zawiesi. Odsetek awarii na wywołanie jest znikomy; pomnożony przez dzień równoległej pracy przestaje być znikomy.
Wyszukiwanie, które nigdy nie wraca
Wzorzec, który rozsadza silnik wyrażeń regularnych, alokuje gigabajty na pliku o rozmiarze kilkuset kilobajtów. Agent czeka na nie, Ty czekasz na agenta, a maszyna płaci za obu.
Zamknąłeś agenta, proces został
Zamknięcie karty nie zawsze cokolwiek zwalnia. Proces, który był już odłączony, zachowuje swoją pamięć i traci ostatnie połączenie z czymkolwiek, co widzisz w aplikacji.
Laptop z 16 GB
Na maszynie z dużą ilością RAM kilka zawieszonych procesów potrafi ukrywać się bardzo długo. Na laptopie z 16 GB szybko dobijają do swapu, a gdy system zaczyna kompresować pamięć, każdy agent zwalnia w tym samym momencie.
Zanim obwinisz aplikację
Kiedy maszyna się wlecze przy otwartym AgentsRoom, aplikacja jest oczywistym podejrzanym. Prawdziwe liczby, proces po procesie, z agentem, który uruchomił każdy z nich, zamieniają podejrzenie w coś, co da się sprawdzić.
To Ty ustalasz granice
Wartości domyślne są celowo ostrożne. Wszystko poniżej znajdziesz w ustawieniach, w zakładce Terminal, a każde z tych ustawień może też odczytać i zmienić agent przez narzędzia MCP AgentsRoom.
- Pilnuj procesów potomnych agentów
- Domyślnie włączone. Wyłącz je, a żaden skan już nigdy nie ruszy.
- Zgłaszaj powyżej progu pamięci
- Domyślnie dwa gigabajty. Poniżej tej wartości zawieszony proces nie jest wart przerywania Ci pracy. Podnieś próg na stacji roboczej z dużą ilością RAM, obniż go na laptopie, gdzie pamięci jest mało.
- Po minimalnym czasie życia
- Domyślnie pięć minut. Poniżej tego nic nie jest nawet mierzone, i to właśnie całkowicie wyklucza z obrazu zwykłe wywołania narzędzi agenta, te, które kończą się w kilka sekund.
- Kończ zawieszone procesy automatycznie
- Domyślnie wyłączone i jest to świadoma decyzja produktowa, a nie ostrożność. Strażnik wydaje osąd, a tylko Ty wiesz, czy duży, cichy proces był spodziewany. Włącz to, a zacznie działać sam, z powiadomieniem po fakcie.
Próg procesora nie jest wystawiony, tak samo jak punkt, w którym maszyna liczy się za nasyconą. Oba raz były ustawione źle i zostały poprawione przez pomiar prawdziwych incydentów, a nie według gustu, więc suwak przy którymkolwiek z nich byłby głównie sposobem na przywrócenie martwego pola.
Najczęściej zadawane pytania
Czy to znaczy, że AgentsRoom spowalnia mój komputer?
Nie, i właśnie dlatego ta funkcja istnieje. W zmierzonej przez nas sesji aplikacja zajmowała 2,8 GB w 91 procesach, a osiem CLI agentów 1,6 GB łącznie. Te 41,8 GB trzymały procesy narzędzi, które się zawiesiły. AgentsRoom jest akurat jedynym miejscem, z którego widać każdego agenta i każdy uruchomiony przez niego proces, więc jedynym miejscem, z którego można to rozstrzygnąć.
Czy zabije mój build albo przebieg testów?
Nigdy nie zakończy go bez pytania. Może go zgłosić: build musi trzymać dwa razy tyle, co Twój próg, domyślnie cztery gigabajty, albo należeć do grupy procesów agentów zapełniającej połowę pamięci Twojej maszyny. Ale automatyczne kończenie nigdy nie tyka procesu, który wciąż używa procesora, ani takiego, który został oznaczony tylko przez to, ile trzymają jego sąsiedzi. W obu przypadkach dostajesz wiersz, prawdziwe liczby i przycisk, i nic się nie dzieje, dopóki go nie naciśniesz.
Czy pilnuje mojego serwera dev?
Nie i nigdy nie będzie. Bezczynny serwer dev spełnia wszystkie kryteria: trzyma dużo pamięci, działa od godzin i między żądaniami nie używa procesora. Pilnowane są tylko procesy potomne terminali agentów, więc Twoje komendy dev są poza zakresem z założenia.
Czy może zakończyć samego agenta?
Nie. CLI agenta jest chronione niezależnie od dostawcy, a ochrona opiera się na pliku binarnym, którym aplikacja uruchomiła ten terminal, a nie na liście znanych nazw. Powłoka i helper terminala samej aplikacji też są wykluczone.
Czym jest proces osierocony i dlaczego traktuje się go osobno?
Proces, którego rodzic się zakończył, traci połączenie z agentem, który go uruchomił, i nikt go nigdy nie posprząta. To, jak zrywa się to połączenie, zależy od systemu: klasyczny Unix przypisuje proces do init, pulpit Linux do Twojego menedżera użytkownika systemd, a Windows nie przypisuje go nigdzie i zostawia po nim martwy identyfikator rodzica. Dlatego AgentsRoom nigdy nie sprawdza rodziców. Zapisuje właściciela, dopóki proces jest jeszcze podpięty, bo to jedyny moment, w którym da się to ustalić, i traktuje jako sierotę wszystko, czego brakuje w żywym drzewie procesów, identycznie na wszystkich trzech systemach.
Ile kosztuje samo pilnowanie?
Jedna migawka procesów na minutę, zmierzona na około 40 ms na maszynie z 824 działającymi procesami. Droższy pomiar pamięci uruchamia się tylko na procesach, które już wyglądają na zawieszone, co w normalnym użyciu oznacza, że się nie uruchamia. A skan w ogóle nie istnieje, dopóki żaden agent nie jest aktywny.
Dlaczego nie wystarczy spojrzeć na kolumnę pamięci w Monitorze aktywności?
Bo na macOS zaniża ona problem o rząd wielkości. Proces wepchnięty do pamięci skompresowanej może pokazywać 20 MB rezydentnej, trzymając 8 GB. Zmierzyliśmy jeden na żywo: 4,7 GB rezydentnej przy rzeczywistym śladzie 14 GB. Rozmiar wirtualny nie jest lepszy: nawet procesy systemowe raportują go w setkach gigabajtów.
Czy działa z Claude Code, Codex i resztą?
Tak. Strażnik nie wie nic o żadnym konkretnym narzędziu ani dostawcy. Pilnuje procesów potomnych dowolnego terminala agenta, który uruchomiłeś, a chronione CLI odczytuje z samego uruchomienia. Dodanie dostawcy nic tu nie zmienia.
Czy działa w systemach Windows i Linux?
Tak. Każda platforma wymaga innego pomiaru, żeby pamięć była podana uczciwie: strony skompresowane na macOS, pamięć rezydentna plus wyrzucona do swapu w systemie Linux, private commit w systemie Windows. Wszystkie trzy są zaimplementowane.
Czy zakończy procesy bez pytania mnie o zdanie?
Nie, chyba że sam to włączysz. Domyślnie zgłasza to, co znalazł, razem z agentem, pamięcią, wiekiem i użyciem procesora, a Ty decydujesz. Automatyczne kończenie to ustawienie, wyłączone zaraz po instalacji.
Co dzieje się z agentem, gdy zakończę jeden z jego procesów?
Agent działa dalej. Jego wywołanie narzędzia dostaje błąd zamiast wisieć w nieskończoność, i to jest dokładnie ten wynik, o który Ci chodzi: ten proces i tak nigdy by się nie skończył. Nic nie jest restartowane i żaden kontekst nie ginie.
Czy to naprawia przyczynę źródłową?
Nie i nawet nie próbuje. Przyczyny się zmieniają: dziś jedno narzędzie, jutro inny wzorzec, za miesiąc inny dostawca. To siatka bezpieczeństwa, zaprojektowana tak, żeby działać dalej, gdy przyczyną okaże się coś, czego nikt jeszcze nie widział.
Dwanaście procesów i żaden nie przekracza mojego progu. Czy coś powie?
Tak, i to właśnie ten przypadek zmienił zasadę. Zmierzone na maszynie z 16 GB: dwanaście sprawdzeń typów uruchomionych przez sześciu agentów, od 0,84 do 1,72 GB każde, wszystkie z zapasem poniżej progu 2 GB, razem 15,4 GB, swap pełny, maszyna nie do użycia. Oceniane pojedynczo, każde z nich było w porządku. Gdy tylko suma przekroczy połowę Twojej pamięci fizycznej, zgłaszane są wszystkie, pogrupowane pod agentem, który je uruchomił.
Co dokładnie robi przycisk Przerwij agenta?
Wysyła Ctrl+C do terminala tego agenta, dokładnie ten sam skrót, który nacisnąłbyś sam. Bieżąca tura agenta się kończy i agent czeka na Ciebie: nie jest zamykany, jego sesja zostaje nienaruszona i nic innego na Twojej maszynie nie jest ruszane. Istnieje dlatego, że zakończenie procesu, gdy agent wciąż nad nim pracuje, leczy tylko objaw, bo agent dostaje błąd i często po prostu uruchamia polecenie jeszcze raz.
Może Cię też zainteresować
Kanarek kontekstu
Drugie wczesne ostrzeżenie: pilnuje kontekstu samego agenta zamiast maszyny i mówi Ci, że agent dryfuje, zanim zacznie wymyślać pliki i API.
Terminale dev
Uruchamiaj swoje serwery dev i długie komendy w AgentsRoom, z powiadomieniem, gdy długa komenda się skończy. To dokładnie te terminale, których strażnik procesów z założenia nigdy nie tyka.
Śledzenie statusu agentów
Zobacz na pierwszy rzut oka, którzy agenci pracują, którzy czekają na Ciebie, a którzy są bezczynni, bez czytania choćby jednego terminala.
Zużycie tokenów
Drugi zasób, który warto mieć na oku. Zużycie tokenów i limit dla każdego agenta, żebyś wiedział, gdzie ucieka Twoje wykorzystanie.
Widok podzielony
Kilku agentów obok siebie w jednym oknie, każdy z własnym panelem, kolorem i statusem na żywo.
CLI Doctor
Gdy agent nie potrafi wystartować, mówi Ci dlaczego i co z tym zrobić, zamiast zostawiać pusty terminal.
Przestań płacić za procesy, których nikt nie używa
AgentsRoom pobierzesz za darmo, a strażnik procesów działa od pierwszego uruchomienia.
Aplikacja towarzysząca: monitoruj agentów w podróży
Użyj Claude, Codex, Antigravity CLI lub innego dostawcy AI.
Wysyłaj bugi i prośby bezpośrednio do swojego publicznego backlogu.
Spojrzenie na AgentsRoom w akcji.