Claude automatisch nach Zeitplan ausführen lassen

Jeder Chat, den Sie bisher mit einem KI-Assistenten hatten, begann wahrscheinlich gleich: Sie öffneten ein Fenster, tippten etwas ein und warteten. Schließen Sie das Fenster, hört das Gespräch auf zu existieren, bis Sie zurückkommen. Nichts passiert, während Sie weg sind, weil nichts geplant ist, während Ihrer Abwesenheit zu passieren.

Automatisches Laufen dreht das um. Eine Claude-Code-Session startet von selbst, zu einer Zeit oder als Reaktion auf ein Ereignis, das Sie vorab eingerichtet haben, arbeitet einen Prompt ab, den Sie bereits geschrieben haben, und hält an, wenn sie fertig ist oder Sie braucht. Wer die Session startet, ist die eigentliche Trennlinie, nicht wie leistungsfähig das zugrunde liegende Modell im Moment ist, in dem Sie es gerade beobachten.

Diese eine Verschiebung, wer die Session startet, ist auch der Grund, warum der Rest dieses Leitfadens sich auf Claude Code statt auf Claude im Allgemeinen bezieht. Anthropics Claude, die Chat-App für Endnutzer, hat eine eigene, separate Funktion für geplante Aufgaben, etwa für eine tägliche Postfach-Zusammenfassung. Claude Code, das Werkzeug für Entwickler, hat andere Mechanismen, gebaut für das Laufen innerhalb eines Repositorys, eines Terminals oder einer CI-Pipeline, und genau die behandelt der Rest dieses Leitfadens.

Keiner der fünf folgenden Mechanismen verlangt, dass Sie neue Software schreiben. Jeder ist nur eine Art, Claude Code zu sagen, wann es starten und was es dann tun soll, mit Werkzeugen, die es heute bereits gibt.

/loop ist der schnellste Weg, das auszuprobieren. Tippen Sie /loop 5m check the deploy and tell me if it finished, und Claude Code wandelt dieses Intervall in einen Cron-Ausdruck um, plant die Aufgabe innerhalb der aktuellen Session und wiederholt Ihren Prompt alle fünf Minuten, bis Sie ihn stoppen oder sieben Tage vergehen, je nachdem, was zuerst eintritt. Lassen Sie das Intervall weg, wählt Claude stattdessen dynamisch eines, und wartet länger, sobald das Beobachtete ruhig wird.

Der Haken liegt genau in der Funktionsweise: /loop ist an die Session gebunden. Die Aufgaben, die es anlegt, feuern nur, solange diese bestimmte Claude-Code-Session noch läuft und untätig auf Ihrem Rechner ist. Schließen Sie das Terminal, stoppen sie. Das macht /loop ausgezeichnet, um einen Deploy oder einen Pull Request einen Nachmittag lang zu beobachten, und ungeeignet für alles, was das Zuklappen Ihres Laptops überstehen muss.

/schedule ist der andere eingebaute Befehl, und er löst genau diese Lücke. Beschreiben Sie eine wiederkehrende Aufgabe in einfacher Sprache, etwa /schedule daily PR review at 9am, oder eine einmalige wie /schedule in 2 weeks, open a cleanup PR that removes the feature flag, und Claude Code speichert sie als Cloud-Aufgabe, was Anthropic vor der Umbenennung eine Routine nannte. Von da an läuft sie auf Anthropics eigener Cloud-Infrastruktur, ausgelöst durch einen Zeitplan, einen API-Aufruf oder ein GitHub-Repository-Ereignis, ganz ohne Abhängigkeit davon, ob Ihr Rechner an ist.

Eigene Cron-Intervalle für eine /schedule-Aufgabe sind auf einmal pro Stunde begrenzt; alles Häufigere wird abgelehnt, eine bewusste Untergrenze und kein Fehler, da diese Arbeit unbeaufsichtigt laufen soll statt ständig abgefragt zu werden. /loop hat keine solche Untergrenze: Seine Cron-Werkzeuge unterstützen eine Granularität von einer Minute, weil eine Session, die Sie aktiv beobachten, eine viel engere Schleife verträgt als eine, die ganz von selbst läuft.

Stellen Sie sich eine /schedule-Aufgabe vor, die für jeden Wochentagmorgen eingerichtet ist. Sie wacht von selbst auf, weil ein Auslöser, nicht eine Person, die Session gestartet hat. Sie klont das Repository frisch, liest die seit gestern geöffneten Pull Requests und prüft deren CI-Status und Review-Kommentare gegen die eigenen CLAUDE.md-Konventionen des Projekts.

Sie merged nichts, und sie pusht nicht in den Standard-Branch. Sie öffnet eine Entwurfszusammenfassung, oder einen kleinen eigenen Pull Request, falls der Prompt das ausdrücklich erlaubt hat, und hält dort an, genauso wie die anderen Methoden in diesem Leitfaden: Ein GitHub-Actions-Lauf postet an den Pull Request, der ihn ausgelöst hat, und sonst nirgendwohin; ein Cron-Job mit claude -p gibt sein Ergebnis in eine Protokolldatei aus und endet mit einem Statuscode; eine /loop-Session sagt Ihnen, was sie gefunden hat, und wartet auf ihr nächstes Intervall.

In jedem Fall erfüllt der Zeitplan eine Aufgabe: die Session zu starten, damit sich niemand daran erinnern muss. Alles danach, was die Session berühren darf und wonach sie vorher fragen muss, ist immer noch eine Entscheidung, die Sie getroffen haben, als Sie den Prompt geschrieben und die Rechte gewählt haben, nicht etwas, das der Zeitplan selbst entscheidet.