Das Deploy-Skript ist durchgelaufen, aber weggehen kannst du trotzdem nicht — wird die CI rot? Staut sich die Queue? Wann ist der Dienst wirklich live? Also aktualisierst du alle fünf Minuten brav die Seite, wie ein pflichtbewusster Wachposten.

Hermes’ neuester Befehl /loop nimmt dir genau diese Wachschicht ab: Ein Prompt wird in deiner Session in regelmäßigem Rhythmus erneut ausgeführt — bei jedem Tick wacht der Agent auf und arbeitet gegen den aktuellen Stand. Es ist Hermes’ Variante von Claude Codes /loop (der Alias /proactive funktioniert hier ebenfalls), gerade erst in main gemerged. Dieser Beitrag erklärt es richtig: Was es fundamental von /goal und cron unterscheidet — und wie man es tatsächlich benutzt.

Drei Befehle, drei Antriebe

Befehl	Antrieb	Lebenszyklus	Typischer Einsatz
/goal	Judge-driven — nach jedem Turn prüft ein Judge-Modell „ist es schon fertig?“, und Hermes arbeitet weiter, solange nicht	Einzelne Session, über mehrere Turns hinweg	„Alle Lint-Fehler in src/ beheben und prüfen, dass der Check durchläuft“
/loop	Timer-driven — im Rhythmus aufwachen, die Arbeit erledigen, bis etwas Stopp sagt	Einzelne Session, über Turns und über Resumes hinweg	„Alle 5 Minuten den Deploy prüfen und Bescheid sagen, sobald er live ist“
cron	Schedule-driven — fester Zeitplan, keine Session beteiligt	Außerhalb aller Sessions, unbeaufsichtigt	„Täglich um 9 Uhr einen Digest in den Kanal posten“

/goal bedeutet „arbeite weiter, bis das Ziel erreicht ist“, /loop bedeutet „prüfe weiter, bis etwas Stopp sagt“, cron bedeutet „läuft nach Zeitplan, unabhängig vom Gespräch“. Drei Werkzeuge, die sich nicht überschneiden.

Zwei Rhythmus-Modi: du stellst die Uhr, oder es nimmt sich selbst das Tempo

Festes Intervall — deine Uhr

/loop 5m check the deploy status and tell me if it's live yet

Alle 5 Minuten (solange die Session untätig ist) injiziert Hermes einen echten Agent-Turn gegen den aktuellen Stand — das neueste CI-Ergebnis, die aktuelle Queue-Tiefe, die Datei so, wie sie gerade ist.

Self-paced — es wird schlauer, je länger es wartet

Lässt du das Intervall weg, nimmt sich Hermes selbst das Tempo:

/loop keep an eye on the migration and summarize progress

Der Mechanismus ist raffiniert: Er startet beim 60-Sekunden-Minimum, und solange sich die Antworten des Agents nicht mehr ändern, fährt er exponentiell zurück (2m → 4m → 8m … bis zur 15-Minuten-Obergrenze). In dem Moment, in dem sich eine Antwort unterscheidet, springt der Rhythmus zurück aufs Minimum. Die Änderungserkennung ist ein lokaler, timestamp-unabhängiger Digest-Vergleich — null zusätzliche LLM-Kosten. Je ruhiger es zugeht, desto seltener meldet er sich; sobald es Fortschritt gibt, rückt er näher ran.

Faustregel: Festes Intervall, wenn eine externe Uhr die Arbeit bestimmt; self-paced, wenn die Arbeit selbst den Rhythmus vorgibt.

Stopp-Bedingungen: fünf Ausgänge

Bedingung	Wie
Der Agent entscheidet, dass es fertig ist	Wakeup-Antworten enden mit LOOP_COMPLETE in einer eigenen Zeile
Ein Ausführungslimit	--times N (z. B. --times 30)
Eine evidenzbasierte Bedingung	--until <Bedingung> — bewertet von demselben Aux-Judge, der auch /goal antreibt (fail-open: ein defekter Judge blockiert den Loop nie)
Du	/loop stop (oder /loop pause, um ihn zu behalten)
Das Sicherheitsbudget	loops.max_ticks (Standard 100; 0 = unbegrenzt), damit eine unbeaufsichtigte Session nicht endlos Tokens verbrennt

/loop 2m poll CI --times 30
/loop 5m watch the queue --until "queue depth reaches zero"

Steuerung und Kombination

• /loop status zeigt Rhythmus, bereits ausgelöste Ticks und die Zeit bis zum nächsten Wakeup; /loop pause / resume / stop decken den gesamten Lebenszyklus ab (Ctrl+C während eines Wakeups pausiert den Loop, per /loop resume wiederherstellbar).
• Genauso leicht lässt sich ein Slash-Befehl loopen: /loop 10m /recap.
• Zusammenarbeit mit /goal: Ein aktives, nicht geparktes Goal besitzt die Idle-Grenze — Loop-Ticks warten, bis das Goal fertig ist, pausiert oder geparkt wird (eine wait barrier). Ein geparktes Goal plus ein Loop-Heartbeat ergänzen sich natürlich. Echte Benutzereingaben haben immer Vorrang vor beiden — in dem Moment, in dem du tippst, machen beide Platz.

Warum es nicht kippt: die Architektur

Das ist der Teil, den man wirklich verstehen sollte — /loop ist keine while true-Schleife:

1. Gewöhnliche user-role turn injection: Jeder Wakeup ist eine normale Nachricht in der User-Rolle. Keine Mutation des System-Prompts, kein Toolset-Wechsel, der prompt cache bleibt intakt — Loopen zerstört weder deinen Cache noch verschwendet es Tokens.
2. Persistierter Zustand: Der Loop-Zustand liegt in SessionDB.state_meta unter loop:<session_id>, sodass /resume den Loop zurückholt; er übersteht auch die Komprimierung des Kontexts (derselbe Mechanismus wie bei /goal, mit dem bekannten Risiko, das bereits vorbeugend behoben wurde).
3. Jede Oberfläche: CLI, TUI, dashboard, Desktop-App und alle gateway-Messaging-Plattformen — ein überwachter loop_wakeup_watcher scannt persistierte Loops und injiziert fällige Wakeups in untätige Chats, selbst während du weg bist. Das kann Claude Code nicht (dessen Loop stirbt mit der CLI-Session).
4. Der Slack-Ausflug: Slack hat ein Limit von 50 Slash-Befehlen; Hermes hat deshalb /version zu /hermes version verschoben, um einen nativen Platz für /loop freizumachen.

Im Vergleich mit Claude Codes /loop

	Claude Code	Hermes
Oberflächen	Nur CLI-Session	CLI, TUI, dashboard, Desktop, alle Messaging-Plattformen
Persistenz	Stirbt mit der Session	Übersteht /resume und Kontext-Kompression
Self-paced-Tempo	Vom Modell entschieden	Lokaler Digest-Backoff (kostenlos, deterministisch)
Stopp-Bedingungen	Im Prompt eingebettet	LOOP_COMPLETE + --times + bewertetes --until + Budget-Backstop
Zusammenspiel mit /goal	Getrennte Features	Explizite Rangfolge: aktives Goal besitzt die Idle-Grenze

Welches will ich?

• Externen Zustand beobachten (Deploy, CI, Queue, Fehlerraten) → /loop (fest oder self-paced)
• Ein Ziel richtig umsetzen (alle Lints beheben, CI grün bekommen) → /goal (siehe Heartbeats, Refinement & Goal Gates)
• Unbeaufsichtigte Zeitplan-Jobs (tägliche Digests, Nachtläufe) → cron (komplette Anleitung: The Hermes Cron Automation Guide)

Release-Status und wie man es bekommt

/loop wurde am 14. August 2026 in main gemerged (PR #72333, mit 77 neuen Tests + 367 Regressionstests + 22 Desktop-Tests, alle grün). Es ist noch in keinem offiziellen Release (das neueste ist weiterhin v0.20.1). So probierst du es aus:

• Warte auf das nächste Release und führe hermes update aus;
• Oder installiere jetzt direkt von main: hermes update --branch main (sobald das Release da ist, wieder zurückwechseln).

Optionale Konfigurationsschlüssel: loops.min_interval_seconds, loops.max_ticks, loops.self_paced_floor_seconds, loops.self_paced_ceiling_seconds.

Fazit

/loop nimmt dir das „Beobachten“ aus der Hand des manuellen Aktualisierens: feste Intervalle für externe Uhren, ein self-paced-Rhythmus, der umso schlauer wird, je länger er wartet (zurückfahren bei Stabilität, näher ranrücken bei Veränderung — zu null LLM-Kosten), Persistenz und Plattform-Abdeckung, die das Claude-Code-Original übertreffen, und explizite Zusammenarbeit mit /goal. Beim nächsten Deploy übergibst du die Wachschicht einfach ihm.