Claude Code dostał rutyny (po angielsku routines) — funkcję, dzięki której agent uruchamia się sam, według harmonogramu, na serwerach Anthropic. Najważniejsza zmiana: twój laptop nie musi być włączony ani nawet otwarty. Wcześniej zadania zaplanowane działały tylko lokalnie, na twojej maszynie. Teraz mogą działać w chmurze, czyli na zdalnych serwerach dostawcy. Anthropic udostępnia tę funkcję na razie w fazie podglądu badawczego (research preview), więc szczegóły mogą się jeszcze zmieniać.
Zacznę od dwóch pojęć. Agent to program oparty na modelu AI, który wykonuje zadanie samodzielnie, krok po kroku — czyta pliki, podejmuje decyzje, sam poprawia błędy po drodze. Claude Code to narzędzie, w którym Claude pracuje przy zadaniach programistycznych i operacyjnych: działa w terminalu lub jako aplikacja, czyta pliki projektu i wykonuje polecenia.
Czym właściwie jest rutyna
Rutyna to jeden zapisany prompt — czyli polecenie, które wydajesz modelowi — konfigurowany raz, a potem uruchamiany automatycznie. Najprościej myśleć o niej tak: to jakbyś wpisał polecenie do Claude Code, a potem ktoś podszedł do twojego komputera i wcisnął „enter” za ciebie — tyle że robi to chmura, o ustalonej porze.
Rutynę da się uruchomić na trzy sposoby:
- według harmonogramu — co godzinę, codziennie, w dni robocze (to odpowiednik dotychczasowych zadań zaplanowanych, tyle że w chmurze);
- przez wywołanie API — inna automatyzacja wysyła żądanie i odpala rutynę (interfejs programistyczny, którym dwa programy „rozmawiają” ze sobą);
- w reakcji na zdarzenie w repozytorium GitHub — na przykład nowy commit, nowe zgłoszenie czy nowe wydanie kodu.
Konfiguracja przypomina zwykłe zadanie zaplanowane: nadajesz nazwę, wpisujesz polecenie dla agenta, wybierasz model, repozytorium i środowisko, ustawiasz częstotliwość. Repozytorium to miejsce, gdzie trzymasz kod projektu — tutaj na platformie GitHub. Minimalny odstęp między uruchomieniami to jedna godzina; nie da się ustawić „co dziesięć minut”.
Dlaczego potrzebne jest repozytorium
To kluczowy mechanizm, więc warto go zrozumieć. Każde uruchomienie rutyny klonuje twoje repozytorium do chmury — robi jego tymczasową kopię. Agent czyta z niej plik CLAUDE.md (instrukcje projektu), skrypty i umiejętności, wykonuje zadanie, a po zakończeniu ta kopia zostaje skasowana. Każdy przebieg jest więc bezstanowy: zaczyna od zera, bez pamięci poprzedniego.
Stąd prosta zasada brzegowa: jeśli coś jest tylko lokalnie na twoim komputerze, albo agent nie sięgnie do tego przez repozytorium lub API — to w rutynie nie zadziała. Nie ma dostępu do twoich plików na dysku ani do danych logowania zapisanych w przeglądarce z wcześniejszych sesji.
Jest jeden wyjątek od kasowania. Jeśli zadaniem rutyny jest zmiana w kodzie albo przegląd kodu, agent nie kasuje wszystkiego — zakłada w repozytorium nową gałąź (branch, równoległą wersję kodu) i tam zapisuje wynik.
Sekret kluczy API: zmienne środowiskowe, nie plik .env
Tu pojawia się pułapka, na którą łatwo wpaść. Klucz API to hasło, którym program loguje się do innej usługi — na przykład do twojego YouTube czy menedżera zadań. W normalnej pracy klucze trzyma się lokalnie w pliku .env, a ten plik świadomie nie trafia do repozytorium (jest na liście wykluczeń). To dobra praktyka bezpieczeństwa: sekretów nie wrzuca się na GitHub.
Skoro jednak rutyna widzi tylko repozytorium, a pliku .env tam nie ma — jak podać jej klucze? Odpowiedź: przez zmienne środowiskowe w ustawieniach środowiska chmurowego danej rutyny. To osobne, prywatne pole; wpisujesz tam klucz do YouTube, do menedżera zadań i co tam jeszcze agent ma użyć.
Zwrócę uwagę na jeden szczegół. Czasem agent z przyzwyczajenia szuka klucza w pliku .env (bo tak działa lokalnie i tak może być opisane w CLAUDE.md) i nie domyśla się sięgnąć do zmiennej środowiskowej. Wtedy w poleceniu trzeba mu to powiedzieć wprost — na przykład: „klucz API jest dostępny jako zmienna środowiskowa, użyj go stamtąd, nie szukaj w .env”. Po takim doprecyzowaniu agent znajduje klucz od razu.
Dostęp do sieci: zaufany czy pełny
W środowisku chmurowym ustawiasz też dostęp do sieci. Domyślnie jest on zaufany: agent łączy się tylko ze sprawdzoną listą usług zweryfikowanych przez Anthropic (między innymi z systemami kontroli wersji i wybranymi platformami chmurowymi). Tryb pełny zdejmuje to ograniczenie — pozwala łączyć się z dowolnym adresem. Jest jeszcze tryb własny, w którym sam wskazujesz dopuszczone domeny, oraz brak dostępu.
Na czym polega ryzyko trybu pełnego? Gdyby agent w trakcie pracy wczytał złośliwą treść, teoretycznie mógłby dać się nakłonić do wysłania danych na zewnętrzny serwer. W trybie zaufanym takie wyjście zostałoby zablokowane. W praktyce, przy prywatnym repozytorium, którego dane wejściowe sam kontrolujesz, ryzyko jest niewielkie — ale warto je znać, zanim świadomie włączysz tryb pełny dla usługi, której nie ma na liście zaufanych.
Pisz polecenia tak, by trafić za pierwszym razem
Rutyna to jednorazowy strzał. Nie ma cię przy komputerze, więc agent nie może się zatrzymać i o coś dopytać — jeśli to zrobi, cała automatyzacja traci sens. Dlatego polecenie musi być na tyle konkretne, żeby agent dał radę wykonać je w całości za pierwszym podejściem.
W praktyce sprawdza się polecenie, które wskazuje gotową umiejętność do uruchomienia i podaje kolejność kroków. Luźne, otwarte sformułowanie typu „przeanalizuj komentarze i daj mi podsumowanie” lepiej zostawić do rozmowy na żywo — chyba że zamykasz je w jasno zdefiniowanej umiejętności. I dobra wiadomość na koniec tej sekcji: nie musisz znać składni cron (technicznego zapisu harmonogramów). Porę uruchomienia ustawiasz zwykłym językiem.
Limity, zasoby i koszty
Liczba uruchomień na dobę zależy od planu. Według tego, co podaje Anthropic: plan Pro daje pięć przebiegów dziennie, plan Max — piętnaście, a plany Team i Enterprise — dwadzieścia pięć. Organizacje z włączonym rozliczeniem nadwyżkowym mogą przekroczyć limit za dopłatą.
Koszt to po prostu twoje zwykłe zużycie w ramach subskrypcji. To ważne: rutyny zużywają tokeny dokładnie tak samo, jak gdybyś rozmawiał z Claude Code na żywo. Token to fragment tekstu, którym operuje model — z grubsza kawałek słowa; każdy przeczytany plik i każda odpowiedź to zużyte tokeny. Dlatego nie warto wrzucać do chmury ogromnego repozytorium z obszernym CLAUDE.md, jeśli do danego zadania potrzebny jest jego ułamek. Często lepiej założyć osobne, małe repozytorium pod konkretną rutynę.
Każdy przebieg w chmurze dostaje określone zasoby: cztery rdzenie procesora (vCPU), 16 GB pamięci RAM i 30 GB miejsca na dysku. To kolejny powód, by nie kopiować do chmury wielkiego projektu bez potrzeby.
Co zostaje, a co znika
Po każdym przebiegu historia uruchomień zostaje zapisana — możesz wejść w daną rutynę i sprawdzić, jak poszło i dlaczego ewentualnie się nie udało. Jeśli agent tworzył gałąź z kodem, trafia ona do twojego repozytorium. Znika natomiast samo środowisko chmurowe wraz ze sklonowaną kopią repozytorium.
Choć każdy przebieg jest bezstanowy, da się skonfigurować rutynę tak, by zostawiała po sobie ślad — krótką notatkę czy zapis postępu w repozytorium. Dzięki temu kolejne uruchomienia mogą stopniowo działać lepiej, mimo że za każdym razem zaczynają od zera.
Zanim uruchomisz na stałe — przetestuj
Najpraktyczniejsza rada: przetestuj rutynę kilka razy, zanim zaczniesz ją odpalać automatycznie co godzinę. Służy do tego przycisk „uruchom teraz”. Wtedy możesz patrzeć, jak agent przechodzi przez kolejne kroki na żywo, w razie potrzeby wtrącić się i naprowadzić go. Chodzi o to, by nabrać pewności, że przy następnym samodzielnym uruchomieniu nie będzie cię już musiał o nic pytać.
Możesz też z góry zabezpieczyć się na wypadek błędu — na przykład dopisać do polecenia, by w razie niepowodzenia agent wysłał ci wiadomość, że coś poszło nie tak. Każdy nieudany przebieg i tak zostaje w historii, więc zawsze sprawdzisz przyczynę.
To, co zyskujesz, to agent działający niezależnie od twojego sprzętu — który czyta instrukcje projektu, korzysta ze swoich skryptów, sam poprawia błędy w trakcie i robi to o ustalonej porze, gdy laptop jest wyłączony. Reszta sprowadza się do trzech rzeczy: konkretne polecenie na jeden strzał, klucze w zmiennych środowiskowych zamiast w pliku .env, oraz kilka testów „na żywo”, zanim oddasz zadanie chmurze na dobre.