Du hast einen Loop eingerichtet, der alle drei Minuten einen Deploy beobachtet, und dich dann wieder an die Arbeit gemacht. Zehn Minuten später wirfst du einen Blick ins Terminal, und dort steht immer noch dasselbe wie beim Start — next in 3m — also stellst du dir die Frage, die sich irgendwann jeder Loop-Nutzer stellt: Lebt das Ding noch, oder hat es still aufgehört? Genau diese Unklarheit wollte ein am 15. Oktober gemergter PR beseitigen, und zwar auf allen drei Oberflächen gleichzeitig.

Was ein laufender Loop ist, in einem Absatz

/loop führt einen Prompt innerhalb deiner aktuellen Session erneut aus — in einem Takt, den du wählst, oder in einem, den er selbst bestimmt:

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

Jedes Aufwachen ist ein normaler Agent-Turn und liest deshalb den aktuellen Zustand — das neueste CI-Ergebnis, die Queue-Tiefe, die Datei so, wie sie jetzt ist — statt eine Zusammenfassung wiederzugeben. Er läuft auf der CLI, der TUI, im Dashboard-Chat, in der Desktop-App und auf jeder Gateway-Plattform, und er lebt in dieser Session: Abbruchbedingungen sind LOOP_COMPLETE vom Agenten, --times N, --until <condition>, loops.max_ticks als Notfall-Budget (standardmäßig 100) — oder du selbst, mit /loop stop und /loop pause.

Das Problem: ein Countdown, der einmal gezeichnet wurde

Das alte Verhalten war eine einzelne Zeile im Transcript — ↻ Loop: next in 3m. —, die ausgegeben wurde, als der Loop akzeptiert wurde. Sie bewegte sich nie. In der Desktop-App war es auf subtilere Weise schlimmer: Das next ~45m der Loop-Karte wurde einmal pro Render berechnet, die Zahl war also auf dem Wert eingefroren, den sie zufällig beim ersten Zeichnen der Karte hatte. Die Information, die du brauchtest (wie lange bis zum nächsten Aufwachen, läuft es gerade, ist es pausiert), existierte in der Session — aber nichts zeichnete sie neu.

Was die drei Oberflächen jetzt zeigen

CLI. Das Live-Work-Dock — das Panel, das bereits Goals, Subagenten, Prozesse und die Queue verfolgt — bekommt eine Loop-Zeile:

↻ loop · every 3m · 1 run · next in 2m · <prompt>

Der Countdown läuft im Minutentakt und wechselt in der letzten Minute auf Sekunden, ein untätiger Prompt wird also höchstens einmal pro Minute neu gezeichnet statt einmal pro Sekunde. Während eines Aufwachens steht dort running now, und wenn der Loop pausiert ist, wird der Pausengrund angezeigt. Klappt man das Dock ein, trägt die Überschrift ein kompaktes Badge — ↻ loop next in 2m —, du bekommst die Antwort also auch, ohne etwas aufzuklappen. Ist das Dock sichtbar, entfällt die alte statische Transcript-Zeile ↻ Loop: next in 3m., denn beides zu behalten wäre nur doppeltes Rauschen.

TUI. hermes --tui bekommt eine LoopBar unterhalb der GoalBar, mit demselben Text, gespeist vom Session-Snapshot und einer Sekundenuhr, die nur neu zeichnet, wenn sich das Label tatsächlich ändert.

Desktop. Die Loop-Karte teilt sich jetzt die Sekunden-Countdown-Uhr des Heartbeats — next 00:02:09 —, und sobald der Termin verstrichen ist, steht dort due — waiting for idle statt einer Zahl, die ins Negative gelaufen ist. Dieser letzte String wird mit der Heartbeat-Karte geteilt, weshalb er auf einen gemeinsamen Key umbenannt wurde, statt dupliziert zu werden.

Der Teil, der dir nicht auffallen würde: das Gateway musste es veröffentlichen

Ein Countdown auf der CLI ist unkompliziert — dieser Prozess besitzt sein Terminal. Die Ink-Bars in der TUI und die Karte in der Desktop-App sind anders: Sie lesen einen Session-Snapshot, den das Gateway als session.control.update veröffentlicht. Und dieses Update wurde nur dann veröffentlicht, wenn jemand auf einer Desktop-Karte einen Button anklickte. Tippst du /loop 3m … in einen Chat, erreichte der Zustand nie die Oberflächen, die ihn hätten rendern sollen.

Der Fix verlagert die Veröffentlichung an die Stellen, an denen sich der Loop-Zustand tatsächlich ändert: Der Owner veröffentlicht nach einem Automation-Slash-Command, nach den Post-Turn-Goal- und Loop-Hooks einer lokalen Session und nachdem ein Loop-Aufwachen ausgelöst oder ein Slash-Tick abgeschlossen wurde. Der Legacy-Pfad tui_gateway bekommt dieselben zwei Veröffentlichungen, damit auch ältere Clients die Aufwachvorgänge sehen.

Das ist die interessante Lektion dieses PRs: Eine Anzeige für einen Live-Wert hinzuzufügen ist selten nur eine Anzeigeänderung. Wird der Wert von jemand anderem veröffentlicht, gehört es zum Fix dazu, diesen jemand davon zu überzeugen, zu den richtigen Momenten zu veröffentlichen — sonst lieferst du einen Fortschrittsbalken, der nur beim ersten Frame ehrlich ist.

Woran du erkennst, ob du es schon hast

Die Änderung wurde am 15. Oktober um 15:34 UTC gemergt, und v0.22.2 war bereits am Morgen desselben Tages veröffentlicht worden, das hier ist also vorerst nur auf main — Arbeit, die nur auf main liegt, kommt mit v0.23.0. Der praktische Check:

hermes version

Wenn du auf einem Release-Build bist, zeigt das Dock weiterhin die alte statische Zeile. Brauchst du die Loop-Sichtbarkeit heute und kannst main nicht laufen lassen, ist der brauchbare Ersatz /loop status: Es meldet Takt, ausgelöste Ticks und die Zeit bis zum nächsten Aufwachen auf Abruf — ein Tastendruck statt eines flüchtigen Blicks, aber es beantwortet immerhin die Frage, ob noch etwas läuft.

Zwei verwandte Details solltest du kennen, bevor du dich auf einen Countdown verlässt: Ein Aufwachen ist ein normaler Turn in der User-Rolle, und die Token-Kosten skalieren mit dem Takt — ein Ein-Minuten-Loop, der nichts zu tun hat, kostet also trotzdem einen Turn pro Minute. Bevorzuge Self-Pacing, wenn du auf etwas wartest, das sich nach seinem eigenen Zeitplan ändert. Und für Arbeit, die das Schließen deines Terminals überleben muss, ist das hier das falsche Werkzeug: Ein unbeaufsichtigter Zeitplan gehört in einen Cron-Job, während /loop für die Überwachung innerhalb einer Session gedacht ist, in der du ohnehin schon bist.

Ebenfalls gut zu wissen

• loops.min_interval_seconds (30), loops.self_paced_floor_seconds (60) und loops.self_paced_ceiling_seconds (900) sind die Stellschrauben hinter dem Takt; loops.max_ticks (100, 0 für unbegrenzt) ist der Notausgang.
• Ein aktives /goal besitzt die Session: Während ein Goal von seinem Judge vorangetrieben wird, werden Loop-Aufwachen zurückgestellt und erst wieder aufgenommen, wenn das Goal fertig wird, pausiert oder an einer Wait-Barrier parkt.
• Ein Loop pro Session — ein neues /loop ersetzt das alte; mehrere Loops bedeuten mehrere Sessions (oder Cron).
• In Desktop und Dashboard ist eine Session mit aktivem Loop vom Reaper für getrennte Sessions ausgenommen, die Aufwachen feuern also weiter, nachdem du das Fenster geschlossen hast — solange der Backend-Prozess selbst noch läuft.
• Strg+C während eines Aufwach-Turns pausiert den Loop, statt ihn zu zerstören; /loop resume nimmt ihn wieder auf.

Wenn /loop selbst neu für dich ist: Der Leitfaden zum Loop-Befehl behandelt die Grundlagen, auf denen dieser Countdown aufsetzt.

---

Quellen: PR #139187 (/loop shows a live countdown to the next wakeup on CLI, TUI and Desktop, gemergt am 15. Oktober 2026) und dessen Validierungstabelle; website/docs/user-guide/features/loops.md auf main für die Befehle, Takt-Modi, Konfigurations-Keys und den Vergleich /loop vs. /goal vs. Cron.