Das Claude Code Monitor-Tool

Problem: Bis diesen Monat war alles, was im Hintergrund lief, für Claude Code undurchsichtig. Ein mit run_in_background gestarteter Befehl lieferte genau einen Ping am Ende. Nichts zwischendurch. Der Workaround war /loop oder ein geplanter Task, was bedeutete, alle paar Minuten einen neuen Prompt abzuschicken und dafür einen vollständigen API-Call zu bezahlen, nur um zu fragen, ob sich irgendwas bewegt hat.

Schnelle Lösung: Zeig Claude auf deinen Dev-Server und lass ihn lauschen. Ein Satz reicht:

Start my dev server and monitor it for errors

Claude startet den Server, umschließt dessen Output mit einem Hintergrunds-Watcher, und bleibt still, bis wirklich etwas kaputt geht. Keine verbrannten Tokens, solange nichts passiert.

Was sich geändert hat

Anthropic hat das Monitor-Tool am 9. April 2026 veröffentlicht. Claude Code PM Noah Zweben kündigte es so an: "Claude can now follow logs for errors, poll PRs via script, and more. Big token saver and great way to move away from polling in the agent loop."

Der grundlegende Wechsel ist vom Zeittakt-Trigger zum Ereignis-Trigger. Das alte Modell ließ Claude den Zustand auf Timer-Basis prüfen. Das neue Modell lässt Claude mit dem Output sitzen und reagiert, wenn etwas auftaucht. Stell dir den gleichen Sprung vor, den du machst, wenn du aufhörst, eine Datenbank alle paar Sekunden abzufragen, und stattdessen ihren Change-Stream abonnierst. Das Timer-Modell verbrennt Rechenleistung für nichts. Das Stream-Modell reagiert in dem Moment, in dem eine Änderung eintrifft.

Mechanisch ist das Tool einfach. Claude führt einen Shell-Befehl aus und behandelt dessen stdout als Ereignisstrom. Jede Zeile weckt die Hauptsession. Ein stiller Befehl kostet nichts. Sobald dein Filter eine Zeile trifft, landet diese Zeile in der Konversation und Claude fängt an, daran zu arbeiten. Der zugrundeliegende Prozess läuft parallel weiter.

So funktioniert es

Jeder Monitor hat vier Parameter:

command ist, wo die Logik sitzt. Eine Zeile stdout gleich eine Benachrichtigung. Kommen mehrere Zeilen innerhalb eines 200-Millisekunden-Fensters rein, werden sie zu einem einzigen Alert gebündelt, sodass der mehrzeilige Output eines echten Ereignisses noch als ein Ding lesbar ist. Stderr wird in eine Datei umgeleitet, die du später lesen kannst, und weckt Claude nicht.

Greif auf persistent: true zurück, wenn der Monitor so lange leben soll wie deine Session. Dev-Server-Watcher, Log-Tailer, PR-Monitore. Für alles Begrenzte, wie ein einzelnes Deployment oder einen Testlauf, übergib timeout_ms, und der Monitor stirbt, wenn das Fenster schließt.

Zwei Monitor-Formen

Stream-Filter beobachten kontinuierlichen Output und zeigen passende Zeilen:

# Watch application logs for errors
tail -f /var/log/app.log | grep --line-buffered "ERROR"
 
# Watch file system changes
inotifywait -m --format '%e %f' /watched/dir
 
# Node script that emits events from a WebSocket
node watch-for-events.js

Poll-and-if-Filter prüfen eine Quelle in einem Intervall und geben aus, wenn sich Bedingungen ändern:

# Poll GitHub PR for new comments every 30 seconds
last=$(date -u +%Y-%m-%dT%H:%M:%SZ)
while true; do
  now=$(date -u +%Y-%m-%dT%H:%M:%SZ)
  gh api "repos/owner/repo/issues/123/comments?since=$last" \
    --jq '.[] | "\(.user.login): \(.body)"'
  last=$now; sleep 30
done

Beide Formen folgen demselben Vertrag. Stdout ist ein Ereignisstrom. Stille bedeutet nichts zu berichten. Claude arbeitet weiter an dem, wofür du es als Nächstes gefragt hast, während der Monitor im Hintergrund tickt.

Die Token-Rechnung

Stell dir vor, /loop prüft eine Test-Suite alle 2 Minuten während einer 10-minütigen Ausführung. Das ergibt 5 vollständige API-Calls. Kontext-Reload, Prompt-Verarbeitung, Antwortgenerierung, jedes Mal. Du zahlst für 5 Roundtrips, und 4 davon liefern nichts Nützliches.

Ein Monitor dreht diese Gleichung um. Claude verfolgt den gefilterten Output des Test-Runners. Wenn Test #23 in Minute 4 fehlschlägt, kommt die Fehlerzeile sofort in der Session an. Claude kann anfangen, den Fix zu erarbeiten, während Tests 24 bis 47 noch laufen. Nichts verschwendet. Nichts verzögert. Je länger der Workflow, desto größer die Ersparnis. Alles Langläufige gewinnt hier, einschließlich CI-Runs, die Stunden dauern, Deployment-Jobs und nächtliche Builds.

Praktische Anwendungsfälle

Dev-Server-Fehler abfangen. Beobachte einen Next.js- oder Vite-Dev-Server und bekomm einen Ping in dem Moment, in dem ein Build-Fehler oder eine Crash-Schleife auftritt. Das Durchsuchen von altem Terminal-Output nach dem Breakpoint fällt weg.

Test-Suite-Triage. Ein fehlgeschlagener Test taucht in dem Moment auf, in dem er fehlschlägt. Claude kann einen Fix öffnen, während der Rest der Suite noch läuft.

Deploy-Pipeline beobachten. Häng einen Filter an deinen CI/CD-Stream und wecke Claude bei Fehlern, Warnungen oder wenn eine bestimmte Deployment-Phase abgeschlossen ist.

PR-Review-Polling. Sitz auf einem GitHub-Pull-Request und reagiere auf neue Kommentare, Review-Anfragen oder Status-Checks, sobald sie ankommen. Jeder neue Kommentar wird sofort etwas, womit Claude arbeiten kann.

Log-Monitoring. Richte einen Filter auf deine Produktions- oder Staging-Logs. Wann immer eine Zeile das Muster trifft, landet sie als Ereignis in der Session und Claude kann sofort reagieren.

Drei Regeln für gute Monitore

1. Leite niemals durch grep ohne --line-buffered. Ohne dieses Flag kann Pipe-Buffering Ereignisse minutenlang zurückhalten. Das ist bei weitem der häufigste Stolperstein.

2. Schluck transiente Fehler innerhalb von Poll-Loops. Häng || true an jeden API-Call, damit ein schlechter Netzwerk-Roundtrip nicht den ganzen Monitor mitreißt.

3. Halte stdout kompakt. Jede Zeile, die du ausgibst, wird zu einer Nachricht in der Konversation. Ein Watcher, der zu viele Ereignisse ausgibt, wird von Claude Code automatisch gestoppt. Filtere rohe Logs immer, bevor du sie reinpipest. Dump niemals einen vollen Stream ungefiltert.

# Good: selective filter
tail -f app.log | grep --line-buffered "ERROR\|WARN\|FATAL"
 
# Bad: firehose that will auto-stop
tail -f app.log

Poll-Intervalle spielen auch eine Rolle. 30 Sekunden oder mehr für alles Remote, weil Rate-Limits gelten. 0,5 bis 1 Sekunde funktioniert gut für lokale Checks.

Monitor vs. Hooks vs. Geplante Tasks

In Claude Code gibt es jetzt drei Automatisierungsschichten, und jede lauscht auf einen anderen Trigger-Typ.

Hooks wachen bei Claudes eigenen Aktionen auf, wie einem Datei-Edit oder einem Commit. Geplante Tasks wachen zur Uhrzeit auf. Monitor wacht auf die Außenwelt auf. Die stärksten Setups schichten alle drei. Guardrails sitzen auf Hooks, periodische Wartung auf geplanten Tasks, und Live-Beobachtung von allem anderen auf Monitor.

Monitor vs. run_in_background

Die werden oft verwechselt. Beide lassen Dinge im Hintergrund laufen. Der Unterschied ist das Feedback-Modell.

run_in_background ist Fire-and-Forget. Du bekommst genau eine Benachrichtigung, wenn der Befehl beendet ist. Nichts dazwischen. Gut für "Starte diesen Build und sag mir, wenn er fertig ist."

Ein Monitor ist stattdessen ein Live-Stream. Eine Benachrichtigung feuert für jedes passende Ereignis unterwegs. Gut für "Starte diesen Build und sag mir, sobald etwas schiefläuft." Claude bleibt reaktiv, während der Prozess noch läuft, nicht erst nachdem er beendet ist.

Nächste Schritte

• Lerne, wie Hooks Monitore ergänzen, indem sie Claudes eigene Aktionen validieren
• Erkunde autonome Agenten-Loops, bei denen Monitore das Feedback-Signal liefern
• Lies über Kontext-Management, um lange überwachte Sessions effizient zu halten
• Sieh dir geplante Tasks für zeitbasierte Automatisierung an, die mit ereignisgesteuertem Monitoring kombiniert werden kann
• Probiere Feedback-Loops aus, um den Zyklus zwischen Code schreiben und Fehler finden zu straffen

Das Monitor-Tool sitzt im fehlenden Slot zwischen "Claude führt Dinge aus" und "Claude beobachtet Dinge". Hintergrundarbeit war früher eine versiegelte Box, die sich erst ganz am Ende öffnete. Heute sitzt Claude neben dem Prozess, reagiert auf alles, was Aufmerksamkeit verdient, und lässt alles andere in Ruhe. Pair-Programming von einer wirklich anderen Art.