O czym jest ten film
- Zamiast testować nowy model na kolejnej aplikacji-demo autor zlecił Fable 5.1 ambitne zadanie: zbudowanie otoczki kodującej (harnessu) zoptymalizowanej pod darmowe modele lokalne działające w Ollama i LM Studio.
- Punkt wyjścia: modele, które realnie uruchomimy na własnym sprzęcie (np. Qwen 3.8), obsługują teoretycznie do 256 tys. tokenów kontekstu, ale RAM pozwala zwykle na 64–128 tys. — a Claude Code pochłania 37 tys. na samym starcie.
- Lżejsze narzędzia, jak Pi Agent SDK, wymagają masy ustawień i wtyczek — modele open source traktują po macoszemu.
- Zasady projektu: natywna obsługa Ollama i LM Studio bez konfiguracji, zwięzły prompt systemowy z definicjami wyłącznie niezbędnych narzędzi, brak MCP i „agent skills”, brak agentów równoległych i działających w tle.
- Fable skorygował pomysł autora, by agent dostał tylko bash: darmowe modele słabo formatują polecenia terminalowe, lepszy jest wąski, jasno zdefiniowany zestaw narzędzi.
- Agent sam testował rozwiązanie (m.in. budując klienta Minecrafta w przeglądarce), obsłużył plik pamięci AGENTS.md oraz listę zadań z notkami „co zrobione, co dalej” — ratują one agenta po każdej kompresji kontekstu.
- Ponieważ agent nie mógł obejrzeć terminala w przeglądarce, powstała webowa wersja harnessu; pierwsza, ponad dwugodzinna sesja kosztowała ok. 225 dol.
- Sprawdzony wzorzec pracy: po zakończeniu budowy nowa, czysta sesja audytowo-naprawcza (15 min, ok. 30 dol.), a potem własne testy i punktowe zgłaszanie usterek.
- Sposób dystrybucji (npm) zaproponował sam agent i przeprowadził autora przez publikację pakietu — instalacja to jedno polecenie
npx smallcoder; dostępny jest też tryb webowy i headless. - Finałowe szlify: panel boczny i wbudowana przeglądarka w interfejsie webowym (godzina pracy, ok. 30 centów) oraz strona projektu wdrożona za darmo na Vercel pod domeną smallcoder.dev.
Redakcyjne tłumaczenie
Wstęp: nie kolejna zabawkowa aplikacja
Fable 5.1 właśnie się pojawił i muszę przyznać, że robi spore wrażenie. Zamiast każeć mu budować kolejną prostą aplikację na pokaz, postanowiłem dać mu naprawdę trudne zadanie: stworzyć najlepsze możliwe środowisko kodujące dla darmowych modeli lokalnych. Tak powstał Small — tak zwany harness, czyli otoczka pośrednicząca między użytkownikiem a modelem: prowadzi sesję, udostępnia agentowi narzędzia i komunikuje się z serwerem modeli. Ten konkretny powstał specjalnie pod darmowe modele uruchamiane lokalnie w Ollama i LM Studio — dwóch popularnych aplikacjach do odpalania modeli na własnym sprzęcie. I od razu zaznaczę: to żadna zabawka.
To, co widzicie na ekranie, to zbudowany w tej współpracy interfejs webowy — z pełnym pakietem funkcji. Mamy tu wbudowaną przeglądarkę, tworzenie przestrzeni roboczych z osobnymi sesjami dla każdej z nich, a także polecenia rozpoczynające się od ukośnika, na przykład do zmiany modelu. Narzędzie samo wykrywa modele, które macie już zainstalowane w Ollama lub LM Studio, a przełączanie się między nimi zajmuje dosłownie sekundę. Całość uruchomicie też w terminalu — jednym poleceniem, bez grama konfiguracji. Wybieracie model, ewentualnie ustawiacie poziom rozumowania i wszystko po prostu działa. Fable dorzucił nawet stronę startową projektu, która moim zdaniem wygląda świetnie i dobrze współgra z estetyką terminala.
W tym odcinku chcę zrobić coś innego niż zwykle. Zamiast benchmarków i marketingowych zapowiedzi Anthropic pokażę wam drogę, którą przeszedłem od pomysłu do finalnego efektu. Mam nadzieję, że coś z tego wynieściecie. A jeśli pracujecie na modelach lokalnych — po prostu wypróbujcie Small.
(Informacja dodatkowa: autor wymienia zamiennie nazwy „Fable 5.1” i „Claude” — pracuje z modelem Fable w interfejsie Claude Code; w tłumaczeniu zachowujemy nazwy tak, jak padają w oryginale.)
Dlaczego modele lokalne potrzebują własnej otoczki
Zacznijmy od liczb. Modele, które realnie da się odpalić na własnym sprzęcie — na przykład Qwen 3.8 — mają okno kontekstu sięgające 256 tysięcy tokenów. (Informacja dodatkowa: w transkrypcji pada zapis „Qwen 3.8”; niemal na pewno chodzi o model Qwen3 8B.) Problem w tym, że garstka z nas zmieści takie okno w pamięci RAM. Realnie mówimy o 64, góra 128 tysiącach tokenów — a to naprawdę niewiele.
Teoretycznie można wpiąć lokalny model w gotowe środowiska typu Claude Code. Szybko jednak widać ich słabość: polecenie /context pokazuje, że Claude Code zużywa 37 tysięcy tokenów, zanim zdążymy cokolwiek zrobić. Gdy cały budżet wynosi 64 tysiące, zaczynamy z ogromnym deficytem.
Istnieją oczywiście lżejsze otoczki, jak Pi Agent SDK — uważam to rozwiązanie za znakomite. Ale wszystkie te narzędzia traktują modele open source po macoszemu: dochodzi masa ustawień, wtyczek i kombinowania. Postawienie lokalnego modelu bywa po prostu bolesne.
Założenia: zero konfiguracji i szacunek dla kontekstu
Chciałem czegoś odwrotnego — narzędzia zaprojektowanego od zera pod darmowe modele lokalne działające w Ollama i LM Studio. W praktyce oznaczało to dopasowanie wszystkich wywołań narzędzi i odpowiedzi do API właśnie tych dwóch środowisk. A ponieważ ich obsługa jest natywna, konfiguracja znika całkowicie.
Drugie kluczowe wymaganie: otoczka musi szanować okno kontekstu użytkownika. W praktyce — zwięzły, dopracowany prompt systemowy, zawierający wyłącznie definicje narzędzi, których agent faktycznie potrzebuje. Od razu odpada wbudowane wsparcie dla serwerów MCP i tzw. agent skills. A skoro pracujemy na modelach lokalnych, nie ma też najmniejszego sensu agent równoległy czy działający w tle — te funkcje odpuściliśmy z góry.
Surowy zrzut wiedzy i pierwsza korekta od modelu
Punktem wyjścia był tzw. brain dump: wylałem na Fable całą powyższą wiedzę jednym strumieniem i dorzuciłem cel końcowy. Chciałem, żeby każdy mógł zainstalować narzędzie pojedynczą komendą npm, a całość działała na Windowsie, Linuksie i macOS. No i oczywiście natywna obsługa Ollama i LM Studio. Podzieliłem się też przemyśleniami o trybach pracy i o tym, ile narzędzi w ogóle powinien dostać agent.
Początkowo sugerowałem wręcz, że wystarczy jedno narzędzie: bash. Skoro agent może uruchamiać dowolne polecenia terminalowe, przecież tymi poleceniami zrobi wszystko. Tu jednak Fable się nie zgodził — i miał rację. Darmowe modele, jak wyjaśnił, słabo radzą sobie z poprawnym formatowaniem poleceń bash. W zamian zaproponował ograniczony zestaw jasno zdefiniowanych i prostych w użyciu narzędzi.
Agent testuje sam siebie
Kolejny krok: poprosiłem agenta, żeby sam sprawdził świeże rozwiązanie — budując klienta Minecrafta działającego w przeglądarce. Zleciłem też obsługę pliku AGENTS.md: gdy użytkownik umieści taki plik w przestrzeni roboczej, zawarte w nim reguły mają trafiać do kontekstu. Claude kontynuował testy i wrzucał do rozmowy zrzuty ekranu gotowej aplikacji.
Dodałem jeszcze listę zadań. Może znacie ją z Claude Code: duże zadanie rozpada się tam na pojedyncze punkty i na bieżąco widać postępy agenta. Chciałem jednak pewnej różnicy. Przy tak ciasnych oknach kontekstu kompresja kontekstu — czyli automatyczne skracanie historii rozmowy, gdy zbliża się do limitu — będzie odpalać się częściej, a to znaczy, że agent potrzebuje czegoś, co po każdym skróceniu historii postawi go z powrotem na właściwym torze. Dlatego nasza faza planowania zapisuje przy każdym zadaniu krótki kontekst: co zostało już zrobione i co jest kolejnym krokiem.
Wersja webowa: szalony pomysł, który się obronił
W pewnym momencie zauważyłem, że agent nie jest w stanie przetestować samego terminala — terminalu nie otwiera się w przeglądarce i nie da się mu zrobić zrzutu ekranu. Pomyślałem: brzmi to jak pomysł od czapy, ale co, jeśli dorzucimy wersję harnessu działającą w przeglądarce? Po wpisaniu small web startuje otoczka w wydaniu webowym.
Szczerze mówiąc, zakładałem, że przenoszenie interfejsu terminalowego do aplikacji webowej to przesada. Tymczasem Claude po prostu przyjął zadanie i je wykonał. Dla przypomnienia: tak wygląda wersja terminalowa. Po wpisaniu small web dostajecie unikalny adres — otwieracie go w przeglądarce i macie przed sobą pełnoprawną wersję webową. Początkowo nie było jeszcze panelu bocznego; istniało tylko główne okno, wyglądające identycznie jak terminal.
Ta sesja trwała około dwóch godzin i dwóch minut, a jej koszt oszacowano na około 225 dolarów. Rzecz jasna nie płaciłem tego z kieszeni — korzystam z subskrypcji.
Przerwa na słowo od sponsora
Tradycyjnie słowo od sponsora tego odcinka — którym jestem… ja sam. Jeśli chcecie poznać mój sposób budowania praktycznie czegokolwiek z agentami kodującymi, zajrzyjcie do Agentic AI Labs. Właśnie dodałem tam kompletny projekt QR Studio: budujemy w nim pełną aplikację SaaS od pustego repozytorium, przez logowanie użytkowników, bazę danych i miejsce na pliki, aż po wdrożenie na produkcję. Link zostawiam w opisie filmu.
Świeża sesja: audyt i poprawki
W tym momencie aplikacja działała — w terminalu i w przeglądarce. Teraz sięgam po zabieg, który stosuję w pracy regularnie: otwieram nową, czystą sesję i proszę agenta o audyt oraz poprawki. Krótko opisuję, czemu aplikacja ma służyć, podkreślam, że musi być zoptymalizowana pod modele lokalne, i proszę Fable o porządne przejrzenie całości wraz z naprawą wykrytych problemów. Sesja zajęła kwadrans i kosztowała około 30 dolarów — i była po prostu warta swojej ceny.
Po zakończonym przeglądzie zabrałem się za własne testy. Trafiłem na kilka potencjalnych błędów i po prostu zgłosiłem je Fable. Szczerze mówiąc, bugów okazało się niewiele — większość problemów wzięła się z moich początkowych wymagań. Na przykład tryb, który początkowo ochrzciłem „YOLO mode”, przemianowałem na „bypass permissions”, czyli pomijanie pytań o uprawnienia, i przy okazji zmieniłem zakres tego, co wolno w poszczególnych trybach.
Publikacja na GitHubie: nazwa, licencja, instrukcja
Na koniec tej odsłony poprosiłem agenta o utworzenie repozytorium GitHub. Wtedy właśnie aplikacja pierwszy raz dostała imię: SmallCoder. Chcecie wesprzeć projekt — kliknijcie gwiazdkę. Dorzuciłem jeszcze prośbę o licencję MIT (projekt jest w pełni open source) oraz o plik README z instrukcją instalacji i podstawami pracy z tym narzędziem.
Dystrybucja przez npm: rekomendacja samego agenta
Potem przyszło to, co z początku wydawało mi się największym wyzwaniem: dystrybucja. Kod wylądował na GitHubie, ale zależało mi, żeby instalacja sprowadzała się do jednego polecenia. Nie miałem pojęcia, jak rozwiązać to poprawnie — więc po prostu zapytałem Fable 5.1: „Jaki byłby najlepszy sposób na dystrybucję tego narzędzia?”. Agent polecił npm: użytkownik będzie mógł zainstalować pakiet komendą npm install albo od razu uruchomić aplikację przez npx smallcoder. Przytaknąłem i poszliśmy w tę stronę.
Wszystko, co zostało z tej sesji, to Fable przeprowadzający mnie krok po kroku przez wygenerowanie tokenu dostępu na npm. Wyszło banalnie prosto — dosłownie dwa polecenia — i pakiet trafił do rejestru. Od tej chwili każdy może zainstalować SmallCoder jednym poleceniem.
Instalacja i pierwsze uruchomienie
Chcecie spróbować? Wystarczy jedna komenda. Samą otoczkę startujecie poleceniem small — uruchomi się w oknie terminala. Pamiętajcie tylko, żeby wywołać je w katalogu roboczym, w którym narzędzie ma dokonywać zmian. Wersję webową odpalicie przez small --web. Jest też tryb headless, czyli praca bez interfejsu — wystarczy na przykład small -p "Cześć". Takie polecenie posłało prompt do Ollama, a odpowiedź wróciła obładowana metadanymi.
Interfejs webowy na poziomie Claude Code
Na koniec chciałem doprowadzić webowy interfejs do wyglądu zbliżonego do Claude Code czy aplikacji ChatGPT Codex: panel boczny z przestrzeniami roboczymi i sesjami oraz wbudowana przeglądarka. I okazało się to zaskakująco łatwe. Otworzyłem kolejną sesję i powiedziałem wprost: „Nie wiem, na ile to wykonalne, ale w wersji webowej chciałbym żywy panel boczny z podglądem przestrzeni roboczych i sesji”. Dodałem, że zależy mi też na wbudowanej przeglądarce i terminalu. Sesja trwała około godzinę i kosztowała około 30 centów, a efekt był w całości wart.
Strona projektu na Vercel
Żeby domknąć całość, postanowiłem wystawić witrynę naszego narzędzia. W Claude Code utworzyłem nowy, bardzo prosty projekt: wkleiłem zrzut ekranu okna terminala, wskazałem Fable repozytorium na GitHubie i wyjaśniłem, że potrzebuję jednostronicowej strony, bez fajerwerków. Następnie poprosiłem o osobne repozytorium dla witryny, wdrożyłem ją na Vercel — całkowicie za darmo — i przypisałem własną domenę. Pod adresem smallcoder.dev działa finalna wersja strony.
Dajcie łapkę w górę i zasubskrybujcie kanał, jeśli chcecie więcej materiałów o kodowaniu z agentami. Do zobaczenia w następnym odcinku!
10 najważniejszych takeaways — z kontekstem zastosowania
1.Sprawdzaj nowe modele na prawdziwym projekcie, nie na aplikacji-demo
Na czym polega: Autor celowo ominął typowy test „zbuduj prostą apkę” i zlecił Fable 5.1 zadanie z realnym celem: narzędzie, które samo miało trafić do publicznej dystrybucji. Dopiero taki projekt obnaża, jak model radzi sobie z architekturą, debugowaniem i decyzjami projektowymi.
Jak stosować: Testując nowy model, wybierz zadanie z dziedziny, na której ci faktycznie zależy, i określ mierzalny efekt końcowy (np. „instalowalne jednym poleceniem narzędzie open source”). Zapisz cel i ograniczenia jeszcze przed pierwszą sesją.
Na co uważać: Ambitny zakres bez podziału na etapy łatwo wymyka się spod kontroli — pilnuj, żeby każdy etap kończył się działającym artefaktem, który da się sprawdzić.
2.Zacznij od surowego zrzutu wymagań i ograniczeń (brain dump)
Na czym polega: Punktem wyjścia był jeden „wylew” wiedzy: ograniczenia sprzętowe, docelowe środowiska, sposób dystrybucji, twarde limity kontekstu. Agent dostał pełny obraz zamiast wyrywkowych informacji доздавanych po kolei.
Jak stosować: Przed otwarciem sesji wypisz wszystko, co model „musi wiedzieć”: środowisko docelowe (u autora: Ollama i LM Studio), platformy (Windows, Linux, macOS), kanał dystrybucji (npm) oraz twarde ograniczenia (małe okno kontekstu).
Na co uważać: Brain dump to wymagania i fakty, a nie gotowe rozwiązania — zbyt szczegółowe dyrektywy projektowe potrafią zasłonić lepsze opcje.
3.Traktuj sprzeciw agenta jako sygnał projektowy
Na czym polega: Autor proponował jedno narzędzie — bash, którym agent „zrobi wszystko”. Fable zaprotestował: darmowe modele słabo formatują polecenia terminalowe, więc lepiej dać wąski, jasno zdefiniowany zestaw narzędzi. Autor poszedł za radą i wyszedł na tym.
Jak stosować: Gdy agent kwestionuje twoją architekturę, dopytaj o powody i porównaj obie opcje na małym przykładzie — model często zna słabości konkretnych modeli i środowisk lepiej niż twoje założenia.
Na co uważać: Sprzeczek nie przyjmuj bezkrytycznie; żądaj konkretnego uzasadnienia, zanim przepisujesz cały plan.
4.Zlecaj agentowi samodzielne testowanie tego, co zbudował
Na czym polega: Fable sam testował otoczkę, budując m.in. klienta Minecrafta w przeglądarce i pokazując zrzuty ekranu w rozmowie. Gdy nie mógł „zobaczyć” terminala, narzędzie doczekało się wersji webowej właśnie po to, by agent miał co testować.
Jak stosować: Na koniec każdego etapu dodaj polecenie w stylu: „przetestuj rozwiązanie, budując przykładową aplikację X, i pokaż zrzuty ekranu”. Efekty weryfikuj zawsze własnymi oczami.
Na co uważać: Agent przetestuje tylko to, co potrafi zaobserwować swoimi narzędziami — interfejsy dla niego niewidoczne (jak terminal) wymagają twojego ręcznego testu.
5.Projektuj listę zadań tak, aby przetrwała kompresję kontekstu
Na czym polega: W małych oknach kontekstu mechanizm skracania historii rozmowy uruchamia się częściej i agent gubi wątek. W Small każde zadanie na liście niesie więc notkę: co już zrobiono i co jest kolejnym krokiem — lista działa jak kotwica po kompresji.
Jak stosować: Przy dużych zadaniach wymagaj podziału na kroki z zapisanym kontekstem przy każdym z nich; po skróceniu historii agent wróci na właściwy tor na podstawie własnej listy.
Na co uważać: Sam nagłówek zadania („napraw formularz”) to za mało — bez zapisanego kontekstu agent może po kompresji cofać się do już ukończonych prac.
6.Oszczędzaj tokeny od pierwszego promptu systemowego
Na czym polega: Claude Code pochłania 37 tys. tokenów na starcie — przy 64 tys. dostępnego okna to dyskwalifikuje narzędzie. Small podejmuje odwrotną strategię: minimalny prompt systemowy, wyłącznie niezbędne definicje narzędzi, zero MCP i „agent skills”, brak agentów równoległych.
Jak stosować: Zanim podepniesz model lokalny do gotowej otoczki, sprawdź jej zużycie kontekstu na pustej sesji. We własnych projektach buduj zestaw narzędzi od minimum i dokładaj tylko to, co agent realnie wykorzystuje.
Na co uważać: Każda „netto fajna” funkcja (serwery MCP, umiejętności, równoległość) kosztuje tokeny — na lokalnych modelach kończy się to degradacją jakości albo brakiem miejsca na właściwy kod.
7.Po zbudowaniu otwórz świeżą sesję audytową
Na czym polega: Zamiast ciągnąć wielogodzinną rozmowę, autor otworzył nową, czystą sesję, krótko opisał cel i ograniczenia aplikacji i poprosił o porządny audyt z poprawkami. Kwadrans pracy, około 30 dolarów.
Jak stosować: Zakończyłeś etap budowy — utwórz nową konwersację, podaj zwięzły opis celu i kluczowych wymagań, poproś o przegląd kodu i naprawę wykrytych problemów. Świeży kontekst łatwiej dostrzega błędy zakorzenione w poprzedniej rozmowie.
Na co uważać: Agent w nowej sesji nie zna wcześniejszych ustaleń — pomiń kluczowe wymagania (np. „zoptymalizowane pod modele lokalne”), a audyt pójdzie w złą stronę.
8.Po audycie testuj ręcznie i zgłaszaj usterki punktowo
Na czym polega: Po przeglądzie autor sam przetestował aplikację, trafił na kilka potencjalnych błędów i po prostu je zgłosił. Okazało się, że większość problemów nie wynikała z kodu, lecz z jego własnych początkowych wymagań (np. nazwa „YOLO mode” → „bypass permissions”).
Jak stosować: Traktuj własne testy jako dopełnienie audytu; każdą usterkę opisz jednym zdaniem i przekaż do sesji naprawczej, zamiast samemu grzebać w kodzie.
Na co uważać: Zanim obwinisz model, sprawdź, czy problem nie siedzi w twoich pierwotnych założeniach — zmiana wymagań bywa tańsza niż seria poprawek w kodzie.
9.Gdy nie wiesz, jak coś wydać — zapytaj agenta o rekomendację
Na czym polega: Dystrybucja wydawała się autorowi największym wyzwaniem. Zamiast samodzielnie szukać, zapytał Fable o najlepszą metodę; agent zaproponował npm i przeprowadził go za rękę przez wygenerowanie tokenu oraz publikację pakietu — wyszły na to dwa polecenia.
Jak stosować: Pytanie „jaki byłby najlepszy sposób, żeby…?” traktuj jak konsultację: dostajesz rekomendację wraz z instrukcją krok po kroku, którą możesz od razu wykonać.
Na co uważać: Publikacja pakietów wymaga uwierzytelnień i trafia do publicznego rejestru — sprawdzaj, co dokładnie wgrywasz, i trzymaj tokeny dostępu z dala od repozytorium.
10.Domknij projekt publiczną publikacją i prostą stroną
Na czym polega: Na koniec autor zamienił zrzut ekranu terminala i link do repozytorium w jednostronicową stronę (Fable zrobił ją od zera), wdrożył ją na Vercel bez kosztów i podpiął własną domenę smallcoder.dev.
Jak stosować: Do wygenerowania prostej strony wystarczy zrzut ekranu istniejącego interfejsu plus wskazanie repozytorium; darmowy hosting typu Vercel domyka całość bez budżetu.
Na co uważać: Trzymaj zakres strony minimalny — jedna strona, „bez fajerwerków”. Rozbudowany serwis zawsze zdążysz dodać, jeśli w ogóle będzie potrzebny.