Ich sage dir genau, wann mir klar wurde, dass sich etwas fundamental ändert. Boris Cherny, der Schöpfer von Claude Code bei Anthropic, hat in einem Podcast-Interview im Februar 2026 einen Satz gesagt, der mich nicht mehr losgelassen hat: „I’m not prompting Claude anymore. I’m building loops.“
Ich hab das damals als Developer-Sprech abgetan. Ich bin kein Entwickler. Ich bin KI-Berater, ich schreibe Texte, ich baue Workflows für EPU und KMU, ich betreibe Home Assistant, ein selbst gehostetes n8n auf Hetzner, ein Strom-Dashboard. Was soll mir ein „Loop“ bringen?
Vier Monate später weiß ich, was gemeint war. Und ich will es dir erklären, Schritt für Schritt, mit Beispielen aus meinem echten Setup.
Claude Code
/loopist das erste native Werkzeug, das KI vom reaktiven Antwortgeber zum proaktiven Beobachter macht. Kein manueller Prompt mehr nötig: Der Agent läuft, schaut hin und handelt, solange du schläfst.
Was ist /loop eigentlich?
Claude Code hat sich in den letzten Monaten rasant entwickelt. Neben /loop gibt es auch /goal und /batch als verwandte Kommandos. Aber fangen wir beim Einfachsten an.
/loop ist seit März 2026 in Claude Code verfügbar, ursprünglich gebaut fürs Polling: einen Deployment-Status alle fünf Minuten checken, einen Pull Request beobachten. Es läuft auf einem definierten Zeitintervall. Lässt du das Intervall weg, wird es selbstgesteuert: Claude arbeitet, prüft seine eigene Stopp-Bedingung, macht weiter oder hört auf.
Die Syntax ist bewusst simpel gehalten:
/loop [Intervall] [Aufgabe]Claude parst das Intervall, konvertiert es in einen cron-Ausdruck und feuert den Prompt wiederholt ab, solange die Session offen ist. Der Standard-Intervall ist 10 Minuten. Natürliche Sprache funktioniert auch: /loop check the build every 2 hours.
Das ist kein Cron-Job. Das ist ein wichtiger Unterschied, und er rechtfertigt die Aufregung rund ums Thema. Ein Cron-Job führt ein fixes Script aus. Ein Agent-Loop führt ein Modell aus, das den aktuellen Zustand liest und selbst entscheidet, was als nächstes zu tun ist. Das klingt nach einem kleinen Unterschied. Es ist keiner.
/loop vs. /goal: Was wann verwenden?
Bevor wir zu den Beispielen kommen, eine Unterscheidung, die ich wichtig finde, weil sie in den meisten Artikeln zu kurz kommt.
Bei /loop (selbstgesteuert) prüft Claude sein eigenes Werk inline in jedem Durchgang. Bei /goal liest ein separates, kleineres Modell das Transcript unabhängig und entscheidet. Beide sind Loops, der Unterschied liegt nur beim Richter.
Vereinfacht:
/loop: Wiederhole eine Aufgabe auf einem Zeitplan. Ideal für Monitoring, Polling, Beobachtungsaufgaben. „Schau alle X Minuten nach.“/goal: Arbeite bis eine Bedingung erfüllt ist, dann stopp. Ideal für Coding-Tasks, bei denen Tests grün sein müssen. „Mach weiter, bis es passt.“/batch: Verteile eine große Aufgabe auf parallele Agenten. Ideal für massenweise Dateiänderungen.
Die Faustregel: /goal für „bleib dran bis es korrekt ist“, /loop für „check das regelmäßig“, /batch für eine große mechanische Änderung über viele Dateien.
Die technischen Grenzen kennen
Tasks enden, wenn du das Terminal schließt. Keine Persistenz über Restarts hinaus. Auto-Expire nach 7 Tagen. Maximum 50 Tasks pro Session.
Das sind keine Bugs, das ist Design. Für dauerhafte, persistente Automatisierungen gibt es die Scheduled Tasks in Claude Code Desktop, die über Restarts hinaus laufen. /loop ist für Sessions-gebundenes Monitoring gedacht, also für die Zeit, in der du aktiv arbeitest oder den Rechner laufen lässt.
Token-Kosten in autonomen Agent-Loops summieren sich schneller als fast jeder erwartet. Das ist ein ehrlicher Hinweis: Ohne klares Stopp-Kriterium und ohne Budgetkontrolle kann ein falsch konfigurierter Loop teuer werden. Ich empfehle, für jeden Loop von Anfang an zu definieren, was „fertig“ oder „normal“ bedeutet, und was eine Reaktion auslösen soll.
Drei Beispiele aus meinem echten Setup
Hier wird es konkret. Alle drei Beispiele passen zu meiner tatsächlichen Infrastruktur, und das ist der Punkt: /loop funktioniert am besten, wenn es mit dem zusammenwächst, was du schon betreibst.
Beispiel 1: Home Assistant Tagescheck via Notion
Ich betreibe Home Assistant über einem Jahr, und es ist nicht klein. Eufy-Kameras, Eve- und Matter-Geräte, Sonoff-Zigbee-Sensoren, Philips Hue, Liebherr-Kühlschrankintegration, ein Balkonkraftwerk mit Hoymiles-Wechselrichter (kommt diese Woche und ich bin bereits vorbereitet), dazu das komplette Energie-Monitoring mit meinem eigenen PHP-Scraper für die Smartmeter-Daten. KI und Home Assistant wachsen gerade zusammen, nicht als Marketing-Versprechen, sondern als funktionierendes Werkzeug in der Hand von Leuten, die tatsächlich beides betreiben.
Das Problem: Ich prüfe meinen Home Assistant zu selten systematisch. Updates schlummern wochenlang, kleine Fehlermeldungen im Log häufen sich, und gelegentlich merke ich erst Tage später, dass eine Automation still gescheitert ist.
Die Lösung mit /loop:
/loop 24h
Verbinde dich mit meiner Home Assistant Instanz über die REST API.
Prüfe folgendes und erstelle einen strukturierten Bericht:
1. UPDATES: Welche Add-ons, Integrationen oder die HA-Core-Version
selbst haben verfügbare Updates?
2. FEHLER: Lies die letzten 200 Zeilen des Home Assistant Logs und
kategorisiere alle WARNING und ERROR Einträge.
Ignoriere bekannte Standardmeldungen (Recorder, etc.).
3. AUTOMATIONEN: Welche Automationen haben in den letzten 24 Stunden
keinen einzigen Trigger erzeugt, obwohl sie das normalerweise sollten?
4. GERÄTE: Welche Entities sind 'unavailable' oder 'unknown',
die es gestern nicht waren?
5. ENERGIE: Wie war der gestrige Verbrauch im Vergleich
zum 7-Tage-Durchschnitt? Auffälligkeiten?
Erstelle danach einen Notion-Eintrag in der Seite 'Home Assistant'
mit Titel 'HA Check [Datum] [Uhrzeit]', Status-Bewertung
(OK / WARNUNG / KRITISCH) und allen gefundenen Punkten gegliedert
nach den 5 Kategorien oben.Was dabei herauskommt, ist kein generischer Statusbericht. Es ist eine tatsächlich lesbare Zusammenfassung mit Datum, Zeitstempel und konkreten Handlungsempfehlungen, direkt in meiner Notion-Seite, jeden Tag, ohne dass ich daran denken muss.
Die Verbindung zu Home Assistant funktioniert über die REST API, für die ich Claude Cowork bereits in einem früheren Artikel mit einem Long-Life-Token ausgestattet habe. Notion ist über den nativen Connector in Claude Code eingebunden.
Ein wichtiger Sicherheitshinweis, den ich bei jedem HA-Projekt anspreche: Der Long-Life-Token hat die Rechte des Nutzers, unter dem er erstellt wurde. Ich verwende dafür einen HA-Benutzer mit eingeschränkten Leserechten, keinen Admin-Account. Das ist nicht paranoid, das ist normales Sicherheitsdenken.
Beispiel 2: n8n Error-Log-Monitoring mit Mattermost-Eskalation
Auf meinem Hetzner-Server läuft via Coolify ein n8n-Stack, der täglich mehrere Dutzend Workflows ausführt: Morningbriefing, WhatsApp-Automation über Evolution API, KI-Mailklassifizierung, den wöchentlichen KI-Trendsmonitor via SerpAPI. Wenn n8n Fehler produziert, merke ich das meistens erst, wenn irgendwas nicht ankommt. Zu spät.
Mit /loop ändert sich das:
/loop 2h
SSH-Zugriff auf meinen Hetzner-Server.
Lies die letzten 100 Zeilen der n8n Error Logs.
Analysiere die Einträge nach folgendem Schema:
- IGNORIEREN: Normale Timeout-Warnungen bei externen APIs,
Retry-Logs bei transienten Fehlern
- MELDEN: Wiederholte Fehler desselben Typs (3x oder öfter),
Workflow-Abbrüche bei kritischen Workflows
(Mailklassifizierung, Morning Briefing),
Authentication Errors, Database Connection Errors
- SOFORT ESKALIEREN: Stack-Traces, FATAL-Level Logs,
n8n-Prozess-Crashes
Bei MELDEN: Schreibe einen strukturierten Eintrag in error-report.md
mit Zeitstempel, Fehlertyp, betroffener Workflow-ID und
Lösungsvorschlag.
Bei SOFORT ESKALIEREN: Sende zusätzlich eine Mattermost-Nachricht
an #infrastruktur mit dem Fehlertext und dem Kontext.Das Schöne an diesem Setup: Die meisten transienten Fehler (kurze API-Timeouts, einmalige Verbindungsabbrüche) interessieren mich nicht. Claude filtert sie heraus. Nur was systemisch ist oder sich wiederholt, landet auf meinem Radar. Das ist Monitoring, wie es sein sollte.
Wer sich fragt, warum ich das nicht einfach mit n8n selbst automatisiere: Weil n8n keine gute Idee ist, wenn es darum geht, n8n selbst zu überwachen. Der Watchdog sollte außerhalb des Systems stehen, das er beobachtet. Das ist ein Grundprinzip, das ich bereits in meinem Artikel über das 90-Minuten-Watchdog-Projekt beschrieben habe.
Beispiel 3: Strom-Dashboard Wochenanalyse
Ich habe einen PHP-Scraper, der täglich meine Salzburg-AG-Smartmeter-Daten über eine eigene REST API abruft und in Home Assistant einspeist. Das Balkonkraftwerk mit dem Hoymiles-Wechselrichter (im loop schon vorbereitet) liefert dazu die Einspeisung. Das Energy Dashboard in Home Assistant zeigt mir die Zahlen, aber es interpretiert sie nicht.
/loop 7d
Analysiere meinen Stromverbrauch der vergangenen Woche.
Datenquelle: REST API meines Strom-Dashboards.
Hole folgende Werte:
- Tagesverbrauch der letzten 7 Tage (kWh)
- Einspeisung Balkonkraftwerk pro Tag (kWh)
- Nettobelastung (Bezug minus Einspeisung)
Berechne:
- Wochendurchschnitt Verbrauch
- Vergleich mit Vorwoche (falls Daten vorhanden)
- Effizientester Tag (niedrigster Nettogesamtbezug)
- Schlechtester Tag mit möglicher Erklärung
(Wetter? Wochentag? Ungewöhnliche Geräteaktivität?)
Erstelle einen Notion-Eintrag 'Strom KW [Nummer] [Jahr]'
mit einer klaren Tabelle der Tageswerte, einer Zusammenfassung
in 3-4 Sätzen und einer konkreten Empfehlung
(z.B. 'Verbrauch liegt 18% über KW 24, mögliche Ursache:
Hitzewelle, Klimaanlage aktiv').Das ist der Use Case, der mich jeden Morgen am meisten freut, wenn ich ihn mir vorstelle: Statt ins Dashboard zu schauen und Zahlen zu lesen, finde ich in WhatsApp eine fertige Einschätzung, die mir sagt, ob ich letzten Montag wegen der Hitze mehr verbraucht habe als üblich, und ob das Balkonkraftwerk (hoffentlich dann) seinen Job tut.
Was /loop von meinen bisherigen Automatisierungen unterscheidet
Ich automatisiere nicht erst seit heute. Auf meinem Hetzner-Stack läuft n8n mit etlichen Workflows, ich habe eigene WordPress-Plugins gebaut, mein eigenes RAG-System auf Qdrant deployed, VINCI als persönlichen Assistenten entwickelt. Warum ist /loop trotzdem etwas anderes?
Der Unterschied liegt in der Intelligenzschicht. Ein n8n-Workflow mit einem HTTP-Node, der eine URL abruft und den Status-Code prüft, ist deterministisch. Er kann „200 OK“ von „503 Service Unavailable“ unterscheiden. Er kann nicht einschätzen, ob ein Warning-Log im n8n-System ein normales Retry-Artifact ist oder der Beginn eines systematischen Verbindungsproblems.
Claude Code mit /loop kann das. Nicht perfekt, aber gut genug, um den Unterschied zu machen.
Ich würde das so formulieren: n8n ersetzt repetitive manuelle Aufgaben. /loop mit Claude Code ersetzt repetitive manuelle Beurteilungen. Das ist eine andere Liga.
Wie ich /loop in meinen Workflow integriere
Praktisch läuft das so ab:
Schritt 1: Claude Code Desktop öffnen.
Das ist die Voraussetzung. /loop in der CLI-Version stirbt, wenn das Terminal geschlossen wird. Für Session-gebundenes Monitoring reicht das, wenn der Rechner läuft. Für persistente Checks über Restarts hinaus: Scheduled Tasks in der Desktop-Version.
Schritt 2: Kontext setzen.
Bevor ich einen Loop starte, stelle ich sicher, dass Claude den Kontext kennt: welche API-Endpoints, welche Credentials (via MCP-Server oder Environment Variables), was „normal“ ist und was eine Reaktion auslösen soll.
Schritt 3: Den Loop formulieren.
Das ist das eigentliche Handwerk. Ein guter Loop-Prompt hat vier Teile:
- Was soll beobachtet werden?
- Wie soll unterschieden werden (normal vs. auffällig vs. kritisch)?
- Was soll bei welchem Befund getan werden?
- Wohin geht das Ergebnis?
Schritt 4: Erste Iteration manuell prüfen.
Ich lass den Loop einmal laufen und schaue mir das Ergebnis an, bevor ich ihn unbeaufsichtigt lasse. Das spart Fehler und gibt mir Sicherheit, dass die Kategorisierung stimmt.
Schritt 5: Budget im Auge behalten.
Token-Kosten in autonomen Agent-Loops summieren sich schneller als fast jeder erwartet. Ich beobachte die ersten 2-3 Durchläufe, um ein Gefühl für den Token-Verbrauch zu bekommen.
Die ehrliche Einschränkung
Ich wäre kein fairer Beobachter, wenn ich das verschweige: /loop ist kein Selbstläufer. Ein schlecht formulierter Loop-Prompt produziert entweder zu viel Rauschen (alles ist auffällig) oder zu wenig Signal (nichts ist auffällig). Die Qualität des Loops hängt direkt an der Qualität des Prompts (ja, Prompt Engineering ist definitiv nicht tot).
Das ist aber auch das Einzige, was du dazulernen musst. Du brauchst keine Kenntnisse in Programmierung, kein Verständnis von Cron-Syntax, keine Erfahrung mit Deployment-Pipelines. Du brauchst die Fähigkeit, klar zu beschreiben, was du sehen willst und was du tun willst, wenn du es siehst.
Das ist Prompt Engineering im direktesten Sinn: nicht Antworten generieren, sondern Beobachtung gestalten.
Die Frage ist nicht, ob du /loop brauchst. Die Frage ist, wie viele deiner regelmäßigen Checks du noch manuell machst, weil du bisher gedacht hast, es gäbe keine bessere Alternative.
