Continue, koniec projektu i co dalej

Continue, projekt zamknięty w czerwcu 2026

Continue był jednym z pierwszych szeroko używanych otwartych asystentów kodu. Wtyczka do VS Code i JetBrains, dowolny model do wyboru, pełna kontrola nad tym, dokąd trafia kod. Dla zespołów, które nie mogły wysyłać repozytorium do zewnętrznej usługi, przez dwa lata była to odpowiedź domyślna.

16 czerwca 2026 roku na stronie projektu pojawiło się ogłoszenie o przejęciu zespołu przez Cursora i o wygaszeniu samodzielnego produktu. Ostatnie wydanie wtyczki do VS Code, oznaczone jako 2.1.0, trafiło do rejestrów rozszerzeń 19 czerwca. Repozytorium przeszło w tryb tylko do odczytu, a dane z usługi chmurowej były kasowane po 15 lipca 2026 roku.

Ten tekst opisuje, co z tego wynika w praktyce: co nadal działa, czego już nie ma i czym rozsądnie zastąpić narzędzie w istniejącym środowisku pracy.

Co dokładnie się stało

Przejęcie miało charakter przejęcia zespołu, nie produktu. Twórcy przeszli do firmy stojącej za Cursorem, a rozwijane przez nich narzędzie przestało być rozwijane jako osobny byt.

Warto dodać szerszy kontekst, bo bez niego decyzja wygląda na odosobnioną. Tego samego dnia, 16 czerwca 2026 roku, podpisano umowę, na mocy której SpaceX przejmuje spółkę stojącą za Cursorem w transakcji akcyjnej wycenionej na sześćdziesiąt miliardów dolarów, z zamknięciem planowanym na trzeci kwartał. Rynek narzędzi deweloperskich przechodzi konsolidację, a otwarte projekty bez własnego modelu przychodowego są w niej stroną kupowaną.

Dla użytkownika liczą się trzy daty. Wydania zakończyły się w czerwcu, więc wtyczka nie dostanie już poprawek. Repozytorium jest tylko do odczytu, więc zgłoszenia i propozycje zmian nie zostaną przyjęte. Dane w chmurze usunięto w połowie lipca, więc konfiguracje trzymane po stronie usługi nie istnieją.

Co nadal działa

Kod pozostaje na licencji Apache 2.0 i nikt tego nie cofnie. To licencja permisywna, więc wolno go używać, modyfikować i wdrażać komercyjnie, także po zamknięciu projektu.

W praktyce oznacza to, że zainstalowana wtyczka działa dalej, o ile pracuje w trybie z własnym kluczem albo z modelem lokalnym. Wywołania idą wprost do dostawcy modelu, więc nie zależą od infrastruktury, której już nie ma.

models:
  - name: lokalny
    provider: ollama
    model: qwen2.5-coder:7b
    roles: [chat, edit, autocomplete]

Taka konfiguracja, oparta wyłącznie na Ollamie, nie odwołuje się do żadnej usługi zewnętrznej. Zespół, który tak właśnie korzystał z narzędzia, może zostać przy nim jeszcze długo.

Rozdzielenie ról jest tu istotne, bo uzupełnianie kodu i rozmowa mają zupełnie inne wymagania czasowe. Mniejszy model odpowiada w kilkadziesiąt milisekund, większy może się zastanawiać sekundę.

models:
  - name: uzupelnianie
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles: [autocomplete]
  - name: rozmowa
    provider: ollama
    model: qwen2.5-coder:7b
    roles: [chat, edit]

Wersje warto przypiąć na sztywno, skoro nowe i tak nie powstaną. W rejestrach rozszerzeń wtyczka do edytora zatrzymała się na 2.1.0 z 19 czerwca 2026 roku, a narzędzie wiersza poleceń w rejestrze npm na 1.5.47 z 18 czerwca, mimo że materiały projektu zapowiadają finalną dwójkę dla obu.

npm install -g @continuedev/cli@1.5.47
cn --version

Automatyczne aktualizacje wtyczki w edytorze wyłącz świadomie. Nie dlatego, że przyjdzie zła wersja, tylko dlatego, że nie przyjdzie żadna, a włączony mechanizm aktualizacji tworzy złudzenie, że narzędzie jest pilnowane.

Granica jest jednak wyraźna i warto ją znać przed podjęciem decyzji. Brak wydań znaczy brak poprawek bezpieczeństwa. Zmiana interfejsu wtyczek w edytorze albo w API dostawcy modelu prędzej czy później coś zepsuje, a nikt tego nie naprawi. Utrzymywanie własnej gałęzi kodu jest możliwe, tylko rzadko opłacalne przy narzędziu, które ma darmowe zamienniki.

Co zastąpi to narzędzie

Wybór zależy od tego, który element był powodem sięgnięcia po Continue. Dla większości zespołów były to trzy różne rzeczy i każda prowadzi gdzie indziej.

Przy migracji najwięcej pracy kosztuje zwykle nie sama wtyczka, tylko odtworzenie kontekstu, który zespół przez lata dopisywał: reguły projektu, wskazówki stylu i opisy konwencji. Warto przenieść je do pliku, który rozumie nowe narzędzie, zamiast pisać od nowa.

Drugą rzeczą do przeniesienia są klucze do modeli. Trzymane wcześniej w konfiguracji wtyczki, po zmianie narzędzia powinny wylądować w zmiennych środowiskowych albo w menedżerze sekretów. Przy okazji dobry moment, żeby je zrotować, skoro i tak dotyka się konfiguracji.

Plan wygaszenia krok po kroku

Zespół, który nadal ma to narzędzie w codziennej pracy, potrzebuje planu, a nie ogólnej rekomendacji. Poniższa kolejność ogranicza przestoje.

Zacznij od inwentaryzacji. Sprawdź, kto faktycznie używa wtyczki, w jakich edytorach i z jakimi modelami. Zwykle okazuje się, że część zespołu przeszła już gdzie indziej, a konfiguracje różnią się między osobami bardziej, niż ktokolwiek zakładał.

Drugi krok to zebranie reguł projektu w jedno miejsce. Wszystko, co opisuje konwencje, styl i kontekst repozytorium, przenieś do pliku w repozytorium, niezależnego od narzędzia. Ten plik przeżyje kolejne zmiany asystenta.

# Konwencje projektu

- Komponenty w PascalCase, katalog `src/components`
- Zapytania do API wyłącznie przez `src/api/client.ts`
- Testy obok pliku źródłowego, nazwa `*.test.ts`
- Nie dodajemy komentarzy do generowanego kodu

Trzeci krok to test zamiennika na prawdziwym zadaniu. Wybierz jedną osobę i jedno zadanie o średniej trudności, na przykład refaktor obejmujący kilka plików. Dzień pracy powie więcej niż lista możliwości na stronie producenta.

Czwarty to rotacja kluczy i usunięcie starej konfiguracji. Plik wtyczki zawiera token do dostawcy modelu, więc porzucone środowisko zostawia działający klucz w miejscu, którego nikt już nie pilnuje.

grep -rlE "sk-[A-Za-z0-9_-]{20,}" ~/.continue 2>/dev/null
rm -rf ~/.continue

Pierwsze polecenie wypisuje pliki zawierające coś, co wygląda na klucz, i warto je uruchomić przed skasowaniem katalogu, żeby wiedzieć, które klucze zrotować. Samo usunięcie plików nie unieważnia tokenu, więc bez rotacji po stronie dostawcy nadal działa on wszędzie, gdzie ktoś go wcześniej skopiował.

Piąty to ustalenie terminu odinstalowania. Bez daty w kalendarzu wtyczka bez wsparcia zostaje na stałe, a ryzyko rośnie po cichu.

Cały ten proces zajmuje zwykle tydzień pracy jednej osoby, rozłożony na dwa tygodnie kalendarzowe. Największym kosztem nie jest konfiguracja, tylko przyzwyczajenia: skróty klawiszowe, sposób zadawania pytań i to, czego zespół nauczył się o zachowaniu poprzedniego narzędzia. Warto ten koszt uwzględnić, zamiast zakładać, że wymiana wtyczki jest neutralna.

Lokalny model, czyli powód, dla którego wielu zostaje

Największa grupa użytkowników wybrała to narzędzie z jednego powodu: kod nie wychodził poza maszynę. Ten wymóg nie zniknął razem z projektem, więc warto powiedzieć, jak go dziś spełnić.

Układ jest prosty. Model uruchamiasz lokalnie, a wtyczka odwołuje się do niego przez adres na localhoście. Do uzupełniania kodu bierzesz model mniejszy, rzędu kilku miliardów parametrów, bo liczy się czas odpowiedzi. Do rozmowy i zmian w wielu plikach model większy, jeśli sprzęt pozwala.

Wymagania sprzętowe są tym, co decyduje o sensowności takiego układu. Model siedmiomiliardowy w kwantyzacji czterobitowej mieści się w kilku gigabajtach pamięci i działa płynnie na współczesnym laptopie. Modele rzędu trzydziestu miliardów parametrów wymagają już maszyny z odpowiednią kartą albo komputera z pamięcią zunifikowaną, a różnica w jakości bywa mniejsza, niż sugerują zestawienia.

Uczciwie trzeba dodać, że model lokalny wypada słabiej od najlepszych modeli komercyjnych, zwłaszcza przy zadaniach obejmujących wiele plików naraz. Przy uzupełnianiu kodu i prostych zmianach różnica jest niewielka, przy trudnym refaktorze widoczna. Wybór jest więc kompromisem, a nie zamianą jeden do jednego.

Jak działał, czyli czego szukać w zamienniku

Warto wiedzieć, co dokładnie to narzędzie robiło, bo lista jego możliwości jest dobrą listą kontrolną przy wyborze następcy.

Podstawą były trzy tryby pracy. Rozmowa odpowiadała na pytania o kod bez modyfikowania plików. Tryb planowania pozwalał przejrzeć zmianę przed jej wprowadzeniem. Tryb agenta wprowadzał zmiany w wielu plikach naraz.

Drugim elementem było uzupełnianie kodu w locie, oparte zwykle na mniejszym i szybszym modelu niż ten używany do rozmowy. Ten podział ma znaczenie praktyczne: podpowiedź musi pojawić się w kilkadziesiąt milisekund, a odpowiedź na pytanie może przyjść po sekundzie.

Trzecim była konfiguracja w pliku trzymanym w repozytorium, dzięki czemu zespół pracował na tych samych ustawieniach. Narzędzie, w którym każdy konfiguruje modele u siebie, prowadzi do sytuacji, gdzie ta sama podpowiedź wygląda inaczej u każdej osoby.

Czwartym była obsługa źródeł kontekstu: plików, katalogów, dokumentacji, wyników wyszukiwania. Ten mechanizm decyduje o jakości odpowiedzi bardziej niż wybór modelu, bo model bez właściwego fragmentu kodu zgaduje.

Co ta historia mówi o rynku

Continue nie zniknął dlatego, że był zły. Zniknął dlatego, że otwarty asystent kodu jest trudnym biznesem, a konkurencja ma modele, do których nikt inny nie ma dostępu na tych samych warunkach.

Mechanizm jest powtarzalny. Narzędzie zdobywa użytkowników, bo daje wolność wyboru modelu i działa lokalnie. Utrzymanie kosztuje, więc pojawia się warstwa chmurowa i plan dla zespołów. Ta warstwa konkuruje z produktami firm, które zarabiają na własnym modelu i mogą sprzedawać narzędzie taniej, bo odbijają koszt gdzie indziej. Kończy się przejęciem zespołu.

Wniosek nie brzmi „nie używaj otwartych narzędzi". Brzmi raczej: licz się z tym, że warstwa nakładki jest wymienialna, i buduj proces tak, żeby jej wymiana kosztowała dzień. Kod, konwencje i wiedza zespołu zostają, wtyczki przychodzą i odchodzą.

Warto też zauważyć, że użytkownicy nie stracili możliwości, tylko wygodę jednego opakowania. Modele, edytory i protokoły są te same, a większość funkcji zamkniętego narzędzia da się złożyć z części dostępnych dziś za darmo.

Ta sama zasada dotyczy zresztą warstwy dostępu do modeli w aplikacji, o czym pisaliśmy przy okazji LangChaina. Cienki interfejs, który da się przełączyć, jest tańszy niż migracja po roku pracy na jednym dostawcy.

Lekcja dla wyboru narzędzi

Zamknięcie projektu z tysiącami użytkowników w ciągu tygodnia to przypomnienie, że otwarta licencja zabezpiecza kod, a nie ciągłość rozwoju.

Praktyczny wniosek jest prosty. Przy wyborze narzędzia sprawdź, na czym zarabia. Projekt bez modelu przychodowego, utrzymywany przez firmę finansowaną z rundy inwestycyjnej, jest kandydatem do przejęcia lub wygaszenia, niezależnie od tego, jak dobry jest technicznie.

Drugi wniosek dotyczy uzależnienia od narzędzia. Warstwa, którą łatwo wymienić, to wtyczka do edytora. Warstwy trudne do wymiany to zgromadzony kontekst projektu i przyzwyczajenia zespołu. Trzymanie reguł i konwencji w zwykłych plikach w repozytorium sprawia, że zmiana narzędzia jest kwestią dnia, a nie kwartału.

Trzeci dotyczy modeli. Narzędzie pozwalające podłączyć dowolnego dostawcę chroni przed sytuacją, w której zmiana cennika po drugiej stronie wywraca budżet. Ta sama zasada dotyczy wyboru asystenta co warstwy dostępu do modeli w aplikacji.

Typowe błędy przy migracji

Pierwszy to zostawienie działającej wtyczki bez decyzji. Narzędzie bez poprawek bezpieczeństwa, mające dostęp do repozytorium i kluczy, to ryzyko rosnące z każdym miesiącem. Decyzja o zostaniu przy nim jest w porządku, o ile jest świadoma i ma termin przeglądu.

Drugi to przenoszenie się na narzędzie zamknięte bez sprawdzenia, dokąd trafia kod. Jeśli powodem wyboru Continue była lokalność, zamiennik wysyłający repozytorium do chmury przekreśla cały sens poprzedniej decyzji.

Trzeci to porzucenie zgromadzonych reguł projektu. To najcenniejsza część konfiguracji i jedyna, której nie da się szybko odtworzyć, bo powstawała miesiącami przy okazji zwykłej pracy.

Czwarty to pozostawienie kluczy w starej konfiguracji. Plik wtyczki, której już nie używasz, dalej zawiera token do modelu, a przy okazji porządków warto go usunąć i zrotować.

Piąty to wybór zamiennika na podstawie jednego dnia testów. Asystent kodu ocenia się przez tydzień pracy na prawdziwym projekcie, bo dopiero wtedy widać, jak radzi sobie z kontekstem konkretnego repozytorium.

FAQ

Czy Continue nadal działa?

Zainstalowana wtyczka działa, o ile korzysta z własnego klucza do modelu albo z modelu lokalnego. Nie otrzymuje jednak żadnych poprawek, w tym poprawek bezpieczeństwa, a usługa chmurowa i związane z nią dane zostały usunięte w lipcu 2026 roku.

Czy kod jest nadal otwarty?

Tak, licencja Apache 2.0 pozostaje w mocy i pozwala używać oraz modyfikować kod, także komercyjnie. Repozytorium jest jednak tylko do odczytu, więc rozwój wymagałby utworzenia własnej gałęzi i samodzielnego jej utrzymywania.

Co wybrać zamiast tego?

Jeśli chodziło o lokalność, sięgnij po wtyczkę współpracującą z Ollamą, na przykład Cline albo Roo Code. Jeśli o wygodę i jakość, rozsądnym wyborem jest Cursor albo asystent w wierszu poleceń oparty o Claude.

Czy da się odzyskać dane z usługi?

Nie, dane w chmurze usunięto po 15 lipca 2026 roku. Konfiguracje trzymane lokalnie w plikach repozytorium pozostają nienaruszone i to je warto przenieść do nowego narzędzia.

Dlaczego projekt zamknięto?

Cursor przejął zespół, a samodzielny produkt wygaszono. Kontekstem jest szersza konsolidacja rynku narzędzi deweloperskich, w tym transakcja, w której SpaceX przejmuje spółkę stojącą za Cursorem w umowie akcyjnej o wartości sześćdziesięciu miliardów dolarów.

Szczegóły przejęcia opisał The New Stack, a archiwalny kod pozostaje w repozytorium na GitHubie.