O czym jest ten film
- Premiera modelu Kimi K3, który według benchmarków dorównuje topowym modelom, a jest znacznie tańszy.
- Instalacja i konfiguracja narzędzia Kimi Code (CLI) oraz logowanie przez subskrypcję lub klucz API.
- Wybór modelu i poziomu „reasoning effort” (autor pracuje na max).
- Prosty test sprawności: zbudowanie działającego Tetrisa w Pythonie.
- Metodyka RAMP jako uporządkowany, agentowy workflow kodowania.
- Ustawianie reguł agenta w pliku
agents.md(zwięzłość, pytania doprecyzowujące, obowiązkowe testowanie, system projektowy). - Rozszerzanie agenta o skille i serwery MCP (Playwright do testów, Hostinger do wdrożeń).
- Tryb planowania i tworzenie szczegółowego planu wdrożenia przed pisaniem kodu.
- Funkcja „swarm” (podagenci pracujący równolegle) — i ostrzeżenie, że zużywa dużo tokenów.
- Wdrożenie gotowej aplikacji na publiczny adres przez serwer MCP Hostingera.
Redakcyjne tłumaczenie
Czym jest Kimi K3 i dlaczego wzbudza zainteresowanie
Właśnie ukazał się Kimi K3, a według benchmarków plasuje się na poziomie topowych modeli, takich jak Fable 5 czy GPT-5.6. W tym materiale użyję Kimi K3 wraz z narzędziem Kimi Code, by zbudować i wdrożyć prawdziwą aplikację, korzystając z realnego, agentowego workflow kodowania.
Do Kimi K3 można dotrzeć na kilka sposobów. Pierwszy to strona internetowa, ale ta nie nadaje się najlepiej do zadań agentowego kodowania. Jeśli chcesz budować aplikacje, sięgnij raczej po aplikację desktopową albo narzędzie CLI. Na samej stronie znajdziemy jednak parę efektownych przykładów: symulator czarnej dziury, ładną stronę z fizyką i animacjami oraz aplikację do śledzenia satelitów, pokazującą rzeczywiste pozycje obiektów na orbicie. Robi to wrażenie.
Ale jak ten model wypada na tle konkurencji? Według serwisu Artificial Analysis Kimi K3 depcze po piętach GPT-5.6 i Fable 5 pod względem inteligencji. W ogólnym indeksie inteligencji zajmuje obecnie trzecie miejsce, wyprzedzając Opus 4.8 na trybie Max — co samo w sobie brzmi nieprawdopodobnie.
(Informacja dodatkowa: przywoływane tu nazwy modeli i pozycje w rankingach pochodzą z narracji autora z lipca 2026 r.; zestawienia benchmarkowe szybko się dezaktualizują.)
Prawdziwym powodem popularności tego modelu jest jednak jego cena. Na wykresie rocznych kosztów widać, że jest tańszy od GPT-5.6 i kosztuje mniej więcej jedną trzecią tego, co Fable 5. Jeśli więc szukasz tańszej alternatywy dla modeli pokroju Fable, to może być najlepszy wybór — ale sprawdzimy to w praktyce.
Instalacja Kimi Code
Kimi K3 można uruchamiać na wiele sposobów — w Cursorze, w OpenCode i innych narzędziach. Ja jednak chcę trzymać się rozwiązania natywnego, żeby dać modelowi najlepsze możliwe warunki. Można zainstalować Kimi Code (narzędzie CLI) albo rozszerzenia do VS Code czy Cursora. Wybieram CLI: wystarczy wskazać swój system operacyjny, skopiować podaną komendę, otworzyć PowerShell (lub inny terminal) i ją uruchomić. To pobierze i zainstaluje Kimi Code.
Potrzebne jest też konto Kimi lub klucz API. Wchodząc na stronę i przechodząc do sekcji uaktualnienia, można wybrać plan. Osobiście subskrybuję plan za około 20 dolarów miesięcznie. Można też użyć klucza API, co oznacza płatność za faktyczne zużycie — model „pay as you go”. Szczerze jednak: przy tego typu usługach niemal zawsze lepiej wyjść na subskrypcji, bo subskrypcje są mocno dotowane i wychodzą taniej niż płacenie za tokeny.
Po instalacji trzeba zrestartować terminal. Następnie uruchamiamy komendę kimi. Na starcie nie będziemy jeszcze zalogowani, więc logujemy się komendą /login — do wyboru jest logowanie subskrypcją albo kluczem API. Wybieram subskrypcję; otwiera się strona Kimi, gdzie uwierzytelniamy konto. Po zalogowaniu wpisuję „hej” i przy poprawnej konfiguracji dostajemy odpowiedź.
Domyślnie działam na modelu Kimi K2.7, a nie o to mi chodzi. Model zmieniam komendą /model, wybierając z listy Kimi K3. Strzałkami lewo–prawo ustawiam poziom rozumowania („reasoning effort”) — wybieram max. Poziom można później zmienić komendą /effort.
Pierwszy test — Tetris w Pythonie
Nie lubię gapić się w sam terminal, więc otwieram VS Code (może być Cursor lub inny edytor). Wystarczy otworzyć pusty folder projektu, a następnie przez menu Terminal otworzyć nowe okno terminala i uruchomić komendę kimi. Zaletą pracy w edytorze jest to, że po lewej stronie widzę wszystkie pliki tworzone przez agenta. Dodatkowo inicjuję repozytorium Git, żeby od razu śledzić zmiany.
Pierwszy prompt brzmi: „Proszę, stwórz grę Tetris działającą w Pythonie”. Agent poświęcił kilka minut na rozumowanie, po czym poprosił o zgodę na wprowadzenie zmian — zatwierdzam je na tę sesję. Tryby zatwierdzania można zmienić komendą /permission; wybieram „yolo”, żeby agent nie pytał o zgodę za każdym razem.
Po lewej stronie widać utworzony plik Tetrisa. Nie podoba mi się, że cały kod trafił do jednego pliku — czystsza byłaby struktura modułowa — ale być może dla większości osób to wystarczy. Sprawdzam, czy agent sam uruchomi grę: „Proszę, uruchom grę”. Potrafi wykonać komendę i grę uruchamia. Klawisze działają, można przyspieszać, obracać klocki, a gdy ułożę linię — bloki znikają. Logika gry faktycznie działa. Jestem pod wrażeniem.
Przejście do prawdziwego workflow: framework RAMP
Zatrzymuję sesję (Escape), kasuję pliki projektu i uruchamiam nową sesję komendą /new, żeby zwolnić okno kontekstu. Teraz zbudujemy coś znacznie bardziej złożonego, prowadząc agenta przez realny, agentowy workflow kodowania oparty na frameworku RAMP.
(Informacja dodatkowa: RAMP to autorska metodyka Leona van Zyla — kolejne litery odpowiadają etapom: ustawienie reguł i środowiska, rozszerzenie agenta o narzędzia, zmapowanie planu i implementacja z weryfikacją.)
Framework pokazuje, jak skutecznie pracować z agentami kodującymi: ustawiamy środowisko i reguły, których agent ma przestrzegać, rozszerzamy go o serwery MCP i skille, tworzymy szczegółowy plan wdrożenia i realizujemy całą aplikację.
Reguły agenta — plik agents.md
Pierwszy krok to ustawienie reguł. Cały mechanizm sprowadza się do pliku agents.md. Domyślnie tworzony jest wprawdzie plik wstępnie wypełniony regułami, ale to niepotrzebne — wystarczy sam plik agents.md, do którego dopisujemy własne reguły. Cokolwiek tam dodasz, agent będzie tego przestrzegał.
Dla przykładu: dopisuję „zawsze odpowiadaj jak pirat” i po rozpoczęciu nowej rozmowy agent faktycznie zaczyna mówić jak pirat. Jeśli więc chcesz nakierować agenta albo łapiesz się na powtarzaniu mu wciąż tych samych poleceń — po prostu zapisz je w tym pliku.
Dodajmy coś praktyczniejszego. W regułach zapisuję, że:
- Odpowiedzi mają być zwięzłe i na temat — nie chcę, żeby agent bez potrzeby przepalał tokeny.
- W trybie planowania agent ma zawsze zadawać pytania doprecyzowujące i nigdy nie zakładać z góry designu, treści ani funkcji.
- Testowanie: agent ma korzystać z dostępnych narzędzi, by testować swoją pracę, i nigdy nie zakładać, że coś po prostu działa — zawsze ma to sprawdzić.
- Design UI: agent ma zawsze trzymać się przyjętego systemu projektowego.
Przy okazji ważna uwaga: nie musisz instalować każdego skilla, jaki krąży po sieci. Naucz się dodawać własne prompty, ustawiać własne reguły i budować własne skille. W kwestii systemu projektowego lubię tworzyć plik design.md — jeśli budujesz aplikację webową, wpisujesz tam typografię, kolory, obramowania i inne zasady, a agent będzie ich przestrzegał przy tworzeniu stron i komponentów. W tym projekcie nie wdrażam systemu projektowego, ale warto o tym wspomnieć.
Rozszerzanie agenta: skille i serwery MCP
Kolejny krok to rozszerzenie agenta o dodatkowe możliwości — zwykle na dwa sposoby: przez skille albo serwery MCP.
Skille to po prostu bardzo szczegółowe prompty, według których agent wykonuje określoną pracę lub konsekwentnie realizuje pewne workflow. Moja szczera rada: wiele osób z jakiegoś powodu uwielbia skille, a często są to zaledwie cztery linijki tekstu — a to samo osiągniesz, prosząc nowoczesnego agenta, by zadawał ci pytania doprecyzowujące. Skille są naprawdę przydatne wtedy, gdy przypisujesz agentowi dokumenty referencyjne albo złożone workflow.
Moja wskazówka: pomyśl o swoim stacku technologicznym i sprawdź, czy istnieje skill związany właśnie z nim. Jeśli projekt używa Next.js, poszukaj dokumentu z najlepszymi praktykami Next.js — zwłaszcza skilla stworzonego przez oficjalnego dostawcę (w tym wypadku Vercel) — i przypisz go agentowi. To nie jest bezużyteczny prompt, lecz zbiór szczegółowych wytycznych i dokumentacji od twórców. Podobnie, jeśli używasz Clerk do uwierzytelniania — zainstaluj oficjalny skill Clerka z kompletem dokumentów referencyjnych.
W naszym projekcie skill nie jest potrzebny, ale zainstaluję kilka serwerów MCP. Pierwszy to Playwright MCP — pozwoli agentowi otworzyć przeglądarkę i wizualnie przetestować aplikację end-to-end. Wystarczy skopiować adres URL i poprosić Kimi: „Proszę, zainstaluj ten serwer MCP w tym projekcie, żebyś mógł z niego korzystać”. To utworzy folder .kimi z plikiem mcp.json zawierającym całą konfigurację MCP.
Ponieważ buduję aplikację webową, którą chcę wdrożyć pod prawdziwą domeną, instaluję też serwer MCP do wdrożeń. Korzystam z Hostingera, bo jest prosty w obsłudze i oferuje serwer MCP, dzięki któremu agent samodzielnie wdraża i zarządza moimi stronami. Loguję się do Hostingera, przechodzę do sekcji API, ręcznie konfiguruję uprawnienia (m.in. strony i domeny — dzięki temu agent może też rejestrować domeny), kopiuję konfigurację i proszę agenta, by ją dodał.
(Informacja dodatkowa: autor zaznacza, że współpracuje z Hostingerem przy tym materiale i oferuje kod rabatowy — to fragment sponsorowany.)
Etap „Map” — planowanie w trybie planning
Rozpoczynam nową sesję, żeby wyczyścić kontekst; przy okazji łączą się wszystkie narzędzia MCP. Wchodzimy w trzeci krok RAMP — mapowanie. To moment, w którym omawiamy projekt z agentem, aby na końcu otrzymać szczegółowy plan wdrożenia, który agent może potraktować jak mapę.
Aby wejść w tryb planowania, wciskam Shift + Tab. W tym trybie agent nie modyfikuje kodu — służy on wyłącznie rozmowie i planowaniu.
Dla tego projektu sprawdzę, czy Kimi odtworzy pewną wyjątkowo efektowną aplikację autorstwa WebDev Cody’ego — to trójwymiarowa wersja Excalidraw, w której obiekty można przesuwać w przestrzeni 3D. To wcale nie jest łatwy projekt; szczerze nie wiem, czy Kimi mu podoła. Ale jeśli model faktycznie jest na poziomie Fable, powinien zbudować coś takiego.
W trybie planowania wklejam bardzo szczegółowy prompt i zapisuję go w kodzie projektu. Zgodnie z regułą w agents.md (w trybie planowania zawsze pytaj o doprecyzowanie) Kimi wraca z serią pytań: gdzie ma powstać aplikacja (odpowiadam: w bieżącej ścieżce), jak zaimplementować automatyczny układ grafu (wybieram opcję własną, zerowo-zależnościową, a przy kolejnym pytaniu — rekomendowaną). Chcę przetestować możliwości modelu, więc raczej go nie steruję i trzymam się rekomendowanych opcji.
Agent tworzy plan. Nie podoba mi się jednak, gdzie go zapisał, więc tworzę podfolder plans w .kimi i przenoszę plan do niego — najszybciej po prostu przeciągając plik. Trzymanie planu w folderze projektu ma sens: plan jest kolokowany z kodem, trafi razem z nim na GitHub, zobaczą go członkowie zespołu, a ja łatwo do niego wrócę. Gdybym nie zdążył dokończyć implementacji w jednej sesji, mogę wyłączyć komputer, wrócić później, wczytać ten sam plan i poprosić agenta o kontynuację.
Kolejny powód, by zapisywać plany: obecnie zużywamy około 20% okna kontekstu, a okno w Kimi nie jest duże — to zaledwie 256 000 tokenów. Modele GPT i te od Claude sięgają miliona, ale i tak nie chciałbym używać aż tylu tokenów, bo wtedy wchodzi się w „strefę głupoty”, gdzie jakość odpowiedzi agenta zaczyna spadać. Skoro plan jest zapisany, mogę teraz wyczyścić kontekst, wczytać plan z powrotem i poprosić agenta o implementację projektu zgodnie z planem.
Implementacja i funkcja „swarm”
Kimi ma ciekawą funkcję o nazwie swarm. Przy złożonych projektach można ją włączyć — Kimi uruchamia wtedy podagentów wykonujących równolegle wiele zadań, delegując do nich różne zadania kodowania czy researchu. To zadanie jest dość złożone, więc włączam swarm, wczytuję plan i proszę o implementację.
Kimi rusza do pracy: instaluje zależności i tworzy pliki. W międzyczasie pokazuję funkcję dla tych, którzy nie lubią przeglądarki — w sesji CLI wpisuję komendę /web, potwierdzam i otwiera się przyjazny interfejs webowy pokazujący wszystkie sesje Kimi. Przypomina to Claude Desktop albo Codex. Ten sam widok można wywołać komendą /session.
Wracając do terminala: swarm w końcu ruszył. Kimi najpierw sam ustawił zależności i pliki projektu, a teraz uruchamia wielu podagentów pracujących równolegle. Obok każdego widać, czym się zajmuje, a osobna sekcja pokazuje bieżący rozmiar okna kontekstu. Co ważne, swarm nie tylko buduje funkcjonalność — także uruchamia testy. Powstają agenci odpowiedzialni za testy jednostkowe oraz za testowanie aplikacji dostępnymi narzędziami, np. Playwright MCP. Dzieje się tak dzięki regułom w agents.md — agent nie tylko buduje projekt, ale też dowodzi poprawności swojej pracy, co jest ostatnim krokiem frameworku RAMP. Sam nie otwierałem przeglądarki — to Kimi przez Playwright otwiera ją i przeprowadza rodzaj smoke testu.
Problemy: zużycie tokenów i czas
Aktualizacja: agent uruchomił drugą falę podagentów i zauważyłem, że mój limit zużycia szybko się wyczerpał — musiałem odczekać kilka godzin na jego reset. Po drugiej fali kazałem agentowi przestać używać swarma i zrealizować resztę projektu samodzielnie, w jednym wątku. Wygląda na to, że swarmy zużywają mnóstwo tokenów. Może pomogłoby obniżenie poziomu rozumowania z max do medium lub high — ale limit skończył mi się zaskakująco szybko. O ile projekt nie jest naprawdę bardzo złożony, radziłbym unikać swarmów.
Minęły niemal dwie godziny, a Kimi wciąż pracuje. W obecnym stanie efekt zdecydowanie nie jest dobry: jest w tym jakiś element 3D i po oddaleniu widać płótno, ale do gotowego produktu daleko. Model jest naprawdę powolny — być może przez użycie swarma; po przejściu na jeden wątek zrobiło się nieco szybciej.
To ostatecznie zajęło bardzo dużo czasu. Musiałem robić zrzuty ekranu z aplikacji referencyjnej i przekazywać je agentowi, żeby poprawił płótno i design 3D. W tym momencie agent ma otwartą przeglądarkę i sam przeprowadza automatyczne testy — dodaje prostokąty i koła, testując aplikację. Przerywam jednak i zaczynam nową sesję, bo chcę pokazać wdrożenie na produkcję. Można by jeszcze długo dodawać funkcje, ale minęły już około dwie godziny.
Jedno mogę powiedzieć o tym modelu: owszem, jest znacznie tańszy niż Fable, ale niekoniecznie tak szybki. Choć znów — mogło to wynikać z czasu zmarnowanego na swarmy. Na ten moment odradzam ich używanie.
Wdrożenie na produkcję przez Hostinger
Najpierw tworzę commit („init”) i publiczne repozytorium, którym można się bawić — link umieszczę w mojej darmowej społeczności z zasobami do YouTube.
Wdrożenie na produkcję jest bardzo proste, skoro podłączyliśmy Hostingera: wystarczy powiedzieć „Proszę, wdróż to na Hostingerze”. Przy pierwszym użyciu MCP Hostingera trzeba uwierzytelnić konto. Kimi informuje, że mam na koncie kilka planów hostingowych — wybieram pierwszy. Deployment kończy się sukcesem, a agent weryfikuje, że strona działa, i podaje publiczną domenę.
To faktycznie działająca wersja aplikacji: spacją i klawiszem Alt mogę się poruszać, suwakami sterować widokiem 3D, kasować węzły, dodać nowy węzeł i wpisać w nim tekst — wszystko działa. Jeśli chcesz podpiąć własną domenę, również zrobisz to przez agenta.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Kimi K3 to tania alternatywa dla topowych modeli
Na czym polega: Kimi K3 według benchmarków dorównuje inteligencją najlepszym modelom, a kosztuje ułamek ceny Fable 5 (ok. jednej trzeciej) i mniej niż GPT-5.6.
Jak stosować: Traktuj go jako opcję „opłacalność ponad wszystko” — do projektów, gdzie liczy się budżet, a nie ostatnie procenty jakości czy szybkości.
Na co uważać: Rankingi benchmarkowe szybko się dezaktualizują, a niższa cena idzie w parze z niższą szybkością i mniejszym oknem kontekstu. Nie zakładaj parytetu z droższymi modelami w każdym zadaniu.
2.Do agentowego kodowania używaj CLI lub aplikacji desktopowej, nie strony
Na czym polega: Interfejs webowy Kimi nadaje się do dem, ale nie do realnego budowania aplikacji. Właściwym narzędziem jest Kimi Code (CLI) lub rozszerzenie do edytora.
Jak stosować: Zainstaluj Kimi Code, zaloguj się przez /login, a pracuj wewnątrz VS Code/Cursora z otwartym terminalem, by na bieżąco widzieć tworzone pliki.
Na co uważać: Po instalacji trzeba zrestartować terminal. Pamiętaj też, by komendą /model przełączyć się na K3 — domyślnie może być ustawiony starszy model.
3.Subskrypcja zwykle bije płatność za tokeny
Na czym polega: Subskrypcje tych usług są mocno dotowane i przy realnym użyciu wychodzą taniej niż rozliczenie „pay as you go” przez klucz API.
Jak stosować: Jeśli kodujesz regularnie, wybierz plan miesięczny (autor płaci ok. 20 USD/mies.). Klucz API zostaw na sporadyczne, przewidywalne użycie.
Na co uważać: Subskrypcje mają limity zużycia, które można wyczerpać w kilka godzin (szczególnie na trybie max i przy swarmach) — reset trwa, co potrafi zablokować pracę.
4.Reguły w agents.md realnie sterują agentem
Na czym polega: Wszystko, co wpiszesz do agents.md, agent egzekwuje w każdej sesji — od stylu odpowiedzi po obowiązek testowania.
Jak stosować: Zdefiniuj reguły: zwięzłość odpowiedzi, obowiązkowe pytania doprecyzowujące w planowaniu, zakaz zakładania „że działa” bez testu, trzymanie się systemu projektowego z design.md.
Na co uważać: Reguły zajmują kontekst i działają tylko, jeśli są konkretne. Zbyt ogólne lub sprzeczne instrukcje przyniosą efekt odwrotny do zamierzonego.
5.Nie instaluj skilli na zapas — pisz własne reguły
Na czym polega: Wiele popularnych skilli to zaledwie kilka linijek promptu, które równie dobrze zastąpisz zwykłą regułą lub prośbą do agenta.
Jak stosować: Skille rezerwuj do rzeczy, których prompt nie zastąpi: dokumentów referencyjnych i złożonych workflow — zwłaszcza oficjalnych skilli dostawców twojego stacku (np. Next.js/Vercel, Clerk).
Na co uważać: Nie myl marketingowej „liczby skilli” z wartością. Instaluj tylko te oparte na realnej dokumentacji dopasowanej do twojej technologii.
6.Rozszerzaj agenta serwerami MCP do testów i wdrożeń
Na czym polega: Serwer Playwright MCP pozwala agentowi samodzielnie otwierać przeglądarkę i testować aplikację end-to-end, a serwer MCP Hostingera — wdrażać ją na żywą domenę.
Jak stosować: Poproś agenta, by zainstalował serwer MCP z podanego URL; konfiguracja trafi do .kimi/mcp.json. Do wdrożeń nadaj w panelu hostingu odpowiednie uprawnienia (strony, domeny).
Na co uważać: Nadanie agentowi uprawnień do rejestrowania domen i deploymentu to realna władza nad twoim kontem — przyznawaj zakres świadomie i weryfikuj, co agent robi.
7.Planuj przed kodowaniem (etap „Map” w RAMP)
Na czym polega: Tryb planowania (Shift + Tab) nie modyfikuje kodu — służy rozmowie prowadzącej do szczegółowego planu wdrożenia, który agent traktuje jak mapę.
Jak stosować: Wejdź w planowanie, opisz projekt szczegółowym promptem, pozwól agentowi zadać pytania doprecyzowujące, a gotowy plan zapisz w folderze projektu (np. .kimi/plans).
Na co uważać: Kolokacja planu z kodem pozwala wrócić do przerwanej pracy i wyczyścić kontekst bez utraty ustaleń. Nie zostawiaj planu w przypadkowym miejscu na dysku.
8.Pilnuj okna kontekstu — unikaj „strefy głupoty”
Na czym polega: Okno kontekstu Kimi to tylko 256 000 tokenów; przy dużym zapełnieniu jakość odpowiedzi agenta spada.
Jak stosować: Zapisuj plany i ustalenia do plików, a potem czyść kontekst (/new) i wczytuj tylko to, co potrzebne do bieżącego kroku.
Na co uważać: Większe okno kontekstu innych modeli to nie zaproszenie, by je zapełniać — degradacja jakości dotyczy każdego modelu przy nadmiernie długim kontekście.
9.Swarm przyspiesza teoretycznie, ale przepala tokeny
Na czym polega: Funkcja swarm uruchamia podagentów pracujących równolegle nad kodowaniem, researchem i testami — kusząca przy złożonych projektach.
Jak stosować: Włączaj ją tylko przy naprawdę złożonych zadaniach i rozważ obniżenie poziomu rozumowania z max do medium/high, by ograniczyć zużycie.
Na co uważać: W teście swarm wyczerpał limit zużycia zaskakująco szybko i spowolnił pracę do ~2 godzin. Domyślnie autor odradza swarmy — bezpieczniej pracować jednowątkowo.
10.Wymuś testowanie i wdrażaj bezpośrednio przez agenta
Na czym polega: Dzięki regule „zawsze testuj” agent sam uruchamia testy jednostkowe i smoke testy w przeglądarce (Playwright), a wdrożenie odpala jedną prośbą przez MCP Hostingera.
Jak stosować: Dodaj regułę testowania do agents.md, a po zbudowaniu aplikacji poproś: „wdróż to na Hostingerze” — agent uwierzytelni konto i zwróci publiczny adres.
Na co uważać: Automatyczne testy agenta nie zastępują twojej oceny — w tym przypadku odtworzenie skomplikowanego UI 3D wymagało ręcznego dosyłania zrzutów referencyjnych i wielu iteracji.