abtop : un htop pour flottes d’agents Claude Code et Codex CLI

https://github.com/graykode/abtop

📌 abtop sert à superviser, en un seul écran, plusieurs sessions d’agents de code qui tournent en parallèle (Claude Code et Codex CLI) : consommation de tokens, remplissage de la fenêtre de contexte, rate limits, processus enfants, ports ouverts et indicateurs d’état. L’intérêt n’est pas de “faire plus d’IA”, mais de remettre de la lisibilité quand le travail réel ressemble à une flotte de terminaux, de sous-agents et de services locaux.

Quand plusieurs agents tournent en même temps, les problèmes ne sont pas toujours “dans le code”. Ils se cachent dans l’exécution : un agent qui lance un serveur et l’oublie, une session qui sature sa fenêtre de contexte, une autre qui se fait throttler, un terminal coincé sur une tâche qui n’avance plus. Les outils classiques donnent des signaux dispersés. abtop regroupe les métriques utiles au bon endroit, au bon moment, pour reprendre la main rapidement.

abtop se positionne comme l’équivalent d’un htop/btop dédié aux workflows d’agents. Le produit n’a pas besoin d’une clé API pour fonctionner : il s’appuie sur l’état local (processus, fichiers, descripteurs ouverts) et sur les artefacts de session pour découvrir automatiquement les sessions actives, même si plusieurs profils sont en cours sur une même machine. Cette approche “read-only” est importante : elle réduit la surface d’erreur, évite d’ajouter une couche d’authentification et garde l’outil utilisable dans des environnements de dev qui changent souvent.

Concrètement, l’usage le plus rentable d’abtop arrive dès qu’il y a au moins trois axes de travail en même temps : un agent qui prépare une refacto, un autre qui implémente une feature, un troisième qui fait des recherches ou de la revue. Le cerveau humain n’est pas fait pour retenir où en est chaque terminal, quel quota est en train de tomber, et quel port a été ouvert il y a 20 minutes. Une vue synthétique évite de “checker au hasard” et transforme le diagnostic en routine.

points clés

• 🧭 Découverte automatique des sessions Claude Code et Codex CLI à partir de l’état local, sans configuration lourde

• 📊 Vue unique des signaux opérationnels : tokens, contexte, rate limits, état de session, tâches en cours

• 🧵 Lecture des processus enfants et des ports ouverts pour repérer rapidement les services orphelins

• 🧰 Intégration fluide en terminal, avec une ergonomie type htop/btop pour naviguer vite

• 🔒 Approche sans clé API et sans authentification, orientée confidentialité et simplicité d’usage

• 🧩 Bonus en tmux : capacité à sauter directement vers le pane de la session sélectionnée

Dans une journée typique, abtop sert d’abord à trier : quelles sessions sont réellement actives, lesquelles attendent, lesquelles sont “bloquées” (par exemple parce que la limite de requêtes a été atteinte). Ensuite, il sert à décider : faut-il compacter le contexte, relancer proprement une session, tuer un processus enfant, ou simplement laisser une tâche finir pendant qu’une autre avance.

Un point pratique : la gestion des ports est souvent un angle mort. Les agents de code lancent des serveurs de dev, des API locales, des watchers, des bundlers, parfois sans les arrêter proprement. Résultat : ports occupés, conflits, lenteurs et confusion. Un écran qui met en évidence les ports orphelins change le jeu : on peut nettoyer sans partir à la chasse dans plusieurs terminaux, et on évite de confondre “bug applicatif” avec “environnement sale”.

L’intégration avec tmux est particulièrement cohérente avec la réalité du terrain. Beaucoup de workflows d’agents se font déjà en panneaux : un panneau par projet, un panneau pour l’orchestrateur, un panneau pour les logs. Avec abtop dans un pane dédié, l’outil devient une console de contrôle : sélectionner une session et basculer immédiatement au bon endroit pour intervenir. Ce détail réduit le coût de contexte, qui est souvent le vrai goulot d’étranglement quand on jongle entre plusieurs tâches.

Côté démarrage, le projet est en Rust et se distribue comme un binaire CLI. L’installation se fait via un script d’install, via cargo, ou via des binaires précompilés. Le bon test, après installation, est simple : lancer l’interface, vérifier que les sessions locales sont détectées, puis laisser tourner quelques minutes pour voir si les métriques évoluent de façon plausible pendant une activité réelle (itérations de prompts, exécution de commandes, création de sous-processus).

Sur la confidentialité, l’approche est pragmatique : abtop lit des métadonnées locales et des fichiers de session, sans afficher le contenu des prompts. Les noms d’outils et des chemins peuvent apparaître dans l’interface, ce qui est utile pour se repérer, mais il faut garder en tête que tout ce qui est visible à l’écran doit être considéré comme un signal de diagnostic, pas comme un endroit pour exposer des données sensibles. Dans des contextes partagés (streaming, démos), cette visibilité peut être un avantage si elle est maîtrisée, ou un risque si elle ne l’est pas.

Au final, abtop répond à un besoin qui devient central : la supervision de l’exécution quand la “productivité agentique” n’est plus un flux linéaire, mais un système distribué sur une machine locale. Ce n’est pas un outil qui remplace un agent ; c’est un outil qui rend les agents utilisables à grande échelle, en réduisant la friction opérationnelle et en ramenant des signaux concrets dans le terminal.