Claude Routines sind kein Reasoning-Cron. Sie sind eine Repository-zentrierte Teilmenge davon.

10 min read

Eine Woche nachdem Anthropic Routines ausgeliefert hat, laufen drei meiner Cron-Jobs in der Produktion. Hat dreißig Minuten gedauert.

Das PR-Auto-Review, das alle halbe Stunde GitHub abgefragt hat? Tot. Das wöchentliche Doc-Drift-Script, das Commits in verrostetem Bash geparst hat? Tot. Der SEO-Datenabgleich, den ich sechs Monate lang aufgeschoben hatte (keine Zeit, ihr kennt das)? Läuft in fünf Minuten.

Drei Jobs, dreißig Minuten, null Reibung. Überzeugt. Am Abend bin ich den vierten angegangen.

Und dann: nichts. Kein Fehler, kein Quota-Limit, kein fehlerhaftes YAML. Der Job läuft, die Binary antwortet, aber der Service, den er abfragt, lebt auf einer IP, die Routines nicht sieht und niemals sehen wird - konstruktionsbedingt. Die siebenundvierzig anderen Jobs auf meinem Server sind in derselben Situation. Nicht einer passt. Und das ist kein Problem, das sich lösen lässt (es ist mechanisch).

Seit Routines da ist, habe ich hauptsächlich Demos gesehen. Alle zeigen die drei Jobs, die funktionieren. Niemand benennt die Grenze. Was folgt, ist, wie man das in die Produktions-Infrastruktur einbindet - inklusive der Teile, wo Routines aufhört und ihr übernehmt.

TLDR. Routines ist kein universeller Reasoning Cron. Es ist ein Reasoning Cron mit einem Perimeter, und die meiste Automatisierung lebt außerhalb dieses Perimeters aus Gründen, die ihr nicht wegkonfigurieren könnt. Die Frage ist nicht, ob Routines gut ist. Sondern wo es aufhört, was dort stattdessen läuft und wie man die DIY-Hälfte am Leben hält, ohne sich jeden Morgen neu einloggen zu müssen.

Die drei Jobs, die ich migriert habe, funktionieren in Anthropics Cloud besser als auf meinem Server. PR-Review feuert bei pull_request.opened statt zu pollen. Das Doc-Drift-Script hat jetzt vollständigen Repo-Kontext, der Output wurde von überfliegbar zu nützlich. Der SEO-Refresh läuft einfach, jeden Morgen, ohne Setup-Steuer. Der Teil ist geklärt.

Der Artikel handelt von allem anderen. Den siebenundvierzig Jobs, die ich als nächstes zu migrieren versucht habe, warum nicht einer davon funktioniert, und dem DIY-Pattern, das 2026 überlebt, sobald ihr akzeptiert, auf welcher Seite der Linie euer Job steht.

Geteilter Bildschirm Büro-Vergleich: überarbeiteter Entwickler umgeben von Fehlerprotokollen und gedruckten Konfigurationen versus ruhiger Entwickler mit sauberem Schreibtisch und einfacher Automatisierungs-Oberfläche.
Cron Jobs vs. Routines: nur einen Screenshot von der Vernunft entfernt.

Was "Reasoning Cron" tatsächlich bedeutet

Lasst mich benennen, worüber wir reden.

Ein Reasoning Cron ist ein Scheduler, der ein LLM zum Denken aufruft, nicht nur zur Ausführung deterministischen Codes. Er liest Kontext, trifft Entscheidungen, generiert Output, der davon abhängt, was er gerade gesehen hat. n8n und Make und Zapier routen Daten (sie denken nicht). Ein Python-Cron ist starr, er bricht, wenn sich das Input-Format ändert. Ein Reasoning Cron passt sich an.

Das ist die Kategorie. Routines gehört dazu. Mein DIY-Pattern auch. Genauso wie jeder Wrapper um claude -p oder gpt oder gemini. Die Kategorie ist real, die Nachfrage ist real, und dass Anthropic ein verwaltetes Produkt dafür ausliefert, ist der richtige Schritt.

Was irreführend ist, ist Routines als den Reasoning Cron zu bezeichnen. Es ist ein Reasoning Cron mit einem festen Perimeter.

Der Perimeter hat drei Wände. Erstens: Routines läuft in Anthropics Cloud, nicht auf eurer Maschine. Es klont ein Git-Repo zu Beginn jedes Laufs, und das ist das gesamte Dateisystem, das es sieht. Zweitens: Es kommuniziert mit der Außenwelt über verwaltete Konnektoren (Slack, Linear, Jira, GitHub, GDrive) und eine HTTP-Allowlist (Standard Trusted, die die meisten externen APIs blockiert). Drittens: Es hat bei jedem Lauf eine saubere Weste. Kein State, keine Cookies, keine persistente Session.

Nimbalyts praktischer Guide kam unabhängig zur selben Linie: Greift zu Routines, wenn die Arbeit repo-zentrisch ist, nach einem Zeitplan läuft und eure lokale Umgebung nicht braucht. Derselbe Perimeter, andere Worte.

Sobald ihr diese drei Wände im Kopf habt, ist das Folgende keine Meinung. Es ist Konsequenz.

Wo Routines gewinnt (Drei Jobs, die ich nie wieder anfasse)

Zugeständnis zuerst, weil Ehrlichkeit schneller ist als Rhetorik.

Diese drei Jobs sind in Routines besser, als sie in meinem Cron waren. Ich migriere sie nicht zurück.

PR-Auto-Review. Vorher: Ein Python-Cron, der alle dreißig Minuten GitHub abgefragt hat, ein claude -p-Review auf jeden neuen PR laufen ließ, einen Kommentar über die API postete. Der Polling-Cron hinkte jedem Push hinterher. Nachher: Eine Routine, die bei pull_request.opened getriggert wird, läuft in dem Moment, wo ein PR geöffnet wird, postet über den GitHub-Konnektor. Derselbe Prompt, dieselbe Output-Qualität. Weniger YAML, keine Polling-Verschwendung.

Doc-Drift wöchentlich. Vorher: Ein Bash-Script, das Commits seit letztem Montag auflistete, sie gegen den Docs-Ordner diffte, beides in claude -p fütterte, mir eine Zusammenfassung mailte. Die Zusammenfassung war immer leicht daneben, weil das Script keinen repo-weiten Kontext hatte. Das Modell sah nur, was Bash sed-piped hineingesteckt hat. Nachher: Eine Routine, die das vollständige Repo geklont bekommt, CLAUDE.md, den Docs-Ordner und das Commit-Log nativ liest und ein "was hat sich geändert, was ist veraltet"-Dokument schreibt, das tatsächlich die Codebase widerspiegelt. Der Output wurde von überfliegbar zu nützlich.

SEO-Datenabgleich. Kein Vorher. Ich wollte schon lange einen wöchentlichen Pull von meinem Analytics-Provider einrichten, ein Modell über die Deltas laufen lassen und eine Zusammenfassung in Slack posten. Jedes Mal, wenn ich mich hingesetzt habe, um das zu verdrahten, kam etwas anderes dazwischen und das YAML wurde nie geschrieben. Nachher: Eine Routine, fünfzehn Minuten Setup, läuft jeden Morgen. Der Job, den ich in sechs Monaten nie gebaut habe, existiert jetzt. Das ist das stärkste Argument für ein verwaltetes Produkt (die Arbeit, die ihr nie dazu gekommen wärt, selbst zu machen).

Diese drei teilen vier Eigenschaften. Repo-zentrisch. Output geht zu Slack oder GitHub. Frequenz ist mindestens eine Stunde. Nichts in der Kette berührt mein lokales Netzwerk.

Das ist exakt der Routines-Perimeter. Meine anderen siebenundvierzig Jobs verfehlen mindestens eine dieser vier Eigenschaften. Nicht einer von siebenundvierzig trifft alle vier.

Sechs Gründe, warum Routines meine Cron-Jobs nicht ersetzen kann

Sechs mechanische Gründe. Keine Präferenzen, keine Randfälle. Jeder einzelne schließt die Tür, bevor ihr das YAML fertig getippt habt.

1. Lokale MCP-Server. Routines verwendet Anthropics verwaltete Konnektoren. Das war's. Der MCP-Server, den ich selbst geschrieben habe, der auf meiner Maschine lebt und meine eigenen Daten für meine Claude Code Sessions freilegt, ist nicht verfügbar. Routines kann ihn nicht sehen, nicht mit ihm sprechen, sich nicht gegen ihn authentifizieren. Jeder Workflow, bei dem das Modell etwas abfragen muss, was ich lokal gebaut habe, fällt raus.

2. Services auf privaten IPs. Tailscale-Mesh. NAS zu Hause. Postgres auf dem Server. Interne Monitoring-Dashboards. Alles, was auf einer 100.x-Adresse oder einem 192.168-LAN sitzt. Routines läuft in Anthropics Cloud. Es weiß nicht, dass mein Mesh existiert. Der vierte Job aus der Einleitung lebt hier, und neunzehn andere auf meiner Liste auch.

3. Sub-stündliche Frequenz. Routines-Mindestintervall ist eine Stunde. Mein Status-Poller läuft alle fünfzehn Minuten, weil das Alert-Fenster das erfordert. Jeder Job, der schneller als einmal pro Stunde feuern muss, kann mechanisch nicht umziehen.

4. Tägliche Quota. Pro sind 5 Läufe pro Tag. Max sind 15. Team sind 25. Ich habe siebenundvierzig Jobs, die nächtlich laufen müssen, plus tägliche, plus die sub-stündlichen. Selbst wenn jede andere Beschränkung verschwände, würde ich die Quota vor Mitternacht auf einem Max-Plan treffen. Die Quota ist kein weiches Limit, das ihr verhandeln könnt (es ist der Vertrag).

5. Persistente Browser-Session. Routines startet bei jedem Lauf eine saubere Umgebung. Keine Cookies, kein localStorage, kein Session-Carryover. Wenn euer Job sich einmal in eine Site einloggen und die Session wiederverwenden muss, Playwright-Automatisierung gegen einen Service, der Auth erfordert, könnt ihr nicht. Nate Herk dokumentierte das auf Skool, als er versuchte, eine Community-Automatisierung in Routines laufen zu lassen. Der Login stirbt zwischen den Läufen. Der Job ist strukturell unmöglich.

6. Lokaler persistenter State. Ein Job, der zwischen Läufen in eine lokale SQLite schreibt, oder eine dateibasierte Queue pflegt, oder an ein langlebiges Log anhängt. Routines startet jedes Mal frisch. Was auch immer euer Job beim letzten Lauf geschrieben hat, ist weg. Ihr könnt die Konnektor-Outputs als State verwenden (Linear-Tickets, GitHub-Issues), aber wenn euer State auf der Festplatte lebt, wo der Cron lebt, ist das nicht portabel.

Ein Community-Kommentar unter Anthropics Launch-Post auf Threads brachte es auf den Punkt: once again github centric features. Das ist die Sicht von außen, und sie ist richtig, aber auch unvollständig. Routines ist nicht nur GitHub, die Konnektoren machen mehr als das. Die ehrliche Einordnung ist: Routines ist repo-zentrisch und managed-connector-zentrisch, und wenn eure Arbeit außerhalb dieses Perimeters stattfindet, hat das Tool euch nichts zu bieten.

Sechs Fälle. Nicht sechs Meinungen.

Das DIY-Pattern, das 2026 überlebt

Wenn euer Job außerhalb des Routines-Perimeters lebt, baut ihr ihn selbst. Was folgt, ist das Pattern, das überlebt, die Teile, die niemand in den Dutzenden "Routines just dropped"-Tutorials dokumentiert, die letzte Woche den Feed gesättigt haben.

Verwendet Shell-Redirect, nicht spawn-with-stdin.

claude -p "Summarize the input as JSON" < input.txt

echo "$LARGE_INPUT" | claude -p "Summarize"

Der Pipe-Deadlock ist der stille Killer. Kein Fehler, kein Timeout, nur ein Prozess, der an einer gepufferten stdin hängt, die nie schließt. Ich habe ein Wochenende damit verloren, bevor ich es zurückverfolgt habe. Shell-Redirect aus einer Datei ist der einzige zuverlässige Weg, große Inputs an die Binary im nicht-interaktiven Modus zu füttern.

Unset ANTHROPIC_API_KEY in eurer Cron-Umgebung.

unset ANTHROPIC_API_KEY
claude -p "..."

Wenn ANTHROPIC_API_KEY gesetzt ist, wenn ihr claude -p aufruft, verwendet die Binary sie und belastet euer API-Konto. Stillschweigend. Die Auth-Priorität ist dokumentiert, aber leicht zu übersehen. Ihr denkt, ihr lauft auf eurem Abonnement, und tatsächlich geht jeder Cron-Lauf über Pay-per-Token. Unset es explizit. Euer Geldbeutel wird es euch danken.

Beschränkt JSON-Output über Prompt, nicht Flag.

Vertraut nicht darauf, dass --output-format json die schwere Arbeit macht. Sagt dem Modell, welches Schema ihr wollt, im Prompt, dann validiert downstream:

claude -p 'Respond ONLY with valid JSON matching: {"status": "ok|fail", "items": [...]}. No prose, no fences.' < input.txt | jq -e .status

Wenn jq -e fehlschlägt, einmal wiederholen. Wenn Wiederholung fehlschlägt, alarmieren. Der Prompt-Level-Vertrag hält in meiner Erfahrung besser als das Flag, und ihr bekommt saubere Fehlermodi, wenn das Modell driftet.

Deshalb verschwindet das DIY-Pattern auch nicht, wenn MCP reicher wird. Die CLI-Binary bleibt vorhersagbar, deterministisch auf der Shell-Ebene, und sie komponiert mit allem anderen, was ihr habt. Ich habe das längere Argument für CLIs über MCP in Agent-Stacks vor ein paar Wochen gemacht, und Routines ändert die Schlussfolgerung nicht. CLIs komponieren. Verwaltete Scheduler nicht, by Design.

Generiert einen langlebigen OAuth-Token mit claude setup-token.

Das ist der Teil, der in jedem Cron-mit-Claude-Tutorial fehlt, das ich gelesen habe.

Das claude-code GitHub-Repo ist voller derselben Beschwerde. OAuth-Token laufen in 8 bis 24 Stunden im --print-Modus ab, Refresh schlägt stillschweigend fehl, Automatisierung stirbt. Der DEV-Community-Post "Building Claudio: My Always-On Claude Code Box" geht genau durch diesen Schmerz. V1 hielt zwei Wochen, bevor Token abliefen. V2 gab Cron komplett auf und schwenkte zu einem Desktop-Tool um.

Es gibt einen eingebauten Befehl, der das löst. Führt ihn einmal aus, interaktiv, auf der Maschine, wo ihr euch ursprünglich eingeloggt habt:

claude setup-token

Er generiert einen langlebigen OAuth-Token (ein Jahr, nur Inference-Scope), der für CI und unbeaufsichtigte Scripts designed ist. Ihr steckt ihn in CLAUDE_CODE_OAUTH_TOKEN. Die Binary respektiert ihn, kein Refresh-Tanz, kein tägliches Re-Login.

Ich paste den Token nicht in meine Cron-Umgebung. Ich speichere ihn in einem Secrets Manager (ich verwende Infisical, Vault und Doppler und AWS Secrets Manager machen alle denselben Job), und der Cron zieht ihn zur Laufzeit über eine Maschinen-Identität, die auf diesen einen Server beschränkt ist:

#!/usr/bin/env bash
set -euo pipefail

TOKEN=$(infisical secrets get CLAUDE_CODE_OAUTH_TOKEN --plain)
export CLAUDE_CODE_OAUTH_TOKEN="$TOKEN"
unset ANTHROPIC_API_KEY

claude -p "$(cat prompt.txt)" < input.json | jq -e . > output.json

unset CLAUDE_CODE_OAUTH_TOKEN

Der Token sitzt für die Dauer des Laufs im Speicher, dann verschwindet er. Wenn der Server kompromittiert wird, widerrufe ich die Maschinen-Identität und rotiere diese eine. Der Claude OAuth-Token selbst muss sich nicht bewegen. Das ist es, was einen DIY-Cron-Stack am Laufen hält, ohne tägliche Re-Logins oder stilles Versagen.

Ein kurzes Wort zu den Nutzungsbedingungen

Anthropic hat die Policy im Februar 2026 klargestellt: Die Claude Code CLI auf eurer eigenen Maschine zu verwenden, Daemon, Cron-Job, alles gut. Die CLI auf eurer eigenen Maschine, die offizielle Binary aufzurufen, ist in Ordnung.

Was im April 2026 gekappt wurde, war anders. Drittanbieter-Tools, die den Claude Code Client spooften und Subscription-Auth verwendeten, um externe Produkte zu betreiben, bekamen ihren Zugang widerrufen. Ich habe das durchlebt und mein Setup in der Woche danach neu aufgebaut. Das DIY-Pattern in diesem Artikel sitzt nicht auf der falschen Seite dieser Linie. Es ist die offizielle Binary, auf meiner Maschine, die tut, wofür die Binary designed ist.

Routines ist eine Research Preview. Die aktuelle ToS-Lesart könnte sich ändern, die Quotas könnten sich ändern, die Konnektor-Liste könnte sich ändern. Checkt die Docs alle paar Monate, wenn ihr etwas baut, das davon abhängt. Das gilt auch für mein Pattern. Lokaler Cron mit der offiziellen Binary war zwei Jahre lang erlaubt, und die Position wurde vor drei Monaten bekräftigt, aber "derzeit erlaubt" ist nicht "permanent".

Drei Fragen, die entscheiden, wo euer Job hingeht

Drei binäre Fragen. Ehrliche Antworten. Die Entscheidung fällt heraus.

1. Lebt der Job in einem Git-Repo, das ihr zu GitHub pusht?
Nicht "könnte er". Tut er es, heute, natürlich. Wenn nein: DIY.

2. Braucht er etwas außerhalb von Anthropics Konnektoren?
Ein lokaler MCP, eine private IP, eine persönliche Datenbank, eine persistente Browser-Session, euer eigener Dateisystem-State zwischen Läufen. Wenn ja: DIY.

3. Läuft er mehr als einmal pro Stunde oder mehr als eure tägliche Quota?
Sub-stündliche Polls, Dutzende nächtlicher Jobs, alles über der Plan-Obergrenze. Wenn ja: DIY.

Drei Neins: Routines, kein Zögern, keine Schuld. Es wird diesen Job besser laufen lassen als euer DIY-Cron, und ihr spart euch die Wartung.

Ein Ja: bleibt lokal. Verwendet das DIY-Pattern. Die DIY-Hälfte verschwindet nicht.

Eigentlich, nein, lasst es mich anders ausdrücken. Routines ist nicht Make, Zapier oder n8n (sie sind nicht dasselbe Tool). Routines ist ein Scheduler mit einem Perimeter. Ein Git-Repo, Anthropics Konnektoren, ein Ein-Stunden-Minimum zwischen Läufen. Was außerhalb dieses Perimeters lebt, ist nicht schlechteres Routines 😅

Die Devs, die ausliefern, kennen den Unterschied. Ihr steckt keinen Fünfzehn-Minuten-Poll in einen Scheduler mit einem Ein-Stunden-Minimum. Ihr steckt keinen Job, der mit eurem privaten Mesh spricht, in eine Cloud, die euer privates Mesh nicht sieht. Ihr steckt keinen stateful Job in eine Clean-Slate-Umgebung. Das ist nicht Geschmack. Das ist Arithmetik.

Passt das Tool zum Job. Routines ist exzellent innerhalb seines Perimeters. Nützlich, aber nicht die ultimative Antwort.

Quellen