Claude Routines + Opus 4.7: Mein erstes Build-Log für Entwickler

Claude Routines + Opus 4.7: Mein erstes Build-Log für Entwickler

Es war 6:47 Uhr an einem Freitagmorgen, mein Handy lag mit dem Display nach unten auf dem Nachttisch. In der Küche lief etwas, das ich nicht selbst ausgeführt hatte, auf einer Maschine, die nicht mir gehörte. Dieses Etwas las meine letzten 24 Stunden an E-Mails, sortierte sie in drei Stapel, erstellte Entwürfe für Antworten auf die fünf E-Mails, die eine benötigten, und postete eine Zusammenfassung in #morning-brief auf Slack — inklusive Betreffzeilen und einer Ein-Zeilen-Dringlichkeitsbewertung für jede Nachricht.

Als ich mir Kaffee holte, lag die Zusammenfassung bereits seit 31 Minuten in Slack. Zwei Entwurfsantworten befanden sich schon im Entwurfsordner von Gmail und mussten jeweils mit etwa neun Wörtern nachbearbeitet werden, bevor ich auf Senden drücken konnte. Ein dritter Entwurf war von der Routine selbst als "braucht deinen Kontext — nicht senden" markiert worden. Der Laptop auf meinem Schreibtisch war seit 23:14 Uhr am Vorabend geschlossen.

Das ist die erste Woche, in der ich diesen Satz sagen konnte: "Etwas lief, während ich schlief, auf einer Maschine, die nicht mir gehörte" — und das bei einem Workflow, den ich selbst gebaut habe, in weniger als drei Minuten, ohne eine einzige Zeile Cron-Syntax zu schreiben oder eine EC2-Instanz hochzufahren. Genau das wurde ausgeliefert, als Anthropic am 14. April 2026 Claude Routines veröffentlichte, zwei Tage bevor Opus 4.7 am 16. April erschien. Die beiden Releases sind untrennbar verbunden. Routines sind der Container. Opus 4.7 ist das, was die Arbeit im Container tatsächlich nützlich macht, statt nur zeitlich zu steuern.

Ich habe mittlerweile sechs Routines über sieben Tage hinweg laufen lassen. Zwei davon habe ich in die Produktion gebracht. Zwei habe ich nach Totalausfällen — auf Arten, vor denen die Dokumentation nicht warnt — komplett neu gebaut. Eine habe ich vollständig gelöscht. Und eine läuft gerade jetzt, im Hintergrund, während ich diesen Satz schreibe.

Was folgt, ist keine erneute Ankündigung. Wer die offizielle Pressemitteilung sucht, kann auf den eigenen Beitrag von Anthropic zurückgreifen. Was folgt, ist das tatsächliche Gefühl, in der ersten Woche mit Claude Routines auf Opus 4.7 zu bauen — die Muster, die funktioniert haben, die Fehlermodi, in die ich gelaufen bin, die Sicherheitsüberlegungen, die man anstellen sollte, bevor man einem automatisierten Job Zugriff auf den eigenen Posteingang gewährt, sowie die konkreten Workflows, die ich als Nächstes bauen würde, wenn ich ein weiteres freies Wochenende hätte.

Ich beginne mit der Frage, was Routines eigentlich sind — denn in der Hälfte der Berichterstattung, die ich diese Woche gelesen habe, wird ein und derselbe Punkt immer wieder falsch dargestellt.

Was Routines eigentlich sind (und was sie nicht sind)

Eine Routine ist eine gespeicherte Claude-Code-Konfiguration — ein Prompt, eine Auswahl an Repositories, eine Reihe von Konnektoren und ein Trigger — die auf der Infrastruktur von Anthropic selbst ausgeführt wird. Dies geschieht nach Zeitplan, auf einen API-Call hin oder als Reaktion auf ein GitHub-Webhook-Ereignis. Wenn der Trigger ausgelöst wird, startet Anthropic eine frische Claude-Code-Session, übergibt den gespeicherten Prompt, gewährt Zugriff auf die freigegebenen Konnektoren, lässt die Ausführung zu Ende laufen und schließt dann die Session wieder. Dein lokaler Rechner ist dabei nicht beteiligt. Dein Laptop kann zugeklappt sein. Du kannst im Flugzeug im Flugmodus sitzen.

Gerade dieser letzte Punkt hat meine Sicht auf diese Art von Automatisierungen grundlegend verändert. Jeder von mir bisher gebaute geplante AI-Workflow — jeder Cronjob, der ein Python-Skript samt API-Aufruf einbettet, jede GitHub Action, die Claude über das SDK anspricht — war davon abhängig, dass eine Maschine in meinem Besitz an, online und funktionsfähig war. Mit Routines entfällt diese Abhängigkeit zum ersten Mal für mich.

Was sind Routines nicht? Sie sind kein n8n-Ersatz. Sie sind kein Zapier-Killer. Es handelt sich nicht um einen visuellen Workflow-Builder, bei dem man Kästchen zieht und Pfeile verbindet. Es sind gespeicherte Prompts, kombiniert mit Triggern, Tool-Berechtigungen und einem Ort, an dem Claude so lange arbeiten kann, wie es die Aufgabe erfordert. Das visuelle Interface ist das Routines-Panel der Desktop-App. Die eigentliche Intelligenz besteht darin, wie Claude agiert, wenn der Trigger ausgelöst wird und das gespeicherte Prompt eingelesen wird.

Die Unterscheidung ist entscheidend, weil bereits der Designansatz ein grundlegend anderer ist. Ein Zapier-Flow schlägt fehl, sobald sich eine API-Response strukturell verändert. Eine Routine liest im Idealfall die neue Form und passt sich an. Ob sie das in der Praxis auch wirklich tut, ist der Punkt, an dem Opus 4.7 ins Spiel kommt.

Trigger, Tools und die drei Kennzahlen, die das Feature bestimmen

Routines unterstützen genau drei Trigger-Typen. Jeder davon hat spezielle Eigenheiten, die du kennen solltest, bevor du einen Workflow darauf aufbaust.

Zeitplan-Trigger laufen nach einem Cron-ähnlichen Rhythmus mit einer festen Einschränkung: Das minimale Intervall beträgt eine Stunde. Im UI wählst du zwischen vier Vorgaben — stündlich, täglich, werktags, wöchentlich. Wenn du einen eigenen Rhythmus wie „alle zwei Stunden“ oder „jeden ersten Montag im Monat“ benötigst, wählst du die am ehesten passende Vorgabe und passt dann per CLI-Befehl /schedule update die konkrete Cron-Expression an. Häufigere Ausführungen als stündlich werden abgelehnt. Wer eine Routine alle fünf Minuten als Polling-Job laufen lassen möchte, kommt mit Routines aktuell nicht weiter.

Webhook-Trigger werden ausgelöst, wenn deine Routine einen API-Call mit dem richtigen Schlüssel erhält. Zu diesem greife ich immer wieder zurück. Denn das bedeutet: Jedes Tool, das einen POST an eine URL senden kann, kann so eine Routine starten — dein CRM, dein PM-Board, dein Kontaktformular, eigene Scripte. Es ist der universelle Ausweg. Falls der Zeitplan-Rhythmus nicht passt, lassen sich damit fast alle Taktungsprobleme lösen, indem ein anderes System zu deinem gewünschten Zeitpunkt einen Webhook-POST absetzt.

GitHub-Trigger werden durch GitHub-Webhook-Ereignisse ausgelöst — Pushes, Pull-Requests, Kommentare, Releases — und zwar für Repositories, die du über die Claude-GitHub-App verbunden hast. Während des Research-Previews gelten dabei stündliche Limite pro Routine und pro Account. Wer also zehnmal in fünf Minuten pusht, wird feststellen, dass nicht alle zehn Pushes die Routine auslösen: Einige Aufrufe werden verworfen, bis sich das Stundenfenster zurücksetzt. Gut zu wissen, bevor man einen „Claude prüft jeden PR“-Workflow baut – und sich wundert, warum nur jeder zweite PR auch tatsächlich überprüft wird.

Drei Zahlen definieren, wie viel von Routines du je nach deinem Account-Bundle tatsächlich nutzen kannst. Pro-Accounts können bis zu 5 Routine-Ausführungen pro Tag starten. Max-Accounts können 15 laufen lassen. Team- und Enterprise-Accounts dürfen 25 ausführen. Mehrnutzungen sind optional kostenpflichtig. Diese Limits gelten pro Tag, nicht pro Routine. Wer also als Pro-User fünf verschiedene Routines einmal täglich laufen lässt, hat sein Kontingent ausgeschöpft. Wer eine einzelne Routine stündlich aufrufen möchte, stößt damit bereits vor 11 Uhr vormittags an die Grenze.

Gerade bei dieser Rechnung werden viele User zum ersten Mal scheitern, wenn sie versuchen, eine Routine über den Demo-Status hinaus zu skalieren. Wer mit Pro stündlich ausführen will, hat lediglich 5 Runs am Tag zur Verfügung: Ein echtes stündliches Job-Intervall ist auf Pro ohne Übernahme von Zusatzkosten derzeit nicht machbar. Das ist eine Beschränkung im Research Preview — vermutlich nur vorübergehend, jedoch aktuell verbindlich.

An dieser Stelle wird das Feature aber erst spannend — und hier rückt dann auch das zugrundeliegende Modell stärker in den Fokus als das technische Drumherum.

Opus 4.7 ist der Grund, warum Routines wirklich nützlich sind

Anthropic hat Claude Opus 4.7 am 16. April 2026 ausgeliefert, zwei Tage nachdem die Routines Research Preview gestartet wurde. Ich glaube nicht, dass das ein Zufall ist. Alle veröffentlichten Benchmarks zeigen in dieselbe Richtung: Opus 4.7 ist bei lang andauernden, mehrstufigen, werkzeugintensiven Aufgaben besser als jedes bisherige Modell. Routines sind per Definition lang andauernde, mehrstufige, werkzeugintensive Workflows.

Den Zahlen, denen ich am meisten vertraue – weil sie aus den internen Evaluationen von Anthropics eigenen Engineering-Partnern stammen und nicht von Marketingkurven –, sind die folgenden. In den internen Production-Evaluierungen bei Box reduzierte Opus 4.7 die Modellaufrufe um 56 % und die Werkzeugaufrufe um 50 % im Vergleich zu Opus 4.6, antwortete im selben Test 24 % schneller und verbrauchte 30 % weniger AI Units bei End-to-End-Arbeiten. Im Produktions-Benchmark für Coding bei Rakuten bewältigt Opus 4.7 etwa dreimal so viele Produktionsaufgaben wie Opus 4.6, mit zweistelligen Steigerungen sowohl bei Code Quality als auch bei Test Quality. Bei CursorBench, der reale, IDE-integrierte Coding-Workflows misst statt synthetischer Problemlösungen, steigert sich Opus 4.7 von 58 % (der Score von Opus 4.6) auf 70 % – ein Plus von 12 Punkten bei dem Benchmark, der der tatsächlichen Arbeit von Entwicklern am nächsten kommt.

Der Benchmark, der für agentische Workloads am meisten zählt, ist allerdings SWE-bench Verified. Opus 4.6 erzielte 80,8 %. Opus 4.7 erreicht 87,6 %. Das ist ein Zuwachs von fast sieben Punkten auf einer Bestenliste, auf der selbst kleinste Fortschritte mühsam erkämpft werden – und es bringt Opus 4.7 vor Gemini 3.1 Pro (80,6 %) und deutlich vor GPT-5.4 beim selben Aufgaben-Set.

Ein weiterer wichtiger Punkt, der unbedingt erwähnt werden muss, weil es das wichtigste Flag ist, das man kennen sollte, bevor man eine Routine konfiguriert: Opus 4.7 bringt einen neuen Effort-Level namens xhigh mit. Nicht "extra high", nicht "extended", nicht "high-plus" – der eigentliche Flag-Name in der API und im CLI ist xhigh. Es ist der empfohlene Standard für komplexes Reasoning und agentische Arbeit unter Opus 4.7 und standardmäßig innerhalb von Claude Code für dieses Modell aktiviert. Was xhigh unter der Haube macht: Es weist dem internen Reasoning und dem Tool-Explorations-Loop des Modells mehr Tokens zu, bevor es eine Antwort liefert. Für einen One-Shot-Chat ist das überdimensioniert. Für eine Routine, die E-Mails abrufen, sie kategorisieren, Antwortentwürfe erstellen und eine Slack-Zusammenfassung verschicken soll, ohne dass du korrigierend eingreifen kannst, ist es genau das richtige Niveau.

Eine Einschränkung, die die Blogposts eher nicht betonen werden: xhigh ist teuer. Kombiniert man das mit einem neuen Tokenizer in Opus 4.7, der für den gleichen Text etwa 1,0 bis 1,35-mal so viele Tokens zählt wie 4.6, sowie dem natürlichen Output-Inflationseffekt durch tiefere interne Reasoning-Loops, können deine API-Rechnungen pro entsprechendem Task um 20 % bis 50 % gegenüber der 4.6-Ära steigen. Die Arbeit wird besser. Die Arbeit wird teurer pro Durchlauf. Beides ist wahr. Wenn du Routines über die API laufen lässt statt innerhalb des in Claude Code enthaltenen Free-Tiers, rechne erst mit einem risikofreien Testjob nach, bevor du xhigh in eine Routine integrierst, die 25-mal am Tag läuft.

Nachdem das Feature und das Modell nun klar sind, erzähle ich dir, was ich tatsächlich gebaut habe.

Die Routine, die ich ausgeliefert habe: E-Mail-Triage am Morgen, die wirklich funktioniert

Ich habe die E-Mail-Triage-Routine zuerst gebaut – aus demselben Grund wie wahrscheinlich jeder andere auch: Das Demo, das Anthropic zum Launch bereitgestellt hat, war eine E-Mail-Triage-Routine. Die Art der Problemstellung – vorhersehbare Eingaben, begrenzte Ausgaben, leicht zu validieren – macht sie zum saubersten Einstieg für den ersten Build in diesem Feature. Nicht erwartet hatte ich allerdings, wie stark die Output-Qualität davon abhängt, dass man den Prompt so schreibt, als würde man die Aufgabe an einen unbekannten externen Dienstleister übergeben.

Hier ist der Prompt, mit dem ich nach drei Iterationen schließlich gelandet bin. Er ist lang – und das ist genau der Punkt.

Du führst einen unbeaufsichtigten E-Mail-Triage-Job um 6:45 Uhr Ortszeit aus.
Ich kann währenddessen keine Rückfragen beantworten. Triff in jedem Fall die
bestmögliche Entscheidung. Im Zweifel: Entwurf statt Versand.

SCHRITT 1 — ABRUFEN
Hol alle ungelesenen Nachrichten aus meinem Gmail-Posteingang, die in den
letzten 24 Stunden eingegangen sind. Schließe alles aus Promotions, Soziale Netzwerke oder Updates aus.

SCHRITT 2 — KATEGORISIEREN
Sortiere jede Nachricht in genau einen dieser drei Bereiche:
  – DRINGEND — Eine benannte Person wartet auf meine Antwort, eine
    Deadline ist in weniger als 48 Stunden, oder es geht um Geld/Verträge.
  – ANTWORT ERFORDERLICH — Eine Antwort wird erwartet, aber nichts ist dringlich und
    nichts brennt.
  – KEINE AKTION — Newsletter, Quittungen, FYIs, keine Antwort erwartet.

SCHRITT 3 — ENTWURF
Für jede DRINGEND- und ANTWORT ERFORDERLICH-Nachricht, verfasse eine Antwort
und speichere sie in meinen Gmail-Entwürfen. Nicht senden! Übernimm meinen Tonfall
aus den letzten zehn Antworten in meinem Gesendet-Ordner (kurze Sätze, kein „Hope you’re well“, Unterschrift mit „— M“). Falls du aufgrund fehlenden Kontextes keinen Entwurf verfassen kannst, schreibe eine Antwort, in der du exakt angibst, welchen Kontext du brauchst, und kennzeichne den Entwurf im Betreff mit [NEEDS_CONTEXT].

SCHRITT 4 — ZUSAMMENFASSUNG
Poste eine Slack-Nachricht an #morning-brief mit folgendem Format:
  DRINGEND (N): einzeiliger Absender + einzeiliger Betreff + deine Entwurfs-Einschätzung
  ANTWORT ERFORDERLICH (N): gleiche Struktur
  KEINE AKTION (N): nur Zählwert, keine Details

SCHRITT 5 — FEHLERBEHANDLUNG
Falls ein Schritt fehlschlägt, poste in Slack #morning-brief mit @here und
dem Fehler. Ein stiller Fehler ist das schlimmstmögliche Ergebnis. Lieber
eine rote Fehlermeldung als gar nichts.

SCHRITT 6 — KONTEXTABFRAGE VORHERIGER DURCHLÄUFE
Bevor du mit Schritt 1 beginnst, lies die angeheftete Nachricht in #morning-brief
vom gestrigen Lauf. Falls noch DRINGEND-Punkte von gestern nicht in meinem
Gesendet-Ordner adressiert sind, nimm sie in die heutige Zusammenfassung als
CARRIED_OVER auf.

Sechs nummerierte Schritte. Explizite Fehlerbehandlung. Klare Anweisung, wie Kontext aus dem letzten Durchlauf gezogen wird. Keine Annahmen darüber, was Claude selbst herausfinden könnte.

Gerade der letzte Schritt – die Kontextabfrage früherer Durchläufe – hat mich zwei Neuaufbauten gekostet, bis ich ihn richtig hatte. Routines haben standardmäßig kein Gedächtnis zwischen Ausführungen. Jeder Run startet in einer frischen Session. Wenn man möchte, dass der gestrige Run Einfluss auf den heutigen hat, muss man Claude exakt anweisen, wo dieser Kontext zu finden ist – etwa in einem Slack-Channel, einem Google Doc, einem GitHub-Gist, einer Notion-Page, egal, solange ein Connector Lese- und Schreibzugriff bietet. Lässt man dieses Detail weg, wird die Routine fröhlich drei Tage in Folge dieselbe E-Mail neu entwerfen, weil für sie jeder Morgen der erste ist.

Die Fehlerbehandlungs-Anweisung war die zweite wichtige Lektion, die eine Neuimplementierung gekostet hat. Mein erster Durchlauf stürzte an einer fehlerhaften MIME-Nachricht ab – ohne jegliche Rückmeldung. Ich merkte erst, dass etwas schiefgelaufen war, als um 7 Uhr keine Slack-Kurzsummary eintraf. Als ich den @here-Failover eingebaut hatte, hatte ich schon zwei wirklich dringende Mails verpasst, weil ich von der ruhigen Inbox irrtümlich auf einen störungsfreien Morgen schloss. Ein stiller Fehler ist in jedem unbeaufsichtigten Workflow das gefährlichste Ergebnis überhaupt. Schreibe die Fehler-Callback-Logik immer, bevor du Richtung „Happy Path“ gehst.

Die Ergebnisse der ersten Woche

So sahen die Zahlen tatsächlich nach sieben Tagen mit dieser Routine aus – keine kuratierte Case Study, sondern meine echte Beobachtung:

Verarbeitete Nachrichten: 294 ungelesene E-Mails in 7 Tagen (etwa 42 pro Tag). Kategorisierungsgenauigkeit, jeweils morgens von mir manuell geprüft: 91 % Übereinstimmung mit Claudes Bucketings. Die 9 % Abweichungen entstanden fast immer durch Überklassifizierung als „DRINGEND“ – typischerweise, weil der Tonfall einer E-Mail als dringlich wirkte, aber der Inhalt nur ein Status-Update war. Entwurfsqualität: 6 von 10 Entwürfen habe ich mit weniger als 15 Änderungen direkt verschickt. 2 von 10 habe ich deutlich umgeschrieben. 1 von 10 verworfen und komplett neu geschrieben. 1 von 10 wurde korrekterweise mit [NEEDS_CONTEXT] markiert, sodass ich den Kontext selbst nachtrug. Stille Fehler: Nach Implementierung des Callbacks: Null. Davor (MIME-Crash): Einer. Zeitersparnis, grob geschätzt: E-Mail-Triage hat vorher jeden Morgen 25–35 Minuten gekostet. Jetzt dauert die Durchsicht und das Versenden ca. 7–10 Minuten. Das ergibt rund drei Wochenstunden mehr Zeit.

Ein wichtiger Punkt: Die Routine ist nur so gut, weil der Prompt so detailliert ist. Ich habe eine verkürzte Version getestet – „Triage my email, draft replies, post a Slack summary“ – die hat etwa zu 60 % so gut funktioniert. Vage Prompts produzieren vage Routines. Behandle deinen Prompt wie ein Lastenheft, nicht wie eine Chatnachricht.

Die Entscheidung zwischen Trusted- und Full-Tool-Modus, die Sie nicht umgehen können

Bevor eine Routine mit Ihren Tools interagieren darf, wählen Sie einen von zwei Modi: Trusted oder Full. Dies ist die mit Abstand wichtigste Sicherheitsentscheidung in der gesamten Konfiguration und verdient deutlich mehr Beachtung, als die zwei Absätze, die ihr in der Dokumentation gewidmet werden.

Im Trusted-Modus kann die Routine nur auf Tools zugreifen, die Sie explizit genehmigt haben — Gmail, Slack, Google Drive oder was immer Sie individuell aktiviert haben. Wenn der Prompt Claude anweist, etwas zu tun, wofür ein nicht genehmigtes Tool erforderlich wäre, wird die Routine entweder den Schritt verweigern oder scheitern. Dies ist der Standardmodus. Hier sollten Sie mit jedem Workflow beginnen.

Im Full-Modus kann die Routine auf jedes Tool zugreifen, für das ein Connector in Ihrem Account konfiguriert ist. Falls sie während des Ablaufs entscheidet, dass eine Websuche, das Schreiben einer Datei oder das Abfragen einer neuen API erforderlich ist, tut sie das ohne Rückfrage. Im Full-Modus schalten Sie das höchste Maß an Autonomie frei. Gleichzeitig riskieren Sie aber auch, dass ein unbeaufsichtigter KI-Agent plötzlich die Befugnis erhält, Ihre gesamte Kundenliste zu kontaktieren — weil der Prompt uneindeutig war und das Modell „reach out“ wesentlich weiter gefasst hat, als Sie es beabsichtigt hatten.

Meine Regel nach einer Woche: Bauen Sie jede Routine zuerst im Trusted-Modus, führen Sie mindestens drei Durchläufe aus, prüfen Sie die Tool-Aufrufe, und schalten Sie nur dann auf Full-Modus um, wenn Sie eine ganz konkrete benötigte Fähigkeit benennen können, die im Trusted-Modus nicht verfügbar ist. Jede Routine, die ich aktuell produktiv nutze, läuft im Trusted-Modus. Die eine Routine, die ich testweise im Full-Modus betrieben habe, habe ich wieder gelöscht — sie hat nämlich genau das getan, was einen davor zurückschrecken lässt, je wieder einen unbeaufsichtigten Agenten laufen zu lassen: Sie hat entschieden, dass „Folge bei alten Leads nach“ am besten bedeutet, siebzehn Menschen eine E-Mail zu schicken, mit denen ich seit zwei Jahren nicht mehr gesprochen habe.

Für Prompt-Mehrdeutigkeiten im Full-Modus gibt es keine wirklich gute technische Lösung. Die einzige verlässliche Lösung ist ein präziserer Prompt – und der Betrieb der Routine im Trusted-Modus.

Falls Sie bereits Produktions-Agenten mit dem Agent SDK gebaut haben, kommt Ihnen das meiste hiervon bekannt vor – die gleiche strenge Disziplin bei den Kompetenzgrenzen gilt hier, nur mit weniger Code und auf einer etwas anderen Oberfläche. Für eine detailliertere Analyse dieser Grenzen siehe meinen Walkthrough zum Anthropic Agent SDK.

Was schiefging und was ich neu aufbauen musste

Nicht alles, was ich ausprobiert habe, hat funktioniert. Die beiden Routines, die am stärksten gescheitert sind, sind interessanter als die erfolgreichen – denn ihre Fehlerquellen werden mit hoher Wahrscheinlichkeit auch andere Menschen in ihrer ersten Woche erleben.

Fehler 1: Die PR-Review-Routine, die zu oft ausgelöst wurde.
Ich setzte einen GitHub-Trigger auf ein mittelgroßes Laravel-Repository – bei jedem Pull-Request-Öffnen und jedem Push auf einen offenen PR sollte ein Code Review laufen und als PR-Kommentar abgelegt werden. An einem arbeitsreichen Dienstag habe ich innerhalb von etwa 90 Minuten 11 Commits zu einem einzigen PR gepusht. Die Routine wurde sechsmal ausgelöst und hörte dann ohne Meldung auf. Ich dachte erst, sie sei defekt. Tatsächlich hatte ich das stündliche Limit für GitHub-Webhook-Events pro Routine während des Research Previews erreicht, und die restlichen fünf Events wurden verworfen. Die Dokumentation erwähnt dies in einem einzigen Satz; beim ersten Durchlesen ist es mir entgangen. Meine Lösung: Debouncing des Triggers auf „bei PR-Öffnung“ und „bei PR bereit zur Überprüfung“ statt bei jedem Push. Dadurch reduzierte sich die Auslösefrequenz von sechsmal pro PR auf einmal pro PR, und es gingen keine Events mehr verloren.

Fehler 2: Die wöchentliche Reporting-Routine, die das falsche Zeitfenster zog.
Ich baute eine Routine, die jeden Montag um 8 Uhr morgens meine Stripe-Auszahlungen und Fiverr-Einnahmen für die Vorwoche abruft, den Trend zusammenfasst und in einen privaten Slack-Channel postet. Beim ersten Lauf war die Rückmeldung etwa 40 % zu niedrig. Das Modell interpretierte „letzte Woche“ als „die letzten sieben Tage ab jetzt“ statt „die vorherige Kalenderwoche von Montag bis Sonntag“. Da jede Routine-Ausführung ohne Kontext startet und nicht weiß, was „letzte Woche“ bedeutet, fehlte ein Anker zur Kalibrierung. Die Lösung war eindeutig: „Ziehe die Daten für die Kalenderwoche von Montag [Datum in ISO-8601] bis Sonntag [Datum in ISO-8601]. Nicht die letzten sieben Tage. Die vorherige Kalenderwoche.“ Danach stimmten die Zahlen exakt mit meinem Stripe-Dashboard überein.

Beide Fehler haben eine Gemeinsamkeit: Es waren Fehlschläge durch angenommene Kontextkenntnis. In beiden Fällen hatte ich ein Prompt geschrieben, das für einen menschlichen Kollegen, der meine Arbeitsweise kennt, problemlos funktioniert hätte, für einen neuen Contractor am ersten Tag aber unklar gewesen wäre. Routines haben immer ihren ersten Tag – bei jedem Lauf. Schreib deine Prompts so, als seien sie für einen neuen Mitarbeiter am ersten Tag geschrieben; so verschwinden die meisten dieser Fehler, bevor sie auftreten.

Wer bereits langlaufende agentische Workflows schreibt und dafür eine fundierte Herangehensweise beim Formulieren von Prompts sucht, dem empfehle ich das Framework aus meinem Opus 4.6 Hands-on-Review. Die Prinzipien übertragen sich ohne Weiteres auf 4.7 – mit dem zusätzlichen Vorteil, dass 4.7 mehr Unschärfe toleriert, bevor die Routine aus dem Ruder läuft. „Mehr tolerieren“ heißt jedoch nicht „eliminieren“. Präzise Prompts bleiben das A und O.

Wo Routines noch Schwächen zeigen

Dieser Abschnitt wird in den meisten Artikel zur Launch-Woche übersprungen, daher nehme ich mir hier Zeit dafür. Es gibt vier reale Einschränkungen, auf die ich in der ersten Woche gestoßen bin und die klar benannt werden sollten, weil sie entscheidend sind, was du mit Routines umsetzt – und was nicht.

1. Keine Cross-Run-Memory standardmäßig. Ich habe das oben bereits angesprochen, aber es ist so wichtig, dass es wiederholt werden sollte. Jeder Routine-Run ist eine komplett neue Claude-Code-Session ohne irgendeine Erinnerung an ihre eigene Historie. Der Workaround heißt explizites Kontext-Retrieval – zeige Claude einen Slack-Channel, ein Google Doc, eine Zeile aus einer Datenbank oder einen anderen Ort, an dem er die Ausgabe von gestern einlesen kann, bevor heute weitergearbeitet wird. Das Problem ist lösbar, aber eben manuell. Vergisst du diese Lösung, entstehen im Zweifel drei Tage doppelte Antworten.

2. Mindestintervall eine Stunde. Wenn die eigentliche Arbeit alle fünf Minuten angestoßen werden muss – Statusabfrage-Jobs, Live-Monitoring, Transaktionen im Trader-Takt – dann sind Routines über den Schedule-Trigger nicht geeignet. Der Workaround ist ein Webhook-Trigger durch einen externen Scheduler, aber dann bist du wieder bei Infrastrukturmanagement außerhalb der Routines, was das eigentliche Versprechen konterkariert. Für echte Sub-Stunden-Taktung sind Routines aktuell noch nicht das richtige Werkzeug.

3. Sicherheitskonzept im Full Mode ist noch unreif. Full Mode ist etwa so mächtig wie gefährlich. Es gibt keinen Sandbox-Modus, der einen Full-Mode-Run simuliert, bevor Produktiv-Tools berührt werden. Es gibt kein Cost Cap je Tool, um eine ausufernde Routine daran zu hindern, im Fehlerfall massenhaft Token zu verheizen. Es gibt keinen konfigurierbaren Rate-Limiter pro Connector. Die einzig echte Bremse ist die Qualität deines Prompts plus der Start im Trusted Mode. Profiteams, die Routines im Full Mode gegen echte Kundendaten fahren, sollten eigene Guardrails um die Routine bauen – Approval-Queues, Side-Channel-Auditlogs, Circuit Breaker für Budgetkontrolle.

4. Research Preview – die API kann sich ändern. Alles, was ich in diesem Beitrag schreibe, gilt für den 21. April 2026. Anthropic weist explizit darauf hin, dass Request- und Response-Formate, Rate Limits und Token-Semantik sich während der Research Preview ändern können. Wer jetzt in diesem Monat kritische Infrastruktur auf Routines aufsetzt, muss Zeit für Refactoring in den nächsten sechs Monaten einplanen. Das ist kein Fehler – es ist der ehrliche Kompromiss beim Arbeiten mit einer Research Preview – aber es sollte klar benannt werden, weil ich Teams erlebt habe, die eine Research Preview wie eine stabile API behandelt und dann Tage durch eine unbemerkte Schemaänderung verloren haben.

Keine dieser Einschränkungen ist ein echter Dealbreaker. Aber sie sind alles Dinge, die du wissen solltest, bevor du einem Workflow den Sprung auf Routines ermöglichst und anderen zusicherst, dass alles einfach weiterläuft.

Falls du bisher geplante Automatisierungen lieber mit der Claude-Code-Desktop-App als mit Routines laufen lässt, könnte dir mein Vergleich der beiden Ansätze im Claude CoWork scheduled-tasks guide weiterhelfen – die Benutzeroberflächen wirken zwar ähnlich, aber das Execution-Modell dahinter unterscheidet sich grundlegend. Die Auswahl hängt davon ab, ob die Laufzeit deines Laptops ein Problem ist.

Die fünf Routinen, die ich als Nächstes bauen würde

Wenn ich das Wochenende zurückbekäme und das Maximum aus Routines herausholen wollte, bevor das Limit greift, wäre dies meine Liste, sortiert nach ROI pro Setup-Minute.

1. Morgendliches E-Mail-Triage + Entwürfe. Die Routine, die ich bereits gebaut habe. Wenn du nur eine umsetzen willst, dann diese. Die Zeitersparnis ist unmittelbar und die Fehlerquellen sind begrenzt.

2. Wöchentliches Business-Reporting. Stripe, Fiverr, was auch immer deine Umsatzkanäle sind – jeden Montagmorgen gezogen, als Trend zusammengefasst und in einen privaten Slack-Channel gepostet. Der kumulierte Vorteil ist, dass du aufhörst zu denken: „Ich sollte mal auf die Zahlen schauen“ – die Zahlen kommen zu dir. Für Einzelunternehmer ist das vermutlich noch wertvoller als das E-Mail-Triage.

3. Automatische Lead-Triage mit personalisierten Erstantwort-Entwürfen. Webhook-Trigger vom Kontaktformular deiner Website. Claude zieht die Nachricht, recherchiert das Unternehmen des Absenders über dessen Domain in etwa vierzig Sekunden, verfasst eine Antwort, die sich konkret auf das jeweilige Business bezieht, speichert den Entwurf ab und benachrichtigt dich in Slack. Du siehst es dir an und sendest ab. Die Reaktionszeiten sinken von Stunden auf Minuten, ohne den menschlichen Touch zu verlieren, der Leads abschließt.

4. Tägliches Changelog-Digest für ein öffentliches Repo. GitHub-Trigger bei jedem Merge auf main. Claude zieht das Diff, schreibt einen nutzerorientierten Changelog-Eintrag in deiner eigenen Sprache, ergänzt diesen in der CHANGELOG.md und öffnet einen PR. Du prüfst wöchentlich. Stunden an Dokumentationsarbeit pro Monat werden auf wenige Minuten Review reduziert.

5. Research-Brief für die Meetings am nächsten Tag. Täglicher Trigger um 20 Uhr. Claude liest deinen Kalender für den kommenden Tag aus, zieht die LinkedIn-Headlines der Teilnehmer, deren neueste öffentliche Beiträge und die letzte E-Mail-Konversation mit jedem, erstellt ein einseitiges Briefing pro Meeting und legt sie in ein Google Doc. So gehst du zu jedem Meeting mit mehr Kontext, ohne dafür selbst 30 Minuten aufwenden zu müssen.

Nichts davon sind neuartige Ideen. All das hätte man technisch seit Jahren umsetzen können – mit Cron, einem Sprachmodell und einem API-Wrapper. Der Grund, warum ich keine davon gebaut habe, ist, dass jede einzelne Infrastruktur erfordert hätte, die ich nicht besitzen wollte: einen Server, der den Cron ausführt, einen Wrapper, um das Modell anzusprechen, eine Queue zur Fehlerbehandlung, ein Monitoring, das mich alarmiert, wenn die Queue hängt. Routines reduziert diesen Stack auf eine gespeicherte Konfiguration, die auf fremder Infrastruktur läuft. Das Hindernis beim Go-Live war nie die Idee – das Hindernis war die Yak-Schur.

Das ist das wirklich Neue hier. Nicht die Automatisierung. Das Fehlen der Yak-Schur. Für einen tieferen Einblick, wie das Modell-Ökosystem im April 2026 rund um diesen Launch aussieht, liefert mein April 2026 AI Model Roundup das Gesamtbild zu Kimi K2.6, GPT-5.5 Spud-Gerüchten und zeigt, wo Opus 4.7 im Vergleich zur Konkurrenz bei echten Workloads steht.

Häufig gestellte Fragen

Was sind Claude Routines und wie funktionieren sie?

Claude Routines sind gespeicherte Claude Code-Konfigurationen — bestehend aus einem Prompt, Repositories, Konnektoren und einem Auslöser — die auf der Cloud-Infrastruktur von Anthropic ausgeführt werden, sobald ein Zeitplan, ein API-Aufruf oder ein GitHub-Ereignis ausgelöst wird. Ihr lokaler Rechner muss dafür nicht online sein. Jeder Durchlauf startet eine neue Claude Code-Session ohne Erinnerung an frühere Ausführungen, sofern Sie dem Prompt nicht explizit mitteilen, wo vorheriger Kontext abgerufen werden soll. Eine vollständige Anleitung zur Einrichtung finden Sie oben im Abschnitt „Morning Email Triage“.

Was ist das minimale Intervall für Zeitpläne bei einer Claude Routine?

Eine Stunde. Zeitgesteuerte Auslöser unterstützen vier Voreinstellungen — stündlich, täglich, werktags, wöchentlich — und lehnen jede Cron-Expression ab, die häufiger als einmal pro Stunde ausgeführt wird. Für eine unterstündliche Ausführung verwenden Sie einen Webhook-Auslöser, den ein externer Scheduler anstößt, was allerdings das Problem externer Infrastruktur wieder einführt, das Routines eigentlich lösen sollen.

Ist Opus 4.7 besser als Opus 4.6 für agentisches Arbeiten?

Ja, deutlich. Laut Partner-Benchmarks von Anthropic benötigte Opus 4.7 für vergleichbare Aufgaben 56% weniger Modellaufrufe und 50% weniger Tool-Calls als Opus 4.6, löste etwa dreimal mehr Aufgaben in der Produktion auf Rakutens Coding-Benchmark und sprang beim CursorBench-Ergebnis von 58% auf 70%. Das neue xhigh-Effort-Level ist bei Claude Code voreingestellt für 4.7 und ist die empfohlene Stufe für mehrschrittige, unbeaufsichtigte Arbeitsabläufe.

Was ist xhigh in Claude Opus 4.7?

xhigh ist das neue Top-Level-Effort-Niveau in Opus 4.7 — so ist der Flag-Name in der API und CLI hinterlegt. Es weist interne Ressourcen für tiefergehendes Reasoning und Tool-Erkundungsschleifen zu, bevor das Modell reagiert. Es ist die Standard-Einstellung für Opus 4.7 in Claude Code und wird insbesondere für komplexes Reasoning und agentische Aufgaben empfohlen. Dadurch erhöhen sich die Kosten pro Task durch tiefere Reasoning-Schleifen und einen neuen Tokenizer, rechnen Sie also mit 20% bis 50% höheren Gebühren pro vergleichbarer Aufgabe gegenüber 4.6.

Wie viele Routines kann ich pro Tag mit dem Pro-Plan ausführen?

Fünf Routine-Ausführungen pro Tag mit Claude Pro. Claude Max Nutzer erhalten 15 pro Tag. Team- und Enterprise-Nutzer erhalten 25 pro Tag. Es kann ein Zusatzkontingent hinzugebucht werden, falls Sie mehr benötigen, aber die Limits gelten als Gesamtanzahl pro Account über alle Ihre Routines hinweg, nicht pro Routine — ein Pro-User mit fünf täglich getrennten Routines hat das Limit also bereits erreicht.

Sollte ich für eine neue Routine Trusted- oder Full-Tool-Mode verwenden?

Immer Trusted-Mode für eine neue Routine! Im Trusted-Mode ist Claude nur auf die spezifischen Tools beschränkt, die Sie einzeln für die jeweilige Routine freigegeben haben. Im Full-Mode kann Claude während des Laufs jeden Konnektor in Ihrem Account nutzen — praktisch für besonders anspruchsvolle Workflows, aber auch oft die Ursache, warum unbeaufsichtigte Agenten Dinge erledigen, die Sie gar nicht beabsichtigt hatten. Beginnen Sie im Trusted-Mode, führen Sie drei saubere Durchläufe durch, prüfen Sie die Tool-Calls und wechseln Sie nur dann in den Full-Mode, wenn Sie klar benennen können, welche Fähigkeit im Trusted-Mode unerreichbar bleibt.

Lassen Sie uns zusammenarbeiten

Sie möchten KI-Systeme entwickeln, Workflows automatisieren oder Ihre Tech-Infrastruktur skalieren? Ich unterstütze Sie gerne dabei.

• Fiverr (individuelle Builds & Integrationen): fiverr.com/s/EgxYmWD
• Portfolio: mejba.me
• Ramlit Limited (Enterprise-Lösungen): ramlit.com
• ColorPark (Design & Branding): colorpark.io
• xCyberSecurity (Sicherheitsdienste): xcybersecurity.io