Monitor tool Claude Code — background scripts event-driven, fin du polling¶

Resume¶

Noah Zweben (Anthropic) annonce le 2026-04-09 l'outil Monitor dans Claude Code : il permet a Claude de creer des scripts background qui reveillent l'agent quand un evenement se produit, au lieu de poller dans la loop agent. Use cases cites : suivre des logs a la recherche d'erreurs, poller des PRs via script, "and more". Le tool est lance en arriere-plan, pas dans un terminal visible — le terminal montre dans la video de demo etait juste illustratif.

L'annonce a fait 751K vues, 4.8K likes, 4K bookmarks en 24h. Zweben credite @alistaiir comme contributeur principal.

Le tool apparait deja dans la liste des capacites deferrees de cette session Claude Code (a cote de CronCreate, TaskOutput, RemoteTrigger, etc), ce qui confirme qu'il est en production.

Analyse critique¶

Le vrai probleme qu'il resout¶

Le polling est le mode degrade historique des agents LLM. Avant Monitor, pour attendre un evenement (pipeline GitLab termine, fichier log modifie, PR mergee), l'agent devait :

1. Faire un Bash call qui interroge l'etat
2. Analyser la reponse
3. Decider s'il faut attendre
4. Attendre X secondes (avec Bash sleep, bloquant)
5. Recommencer

Chaque cycle mange du contexte (output Bash garde en historique), du temps mur (l'agent tourne meme pour rien), et des tokens facturables. Sur une surveillance de pipeline de 30 minutes avec un poll toutes les 20 secondes, on arrive a 90+ cycles vides qui peuvent couter plusieurs dollars et saturer le contexte.

Monitor inverse le flux : on lance un script qui s'execute en arriere-plan, l'agent rend la main et peut faire autre chose ou s'eteindre, et le script wake l'agent via stdout/stderr quand un evenement match. C'est du event-driven, comme une liste d'abonnes pub/sub.

Comparaison avec ce qu'on fait deja¶

Le gain n'est pas juste cosmetique. Pour un workflow comme le notre qui surveille souvent des pipelines CI/CD et des logs, la difference de cout peut etre de l'ordre de 10x sur une surveillance longue.

Ce qui n'est pas clair¶

• La persistence cross-session. Si Claude Code redemarre (nouveau terminal, nouvelle session), est-ce que les Monitors existants reattachent ? La commentaire @slashmsu dans les replies demande la meme chose : "what's the process overhead per session, and how does it handle agent [restarts]" — pas de reponse publique d'Anthropic.
• La scope. Est-ce que Monitor peut appeler d'autres outils (ecrire un fichier, poster un commentaire Jira) quand il wake, ou est-ce uniquement un signal "hey reveille-toi" vers l'agent principal ?
• La difference avec les Cron tools (CronCreate, CronList, CronDelete) qui sont aussi en deferred dans cette session. Le modele mental n'est pas clair : Cron = tache periodique ; Monitor = tache declenchee par evenement. Mais il y a sans doute chevauchement.

Reception¶

Les replies sont majoritairement positives, avec quelques usages immediats evoques : monitoring de paiements Web3, surveillance d'APIs, auto-trigger de tests. Le commentaire @deshiou0604 : "agent-defined [schedules] is wild. kinda like self-managed memory for future actions." C'est juste — Monitor + Cron + Memory forment ensemble un pattern "l'agent gere ses propres processus asynchrones", ce qui est un saut qualitatif.

Pertinence ProbatioVault¶

Impact fort — directement applicable a au moins 3 items de notre TODO et a plusieurs scripts existants.

Ou on peut piquer ca tout de suite¶

1. TODO forge (correction pipeline GitLab). Notre skill /forge surveille un pipeline GitLab apres push et itere sur les erreurs jusqu'a pipeline vert. Aujourd'hui, il poll via curl /pipelines/{id} en boucle. Avec Monitor, on lance un script qui poll l'API GitLab en background et wake l'agent uniquement quand l'etat change. Economie : potentiellement tout le temps de polling = des $ par story.

2. TODO #70 /schedule surveillance pipelines 24/7. Aujourd'hui pense comme un job cron cloud. Monitor peut faire partie de la solution : pour chaque push sur un repo tracke, un Monitor qui watch le pipeline et alerte si failed. Combinaison Cron (daily scan) + Monitor (event-driven) plutot que l'un ou l'autre.

3. gov-lord orchestration multi-stories. Les Ringbearers (sessions /gov) tournent en parallele sur cmux. Aujourd'hui, le Lord poll via lord_term_capture_last pour detecter les events. Monitor permettrait d'etre reactif sur log pattern ("Gate 8 GO", "blocage", "error") sans boucler.

4. TODO #27 REX injection terminal.log. Au lieu d'extraire les erreurs/warnings/retries du terminal.log en post-processing step 9, on peut installer un Monitor qui les capture en temps reel et les injecte dans une memoire de session. Reduit la latence de detection des erreurs LLM invisibles.

Ce qui bloque¶

Monitor est un tool natif Claude Code. Notre workflow passe beaucoup par subprocess claude -p qui n'a probablement pas (encore) acces aux memes tools que l'agent principal. A verifier : est-ce que les subprocess spawnes par nos scripts shell peuvent creer des Monitors ? Si non, l'usage est limite aux commandes tapees directement dans la session principale — ce qui reste utile mais ne change pas les scripts automatises.

Action recommandee¶

Tester Monitor ce soir ou demain sur un cas concret :

Micro-POC Monitor. Sur le prochain lancement pipeline GitLab (forge ou push manuel), utiliser Monitor pour watcher l'etat au lieu d'un Bash poll. Comparer : duree, nombre de tokens consommes, fiabilite de detection. Si ca marche, integrer dans /forge comme default sur la prochaine version.

C'est le test le plus petit possible, reversible, et directement actionnable. Le resultat determine si Monitor s'integre immediatement a notre boite a outils ou attend une maturation. A ajouter dans le TODO.md sous "Outils Claude Code — watchlist adoption".