I tuoi agenti lasciano processi indietro.
AgentsRoom li trova.
Un agente IA lancia un vero processo di sistema per ogni strumento che chiama. Quasi tutti finiscono in pochi secondi. Alcuni mai, e ne bastano una manciata attivi insieme per riempire la memoria di una macchina.
Il guardiano passa al setaccio i processi figli dei tuoi agenti, segnala quelli che ti mangiano la memoria, uno per uno o tutti insieme, dice quale agente ne è responsabile e ti lascia interromperlo. Niente viene terminato alle tue spalle.
Quello che il guardiano guarda davvero: i processi lanciati da un agente, e quali di essi hanno smesso di lavorare.
Un agente IA non è un processo. Ogni chiamata a uno strumento ne avvia uno vero sulla tua macchina: una ricerca, una build, un controllo dei tipi, una serie di test, uno script. Moltiplica tutto questo per qualche agente che lavora in parallelo, su una giornata intera, e ti ritrovi centinaia di processi nati e sepolti senza che tu ne veda uno.
Quasi tutti finiscono. Il problema sono gli altri. Una ricerca il cui pattern fa esplodere il motore delle espressioni regolari non va in crash e non rallenta: alloca, finisce spinta nella memoria compressa, e poi passa la vita a fare page fault mentre il kernel sposta gigabyte nello swap per lei. Non finirà mai. Nessuno la ucciderà mai. E se l'agente che l'ha lanciata viene chiuso, diventa un orfano di cui sulla macchina non è più responsabile nessuno.
È per questo che il rallentamento si insinua piano. Non c'è un momento in cui qualcosa si rompe, c'è un accumulo lungo la giornata, ed è esattamente la forma che porta ad accusare la causa sbagliata: il surriscaldamento, troppi agenti, una perdita di memoria dell'app. Nella sessione che abbiamo misurato, l'app stava dentro 2,8 GB su 91 processi e le otto CLI degli agenti dentro 1,6 GB in tutto. Nessuna delle due era il problema.
Il guardiano dei processi è la rete di sicurezza. Sorveglia quello che gli agenti lasciano indietro, ti dice quale è bloccato e chi l'ha lanciato, e ti lascia terminarlo. Le cause continueranno a cambiare: un altro strumento, un altro pattern, un altro provider. La rete no.
Perché una macchina che fa girare agenti IA rallenta
I numeri qui sotto vengono da una sessione misurata su un portatile da 16 GB con otto agenti attivi. Qui non c'è nessuna stima.
La macchina era accesa da cinque ore e mezza. Nessun problema termico: nessun throttling registrato, batteria a 30,6 C. Il load average stava tra 17 e 21 su 8 core, e la CPU passava il 56% del tempo nel kernel per l'1,5% di inattività. È quel rapporto a tradire tutto. Una macchina che lavora davvero passa il tempo in codice utente; una macchina al 56% di tempo di sistema è un kernel che non fa altro che comprimere, decomprimere e spostare memoria nello swap.
Sette processi di ricerca bloccati occupavano tra 3,9 e 8,0 GB ciascuno, 41,8 GB in tutto su una macchina con 16 GB di RAM. Lo swap era a 22,3 GB su 23,5, e dall'avvio erano stati scritti circa 993 GB nello swap. Terminare quei sette processi ha restituito 15,5 GB all'istante, senza riavviare un solo agente e senza riavviare l'app.
Se nessuno se ne accorge a mano è perché gli strumenti di sempre mentono. Su macOS un processo bloccato può mostrare 20 MB di memoria residente mentre in realtà ne occupa 8 GB, perché tutto quello che ha toccato è passato dal compressore di memoria. Ne abbiamo misurato uno dal vivo a 4,7 GB di residente per un'impronta reale di 14 GB. Nemmeno la dimensione virtuale aiuta: su quella piattaforma perfino launchd dichiara circa 440 GB di dimensione virtuale, quindi filtrare su quella significa segnalare l'intera macchina.
La stessa sessione, ora per ora: le fette di memoria che nessuno usa più, e cosa succede quando le si libera.
E questi processi hanno quattro proprietà che garantiscono che domani saranno ancora lì.
Non finiscono mai
La loro stessa memoria è nello swap, quindi passano il tempo a fare page fault invece di calcolare. E non stanno fermi mentre lo fanno: i processi fuori controllo che abbiamo misurato bruciavano ciascuno tra il 10 e il 19% di un core, e più se ne accumulano meno ne tocca a ognuno. Da quella spirale non si esce, e aspettare non serve a niente.
Non muoiono mai
Non c'è nessun tempo massimo su una chiamata a uno strumento. Niente sulla macchina ha un'opinione su un processo fermo da cinquanta minuti. Resterà lì finché qualcuno non lo uccide o la macchina non si riavvia.
Sopravvivono al loro agente
Chiudi la scheda dell'agente e il processo può sopravvivere. Ogni sistema spezza il legame a modo suo: lo Unix classico lo riaggancia a init, un desktop Linux al tuo gestore utente systemd, e Windows non lo riaggancia proprio a niente e lo lascia puntare a un padre che non esiste più. Per questo il guardiano non guarda mai i padri. Si ricorda quello che ha adottato mentre il legame c'era ancora, e tratta come orfano tutto ciò che manca dall'albero vivo dei processi, in modo identico sui tre sistemi. Due dei sette che abbiamo misurato erano già in quello stato.
Si accumulano
Uno per passata di verifica, uno per ricerca sfortunata, e uno in più ogni volta che un agente scambia un comando lento per un comando piantato e lo rilancia. Abbiamo misurato dodici controlli dei tipi in esecuzione insieme, lanciati da sei agenti, due dei quali ne avevano tre in corso. È per questo che il rallentamento cresce senza sosta lungo la giornata ed è per questo che un riavvio sembra risolvere. Non risolve niente, azzera solo il contatore.
Cosa fa il guardiano dei processi
Sorveglia i processi che i tuoi agenti lanciano, ed è volutamente strettissimo su quelli che si permette di toccare.
Misura la memoria vera
Non la dimensione residente, che sottostima un processo bloccato di diversi gigabyte. Il guardiano legge l'impronta reale, pagine compresse e pagine finite in swap comprese, così un processo che mostra 20 MB e ne tiene 8 GB viene visto per quello che è.
Misura il processore, non si fida mai
L'uso del processore è letto come un tasso tra due scansioni, non come la media su tutta la vita del processo che dà uno strumento di sistema, così viene preso anche chi ha lavorato sodo e poi si è piantato. Quello che se ne ricava è un'asticella più alta per qualcosa che sta ancora lavorando, mai un lasciapassare: un processo fuori controllo che brucia un quinto di un core è esattamente quello che la prima versione di questo guardiano si lasciava sfuggire.
Prende i processi orfani
Un processo sopravvissuto all'agente che l'ha lanciato viene segnalato di diritto, perché nessun altro lo reclamerà. L'appartenenza viene memorizzata mentre il processo è ancora attaccato, l'unico momento in cui si può stabilire.
Un clic per terminarlo
Un indicatore nella barra di stato elenca ogni processo bloccato con l'agente che l'ha lanciato, la sua memoria, la sua età e la sua CPU. Terminarne uno uccide anche tutto quello che ha lanciato a sua volta. La memoria torna subito e i tuoi agenti continuano a girare.
macOS, Windows e Linux
Ogni sistema richiede una misura diversa perché il dato sulla memoria dica il vero: pagine compresse su macOS, residente più swap su Linux, private commit su Windows. Tutte e tre sono implementate, non previste.
Non costa quasi niente
Un'istantanea dei processi al minuto, misurata in circa 40 ms su una macchina che ne fa girare 824. La misura di memoria costosa scatta solo se qualcosa sembra già bloccato, e finché nessun agente è attivo non gira nessuna scansione.
Vede la folla, non solo il caso isolato
Dodici controlli dei tipi da 1,4 GB l'uno fanno 16,8 GB su una macchina da 16 GB, e ognuno di loro sta sotto una soglia sensata. Quando i processi lanciati dai tuoi agenti riempiono insieme metà della memoria fisica della macchina, la dimensione smette di essere giudicata uno alla volta.
Indica l'agente responsabile
Due o più comandi segnalati dello stesso agente vengono raggruppati sotto il suo avatar, con quanto tengono insieme e un avviso che spiega il circolo vizioso in cui sono finiti. Un comando è un incidente; diversi insieme sono un comportamento.
Interrompe l'agente, non solo il processo
Terminare un processo mentre il suo agente è a metà del turno gli consegna un errore a cui reagisce, spesso rilanciando lo stesso comando. Un pulsante manda invece Ctrl+C al terminale dell'agente: il suo turno finisce, non riparte niente e l'agente resta aperto.
Le regole che gli impediscono di gridare al lupo
Un guardiano che ti segnala le build è un guardiano che disattivi nel giro di una settimana, quindi l'asticella è volutamente alta. Ogni processo figlio di un agente vivo da più della tua soglia si vede misurare la memoria reale, e viene segnalato appena tiene più di quanto hai concesso. Un processo che sta ancora usando il processore deve tenerne il doppio, ed è questo che tiene una build lunga e legittima fuori dal quadro.
L'uso del processore fissa quell'asticella, non è una condizione d'ingresso. La prima versione di questo guardiano pretendeva che un processo fosse fermo prima ancora di guardargli la memoria, ed era sbagliato. Una ricerca il cui pattern fa esplodere il motore delle espressioni regolari non è ferma: brucia un quinto di un core mentre il kernel sposta gigabyte nello swap per lei. Peggio ancora: più se ne accumulano, meno processore tocca a ciascuna, quindi il punto cieco era più largo proprio all'inizio, quando terminarne una costava meno.
La seconda regola esiste perché un'asticella per singolo processo non può vedere una folla. Dodici controlli dei tipi che tengono 1,4 GB ciascuno sono ragionevoli presi uno per uno e fatali tutti insieme su una macchina da 16 GB. Per questo, quando tutto ciò che gli agenti hanno lanciato arriva a sommare metà della memoria fisica della macchina, viene segnalato tutto, qualunque cosa pesi ogni singolo pezzo. Niente di quel gruppo viene mai terminato in automatico: sta sotto il limite che hai fissato, ed è stato segnalato solo per colpa dei suoi vicini.
Come funziona
Quattro passaggi, una volta al minuto, e quello costoso non scatta quasi mai.
Un'istantanea a buon mercato della macchina
Ogni minuto il guardiano scatta una sola istantanea di tutti i processi attivi e percorre l'albero sotto ogni terminale di agente. Costo misurato su una macchina che fa girare 824 processi: circa 40 ms. Finché non gira nessun agente, non succede proprio niente.
Selezionare i sospetti
Da quell'istantanea tiene ogni processo figlio di un agente vivo da più della tua soglia. Il filtro è tutto qui, e niente viene escluso perché sta ancora usando il processore: è esattamente così che la versione precedente di questo guardiano si lasciava sfuggire i processi fuori controllo. In uso normale la lista è vuota, visto che le chiamate agli strumenti di un agente finiscono in pochi secondi.
Misurare quelli che sembrano bloccati
È solo per quella lista corta che il guardiano paga la misura di memoria vera, pagine compresse e pagine finite in swap comprese. Un processo che non riesce a misurare non viene mai segnalato: un'incognita non è un verdetto.
Segnalare, e lasciarti decidere
Nella barra di stato compare un indicatore e un solo avviso te lo dice una volta. Apri la lista, vedi cos'è il processo, quanto occupa, da quanto è bloccato e quale agente l'ha lanciato, e lo termini se vuoi.
Quello che non toccherà mai
Uno strumento capace di terminare processi deve essere strettissimo su cosa considera affar suo. Questi limiti sono strutturali, non opzioni che devi ricordarti di attivare.
- La CLI dell'agente stessa. Qualunque provider tu usi, il guardiano protegge il binario con cui l'app ha lanciato quel terminale. Legge quel nome dal lancio stesso invece che da una lista scritta a mano, quindi anche un sottoprocesso della stessa CLI è protetto, a qualsiasi profondità.
- I tuoi terminali di comandi dev. Un server di dev a riposo soddisfa tutti i criteri: grosso, vecchio, nessun uso di processore. Ed è anche l'unico processo che vuoi davvero avere in esecuzione. Sono sorvegliati solo i terminali degli agenti, quindi il tuo server di dev non entra mai nel quadro.
- La shell e gli ingranaggi interni dell'app. L'helper del terminale e la shell in cui gira un agente sono esclusi per costruzione. Gli unici candidati sono i processi degli strumenti che stanno sotto la CLI dell'agente.
- Tutto ciò che non ha adottato. L'unica strada che può terminare un processo rifiuta qualsiasi processo che il guardiano non abbia raccolto dall'albero di un agente. Non può diventare un modo per terminare qualcos'altro sulla tua macchina.
E niente viene terminato in automatico se non lo chiedi tu. Di default il guardiano segnala quello che ha trovato e decidi tu, perché sei tu a sapere se un processo grosso e silenzioso era previsto. Anche attivata, la terminazione automatica lascia stare tutto ciò che sta ancora usando il processore, e tutto ciò che è stato segnalato solo per quanto tengono i suoi vicini.
Quando si guadagna il suo posto
Ognuna di queste situazioni è reale, nessuna è ipotetica.
La macchina più lenta alle 18 che alle 9
Nessun momento preciso in cui si è rotto qualcosa, solo una discesa costante lungo la giornata. Questa forma è quasi sempre fatta di processi bloccati accumulati, ed è la più difficile da diagnosticare a mano perché in nessun istante preciso c'è qualcosa che sembri sbagliato.
Più agenti che lavorano in parallelo
Più agenti fai girare, più chiamate a strumenti ci sono, e più possibilità che una si pianti. Il tasso di fallimento per chiamata è minuscolo; moltiplicato per una giornata di lavoro in parallelo smette di esserlo.
Una ricerca che non torna mai
Un pattern che fa esplodere il motore delle espressioni regolari alloca gigabyte su un file da qualche centinaio di kilobyte. L'agente la aspetta, tu aspetti l'agente, e la macchina paga per entrambi.
Hai chiuso l'agente, il processo è rimasto
Chiudere una scheda non sempre libera qualcosa. Un processo già staccato si tiene la sua memoria e perde l'ultimo legame con qualsiasi cosa tu possa vedere nell'app.
Un portatile con 16 GB
Su una macchina con RAM in abbondanza qualche processo bloccato si nasconde a lungo. Su un portatile da 16 GB arrivano allo swap in fretta, e appena il sistema si mette a comprimere memoria tutti i tuoi agenti rallentano insieme.
Prima di dare la colpa all'app
Quando una macchina arranca con AgentsRoom aperto, l'app è il sospettato ovvio. Avere i numeri veri, processo per processo, con l'agente che ha lanciato ciascuno, trasforma un sospetto in qualcosa che puoi davvero verificare.
I limiti li fissi tu
I valori di default sono volutamente prudenti. Tutto quello che segue sta nelle impostazioni, scheda Terminale, e ognuna di queste impostazioni può anche essere letta e modificata da un agente tramite gli strumenti MCP di AgentsRoom.
- Sorvegliare i processi figli degli agenti
- Attivo di default. Disattivalo e non gira più nessuna scansione, mai.
- Segnalare oltre una soglia di memoria
- Due gigabyte di default. Sotto quella cifra, un processo bloccato non vale un'interruzione. Alza la soglia su una workstation piena di RAM, abbassala su un portatile dove la memoria è contata.
- Dopo una durata di vita minima
- Cinque minuti di default. Sotto quella durata non viene misurato proprio niente, ed è questo che tiene completamente fuori dal quadro le normali chiamate agli strumenti di un agente, quelle che finiscono in pochi secondi.
- Terminare automaticamente i processi bloccati
- Disattivato di default, ed è una scelta di prodotto voluta più che prudenza. Il guardiano sta dando un giudizio, e solo tu sai se un processo grosso e silenzioso era previsto. Attivalo e agirà da solo, con una notifica a cose fatte.
La soglia del processore non è esposta, e nemmeno il punto oltre il quale la macchina viene considerata satura. Entrambi sono già stati sbagliati una volta e sono stati corretti misurando incidenti reali invece che a gusto, quindi metterci un cursore sarebbe soprattutto un modo per rimettere al suo posto il punto cieco.
Domande frequenti
Vuol dire che AgentsRoom rallenta il mio computer?
No, ed è esattamente per questo che la funzionalità esiste. Nella sessione che abbiamo misurato, l'app stava dentro 2,8 GB su 91 processi e le otto CLI degli agenti dentro 1,6 GB in tutto. I 41,8 GB erano occupati da processi di strumenti che si erano piantati. AgentsRoom si dà il caso sia l'unico posto da cui si vedono tutti gli agenti e tutti i processi che hanno lanciato, quindi l'unico posto da cui si può arbitrare.
Ucciderà la mia build o i miei test?
Non ne terminerà mai una senza chiedertelo. Può segnalarla: una build deve tenere il doppio della tua soglia, quattro gigabyte di default, oppure far parte di un gruppo di processi di agenti che occupa metà della memoria della tua macchina. Ma la terminazione automatica non tocca mai un processo che sta ancora usando il processore, né uno segnalato solo per quanto tengono i suoi vicini. In tutti e due i casi ti ritrovi una riga, i numeri veri e un pulsante, e non succede niente finché non lo premi.
Sorveglia il mio server di dev?
No, e non lo farà mai. Un server di dev a riposo soddisfa tutti i criteri: occupa molta memoria, gira da ore, e tra una richiesta e l'altra non usa processore. Sono sorvegliati solo i processi figli dei terminali degli agenti, quindi i tuoi comandi dev restano fuori portata per costruzione.
Può terminare l'agente stesso?
No. La CLI dell'agente è protetta qualunque sia il provider, e la protezione si basa sul binario con cui l'app ha lanciato quel terminale, non su una lista di nomi noti. Anche la shell e l'helper del terminale dell'app sono esclusi.
Cos'è un processo orfano e perché ha un trattamento a parte?
Un processo il cui padre è terminato perde il legame con l'agente che l'ha lanciato, e nessuno lo ripulirà mai. Come si spezza quel legame dipende dal sistema: lo Unix classico lo riaggancia a init, un desktop Linux al tuo gestore utente systemd, e Windows non lo riaggancia a niente e lascia dietro di sé un id di padre morto. Per questo AgentsRoom non guarda mai i padri. Registra l'appartenenza mentre il processo è ancora attaccato, l'unico momento in cui si può stabilire, e tratta come orfano tutto ciò che manca dall'albero vivo dei processi, in modo identico su tutti e tre i sistemi.
Quanto costa la sorveglianza in sé?
Un'istantanea dei processi al minuto, misurata in circa 40 ms su una macchina che ne fa girare 824. La misura di memoria più costosa si applica solo ai processi che sembrano già bloccati, il che in uso normale vuol dire che non si applica. E la scansione non esiste proprio finché nessun agente è attivo.
Perché non guardare semplicemente la colonna della memoria in Monitoraggio Attività?
Perché su macOS sottostima il problema di un ordine di grandezza. Un processo spinto nella memoria compressa può mostrare 20 MB di residente pur tenendone 8 GB. Ne abbiamo misurato uno dal vivo a 4,7 GB di residente per un'impronta reale di 14 GB. La dimensione virtuale non è meglio: perfino i processi di sistema ne dichiarano centinaia di gigabyte.
Funziona con Claude Code, Codex e gli altri?
Sì. Il guardiano non conosce nessuno strumento né nessun provider in particolare. Sorveglia i processi figli del terminale di agente che hai lanciato, e la CLI che protegge viene letta dal lancio stesso. Aggiungere un provider qui non cambia niente.
Funziona su Windows e Linux?
Sì. Ogni piattaforma richiede una misura diversa perché la memoria sia detta con onestà: pagine compresse su macOS, residente più swap su Linux, private commit su Windows. Tutte e tre sono implementate.
Terminerà processi senza chiedermelo?
Non finché non lo attivi tu. Di default segnala quello che ha trovato, con l'agente, la memoria, l'età e l'uso del processore, e decidi tu. La terminazione automatica è un'impostazione, disattivata di fabbrica.
Cosa succede all'agente quando termino uno dei suoi processi?
L'agente continua a girare. La sua chiamata allo strumento riceve un errore invece di restare appesa per sempre, che è esattamente il risultato che vuoi: quel processo non sarebbe comunque mai arrivato in fondo. Non viene rilanciato niente e non si perde nessun contesto.
Risolve la causa alla radice?
No, e non ci prova. Le cause cambiano: uno strumento oggi, un altro pattern domani, un altro provider il mese prossimo. Questa è una rete di sicurezza, pensata per continuare a funzionare quando la causa è una che nessuno ha ancora visto.
Dodici processi, nessuno sopra la mia soglia. Dirà qualcosa?
Sì, ed è proprio questo caso ad aver fatto cambiare la regola. Misurato su una macchina da 16 GB: dodici controlli dei tipi lanciati da sei agenti, da 0,84 a 1,72 GB ciascuno, tutti ampiamente sotto una soglia di 2 GB, 15,4 GB in tutto, swap pieno e macchina inutilizzabile. Giudicati uno alla volta, andavano bene tutti quanti. Appena il totale supera metà della tua memoria fisica, vengono segnalati tutti, raggruppati sotto l'agente che li ha lanciati.
Cosa fa esattamente il pulsante Interrompi l'agente?
Manda Ctrl+C al terminale di quell'agente, la stessa combinazione di tasti che premeresti tu. Il turno in corso dell'agente finisce e lui aspetta te: non viene chiuso, la sua sessione resta intatta e non viene toccato nient'altro sulla tua macchina. Esiste perché terminare un processo mentre l'agente ci sta ancora lavorando cura solo il sintomo, visto che l'agente riceve un errore e spesso si limita a rilanciare lo stesso comando.
Potrebbe interessarti anche
Canarino di contesto
L'altro allarme precoce: sorveglia il contesto dell'agente invece della macchina, e ti avverte che un agente sta derivando prima che si metta a inventare file e API.
Dev Terminals
Fai girare i tuoi server di dev e i tuoi comandi lunghi dentro AgentsRoom, con una notifica quando uno lungo finisce. Questi terminali sono esattamente quelli che il guardiano dei processi è fatto per non toccare mai.
Monitoraggio dello stato degli agenti
Vedi a colpo d'occhio quali agenti stanno lavorando, quali aspettano te e quali sono fermi, senza leggere un solo terminale.
Utilizzo dei token
L'altra risorsa che vale la pena tenere d'occhio. Consumo di token e quota per agente, per sapere dove finisce il tuo utilizzo.
Vista divisa
Più agenti affiancati in un'unica finestra, ognuno con il suo pannello, il suo colore e il suo stato in diretta.
CLI Doctor
Quando un agente non riesce ad avviarsi, ti dice perché e cosa fare, invece di lasciarti davanti a un terminale vuoto.
Smetti di pagare per processi che non usa nessuno
AgentsRoom è gratis da scaricare, e il guardiano dei processi è attivo dal primo avvio.
App companion: monitora i tuoi agenti in movimento
Usa Claude, Codex, Antigravity CLI o un altro provider IA.
Invia bug e richieste direttamente nel tuo backlog pubblico.