Claude Code Routines, die Anthropic im April 2026 einführte, sind eine gespeicherte Claude Code-Konfiguration: ein Prompt, ein oder mehrere Repositories und Connectoren, einmalig verpackt und automatisch auf Anthropic-verwalteter Cloud-Infrastruktur ausgeführt. Die offizielle Dokumentation beschreibt drei Trigger-Typen: zeitlicher Rhythmus, API (HTTP POST mit Bearer-Token) und GitHub-Events. GitHub Actions hingegen führen die von dir geschriebenen Skripte auf GitHub-gehosteten Runnern aus. Beide können KI-Agenten zeitgesteuert ausführen. Sie sind nicht dasselbe, und die falsche Wahl kostet dich entweder Geld oder Stunden YAML-Fummelei. Dieser Post kartographiert die Entscheidung, zeigt die Blog-Queue-Worker und behandelt Fehler-Recovery.
Wähle Cloud Routines, Desktop, Session Loops oder Actions
Es gibt vier Hosting-Optionen. Sie sind nicht austauschbar.
Cloud Routines laufen auf Anthropics Infrastruktur, egal ob dein Laptop an ist. Nach der Dokumentation kann jede Routine einen zeitgesteuerten Trigger, einen API-Trigger oder einen GitHub-Event-Trigger haben, und du kannst alle drei auf einer Routine kombinieren. Der Kompromiss: jede Ausführung macht einen frischen Clone, daher sind lokale Dateien nie verfügbar.
Desktop-geplante Aufgaben laufen auf deinem Rechner. Sie haben vollständigen Zugriff auf dein lokales Dateisystem, lokale Datenbanken und .env-Dateien. Wenn der Rechner aus ist, läuft die Aufgabe nicht. Einfach.
Session-gebundene Zeitplanung (die Tools CronCreate, CronList, CronDelete) funktioniert nur innerhalb einer offenen CLI-Session. Das sind Session-Scheduling-Tools, nicht die Cloud-Routines-API. Sie verschwinden, wenn die Session endet.
GitHub Actions mit Cron-Trigger ist eine Workflow-YAML-Datei, die GitHub auf einem gehosteten Runner ausführt. Kostenlos für öffentliche Repos, günstig für private, deterministisch und tief in deine Codebasis integriert. Der Overhead ist real, wenn du nicht ohnehin in GitHub lebst, aber für Entwickler, die es tun, minimal.
Also: Wie wählst du?
- Die Aufgabe läuft, ob dein Rechner an ist oder nicht, und braucht echtes KI-Reasoning (Zusammenfassen, Entwerfen, Triage)? Cloud Routine.
- Die Aufgabe braucht deine lokale
.env, eine lokale Datenbank oder lokales Werkzeug? Desktop-geplante Aufgabe. - Die Aufgabe ist eine CI/CD-Pipeline, PR-Event-Handler oder ein deterministisches Skript, das eine API aufruft und zu Slack postet? GitHub Actions, möglicherweise mit einem kurzen Python-Skript und gar keinem LLM.
- Die Aufgabe ist explorativ und lebt innerhalb einer einzelnen Session, die du ohnehin laufen hast? Session Loop.
AI Magicx's Übersicht macht es klar: Wenn deine Routine „API aufrufen, transformieren, zu Slack posten" ist, sind GitHub Actions mit einem 10-Zeilen-Python-Skript billiger und einfacher. Routines werden die richtige Wahl, wenn die Arbeit wirklich von Claudes Reasoning profitiert: entscheiden, was zu berichten ist, eine Erzählung schreiben, Qualität prüfen.
Persistenz, lokale Dateien und Anmeldedaten nach Host
Hier werden Operatoren verletzt. Die nachfolgende Tabelle verwendet Informationen aus der offizielle Dokumentation und Community-Forschung, nicht behauptete Testergebnisse.
| Host | Lokale Dateien | .env | Anmeldedaten | Bleibt bei geschlossenem Laptop erhalten |
|---|---|---|---|---|
| Cloud Routine | Nein (frischer Clone) | Nein | Routine-Umgebungsvariablen | Ja |
| Desktop-geplante Aufgabe | Ja | Ja | Lokale Konfiguration | Nein |
Session Loop (CronCreate) | Ja (Session-Bereich) | Ja | Session-Bereich | Nein |
| GitHub Actions | Nur Repo-Dateien | Nein | GitHub Secrets | Ja |
Shareuhack's 2026 write-up weist auf eine spezifische Falle hin, die es wert ist, zitiert zu werden:
„Jede Cloud Routine-Ausführung führt einen frischen Clone in Anthropics Cloud-Umgebung durch. Sie kann nicht auf Ihre lokale .env.local, lokale Datenbanken oder anderen lokalen Status zugreifen."
Und noch eine: Der Netzwerkzugriff in Cloud Routines ist standardmäßig auf „trusted" eingestellt, was manche APIs rundweg ablehnen. Wenn Sie auf ClickUp oder eine andere API treffen, die Trusted-Mode-Anfragen ablehnt, schalten Sie in den Umgebungseinstellungen der Routine auf „full" Netzwerkzugriff um. Es gibt einen kleinen Sicherheits-Kompromiss, wiegen Sie ihn also gegen die Sensibilität Ihres Repos ab.
Bei GitHub Actions befinden sich Secrets in den Repository-Einstellungen und werden zur Laufzeit als Umgebungsvariablen eingespielt. Die Aktion anthropics/claude-code-action@v1, die auf dem Claude Agent SDK aufbaut, übernimmt diese automatisch. Sie übergeben --model, --max-turns und --allowedTools über die claude_args-Eingabe, um zu kontrollieren, was der Agent tatsächlich tun darf.
Den aktuellen Blog Queue Worker lesen
Der Blog Queue Worker ist eine Routine (oder ein gleichwertiger geplanter Job), die einen Post aus einer Warteschlange abholt, Inhalte generiert und ihn als erledigt markiert. Hier ist die Struktur in ihrem aktuellen Zustand, mit klaren Vorbehalten darüber, was der Code tatsächlich tut versus das, was Sie annehmen könnten.
Die bedingte Aussage: Der Worker prüft, ob ein Post bereits beansprucht wurde, bevor er ihn abholt. Das verhindert, dass zwei Ausführungen gleichzeitig denselben Eintrag greifen – zumindest im Happy Path. Was der aktuelle Code nicht hat, ist die Wiederherstellung verwaister Claims. Wenn ein Worker mid-run mit einem Post ausfällt, der als „in progress" markiert ist, bleibt dieser Post beansprucht, bis jemand ihn manuell zurückzusetzt. Beschreiben Sie dies nicht als Exactly-Once-Delivery oder garantieren Sie einen Post pro Tag; beide Aussagen gehen weiter, als der Code unterstützt.
Das Worker-Diagramm sieht ungefähr so aus:
- Fetch queue, filter for
status = queued - Den ersten verfügbaren Post beanspruchen (set
status = in_progress, write a timestamp) - Run the generation prompt against the claimed post's metadata
- On success: set
status = published, write the output path - On failure: increment
retry_count, resetstatus = queued(if retries remain) or setstatus = failed
Schritt 5 ist der Punkt, in den die meisten Teams zu wenig investieren. Die Retry-Logik muss im Routine-Prompt oder im Wrapper-Skript leben, weil die Cloud-Infrastruktur selbst eine Routine, die mit einem Fehler endet, nicht erneut ausführt.
Wenn du Content Pipelines wie diese aufbaust und möchtest, dass die agentic layer für dich übernommen wird, deckt die Arbeit, die wir bei agentic engineering leisten, genau dieses Muster ab.
Schedule Due Jobs and Handle Retries
Das Scheduling einer Routine via CLI erfordert Claude Code v2.1.225 oder später. Vor v2.1.211 meldete die CLI eine Phantom-Startzeit (Jahr 1) für Routinen ohne Schedule Trigger. Wichtig zu wissen, wenn du alte Logs liest.
Eine Routine mit nur API oder GitHub Event Triggern hat keine nächste Startzeit. Die CLI zeigt nichts an. Das ist korrektes Verhalten, kein Bug.
Für Retry-Handling hast du zwei Optionen:
- Retry inside the prompt. Schreib den Prompt so, dass er den fehlgeschlagenen Schritt bis zu N mal versucht, bevor er den Job als fehlgeschlagen markiert. Claudes Reasoning kann zwischen einem transienten Netzwerkfehler und einem echten Content-Problem unterscheiden.
- Retry via a separate scheduled routine. Eine leichte „Requeue"-Routine läuft stündlich, scannt nach Posts, bei denen
status = queuedundretry_count < 3, und triggert den Main Worker über seinen API Trigger erneut (ein POST zum Pro-Routine-Endpoint mit einem Bearer Token).
Das zweite Muster ist im großen Maßstab sauberer. Es entkoppelt die Retry-Richtlinie vom Generation Prompt, und du kannst Retry-Limits anpassen, ohne den Main Routine zu ändern.
Daily run caps und gemeinsame Subscription-Nutzung sind eine echte Einschränkung für Teams, wie Arcades Enterprise-Schreiben hinweist. Ihre Empfehlung: Batch-Arbeit in eine einzelne täglich „Meta-Orchestrator"-Routine und reserviere echte Trigger nur für hochpriorisierte Events.
Für die SEO-Keyword-Retrieval-Seite einer Content Pipeline wird der Automation Stack, den wir bei DataForSEO + Claude Code dokumentiert haben, separat behandelt und lohnt sich, vor dem Entwerfen des Queue-Schemas zu lesen.
Detect Stuck Claims and Verify Published Output
Veraltete Claims sind der stille Killer von Queue-basierten Pipelines. Ein Post, der sechs Stunden lang in_progress ist, ist fast sicher stuck, nicht am Laufen.
Eine Detection-Routine kann so einfach sein wie:
- Query for posts where
status = in_progressandclaimed_at < now() - 2 hours - Diese auf
status = queuedzurücksetzen, die Worker-Kennung löschen, den Reset protokollieren - Via Slack oder einen Webhook alerten, wenn die Reset-Anzahl einen Schwellenwert überschreitet
Führen Sie dies als separate Low-Frequency-Routine aus (alle zwei Stunden ist in Ordnung), anstatt es in den Hauptworker einzubauen. Separation of Concerns ist hier wichtig: Der Hauptworker sollte nicht dafür verantwortlich sein, nach sich selbst aufzuräumen.
Die Überprüfung der veröffentlichten Ausgabe ist ein anderes Problem. „Published" als Status-Flag bedeutet, dass die Datenbank geschrieben wurde. Es bedeutet nicht, dass der Beitrag auf der Website korrekt angezeigt wurde, eine Lesbarkeitsüberprüfung bestanden hat oder indexiert wurde. Ein Überprüfungsschritt sollte:
- Die Live-URL abrufen und bestätigen, dass sie eine 200 zurückgibt
- Die Wortanzahl oder ein einfaches Qualitätssignal gegen einen definierten Schwellenwert prüfen (wählen Sie Ihre eigene Zahl und kennzeichnen Sie sie als Team-Heuristik, nicht als universellen Standard)
- Falls die Überprüfung fehlschlägt, den
Statusaufqueuedzurücksetzen, mit erhöhtemretry_countund einemverification_failedFlag
Die Humaniser-Pipeline, die wir unter AI Content Humanizer Pipeline beschrieben haben, führt einen ähnlichen Post-Publish-Überprüfungsschritt durch und ist wertvoll zum Querverweis, wenn Sie diese Schicht aufbauen.
Betriebskosten und Verantwortung
Hier stößt die Erzählung „Routinen sind einfacher" auf Widerstand.
Cloud Routines laufen auf Anthropics Infrastruktur und verbrauchen Claude Code Session-Limits genauso wie eine interaktive Sitzung. Das Research Preview macht dies explizit: Routinen reduzieren Ihre Limits. Für einen kleinen unabhängigen Betreiber, der drei oder vier Routinen pro Tag ausführt, ist das wahrscheinlich in Ordnung. Für ein Team, das 20+ tägliche Läufe zusammenfasst, werden Sie die Obergrenze erreichen und müssen die Architektur entsprechend anpassen.
GitHub Actions ist kostenlos für öffentliche Repositories und wird für private nach Minute berechnet. Ein Claude Code Agent-Lauf innerhalb von Actions über anthropics/claude-code-action@v1 verbraucht immer noch API-Token (berechnet nach Ihrem Anthropic API-Tarif), aber Sie kontrollieren den Runner, das Timeout und die Wiederholungslogik vollständig. Diese Verantwortung ist der Punkt.
Die Verantwortungsteilung in der Praxis:
- Routinen verantworten: Urteilsintensive Aufgaben, die Claudes Denken erfordern, Aufgaben, die unbeaufsichtigt ohne Infrastruktur-Overhead ausgeführt werden müssen, GitHub-ausgelöste PR-Reviews und Sentry/Log-Triage.
- GitHub Actions verantworten: CI/CD-Pipelines, PR Event-Handling und Installationsflows, deterministische Build-Test-Deploy-Sequenzen und alle Aufgaben, bei denen ein 10-zeiliges Python-Skript wirklich die Arbeit erledigt.
Keines ersetzt das andere. Der Shareuhack-Artikel formuliert es gut: „Die optimale Kombination lässt GitHub Actions CI/CD handhaben, während Routinen die reasoningintensiven Teile handhaben." Diese Formulierung ist richtig, und es ist die Entscheidungsgrenze, die es sich lohnt zu merken.
FAQ
Kann eine Cloud Routine in mein Repository zurückschreiben?
Ja. Routinen verbinden sich mit einem oder mehreren Repositories und können Commits pushen und Pull Requests über das verbundene Repo öffnen. Was sie nicht können, ist der Zugriff auf Dateien, die nur auf Ihrem lokalen Computer vorhanden sind. Alles, was die Routine benötigt, muss im Repo sein oder als Umgebungsvariable in den Cloud-Umgebungseinstellungen der Routine konfiguriert sein.
Was passiert, wenn eine Cloud Routine während eines Laufs auf ein Rate Limit trifft?
Die Routine selbst wiederholt nicht automatisch bei Rate Limit Fehlern. Falls sie mit einem Fehler endet, bleibt sie fehlgeschlagen, bis der nächste geplante Lauf stattfindet oder bis Sie sie manuell über den API-Endpunkt auslösen. Das Erstellen von Wiederholungslogik in den Prompt (Rate Limit Antwort erkennen, warten, neuer Versuch) oder die Verwendung einer separaten Requeue-Routine sind beide angemessene Maßnahmen.
Ist die GitHub App Installation getrennt vom CLI web-setup Befehl?
Ja, und das verwirrt manche Leute. Das Ausführen von /web-setup in der CLI gewährt Clone-Zugang zur Routine, installiert aber nicht die GitHub App. Die Webhook-Zustellung für GitHub Event-Trigger erfordert die separate GitHub App Installation. Der Routine-Setup-Flow leitet Sie durch dies, aber die beiden Schritte sind unterschiedlich.
Haben GitHub Event-Trigger in Routinen während des Research Preview Rate Limits?
Nach der offiziellen Routinen-Dokumentation unterliegen GitHub Webhook-Events während des Research Preview pro-Routine und pro-Konto stündlichen Obergrenzen. Events über der Grenze werden gelöscht, bis das Fenster zurückgesetzt wird. Planen Sie entsprechend, wenn Sie Bursts von PR-Aktivität erwarten.
Kann ich Skills in einem GitHub Actions-Workflow mit `anthropics/claude-code-action` verwenden?
Ja. Der Input `prompt` akzeptiert Skill-Aufrufe wie /skill-name. Du benötigst einen `actions/checkout`-Schritt vor der Action, damit die Skill-Dateien in .claude/skills/ auf dem Runner vorhanden sind. Skills und Commands sind unterschiedliche Konzepte in Claude Code; überprüfe die offizielle Skills-Dokumentation, bevor du die beiden vermischst.
Die eine wichtigste Einschränkung aus allem oben: Cloud Routines verbrauchen deine Claude Code-Sitzungslimits genauso wie interaktive Sitzungen, und der aktuelle Queue Worker hat keine eingebaute Recovery für abgelaufene Ansprüche. Berücksichtige beide Aspekte, bevor du etwas in die Produktion bringst.