O czym jest ten film
- Z-code to darmowa aplikacja desktopowa do pracy z agentem kodującym, będąca tańszą alternatywą dla Claude Code.
- Działa na otwartowagowym modelu GLM 5.2, którego benchmarki plasują się tuż za flagowymi modelami Anthropic i OpenAI.
- Porównanie kosztów: API GLM jest około sześć razy tańsze niż Opus 4.8 — cały „klon Minecrafta” kosztował autora 1 dolara.
- Instalacja i podłączenie konta ZAI: subskrypcja albo tryb pay-as-you-go z kluczem API.
- Obejście problemu z kluczem API poprzez ręczne dodanie własnego providera (chat completions).
- Konfiguracja środowiska: instalacja Gita i GitHuba wykonana w całości przez agenta.
- Budowa pierwszego projektu (aplikacja z fajerwerkami) w trybie automatycznej edycji.
- Tryby pracy agenta: pytanie o zgodę, automatyczna edycja, planowanie, pełny dostęp.
- Funkcje zaawansowane: równoległe sesje, sterowanie z telefonu, skille, subagenci, serwery MCP.
- Wersjonowanie na GitHubie i darmowe wdrożenie na produkcję przez Vercel.
Redakcyjne tłumaczenie
Czym jest Z-code
Z-code to obecnie jedna z najlepszych alternatyw dla Claude Code, a przy tym znacznie tańsza. Aplikację można pobrać za darmo, a pod spodem działa otwartowagowy model GLM 5.2. Według benchmarków GLM 5.2 wypada tylko nieznacznie gorzej od flagowych modeli Anthropic i OpenAI. W tym materiale pokażę wszystko, co trzeba wiedzieć, żeby zacząć: od instalacji Z-code, przez konfigurację środowiska, aż po zaplanowanie i zbudowanie pierwszego projektu.
Jeśli używałeś kiedyś Claude Code Desktop albo Codeksa, poczujesz się tu jak w domu. To natywna aplikacja desktopowa, w której rozmawiasz z agentem, żeby zbudować to, co chcesz. Z poziomu czatu wywołujesz agentów kodujących z różnych obszarów roboczych i projektów. Dzięki temu łatwo widzisz wszystkie projekty w jednym miejscu i możesz uruchamiać równolegle tyle sesji Z-code, ile potrzebujesz.
To rozwiązanie jest bardzo podobne do Claude Code Desktop — właściwie oparte na tym samym schemacie działania. Masz subskrypcję GLM, która jest sporo tańsza od Claude Code, i na tym podobieństwa się nie kończą.
GLM 5.2 kontra Opus 4.8
Jeśli porównamy specyfikacje Opus 4.8 i GLM 5.2, oba mają okno kontekstu na milion tokenów i maksymalny wynik 128 000 tokenów. Różnica polega na tym, że model chmurowy Anthropic ma wizję — możesz wgrywać obrazy, a model potrafi sterować przeglądarką i wizualnie analizować stronę dzięki możliwościom multimodalnym. W GLM 5.2 tego jeszcze nie ma, choć model potrafi ocenić stronę na podstawie samego kodu HTML.
Oba modele obsługują wywoływanie narzędzi i rozszerzone rozumowanie. Kluczowa różnica: GLM 5.2 to model otwartowagowy. Oznacza to, że jeśli masz odpowiednią infrastrukturę, możesz uruchomić go na własnym sprzęcie.
Druga istotna różnica to cena. Modele GLM są dużo tańsze od chmurowych — mniej więcej sześciokrotnie, licząc po stawkach API. W momencie nagrania Opus 4.8 kosztuje 5 dolarów za milion tokenów wejściowych, a GLM tylko 1,40 dolara. Największa różnica jest jednak po stronie wyjścia: Opus to 25 dolarów za milion tokenów, GLM tylko 4,40 dolara — i naprawdę to czuć. Testując model, poprosiłem go o stworzenie klona Minecrafta, i cała budowa kosztowała mnie tylko 1 dolara. Z Opusem 4.8 byłoby zupełnie inaczej.
Pobranie i instalacja
Żeby używać Z-code, trzeba go pobrać z witryny, do której link znajdziesz w opisie filmu. Chcę być tu jasny: nie jestem sponsorowany ani w żaden sposób powiązany z Z-code. Po prostu sam wypróbowałem to narzędzie, uważam je za naprawdę fajne i warte przetestowania.
Wystarczy pobrać i zainstalować Z-code dla swojego systemu — ja korzystam z Windowsa. Po pierwszym uruchomieniu zobaczysz interfejs bez projektów po lewej stronie. Pierwsze, co trzeba zrobić, to podłączyć konto: klikamy „Connect”, a następnie „Connect to ZAI”. Na tym etapie zostaniesz poproszony o zalogowanie się lub założenie konta.
Subskrypcja czy klucz API
Po zalogowaniu można kliknąć w profil i wybrać „Upgrade”. To usługa płatna — w planie darmowym dostajesz trochę tokenów do zabawy, ale docelowo warto przejść na plan płatny. Możesz zapłacić za subskrypcję albo korzystać z kluczy API, czyli w modelu pay-as-you-go.
Pokażę też drogę przez API, dla tych, którzy na razie chcą płacić za faktyczne zużycie. W „Settings”, w sekcji „Providers”, można spróbować przełączyć się na klucz API — u mnie jednak w momencie nagrania to nie zadziałało. Mimo podania klucza logowanie się nie powiodło, bo aplikacja kierowała do endpointu Anthropic, który po prostu nie działał.
Żeby zdobyć klucz, wejdź na z.ai, zaloguj się, kliknij link „API” w prawym górnym rogu, potem profil i „API keys”. Trzeba jeszcze doładować konto — w zakładce „Billing” można wgrać kredyty. Następnie kopiujesz klucz, dodajesz go do Z-code i klikasz „Test”.
(Informacja dodatkowa: „doładowanie kredytów” oznacza wpłacenie środków z góry, z których potem odliczane jest zużycie tokenów — inaczej niż w subskrypcji z miesięcznym abonamentem.)
U mnie test z kluczem API zwracał błąd. Podejrzewam, że chodziło o bazowy adres URL, którego nie dało się zmienić. Rozwiązałem to, dodając nowego, własnego providera: nazwałem go „GLM Pay-as-you-go”, wpisałem odpowiedni adres bazowy, zmieniłem format API na „chat completions” i wkleiłem klucz. Po tym test przeszedł poprawnie. Jeśli natrafisz na ten sam problem, po prostu skopiuj moje ustawienia połączenia.
Konfiguracja środowiska: Git i GitHub
Zanim cokolwiek zbudujemy, zalecam zainstalować Gita i GitHuba. Jeśli nie jesteś techniczny i nie wiesz, co to znaczy: Git i GitHub służą do kontroli wersji aplikacji. Możemy zrobić migawkę aplikacji w dowolnym momencie, a jeśli coś przypadkiem popsujemy, zawsze wrócimy do tej konkretnej migawki. GitHub pozwala dodatkowo utworzyć zdalną kopię zapasową projektu — gdyby coś stało się z komputerem, nie stracisz kodu.
To krok, który wielu ludzi pomija, a naprawdę warto go wykonać i jest bardzo prosty. Wystarczy wejść na GitHub.com i założyć darmowe konto. Potem w Z-code pozwalamy zrobić wszystko agentowi. Wystarczy poprosić: „Skonfiguruj Git i GitHub na tej maszynie i połącz z moim kontem GitHub”. To wszystko. Agent pobierze i zainstaluje Gita oraz GitHub CLI, a następnie poprosi tylko o uwierzytelnienie w GitHubie.
Pierwszy projekt: aplikacja z fajerwerkami
Tworzę nowy folder „My First Project” i mówię Z-code, co ma zbudować: aplikację webową z fajerwerkami — po kliknięciu w dowolnym miejscu odpala się fajerwerk, który wystrzeliwuje i eksploduje w kolorowe cząstki opadające i gasnące; ciemne tło, żeby kolory były wyraziste; możliwość odpalenia wielu naraz; całość płynna i satysfakcjonująca. Oczywiście możesz zbudować cokolwiek chcesz.
Warto przyjrzeć się opcjom. Można wgrywać pliki, na przykład dokumenty PDF. Można też zmieniać tryby pracy agenta:
- „Ask before changes” — agent zawsze pyta o zgodę przed zmianą plików lub uruchomieniem poleceń.
- „Edit automatically” — agent sam edytuje pliki, ale wciąż pyta o zgodę na niektóre polecenia.
- Tryb planowania — agent nic nie zmienia; to moment na rozmowę i dopracowanie pomysłu.
- „Full access” — agent uruchamia polecenia i edytuje pliki bez zatrzymywania się na akceptację.
Wybieram „Edit automatically”. Następnie wybieramy model: przy subskrypcji można wskazać GLM 5.2 albo GLM 5 Turbo (biorę GLM 5.2), a przy API — model z ustawionego providera. Można też wybrać poziom rozumowania: wyłączyć myślenie albo ustawić „High” lub „Max”. Wybieram „Max” i wysyłam.
Równoległe sesje i wiele projektów
Kiedy Z-code pracuje, po lewej stronie pojawia się folder, a sesja się uruchamia. Gdybyśmy chcieli prowadzić więcej niż jedną sesję na tym samym projekcie, wystarczy kliknąć obok projektu „New task” — na przykład „Opisz projekt” — i mamy dwie sesje działające równolegle na tym samym projekcie. Można też przeskoczyć do zupełnie innego projektu i pracować tam, a nawet odpalić w nim wiele sesji Z-code jednocześnie. Ten interfejs świetnie nadaje się do wielozadaniowości. Niepotrzebne sesje usuwamy przyciskiem archiwizacji.
Ciekawe funkcje: telefon, skille, subagenci
Kilka fajnych rzeczy w Z-code. Po pierwsze, wszystkimi sesjami można sterować zdalnie z telefonu — wystarczy kliknąć odpowiedni przycisk i przejść proces łączenia aplikacji desktopowej z telefonem.
Łatwo dodaje się też skille — po kliknięciu „Skills” widać wszystkie skonfigurowane globalnie na maszynie. Ja uwielbiam używać skilla „Grill me” na etapie planowania. Nowe skille dodajemy przyciskiem „Import skills from external agents” — można je zaimportować z Claude Code lub innych narzędzi. Można też stworzyć nowy skill, co uruchamia skill do tworzenia skilli, i po prostu powiedzieć agentowi, co ma powstać.
(Informacja dodatkowa: „skille” to wielokrotnie używalne zestawy instrukcji i wiedzy dla agenta, definiowane najczęściej jako pliki Markdown, które rozszerzają jego umiejętności w konkretnych zadaniach.)
Podgląd wyniku i zapis na GitHubie
Agent skończył pracę, więc klikam „Open” i widzę aplikację działającą we wbudowanej przeglądarce. Wszystko działa, są nawet efekty dźwiękowe.
Skoro mamy działającą aplikację, robimy migawkę i zapisujemy ją na GitHubie, żeby jej nie stracić. Wystarczy powiedzieć: „Utwórz repozytorium i wypchnij te zmiany”. Jeśli wszystko było poprawnie skonfigurowane, Z-code zapyta o kilka rzeczy — na przykład, czy repozytorium ma być prywatne, czy publiczne. Przy publicznym każdy widzi i może skopiować kod; przy prywatnym dostęp masz tylko ty i twój zespół. Robię to publicznie. Z-code zwraca adres URL, który prowadzi do repozytorium na GitHubie z plikami projektu. Właśnie dlatego konfiguracja Gita i GitHuba jest tak ważna.
Drugi projekt w trybie planowania
Tworzę kolejny folder, tym razem przełączam się w tryb planowania. Przy bardziej złożonych zadaniach, gdzie agent musi coś doprecyzować albo gdy chcesz dopracować pomysł, warto skorzystać z tego trybu. Agent niczego nie zmienia w folderze projektu, ale na końcu tworzy plan wdrożenia.
Proszę o grę typu breakout w przeglądarce: paletka na dole sterowana myszą lub strzałkami, odbijająca się piłka, siatka kolorowych cegieł do zbicia, wynik, życia, kolejne coraz trudniejsze poziomy, jaskrawy neonowy blask na ciemnym tle, „soczyste” wybuchy cząstek przy zbiciu cegły, menu startowe i ekran końca gry.
Ponieważ działamy w trybie planowania, agent zadaje pytania doprecyzowujące — na przykład jak grą ma obsłużyć dźwięk, bo „soczystość” dobrze łączy się z efektami dźwiękowymi, choć to opcjonalne. Odpowiadam na wszystkie pytania.
Subagenci i serwery MCP w ustawieniach
Kiedy agent pracuje, pokażę jeszcze kilka rzeczy. Bardzo podoba mi się, jak Z-code obsługuje skille, subagentów i serwery MCP. Oprócz widoku skilli jest widok subagentów. Konfiguracja subagentów bywa uciążliwa, a tutaj jest banalnie prosta. Na razie mamy dwóch subagentów, ale dodanie nowego to kwestia kliknięcia „New subagent”: nadajesz nazwę (na przykład „code reviewer”), wybierasz kolor i model, wpisujesz opis, przydzielasz uprawnienia i definiujesz prompt systemowy wprost w interfejsie — nie musisz grzebać w plikach Markdown. To bardzo intuicyjne.
(Informacja dodatkowa: „subagenci” to wyspecjalizowani agenci uruchamiani do konkretnych, wąskich zadań — na przykład przeglądu kodu — działający pod kierunkiem agenta głównego.)
Podobnie z serwerami MCP: klikamy „Add”, nadajemy nazwę, wybieramy protokół, ustawiamy polecenia, argumenty i zmienne środowiskowe. Można też przełączyć się na widok JSON i wkleić całą konfigurację. Naprawdę doceniam sposób, w jaki uporządkowano tu ustawienia.
(Informacja dodatkowa: MCP, czyli Model Context Protocol, to standard łączenia modeli z zewnętrznymi narzędziami i źródłami danych.)
Zatwierdzenie planu i implementacja
Agent stworzył plan. Możemy go przeczytać i poprosić o zmiany, jeśli coś nam nie pasuje. Ja ufam agentowi i klikam „Approve plan”, co wyprowadza nas z trybu planowania. Przełączam tryb na „Full access” i mówię: „Zaimplementuj plan”.
W międzyczasie wracam do subagentów i szybko tworzę jednego z promptem: „Twoją rolą jest przegląd kodu projektu, aby zapewnić przestrzeganie dobrych praktyk programistycznych. Napraw wszelkie problemy”. Zapisuję agenta, użyjemy go za chwilę.
Warto też wiedzieć, że przełącznik w interfejsie daje opcje takie jak „Review” — pokazuje wszystkie niezacommitowane lub nieśledzone zmiany. Gdy agent wprowadza zmiany, a mamy skonfigurowane repozytorium Git, wszystkie zmiany plików pojawiają się tutaj. Można też otwierać okna terminala — i to wiele naraz — oraz przełączyć się na widok przeglądarki, żeby zobaczyć aplikację po prawej.
Wynik drugiego projektu i przegląd kodu
Sprawdzam efekt — klikam „Open” i widzę „Neon Breakout”. Klikam „Start game”: grafika wygląda świetnie, gra działa, są ładne efekty cząsteczkowe, a przy zbijaniu cegieł pojawiają się punkty. Wszystko działa i wygląda naprawdę dobrze.
Zanim użyję subagenta, tworzę repozytorium i wypycham projekt — znów publicznie. W repo jest projekt z ładnym plikiem README opisującym funkcje gry.
Żeby użyć subagenta, naciskam ukośnik, co wywołuje listę poleceń, przewijam do sekcji agentów i wybieram „code reviewer”. Proszę go: „Przejrzyj projekt”. Jeśli dopiero zaczynasz z subagentami — to małe wyspecjalizowane agenty, które wykonują konkretne zadania w projekcie. W tym przypadku agent przechodzi przez kod, dba o zgodność z dobrymi praktykami i wprowadza poprawki. Kiedy skończy, prosimy go o wypchnięcie zmian na GitHuba.
Wdrożenie na produkcję przez Vercel
Na razie grę można uruchomić tylko na moim komputerze. Docelowo chcemy wdrożyć ją na produkcję, żeby każdy miał do niej dostęp. Ponieważ kod trafił na GitHuba, jest to banalnie proste i przy okazji darmowe.
Do wdrażania aplikacji webowych lubię Vercel — możesz na nim postawić wszystko, od prostej strony po złożone aplikacje SaaS, całkowicie za darmo. I znów: nie jestem przez nich sponsorowany.
Po zalogowaniu do Vercela klikamy „Add New”, potem „Project”. Zostaniesz poproszony o połączenie z kontem GitHub. Na liście pojawią się wszystkie repozytoria — na przykład aplikacja z fajerwerkami i „Neon Breakout”. Importuję „Neon Breakout”, niczego nie zmieniam na ekranie i klikam „Deploy”. Wdrożenie zajęło jakieś 10 sekund. W zakładce „Domains” dostajemy automatycznie wygenerowaną domenę i teraz każdy, kto ma ten adres, może uruchomić aplikację. Jeśli chcesz przypisać własną domenę, też jest to proste: w „Domains” możesz dodać istniejącą domenę od innego dostawcy albo kupić ją bezpośrednio w Vercelu.
Dajcie znać w komentarzach, co sądzicie o Z-code i modelach GLM. Dzięki za obejrzenie — do zobaczenia w następnym materiale.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Z-code + GLM 5.2 jako tańsza alternatywa dla Claude Code
Na czym polega: Z-code to darmowa aplikacja desktopowa z agentem kodującym, działająca na otwartowagowym GLM 5.2. Interfejs i sposób pracy przypominają Claude Code Desktop, więc próg wejścia jest niski.
Jak stosować: Jeśli już znasz agentów kodujących, pobierz Z-code i przenieś swój dotychczasowy workflow właściwie bez przeuczania się. To dobry wybór do prototypów i mniejszych projektów, gdzie liczy się koszt.
Na co uważać: GLM 5.2 według benchmarków wypada nieco słabiej od flagowców Anthropic i OpenAI, więc przy najbardziej złożonych zadaniach różnica w jakości może być odczuwalna.
2.Realna oszczędność kosztów tokenów
Na czym polega: API GLM jest około sześciokrotnie tańsze od Opus 4.8 — wejście 1,40 zamiast 5 dolarów, wyjście 4,40 zamiast 25 dolarów za milion tokenów. Cały „klon Minecrafta” kosztował autora 1 dolara.
Jak stosować: Do zadań generujących dużo kodu (dużo tokenów wyjściowych) różnica jest największa — właśnie tam GLM daje najwięcej oszczędności. Dobre do intensywnego, iteracyjnego budowania.
Na co uważać: Ceny podano „w momencie nagrania” — zweryfikuj aktualne stawki przed decyzją budżetową. Subskrypcja i pay-as-you-go mają różną opłacalność zależnie od intensywności pracy.
3.GLM 5.2 nie ma jeszcze wizji
Na czym polega: Oba modele mają milion tokenów kontekstu i 128 000 tokenów wyjścia, ale GLM 5.2 nie obsługuje obrazów ani wizualnej analizy stron — ocenia strony tylko na podstawie HTML.
Jak stosować: Jeśli twój workflow nie wymaga wgrywania zrzutów ekranu, sterowania przeglądarką ani analizy makiet graficznych, brak wizji nie przeszkadza.
Na co uważać: Do zadań opartych na obrazach (analiza UI ze screenshotów, praca z projektami graficznymi) GLM 5.2 się nie nada — tu potrzebny jest model multimodalny.
4.Model otwartowagowy można uruchomić lokalnie
Na czym polega: GLM 5.2 jest otwartowagowy, więc mając odpowiednią infrastrukturę, można go uruchomić na własnym sprzęcie.
Jak stosować: Rozważ hosting własny tam, gdzie liczą się prywatność danych, brak zależności od zewnętrznego dostawcy albo przewidywalność kosztów przy dużej skali.
Na co uważać: Wymagania sprzętowe dla modelu tej wielkości są poważne — dla większości użytkowników API lub subskrypcja pozostaną tańsze i prostsze niż własna infrastruktura.
5.Obejście problemu z kluczem API
Na czym polega: Wbudowana ścieżka logowania kluczem API kierowała do endpointu Anthropic i nie działała. Autor rozwiązał to, dodając własnego providera z poprawnym adresem bazowym i formatem „chat completions”.
Jak stosować: Jeśli test klucza API zwraca błąd, nie poddawaj się — dodaj custom provider, ustaw format na „chat completions” i wklej klucz ręcznie.
Na co uważać: To obejście z konkretnego momentu nagrania — bug mógł zostać naprawiony lub adresy endpointów mogły się zmienić. Traktuj to jako wskazówkę diagnostyczną, nie sztywną receptę.
6.Konfigurację Gita i GitHuba zlecasz agentowi
Na czym polega: Zamiast ręcznie instalować Gita i GitHub CLI, wystarczy poprosić agenta: „Skonfiguruj Git i GitHub i połącz z moim kontem” — resztę robi sam, prosząc tylko o uwierzytelnienie.
Jak stosować: To najprostszy sposób, by nawet nietechniczny użytkownik miał kontrolę wersji i zdalną kopię zapasową od pierwszego projektu.
Na co uważać: Nadal musisz najpierw założyć konto na GitHubie i uważnie przejść krok uwierzytelnienia. Nie pomijaj wersjonowania — to zabezpieczenie przed utratą kodu i podstawa późniejszego wdrożenia.
7.Tryby pracy agenta dobierasz do ryzyka
Na czym polega: Z-code oferuje cztery tryby: pytanie o zgodę, automatyczna edycja, planowanie (bez zmian) i pełny dostęp (bez pytań).
Jak stosować: Do prostych zadań wybierz „Edit automatically”; do złożonych zacznij od trybu planowania, żeby dopracować pomysł; „Full access” zostaw na etap implementacji zatwierdzonego planu.
Na co uważać: „Full access” uruchamia polecenia i edytuje pliki bez pytania — używaj go świadomie, najlepiej po zatwierdzeniu planu i przy włączonym wersjonowaniu, na wypadek konieczności cofnięcia zmian.
8.Tryb planowania z pytaniami doprecyzowującymi
Na czym polega: W trybie planowania agent nie zmienia plików, tylko zadaje pytania i tworzy plan wdrożenia, który możesz przeczytać i skorygować przed akceptacją.
Jak stosować: Używaj go przy złożonych funkcjach — pozwól agentowi wypytać cię o szczegóły (np. obsługę dźwięku), zanim napisze choć linię kodu. To ogranicza kosztowne poprawki później.
Na co uważać: Zatwierdzenie planu bez przeczytania przenosi całą odpowiedzialność na agenta. Przy większych projektach warto realnie przejrzeć plan, a nie klikać „Approve” automatycznie.
9.Równoległe sesje, subagenci i MCP z prostą konfiguracją
Na czym polega: Z-code pozwala uruchamiać wiele sesji naraz (także na jednym projekcie), tworzyć subagentów przez formularz z promptem systemowym oraz dodawać serwery MCP z poziomu GUI lub widoku JSON.
Jak stosować: Twórz wyspecjalizowanych subagentów (np. „code reviewer”) do powtarzalnych zadań i uruchamiaj równoległe sesje do multitaskingu między projektami. Konfiguracja nie wymaga grzebania w plikach.
Na co uważać: Wiele równoległych sesji zużywa więcej tokenów jednocześnie — pilnuj kosztów. Subagent do przeglądu kodu jest tak dobry, jak jego prompt, więc formułuj instrukcje precyzyjnie.
10.Darmowe wdrożenie na produkcję przez Vercel
Na czym polega: Skoro kod jest na GitHubie, wdrożenie na Vercel to kilka kliknięć („Add New” → „Project” → połączenie z GitHubem → „Deploy”) i około 10 sekund, po których dostajesz publiczną domenę.
Jak stosować: Użyj tej ścieżki, by szybko udostępnić aplikację webową innym — działa dla prostych stron i bardziej złożonych aplikacji, a darmowy plan wystarczy do prototypów i projektów pobocznych.
Na co uważać: Automatyczna domena Vercela jest publiczna — nie wrzucaj tam wrażliwych danych ani prywatnych projektów bez świadomej decyzji. Publiczne repozytorium na GitHubie oznacza, że każdy może zobaczyć i skopiować twój kod.