Cline, agent kodujący w edytorze z własnym kluczem

Cline, agent kodujący w edytorze z własnym kluczem

Cline to agent programistyczny dostępny jako rozszerzenie edytora, jako program wiersza poleceń i jako biblioteka. Czyta pliki, uruchamia polecenia i wprowadza zmiany w kodzie, pytając o zgodę na kolejne operacje. Repozytorium cline/cline ma około 66,6 tysiąca gwiazdek i licencję Apache 2.0, a za inferencję płacisz z własnego konta u dostawcy modelu.

Co Cline właściwie robi

Cline sam w sobie nie jest modelem. Jest pętlą, która bierze Twoje polecenie, dokłada do niego kontekst z repozytorium, wysyła całość do wybranego modelu, odbiera żądanie użycia narzędzia, wykonuje je i wraca do modelu z wynikiem. Ta pętla kręci się do momentu, w którym model uzna zadanie za zakończone albo Ty ją zatrzymasz. Cała inteligencja siedzi po stronie dostawcy modelu, cała mechanika po stronie Cline.

Narzędzia, którymi agent dysponuje, są konkretne i policzalne. Czytanie plików i katalogów, wyszukiwanie w projekcie, tworzenie i edytowanie plików, uruchamianie poleceń w terminalu, sterowanie przeglądarką oraz wywoływanie narzędzi udostępnianych przez serwery MCP. Każda z tych kategorii ma osobny przełącznik zatwierdzania, do czego wrócę osobno, bo to najważniejsza część konfiguracji.

Narzędzie występuje w trzech postaciach i różnią się one na tyle, że warto od razu wiedzieć, o której mowa. Rozszerzenie do Visual Studio Code jest publikowane pod identyfikatorem saoudrizwan.claude-dev, w wersji 4.1.11 z 21 sierpnia 2026 roku, z około 5,05 miliona instalacji i średnią oceną 4,07 z 311 ocen. Program wiersza poleceń instaluje się z rejestru npm jako pakiet cline i ma wersję 3.0.56. Biblioteka @cline/sdk w wersji 0.0.77 jest aliasem pakietu @cline/core i pozwala osadzić tę samą pętlę we własnej aplikacji. Numeracja jest więc niezależna dla każdej z tych rzeczy i porównywanie wersji rozszerzenia z wersją programu terminalowego nie ma sensu.

Wszystko leży w jednym repozytorium. W katalogu apps znajdziesz podprojekty cli, vscode, cline-hub, vscode-rollout oraz examples, obok nich katalogi sdk, evals i docs. Sam program terminalowy ma pięć zależności produkcyjnych, wszystkie z tej samej rodziny: @cline/sdk, @cline/core, @cline/agents, @cline/llms i @cline/shared.

Instalacja wygląda tak.

# rozszerzenie do Visual Studio Code
code --install-extension saoudrizwan.claude-dev

# program wiersza polecen, globalnie
npm install -g cline

# sprawdzenie wersji i konfiguracji
cline --version
cline config

# diagnostyka, gdy cos nie dziala
cline doctor

# konfiguracja dostawcy modelu i klucza
cline auth

Wersja, licencja i stan projektu

Licencja jest tu prosta i to sama w sobie jest dobrą wiadomością, bo przy agentach kodujących bywa różnie. Plik LICENSE w katalogu głównym repozytorium zawiera pełny tekst Apache License 2.0 z notą praw autorskich Cline Bot Inc. z 2026 roku. Pole license w rejestrze npm dla pakietu cline ma wartość Apache-2.0, tak samo dla @cline/sdk. Interfejs programistyczny GitHuba raportuje dla tego repozytorium apache-2.0. Trzy niezależne źródła zgadzają się co do jednej wartości, nie ma osobnego katalogu z warunkami komercyjnymi ani wyniku NOASSERTION, który wymuszałby dokładniejsze śledztwo.

Apache 2.0 to licencja permisywna z jawnym udzieleniem patentów i z wymogiem zachowania not przy redystrybucji. Wolno używać kodu komercyjnie, modyfikować go i wdrażać wewnątrz firmy bez pytania nikogo o zdanie. Jeśli w organizacji prowadzisz listę licencji zależności, ten wpis nie sprawi kłopotu.

Aktywność projektu jest wysoka. Repozytorium powstało 6 lipca 2024 roku, nie jest zarchiwizowane, ma 7174 rozgałęzienia i 1048 otwartych zgłoszeń, a ostatnia zmiana w gałęzi głównej pochodzi z 21 sierpnia 2026 roku. Wydania stabilne pakietu cline wychodzą mniej więcej co tydzień, wersja 3.0.55 ukazała się 14 sierpnia, a 3.0.56 siedem dni później. Równolegle działa kanał nightly publikowany codziennie, z osobnym znacznikiem w rejestrze npm. Przy takim tempie przypinanie dokładnej wersji w środowisku ciągłej integracji nie jest przesadą, bo zachowanie agenta i domyślne ustawienia potrafią się zmienić między wydaniami mniejszymi.

Za projektem stoi spółka, nie fundacja, i to widać w podziale funkcji. Kod klienta jest otwarty i darmowy dla pojedynczego programisty, natomiast plan Enterprise, wyceniany indywidualnie po kontakcie z działem sprzedaży, dokłada rzeczy, których w wersji otwartej nie ma. Na liście funkcji planu płatnego znajduje się między innymi rozszerzenie do JetBrains, logowanie jednokrotne, centralne rozliczenia, zarządzanie zespołem, kontrola dostępu oparta na rolach, ograniczanie listy dozwolonych dostawców modeli oraz dzienniki uwierzytelnień. Jeśli pracujesz w IntelliJ IDEA albo w PyCharm, to jest informacja, która przesądza sprawę na starcie: darmowa ścieżka prowadzi przez Visual Studio Code albo przez terminal.

Tryby Plan i Act

Podział na dwa tryby jest tym, co najbardziej odróżnia Cline od agentów działających jednym ciągiem. W trybie Plan agent może czytać kod, przeszukiwać projekt i rozmawiać o podejściu, ale nie może modyfikować plików ani uruchamiać poleceń. Ograniczenie wynika z odebrania mu odpowiednich narzędzi, a nie z prośby zawartej w instrukcji systemowej, więc jest realne.

W trybie Act ten sam agent dostaje pełny zestaw narzędzi i wykonuje ustalony plan. Historia rozmowy przechodzi między trybami bez zmian, co oznacza, że po przełączeniu nie trzeba powtarzać ustaleń. Ten szczegół decyduje o użyteczności całego mechanizmu, bo gdyby kontekst przepadał, planowanie byłoby stratą pieniędzy.

Można też przypisać osobny model do każdego trybu. W ustawieniach służy do tego przełącznik opisany jako używanie różnych modeli dla Plan i Act. Sensowny układ to mocniejszy model rozumujący do planowania i tańszy, szybszy do wykonania, bo faza planowania zużywa niewiele tokenów wyjściowych, a faza wykonania generuje ich dużo. Dokumentacja podaje przykładowe pary, między innymi GLM 4.6 do planowania i Grok Code Fast do wykonania w wariancie oszczędnym oraz Claude Opus do planowania i Sonnet do wykonania w wariancie nastawionym na jakość.

Do zadań większych niż jeden plik przydaje się polecenie /deep-planning. Uruchamia dłuższą sesję analizy, w której agent systematycznie przechodzi przez repozytorium, wypisuje pliki i zależności objęte zmianą, buduje szczegółowy plan i zadaje pytania doprecyzowujące, zanim cokolwiek zrobi. Kosztuje to więcej niż zwykły start w trybie Act, ale przy zmianie dotykającej kilkunastu plików zwraca się na pierwszym błędzie, którego agent nie popełni.

W terminalu wygląda to tak.

# tryb planowania, agent nie ruszy plikow
cline --plan "przeanalizuj warstwe autoryzacji i zaproponuj plan migracji"

# jednorazowe zadanie w trybie act, z jawnym modelem
cline --model claude-sonnet-4-5 "napraw failujace testy w katalogu src/auth"

# interfejs terminalowy do dluzszej sesji
cline --tui

# wznowienie wczesniejszej sesji po identyfikatorze
cline --id 01JQ8X5K2M "kontynuuj od miejsca, w ktorym skonczylismy"

# wyjscie w formacie JSON, do potoku
cline --json --timeout 600 "wygeneruj raport pokrycia testami"

Jedna rzecz w tym zestawie zasługuje na uwagę już teraz. Domyślnym trybem programu terminalowego jest Act z włączonym automatycznym zatwierdzaniem wszystkich narzędzi, bo flaga --auto-approve ma wartość domyślną true. Domyślnym dostawcą jest cline, czyli usługa rozliczana kredytami, a nie Twój własny klucz. Oba domyślne ustawienia da się zmienić, ale trzeba o nich wiedzieć przed pierwszym uruchomieniem w prawdziwym repozytorium.

Zatwierdzanie operacji, czyli gdzie jest hamulec

Zgoda sprawdzana jest przy każdym wywołaniu narzędzia. Zanim agent odczyta plik, zapisze zmianę, uruchomi polecenie albo sięgnie do przeglądarki, mechanizm porównuje kategorię operacji z ustawieniami. Struktura tych ustawień w kodzie źródłowym wygląda następująco.

export interface AutoApprovalSettings {
  version: number
  enabled: boolean
  favorites: string[]
  maxRequests: number
  actions: {
    readFiles: boolean
    readFilesExternally?: boolean
    editFiles: boolean
    editFilesExternally?: boolean
    executeSafeCommands?: boolean
    executeAllCommands?: boolean
    useBrowser: boolean
    useMcp: boolean
  }
  enableNotifications: boolean
}

Pola enabled, favorites i maxRequests są oznaczone w kodzie jako pozostałości po starszych wersjach i nie wpływają już na działanie. Dawny limit liczby żądań w jednym zadaniu został usunięty, co znaczy, że nie ma wbudowanego licznika zatrzymującego pętlę po ustalonej liczbie wywołań modelu.

Wartości domyślne z tego samego pliku źródłowego są zaskakująco liberalne. Czytanie plików w projekcie i poza nim jest włączone, edytowanie plików w projekcie i poza nim również, korzystanie z przeglądarki i z serwerów MCP także. Pole executeSafeCommands ma wartość fałsz, ale executeAllCommands ma wartość prawda. Powiadomienia są wyłączone. Dokumentacja w tym samym repozytorium zaleca układ dokładnie odwrotny: włączyć wyłącznie czytanie plików projektu, a edycję, polecenia, przeglądarkę i MCP zostawić wyłączone do czasu, aż pojawi się konkretny powód. Rozbieżność między zaleceniem a domyślnym obiektem w kodzie jest realna i sprawdzenie ustawień przed pierwszym uruchomieniem trwa minutę.

Osobno działa rozróżnienie na polecenia bezpieczne i wymagające zgody. Cline nie ma stałej listy dozwolonych poleceń. To model oznacza każde polecenie flagą requires_approval na podstawie samego polecenia i jego argumentów. Dokumentacja podaje przykłady typowo uznawane za bezpieczne, jak npm run build, git status czy ls -la, oraz typowo wymagające zgody, jak npm install, rm -rf, mv czy sed -i, i wprost zaznacza, że są to przykłady, a nie gwarancje. Ryzyko jest oczywiste: decyzja o tym, co jest bezpieczne, należy do modelu, więc włączenie zatwierdzania poleceń bezpiecznych bez czytania wyniku jest zaufaniem udzielonym klasyfikatorowi, a nie regule.

Twardsze ograniczenie daje zmienna środowiskowa CLINE_COMMAND_PERMISSIONS, która przyjmuje politykę w formacie JSON zawężającą dopuszczalne polecenia powłoki. To mechanizm po stronie Cline, niezależny od oceny modelu, i w środowiskach współdzielonych jest sensowniejszym punktem oparcia niż same przełączniki w interfejsie.

Na drugim końcu skali stoi tryb YOLO, dostępny w ustawieniach w sekcji funkcji. Włączony zatwierdza wszystko: operacje na plikach w dowolnym miejscu systemu, dowolne polecenia w terminalu, akcje przeglądarki, narzędzia MCP oraz przejścia między trybami Plan i Act. Dokumentacja opisuje go jako niebezpieczny i wymienia konsekwencje wprost, łącznie z usunięciem plików, nadpisaniem konfiguracji, instalowaniem pakietów i wypchnięciem zmian do repozytorium zdalnego. To narzędzie do eksperymentów w odizolowanym katalogu, nie do pracy w repozytorium firmowym.

Siatką bezpieczeństwa są punkty kontrolne, czyli migawki stanu obszaru roboczego, do których można wrócić po nieudanej zmianie. Jeśli włączasz automatyczne zatwierdzanie edycji, punkty kontrolne przestają być dodatkiem i stają się warunkiem. Przydaje się też włączenie powiadomień, bo domyślnie wyłączone enableNotifications odpowiada również za sygnał o poleceniu, które działa dłużej niż trzydzieści sekund.

Konfiguracja, reguły i serwery MCP

Konfiguracja rozkłada się na dwa poziomy. Globalny leży w katalogu domowym i obowiązuje wszystkie postaci narzędzia, projektowy leży w repozytorium i podróżuje razem z nim.

~/.cline/
  data/
    settings/
      providers.json           # klucze API i konfiguracja dostawcow
      global-settings.json     # ustawienia globalne
      cline_mcp_settings.json  # konfiguracja serwerow MCP
    sessions/                  # dane sesji
    workflows/                 # globalne przeplywy pracy
  rules/                       # globalne reguly
  hooks/                       # globalne haki
  skills/                      # globalne umiejetnosci
  agents/                      # definicje agentow
  plugins/                     # wtyczki .js i .ts
  cron/                        # harmonogramy

.cline/                        # w katalogu glownym repozytorium
  rules/
  skills/
  hooks/
  agents/
  plugins/
  cron/

Klucze dostawców leżą w zwykłym pliku providers.json w katalogu domowym. To wygodne i jednocześnie warte odnotowania przy pracy na maszynie współdzielonej albo przy kopiowaniu katalogu domowego do obrazu kontenera. Ścieżkę można przenieść zmienną CLINE_DATA_DIR albo flagą --data-dir, co bywa najprostszym sposobem odizolowania konfiguracji służbowej od prywatnej.

Reguły projektowe z katalogu .cline/rules to plik tekstowy dopisywany do instrukcji systemowej, czyli miejsce na konwencje, których agent ma przestrzegać. Warto trzymać je krótkie, bo doklejają się do każdego zapytania i płacisz za nie tokenami przy każdym obrocie pętli. Repozytorium Cline obsługuje też starszy katalog .clinerules oraz plik AGENTS.md, którego sam używa u siebie.

Serwery MCP dodaje się w pliku ~/.cline/mcp.json przy pracy z terminalem albo przez panel MCP Servers w rozszerzeniu. Format jest standardowy dla ekosystemu protokołu.

{
  "mcpServers": {
    "postgres": {
      "command": "node",
      "args": ["/opt/mcp/postgres-server.js"],
      "env": {
        "DATABASE_URL": "postgres://localhost:5432/app"
      },
      "disabled": false,
      "autoApprove": []
    },
    "docs": {
      "url": "https://mcp.example.com/v1/stream",
      "headers": {
        "Authorization": "Bearer ${DOCS_TOKEN}"
      },
      "disabled": false
    }
  }
}

Serwer lokalny opisuje się parą command i args, serwer zdalny polem url. Dostępne są dwa transporty: Streamable HTTP, oznaczony w dokumentacji jako zalecany, oraz SSE opisany jako starszy. Pole autoApprove przyjmuje listę nazw narzędzi zatwierdzanych bez pytania i domyślnie jest puste, co jest rozsądnym ustawieniem. Z poziomu terminala tym samym zarządza kreator uruchamiany poleceniem cline mcp, który pozwala wypisać serwery, dodać nowy, edytować istniejący, włączyć go, wyłączyć albo usunąć.

Skąd bierze się rachunek

To jest punkt, w którym Cline różni się najbardziej od Cursora czy GitHub Copilota. Tam płacisz stałą kwotę miesięczną i dostawca bierze na siebie ryzyko tego, ile faktycznie zużyjesz. Tutaj płacisz za tokeny z własnego konta, więc ryzyko przechodzi na Ciebie, a w zamian dostajesz swobodę wyboru modelu i brak przywiązania do jednego dostawcy.

Mechanizm powstawania rachunku jest prosty i właśnie dlatego potrafi zaskoczyć. Każdy obrót pętli to osobne wywołanie modelu, do którego trafia cała dotychczasowa rozmowa razem z treścią odczytanych plików, wynikami poleceń i opisami dostępnych narzędzi. Zadanie, które zamyka się w dwudziestu obrotach, wysyła kontekst dwadzieścia razy, a kontekst z każdym obrotem rośnie. Koszt nie jest więc proporcjonalny do liczby zmienionych linii, tylko do iloczynu liczby obrotów i średniej wielkości kontekstu.

Dokłada się do tego automatyczne zagęszczanie kontekstu. Gdy rozmowa zbliża się do limitu okna, Cline tworzy podsumowanie całej dotychczasowej historii, podmienia ją na to podsumowanie i pracuje dalej. Dokumentacja zaznacza, że operacja pojawia się jako wywołanie narzędzia i pokazuje swój koszt tak samo jak każde inne zapytanie do modelu. Innymi słowy, samo sprzątanie kontekstu też jest płatne, a w długich zadaniach zdarza się kilka razy.

Trzecim mnożnikiem jest poziom rozumowania. Flaga --thinking przyjmuje wartości none, low, medium, high i xhigh, przy domyślnym medium. Wyższe poziomy generują więcej tokenów rozumowania, które również są rozliczane. Wybór poziomu ma sens przy zadaniu wymagającym analizy, a nie przy przepisaniu importów w jednym pliku.

Praktyczne wnioski są takie. Zaczynaj w trybie Plan tańszym modelem, żeby zawęzić zakres, zanim ruszy właściwa praca. Trzymaj zadania krótkie i zamykaj sesję po skończonym kroku, zamiast prowadzić jedną rozmowę przez cały dzień. Ustaw --timeout i --retries, żeby pętla nie kręciła się w nieskończoność po serii nieudanych prób. Ogranicz reguły projektowe do rzeczy naprawdę potrzebnych.

Alternatywą dla własnych kluczy są dwie usługi samego dostawcy. Pierwsza, opisana jako Cline z rozliczeniem za użycie, działa na kredytach doładowywanych z panelu i daje dostęp do listy modeli bez zakładania kont u każdego dostawcy osobno, z częścią modeli oznaczonych jako darmowe. Druga, ClinePass, to abonament w cenie 9,99 dolara miesięcznie, który obejmuje wybrane otwarte modele kodujące, między innymi z rodzin GLM, Kimi, DeepSeek, MiniMax i Qwen, i według opisu daje od dwóch do pięciu razy większe wykorzystanie tych modeli niż standardowa stawka interfejsu programistycznego. Obie są opcjonalne i obie oznaczają rozliczenie przez pośrednika. Jeśli zależy Ci na pełnej kontroli nad kosztem, zostaje własny klucz u dostawcy albo agregator taki jak OpenRouter, a jeśli na braku rachunku w ogóle, to model uruchomiony lokalnie przez Ollamę.

Cline a alternatywy

Wybór rozstrzyga się na kilku pytaniach. Jeśli chcesz przewidywalnego kosztu miesięcznego i nie masz ochoty patrzeć na zużycie tokenów, abonament w Cursorze albo w Windsurfie będzie spokojniejszy. Jeśli chcesz zostać w swoim edytorze i samodzielnie decydować, który model wykonuje które zadanie, Cline pasuje lepiej niż jedno i drugie. Jeśli szukasz otwartego rozszerzenia z podobną filozofią, Continue jest najbliższym odpowiednikiem, a przy pracy wyłącznie w terminalu i wokół historii zmian sensowniej sprawdza się Aider.

Typowe błędy

Pierwszy to uruchomienie programu terminalowego w prawdziwym repozytorium bez sprawdzenia domyślnych ustawień. Domyślnie działa tryb Act z --auto-approve ustawionym na prawdę, więc agent zacznie zmieniać pliki i uruchamiać polecenia bez pytania. Pierwsze uruchomienie zrób w katalogu, którego nie żal, albo z jawnie ustawionym --auto-approve false.

Drugi to potraktowanie kategorii poleceń bezpiecznych jako gwarancji. Klasyfikacja pochodzi od modelu, który oznacza każde polecenie flagą requires_approval, a nie od stałej listy dozwolonych wzorców. Do twardego ograniczenia służy zmienna CLINE_COMMAND_PERMISSIONS z polityką w formacie JSON.

Trzeci to pomijanie trybu Plan przy zmianach obejmujących wiele plików. Agent, który od razu zaczyna edytować, buduje kontekst po drodze i częściej wybiera złe miejsce. Faza planowania kosztuje niewiele tokenów wyjściowych, a oszczędza całe obroty pętli.

Czwarty to prowadzenie jednej rozmowy przez wiele godzin. Kontekst rośnie, każde kolejne zapytanie jest droższe, a przy limicie okna dochodzi płatna operacja zagęszczania. Zamykaj sesję po skończonym kroku i zaczynaj nową.

Piąty to rozdmuchane reguły projektowe. Plik z regułami dokleja się do każdego zapytania, więc kilkaset linii konwencji zamienia się w stały podatek od każdego obrotu pętli.

Szósty to liczenie na wtyczkę do JetBrains w wersji darmowej. Znajduje się ona na liście funkcji planu Enterprise, wycenianego indywidualnie, więc bez umowy zostaje Visual Studio Code albo terminal.

Siódmy to zostawienie pustego pola autoApprove bez sprawdzenia, co dany serwer MCP faktycznie potrafi. Przełącznik useMcp w ustawieniach zatwierdzania jest domyślnie włączony, a narzędzia serwera zdalnego mogą sięgać do systemów produkcyjnych.

FAQ

Czy Cline jest darmowy?

Sam klient tak. Rozszerzenie, program wiersza poleceń i biblioteka są na licencji Apache 2.0 i nie mają opłat licencyjnych ani opłat za stanowisko. Płacisz wyłącznie za inferencję, czyli za tokeny u wybranego dostawcy modelu. Osobno istnieje plan Enterprise z ceną ustalaną indywidualnie, który dokłada funkcje zespołowe.

Czym różni się tryb Plan od trybu Act?

W trybie Plan agent może czytać kod i przeszukiwać projekt, ale nie ma narzędzi do modyfikowania plików ani do uruchamiania poleceń. W trybie Act dostaje pełny zestaw. Historia rozmowy przechodzi między trybami, więc ustaleń nie trzeba powtarzać, a do każdego trybu można przypisać inny model.

Czy Cline może zrobić coś bez mojej zgody?

Zależy od ustawień, i to jest część, którą trzeba sprawdzić samodzielnie. Zgoda jest weryfikowana przy każdym wywołaniu narzędzia, ale domyślny obiekt ustawień w kodzie ma włączone czytanie i edytowanie plików, przeglądarkę oraz MCP. Tryb YOLO zatwierdza wszystko, łącznie z przejściami między trybami.

Ile kosztuje typowa sesja?

Nie da się podać jednej liczby, bo koszt zależy od modelu, od liczby obrotów pętli i od wielkości kontekstu wysyłanego przy każdym obrocie. Mechanizm jest taki, że rachunek rośnie z długością rozmowy, a nie z liczbą zmienionych linii. Zużycie podglądasz w panelu użycia i u swojego dostawcy.

Czy Cline działa w JetBrains?

Wtyczka do JetBrains figuruje na liście funkcji planu Enterprise. W wersji otwartej dostępne jest rozszerzenie do Visual Studio Code oraz program wiersza poleceń, którego można użyć obok dowolnego edytora, także w trybie zgodnym z protokołem Agent Client Protocol.

Czy dane trafiają na serwery Cline?

Przy własnym kluczu zapytania idą prosto do wybranego dostawcy modelu. Przy korzystaniu z rozliczenia kredytowego albo z abonamentu ClinePass pośredniczy infrastruktura dostawcy narzędzia. Konfiguracja i klucze leżą lokalnie, w katalogu ~/.cline/data/settings.

Dokumentację znajdziesz w serwisie docs.cline.bot, informacje o planach na stronie produktu, a kod źródłowy w repozytorium na GitHubie.