Zeitplan, Browser, Gedächtnis. Was hinter den viralen Claude-Funktionen steckt

Die Liste stammte aus einem Video mit dem Titel „10 neue Claude Funktionen, die kaum einer nutzt“. Solche Listen vermischen gern, was der Hersteller liefert, was andere dazubauen und was jemand im Code gefunden hat. Für eine Entscheidung im Unternehmen ist dieser Unterschied aber zentral. So sieht es mit Stand September 2026 aus:

• Stitch MCP gehört zu Stitch, einem Design-Werkzeug von Google. Über den MCP-Server holen sich Entwicklerwerkzeuge Farben, Schriften und Layouts aus einem Stitch-Projekt. Claude Code kann ihn nutzen, eine Claude-Funktion ist das aber nicht.
• Browser Use ist ein quelloffenes Projekt eines Drittanbieters. Anthropic hat eine eigene Browser-Anbindung, Claude in Chrome. Sie kann Webseiten testen, Formulare ausfüllen und Daten auslesen, und zwar mit den Logins, die im Browser schon offen sind. Das ist bequem und zugleich der Grund, sie nicht unbeaufsichtigt laufen zu lassen.
• AutoDream soll die Notizen aufräumen, die sich Claude Code selbst anlegt. Die offizielle Dokumentation zum Gedächtnis von Claude Code beschreibt CLAUDE.md-Dateien und automatische Notizen, AutoDream kommt dort nicht vor. Wir behandeln es deshalb als unfertig.
• Zeitgesteuerte Aufgaben gibt es wirklich, sogar in drei Varianten. Um die geht es im Rest dieses Beitrags.

Die Dokumentation von Claude Code unterscheidet drei Wege:

1. 1

   /loop in der offenen Sitzung

   Wiederholt eine Anweisung, solange die Sitzung läuft. Gut, um einen Build zu beobachten. Wiederkehrende Aufgaben laufen nach sieben Tagen von selbst aus, und wer das Terminal schließt, beendet sie.

2. 2

   Geplante Aufgaben in der Desktop-App

   Laufen auf dem eigenen Rechner, mit Zugriff auf lokale Dateien. Der Rechner muss dafür an sein.

3. 3

   Routines in der Cloud

   Laufen bei Anthropic, auch wenn der Laptop zu ist. Auslöser sind ein Zeitplan, ein Aufruf per HTTP oder ein Ereignis auf GitHub. Der kürzeste Abstand ist eine Stunde. Routines sind laut Dokumentation eine Forschungsvorschau.

Die Beispiele in der Dokumentation zeigen, wofür das gedacht ist. Ein nächtlicher Durchgang durch neue Tickets mit Zusammenfassung in Slack, ein Code-Review bei jedem neuen Pull Request, ein Abgleich, welche Doku nach einer Änderung veraltet ist. Das sind Aufgaben mit offenem Weg, bei denen gelesen und abgewogen werden muss.

Vier Punkte aus der Dokumentation zu Routines, die für den Betrieb zählen:

• Eine Routine gehört einem einzelnen Konto. Sie wird nicht im Team geteilt, und alles, was sie tut, erscheint unter dem Namen dieser Person. Commits, Slack-Nachrichten, Tickets.
• Sie läuft ohne Rückfragen. Jedes Werkzeug einer eingebundenen Anbindung darf sie nutzen, auch schreibend. Standardmäßig sind alle verbundenen Anbindungen eingebunden.
• Ein grüner Status heißt nur, dass die Sitzung ohne technischen Fehler lief. Ob die Aufgabe erledigt wurde, steht im Protokoll.
• Es gibt eine tägliche Obergrenze an Läufen je Konto, zusätzlich zum normalen Kontingent.

Beides schließt sich nicht aus. Ein fester Workflow kann an genau einer Stelle einen Agenten fragen, etwa um eine Anfrage einzuordnen. Wie man einen Workflow so baut, dass ein Ausfall nicht unbemerkt bleibt, steht in diesem Beitrag.

1. 1

   Herkunft prüfen

   Stammt die Funktion vom Hersteller, steht sie in dessen Dokumentation, und hat sie einen Status wie Beta oder Vorschau? Ein Werkzeug aus einem Video ist noch keine Grundlage für einen Prozess.

2. 2

   Anbindungen eng schneiden

   MCP ist seit Dezember 2025 ein offener Standard unter dem Dach der Linux Foundation und steckt in vielen Werkzeugen. Das macht Anbindungen einfach. Jede Anbindung ist aber ein Zugang. Nur einbinden, was die Aufgabe braucht.

3. 3

   Einen Verantwortlichen benennen

   Eine Routine, die unter dem Namen eines Mitarbeiters läuft, hängt an dessen Konto und Abo. Wird das Abo pausiert, pausiert laut Dokumentation auch die Routine. Wer so etwas im Team nutzt, braucht eine Liste, was wo läuft und wem es gehört.