Ein Report, der jeden Montag um sieben schon fertig auf dem Tisch liegt. Ein Pull Request, der sich selbst überprüft, noch bevor jemand aus dem Team morgens den Rechner hochfährt. Genau dafür sind Claude Routinen gedacht, und der Unterschied zu einem gespeicherten Prompt ist größer, als der Name vermuten lässt.
Symbolbild: Eine Claude Routine läuft weiter, auch wenn der Bildschirm längst dunkel ist. Foto: Rafael Minguet Delgado auf Pexels
Was eine Claude Routine wirklich ist
Der naheliegende Vergleich ist ein Cronjob, aber der greift zu kurz. Ein klassischer Cronjob startet ein Skript zu einer festen Zeit auf einem Server, den jemand betreiben und pflegen muss. Claude baut mit Routinen stattdessen eine vollständige Claude-Code-Sitzung in der Cloud: Sie klont die hinterlegten Repositories, kann Shell-Befehle ausführen, in der Repository committete Skills nutzen und jede eingebundene Verbindung ansteuern, von Slack über Linear bis zum eigenen internen Tool. Anthropic beschreibt das in der offiziellen Dokumentation so: Eine Routine sei “eine gespeicherte Claude-Code-Konfiguration, ein Prompt, ein oder mehrere Repositories und eine Reihe von Verbindungen, einmal zusammengestellt und automatisch ausgeführt”. Der Nebensatz danach ist der eigentlich wichtige Teil: Routinen laufen auf der von Anthropic verwalteten Cloud-Infrastruktur und arbeiten deshalb weiter, wenn dein Laptop zugeklappt ist.
Das trennt Claude Routinen von den lokalen geplanten Aufgaben, die Claude Code seit Längerem beherrscht. Wer in einer offenen Sitzung mit /loop oder einer ähnlichen Anweisung arbeitet, bindet die Ausführung an die laufende Sitzung auf dem eigenen Rechner. Auch die Desktop-App kennt lokale geplante Aufgaben mit Zugriff auf lokale Dateien. Eine Routine dagegen gehört zum claude.ai-Konto, nicht zum Gerät, und ist in dem Sinn eher mit einem Cloud-Dienst als mit einem lokalen Skript vergleichbar. Für Unternehmer ist das der entscheidende Praxisunterschied: Eine lokale Automatisierung fällt aus, sobald jemand den Rechner ausschaltet, den Urlaub antritt oder das WLAN wechselt. Eine Routine nicht.
Die drei Auslöser: Zeitplan, API, GitHub-Ereignis
Eine Routine kann einen einzelnen Auslöser haben oder mehrere gleichzeitig kombinieren. Anthropic unterscheidet drei Typen.
Der Zeitplan-Auslöser ist der einfachste Fall und deckt die meisten wiederkehrenden Bürovorgänge ab: stündlich, täglich, an Werktagen oder wöchentlich, jeweils zu einer festen Uhrzeit in deiner Zeitzone, die automatisch in die UTC-Zeit der Cloud-Infrastruktur umgerechnet wird. Für ein feineres Intervall, etwa alle zwei Stunden oder am Monatsersten, wählst du zunächst die nächstliegende Voreinstellung im Formular und passt danach über den Befehl /schedule update den genauen Cron-Ausdruck an. Kürzer als ein Stunden-Takt lässt Anthropic aktuell nicht zu, engere Ausdrücke werden abgelehnt. Rechne außerdem damit, dass ein Lauf ein paar Minuten nach der eingestellten Uhrzeit startet: Anthropic verteilt die Starts absichtlich über das Zeitfenster. Der Versatz bleibt pro Routine aber konstant, ein Montagsreport ist also jede Woche zur selben Minute fertig. Daneben gibt es eine einmalige Variante: Eine Routine, die nur zu einem bestimmten Zeitpunkt genau einmal feuert, etwa “in zwei Wochen die Test-Kampagne deaktivieren”, danach schaltet sie sich selbst ab.
Der API-Auslöser gibt einer Routine eine eigene HTTP-Adresse. Ein POST-Aufruf mit dem hinterlegten Zugriffstoken startet sofort eine neue Sitzung, egal ob der Aufruf aus einem Monitoring-Tool, einer Deploy-Pipeline oder einem internen Formular kommt. Praktisch heißt das: Eine Überwachung, die einen Fehler-Schwellwert erkennt, kann Claude direkt anstoßen, den Stacktrace zu untersuchen, ihn mit den letzten Commits abzugleichen und einen ersten Korrekturvorschlag als Pull Request zu öffnen, noch bevor jemand aus dem Team überhaupt eine Meldung liest. Der Aufruf darf ein freies Textfeld mitgeben, etwa den Wortlaut des Alarms. Dieser Text erreicht die Sitzung eingepackt in einen Block namens routine-fire-payload, der ihn ausdrücklich als unbestätigte Daten kennzeichnet. Praktisch heißt das: Dein gespeicherter Prompt muss sich aktiv darauf beziehen, etwa mit “untersuche den Alarm im routine-fire-payload-Block”, sonst bleibt der übergebene Text wirkungslos. Dieselbe Verpackung gilt für den Text, den du im Web-Knopf “Run now” mitgibst. Der Grund dafür ist einfach: Wer das Token in die Hände bekommt, kann beliebigen Text schicken, und der soll die Routine nicht fernsteuern können.
Der GitHub-Auslöser reagiert automatisch auf Ereignisse in einem verbundenen Repository. Zwei Ereignisklassen stehen zur Auswahl, Pull Request und Release, jeweils entweder als bestimmte Aktion wie pull_request.opened oder als ganze Klasse. Filter grenzen ein, welche Ereignisse tatsächlich einen Lauf starten, und zwar nach Autor, Titel, Beschreibungstext, Ziel-Branch, Quell-Branch, Labels, Entwurfsstatus und Merge-Status. Jeder Filter kombiniert ein Feld mit einem Operator, von “ist gleich” über “enthält” bis “passt auf regulären Ausdruck”. Bei den regulären Ausdrücken lauert die einzige echte Stolperstelle: Geprüft wird der ganze Feldwert, nicht ein Ausschnitt daraus. Wer jeden Titel mit dem Wort hotfix treffen will, schreibt .*hotfix.*, ohne die Punkt-Stern-Klammern greift der Filter nur bei einem Titel, der exakt hotfix lautet. Für einfaches Suchen nach einem Wortbestandteil ist der Operator “enthält” die bessere Wahl. Eine Regel wie “Ziel-Branch main und Entwurfsstatus falsch” verhindert, dass jeder Zwischenstand sofort eine Routine auslöst.
Zwei Dinge gehören dazu, damit das überhaupt anspringt. Die Claude-GitHub-App muss auf dem Repository installiert sein, /web-setup allein reicht nicht, das erteilt nur das Klon-Recht und schaltet die Webhooks nicht frei. Und solange Routinen Research Preview sind, gelten für eingehende GitHub-Ereignisse stündliche Obergrenzen je Routine und je Konto. Was darüber hinausgeht, wird verworfen, bis das Zeitfenster neu beginnt. Für ein Repository mit hoher PR-Frequenz heißt das: eng filtern, statt auf alle Pull-Request-Aktionen zu hören.
”Routines execute on Anthropic-managed cloud infrastructure, or on your organization’s self-hosted environment when routed there, so they keep working when your laptop is closed.”
Quelle: Claude-Code-Dokumentation, Anthropic, Stand 11. September 2026
Praxisbeispiele, die sich direkt übertragen lassen
Anthropic nennt in der eigenen Dokumentation eine Handvoll Beispiele, die sich fast unverändert auf ein mittelständisches Unternehmen übertragen lassen. Eine Backlog-Pflege läuft jede Nacht gegen das Ticket-System, liest neu eingegangene Anfragen seit dem letzten Lauf, vergibt Labels, ordnet Zuständigkeiten nach dem betroffenen Bereich zu und schickt eine Zusammenfassung in einen Team-Kanal, sodass am Morgen eine aufgeräumte Warteschlange wartet statt eines ungefilterten Eingangskorbs. Eine Alarm-Triage wird von der Überwachung selbst über den API-Auslöser gestartet, sobald ein Fehlerwert eine Schwelle überschreitet, untersucht die Fehlermeldung, gleicht sie mit den letzten Änderungen ab und legt einen fertigen Korrekturvorschlag zur Prüfung an, statt dass der Bereitschaftsdienst bei null anfängt.
Eine Bereitstellungs-Prüfung wird nach jedem Produktions-Deploy von der eigenen Pipeline aufgerufen, führt Funktionstests gegen den neuen Stand aus, durchsucht die Fehlerprotokolle nach Auffälligkeiten und meldet vor Ablauf des Deploy-Fensters eine klare Freigabe- oder Stopp-Empfehlung an den zuständigen Kanal. Eine Dokumentations-Pflege läuft wöchentlich, durchsucht zusammengeführte Änderungen seit dem letzten Lauf, markiert veraltete Dokumentations-Abschnitte und öffnet passende Korrektur-Vorschläge, statt dass Dokumentation stillschweigend hinter dem Code zurückbleibt. Wer wissen will, wie sich einzelne dieser Schritte zusätzlich als wiederverwendbare eigene Claude Skills bauen lassen, kann die Routine direkt darauf aufsetzen, eine Routine kann committete Skills aus dem geklonten Repository genauso nutzen wie eine interaktive Sitzung.
Diese Kolumne selbst ist ein weiteres Beispiel aus erster Hand: Der Artikel, den du gerade liest, ist Teil einer täglichen Redaktions-Routine, die ein Themenplan-Dokument abarbeitet, Fakten gegenprüft, den Text als MDX-Datei anlegt, ein passendes Titelbild recherchiert und den fertigen Beitrag automatisch veröffentlicht, ohne dass jemand den Ablauf manuell antriggert.
Eine Routine in wenigen Minuten einrichten
Der schnellste Einstieg läuft über eine laufende Claude-Code-Sitzung mit dem Befehl /schedule, alternativ /routines. Ein Satz wie “/schedule täglich um 9 Uhr die Pull Requests von gestern zusammenfassen” reicht als Startpunkt, Claude stellt danach Rückfragen zu Repository, genauem Zeitplan und den benötigten Verbindungen und speichert die Routine erst, wenn alles geklärt ist. Für einen einmaligen Lauf funktioniert dieselbe Eingabe in natürlicher Sprache, etwa “/schedule in zwei Wochen einen Aufräum-Pull-Request öffnen, der das Feature-Flag entfernt”, Claude löst die Zeitangabe gegen die aktuelle Uhrzeit auf und bestätigt den genauen Zeitstempel vor dem Speichern.
Wer lieber in der Oberfläche arbeitet, findet unter claude.ai/code/routines das vollständige Formular: Name und Prompt, ein oder mehrere GitHub-Repositories, eine Cloud-Umgebung mit Netzwerkzugriff, Umgebungsvariablen und Setup-Skript, sowie den oder die gewünschten Auslöser. Denselben Weg gibt es inzwischen in der Desktop-App, im Reiter Code über den Eintrag Routinen in der Seitenleiste. Achte dort auf die Auswahl zwischen Cloud und Lokal: Nur Cloud legt eine echte Routine an, Lokal erzeugt eine geplante Aufgabe, die wieder am eigenen Rechner hängt. Alle drei Oberflächen schreiben in dasselbe Konto, eine im Terminal angelegte Routine taucht also sofort im Web und in der Desktop-App auf.
Ein Detail im Formular lohnt einen zweiten Blick: Das Prompt-Feld hat eine eigene Modellauswahl, und das dort gewählte Modell gilt für jeden Lauf. Eine nächtliche Backlog-Sichtung braucht kein Spitzenmodell, eine Code-Prüfung vor dem Deploy schon. Beim Auslöser hat sich seit Sommer etwas verschoben: Ein GitHub-Auslöser lässt sich mittlerweile auch aus der Kommandozeile anhängen, ab Claude Code v2.1.225, etwa mit “/schedule hänge einen GitHub-Auslöser für neue Pull Requests in acme/webapp an meine nächtliche Prüfung”. Der API-Auslöser bleibt der Weboberfläche vorbehalten, weil dort das Zugriffstoken erzeugt und wieder zurückgezogen wird.
Bestehende Routinen lassen sich ebenfalls vom Terminal aus verwalten: /schedule list zeigt alle, /schedule update ändert eine, /schedule run startet sie sofort. Ab Version 2.1.227 kannst du auch nach der Vergangenheit fragen, etwa “warum hat meine nächtliche Prüfung heute früh nichts getan?”. Claude listet dann die letzten Läufe mit Status auf und liest das Protokoll eines Laufs vor, inklusive Werkzeug-Fehlern und abgelehnter Aktionen. Wichtig für den Prompt-Text: Er muss vollständig für sich stehen, weil die Routine ihn beim Start als bereits erteilten Auftrag behandelt und nicht als neue, ungeprüfte Nachricht mitten im Gespräch. Was zur Laufzeit über den API- oder GitHub-Auslöser zusätzlich mitgeliefert wird, etwa der Inhalt eines Alarms, kommt dagegen ausdrücklich als unbestätigter Kontext an und wird nur dann befolgt, wenn der gespeicherte Prompt selbst darauf verweist.
Wem eine Routine gehört und wer sie abschalten kann
Eine Routine gehört zum persönlichen claude.ai-Konto, in dem sie entstanden ist. Kolleginnen und Kollegen sehen sie nicht in ihrer Liste, und jeder Lauf zählt gegen das Tageskontingent dieses einen Kontos. Wichtiger für die Buchführung im Betrieb: Alles, was die Routine anfasst, erscheint unter der Identität dieser Person. Commits und Pull Requests tragen ihren GitHub-Namen, Slack-Nachrichten und Linear-Tickets laufen über ihre verknüpften Konten. Wer später ein Protokoll liest, sieht dort den Namen dieser Person, nicht den eines Dienstkontos. Daraus folgen zwei Dinge für die Praxis. Verlässt jemand das Unternehmen und wird sein Konto deaktiviert, steht seine Routine still und niemand kommt an die Konfiguration. Und eine Routine, die Firmenprozesse abarbeitet, gehört deshalb besser in ein eigenes Konto für genau diesen Zweck als in das Konto der Geschäftsführung.
Auf Team- und Enterprise-Plänen gibt es dafür einen zentralen Schalter. Unter claude.ai/admin-settings/claude-code können Inhaber Routinen für die gesamte Organisation deaktivieren. Steht der Schalter auf aus, stoppen bestehende Routinen und niemand legt neue an. Ab Claude Code v2.1.227 verschwindet dann auch der Befehl /schedule aus der Kommandozeile. Meldet also jemand im Team, der Befehl sei unbekannt, ist diese Einstellung der erste Ort zum Nachsehen. Die zweite häufige Ursache liegt an der Anmeldung: Routinen setzen ein Login mit einem claude.ai-Abo voraus. Wer über einen Console-API-Schlüssel, ein Anthropic-Profil oder eine Cloud-Plattform wie Bedrock, Google Cloud oder Microsoft Foundry angemeldet ist, sieht den Befehl gar nicht erst. Auch eine im Terminal gesetzte Variable ANTHROPIC_API_KEY sticht das Abo-Login und muss vorher raus.
Rechte, Kosten und der Stand als Research Preview
Claude schiebt seine Arbeit in Branches mit dem Präfix claude/, die immer angenommen werden. Weist der Prompt die Routine auf einen anderen Branch, prüft Claude Code den Push vorher und lehnt ihn in drei Fällen ab: wenn der Branch auf GitHub geschützt ist, wenn jemand anderes bereits einen offenen Pull Request aus diesem Branch hat, oder wenn auf dem Branch Commits von einer anderen Person liegen. Diese drei Regeln sind der eigentliche Schutz vor einem überschriebenen Arbeitsstand, und sie greifen auch bei großzügig formuliertem Prompt. Jedes Repository wird bei jedem Lauf frisch geklont, jeweils vom Standard-Branch aus, sofern der Prompt nichts anderes vorgibt. Bei den Verbindungen gilt eine ähnliche Logik: Standardmäßig sind alle verknüpften Werkzeuge in einer neuen Routine bereits aktiviert, jedes davon kann während eines Laufs ohne Rückfrage lesen und schreiben. Wer eine Routine nur für die Backlog-Pflege in einem Ticket-System braucht, sollte alle anderen Verbindungen wieder entfernen, statt sie aus Bequemlichkeit aktiviert zu lassen.
Die zweite Stellschraube ist die Umgebung. Jede Routine läuft in einer Cloud-Umgebung, die Netzwerkzugriff, Umgebungsvariablen und ein Setup-Skript festlegt. Die mitgelieferte Umgebung “Default” steht auf der Stufe Trusted und lässt nur eine feste Liste durch: Paket-Registries, Cloud-Anbieter-APIs, Container-Registries und übliche Entwickler-Domains. Jeder Aufruf an eine andere Adresse scheitert mit HTTP 403 und dem Hinweis host_not_allowed im Antwort-Header. Das ist in der Praxis der häufigste Grund für eine Routine, die grün durchläuft und trotzdem nichts erreicht hat. Braucht deine Routine eigene Dienste oder eine Domain außerhalb dieser Liste, stellst du den Netzwerkzugriff der Umgebung auf Custom und trägst sie nach, mit dem Haken für die Standardliste, wenn du die Paketquellen behalten willst. Verbindungen brauchen diesen Eintrag nicht, ihr Verkehr läuft ohnehin über die Server von Anthropic. Ein Punkt wird dabei leicht übersehen: Umgebungsvariablen sind für jeden sichtbar, der dieselbe Umgebung benutzt. Zugangsschlüssel für APIs, die Claude während eines Laufs aufruft, gehören auf Pro und Max deshalb in die dafür vorgesehenen API-Zugangsdaten der Umgebung.
Kostenseitig zieht eine Routine dasselbe Nutzungskontingent wie eine normale Sitzung, zusätzlich gilt ein Tageslimit an Routine-Starts je Konto, das sich im selben Bereich der Web-Oberfläche einsehen lässt wie die Routinen selbst. Ist das Limit erreicht, laufen weitere Starts nur mit aktiviertem Nutzungs-Guthaben weiter, Teams und Unternehmen schalten das zentral über die Verwaltungseinstellungen frei. Einmalige Routinen zählen ausdrücklich nicht gegen dieses Tageslimit, sie verbrauchen nur das reguläre Abo-Kontingent wie jede andere Sitzung.
Wichtig für die Planung: Anthropic kennzeichnet Routinen ausdrücklich als Research Preview, Verhalten, Limits und die programmierbare Schnittstelle können sich noch ändern. Der Endpunkt für den API-Auslöser läuft unter dem experimentellen Beta-Header experimental-cc-routine-2026-04-01. Anthropic bringt Änderungen mit Folgen für bestehende Aufrufe unter einem neuen, datierten Header heraus und hält die beiden zuletzt gültigen Versionen weiter am Leben, du hast für eine Umstellung also Zeit, musst sie aber einplanen. Für die ersten produktiven Routinen bedeutet das: Mit unkritischen, gut überprüfbaren Aufgaben anfangen, etwa einer Zusammenfassung oder einer Vorprüfung mit anschließender menschlicher Freigabe, und erst mit wachsendem Vertrauen mehr Verantwortung an die Routine übergeben. Wer sich noch nicht sicher ist, wie Verbindungen zu Firmensystemen grundsätzlich funktionieren, sollte diesen Schritt vor der ersten Routine klären, weil Routinen genau auf denselben Verbindungen aufsetzen. Für einen strukturierten Einstieg ins Thema insgesamt lohnt sich außerdem ein Blick in unseren 30-Tage-Rollout-Plan, Routinen lassen sich dort als eigener Baustein in Woche drei oder vier einplanen, nachdem Team und Rechte einmal sauber stehen. Wer den größeren Rahmen sucht, in dem solche Läufe stehen, findet ihn in unserer Übersicht zur KI-Automatisierung.
Der konkrete nächste Schritt für diese Woche: Nimm eine einzige Aufgabe, die heute jemand an einem festen Wochentag von Hand anstößt, lege sie mit /schedule als Routine an, entferne im Formular alle Verbindungen bis auf die eine, die sie wirklich braucht, und lies am Tag darauf das Transkript des ersten Laufs.
Häufige Fragen
Kostet eine Claude Routine zusätzlich zum normalen Abo?
Nein, eine eigene Gebühr gibt es nicht. Routinen ziehen dasselbe Nutzungskontingent wie ein normaler Chat oder eine interaktive Claude-Code-Sitzung, zusätzlich gilt ein Tageslimit an Routine-Starts pro Konto. Ist das Tageslimit erreicht, laufen weitere Starts nur noch, wenn dein Team im Abo Nutzungs-Guthaben aktiviert hat, sonst werden sie bis zum nächsten Zeitfenster zurückgestellt. Einmalige Routinen, die nur zu einem bestimmten Zeitpunkt einmal feuern, zählen nicht gegen dieses Tageslimit.
Läuft eine Claude Routine auch, wenn mein Rechner aus ist?
Ja, genau das ist der Kernunterschied zu einer lokal laufenden Automatisierung. Eine Routine ist eine gespeicherte Konfiguration aus Prompt, Repository und Verbindungen, die auf der Cloud-Infrastruktur von Anthropic ausgeführt wird. Ob dein Laptop läuft, im Standby ist oder du im Urlaub bist, ändert nichts am geplanten Lauf.
Kann eine Routine versehentlich Schaden anrichten, weil niemand die Aktionen freigibt?
Das Risiko ist real und der Grund, warum die Rechte-Konfiguration vor dem ersten Lauf wichtig ist. Eine Routine läuft ohne Rückfragen und ohne Freigabe-Dialog durch, sie kann also jede Aktion ausführen, die ihre Repositories, Umgebung und Verbindungen erlauben. Anthropic begrenzt das serienmäßig, Claude darf standardmäßig nur in eigens angelegte Branches schreiben, nicht direkt in bestehende. Zusätzlich solltest du jeder Routine nur die Verbindungen mitgeben, die sie für ihre Aufgabe tatsächlich braucht, und nicht automatisch alle verknüpften Tools.
Braucht mein Team Entwickler, um eine erste Claude Routine einzurichten?
Für den Einstieg nicht zwingend. Der schnellste Weg ist der Befehl /schedule in einer laufenden Claude-Code-Sitzung, dort beschreibst du in einem Satz, was wiederkehrend passieren soll, und Claude stellt Rückfragen zu Zeitplan, Repository und Prompt, bevor es die Routine speichert. Seit Claude Code v2.1.225 lässt sich auch ein GitHub-Auslöser über die Kommandozeile anhängen. Nur der API-Auslöser braucht weiterhin die Weboberfläche, weil dort das Zugriffstoken erzeugt wird.
Wem gehört eine Claude Routine im Unternehmen?
Dem persönlichen claude.ai-Konto, in dem sie angelegt wurde. Teammitglieder sehen sie nicht in ihrer Liste, und die Läufe zählen gegen das Tageskontingent dieses einen Kontos. Alles, was die Routine tut, erscheint außerdem unter der Identität dieser Person: Commits und Pull Requests tragen ihren GitHub-Namen, Slack-Nachrichten und Linear-Tickets laufen über ihre verknüpften Konten. Für wiederkehrende Firmenprozesse ist deshalb ein eigenes Konto für genau diesen Zweck die sauberere Lösung als die Routine im Konto der Geschäftsführung.
Warum läuft meine Routine grün durch, ohne etwas zu erledigen?
Der grüne Status meldet nur, dass die Sitzung gestartet und ohne Infrastruktur-Fehler geendet hat. Über das inhaltliche Ergebnis sagt er nichts. Die häufigste Ursache steckt im Netzwerkzugriff: Die Standard-Umgebung steht auf der Stufe Trusted und lässt nur eine feste Liste von Domains durch, alle anderen Aufrufe scheitern mit HTTP 403 und dem Hinweis host_not_allowed. Das steht im Protokoll des Laufs, nicht im Statuspunkt. Öffne den Lauf als Sitzung und lies das Transkript, dort stehen auch fehlende Verbindungs-Werkzeuge und abgebrochene Aufgaben.
Quellen & Referenzen
- Anthropic: Offizielle Dokumentation zu Claude-Code-Routinen, Einrichtung, Auslöser-Typen, Rechte und Nutzungslimits. code.claude.com
- Anthropic: Ankündigungs-Beitrag zur Einführung von Routinen in Claude Code. claude.com
- InfoQ: Einordnung der Routinen-Funktion und ihrer Auslöser-Typen im Entwickler-Kontext. infoq.com
- Anthropic: Dokumentation der Cloud-Umgebungen mit Netzwerkstufen, Standard-Domainliste, API-Zugangsdaten und Setup-Skript-Caching. code.claude.com
- Anthropic: Referenz zum Auslösen einer Routine per API, inklusive Beta-Header, Fehlerantworten und Feldgrenzen. platform.claude.com
- Anthropic: Abgrenzung der lokalen geplanten Aufgaben in der Desktop-App gegenüber Cloud-Routinen. code.claude.com
