O czym jest ten film
- Fable 5 — model opisywany jako „superinteligentny badacz na poziomie doktora pracujący w twoim edytorze” — przepadł, a autor pokazuje, jak odzyskać część jego jakości w modelach, które zostały.
- Rozmowy z Claude Code i Codexem zapisują się lokalnie na komputerze w plikach JSONL pełnych metadanych.
- W tych metadanych są prompty użytkownika, odpowiedzi modelu, jego plany pracy i wywołania narzędzi, w tym MCP.
- Claude Code może przepuścić te archiwa przez własne skrypty i zamienić surowy zrzut w czytelny podręcznik zachowań (playbook) dla dowolnego modelu.
- Surowych plików nie ma sensu wrzucać do rozmowy — najpierw trzeba je odchudzić, zostawiając tylko znaczniki czasu, nazwę modelu, pytania i odpowiedzi.
- Każda tura w pliku ma etykietę modelu, więc da się zestawić ze sobą zachowania, np. Fable 5 kontra Opus 4.8.
- Kto nie zdążył popracować z Fabłem, może przeprowadzić to samo ćwiczenie na otwartych sesjach innych użytkowników z Hugging Face.
- Analiza ma dawać liczby, nie wrażenia: rytm wywołań narzędzi, kolejność akcji, liczbę odczytów przed edycją, testy po edycji.
- Wnioski trafiają do pliku playbook, który podpina się przez hook, skill albo CLAUDE.md, by działał w każdej nowej sesji.
- Autor udostępnia w opisie wszystkie prompty z filmu, link do otwartych danych i własny, gotowy playbook.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Lokalne archiwum sesji to surowiec do ulepszania modeli
Na czym polega: Claude Code i Codex zapisują każdą rozmowę w plikach JSONL zawierających prompty, odpowiedzi, plany zadań i wywołania narzędzi wraz z nazwą modelu.
Jak stosować: Sięgnij po te pliki zawsze, gdy chcesz uchwycić, jak pracował najlepszy model w twojej historii, i przenieść te wzorce na słabsze modele.
Na co uważać: Archiwa zawierają też dane osobiste i wrażliwe treści projektów — zatarz je, zanim cokolwiek udostępnisz lub wyślesz dalej.
2.Nie wrzucaj surowych plików do kontekstu — najpierw destylacja
Na czym polega: Większość JSONL to wyniki działania narzędzi, pełne zawartości plików i wyjścia poleceń. Model zadławi się tysiącami linii balastu.
Jak stosować: Każ Claude Code napisać mały skrypt w Pythonie, który wycina szum i zostawia znaczniki czasu, nazwę modelu, twoje pytania i odpowiedzi asystenta.
Na co uważać: Przy pierwszym podejściu przepuść przez skrypt jeden konkretny plik i ręcznie sprawdź, czy format wyniku zgadza się z oczekiwaniami.
3.Etykiety modeli pozwalają porównywać zachowania
Na czym polega: Każda tura ma pole z nazwą modelu, więc rozmowy jednego modelu można odcedzić od drugiego i zestawić ich style pracy.
Jak stosować: Zbuduj osobny, połączony korpus rozmów najlepszego modelu — u autora był to Fable 5 — jako punkt odniesienia dla reszty.
Na co uważać: Porównuj sesje przy podobnych zadaniach; przy odmiennych problemach różnice będą mówić o zadaniach, nie o modelach.
4.Żądaj liczb, nie wrażeń
Na czym polega: Subiektywny ogląd „jakości rozmowy” niczego nie da się przenieść na inny model. Konkretne wskaźniki — tak.
Jak stosować: W prompcie o syntezę dopisz wprost: „wzorce zachowań jako zmierzone liczby, nie wrażenia”.
Na co uważać: Przy ubogiej historii sesji liczby mogą przerysowywać obraz — im większa próba, tym pewniejszy wniosek.
5.Kluczowe metryki: rytm narzędzi, kolejność akcji, odczyty przed edycją, testy po edycji
Na czym polega: Różnica między Fable a Opusem to przede wszystkim struktura pracy: dyscyplina w doborze narzędzia, łańcuchowanie kroków, czytanie plików przed ich edycją i testowanie po niej.
Jak stosować: Poproś o raport „obok siebie” dla dwóch modeli i listę wskaźników — to właśnie tę strukturę będziesz naśladować.
Na co uważać: Część zachowania wypływa z wag modelu i nie da się jej odtworzyć promptem; przenosisz metodę, nie inteligencję.
6.Dłuższe planowanie potrafi wyraźnie podnieść słabszy model
Na czym polega: W porównaniu Opus 4.8 brał znacznie więcej tur i rzadziej zastanawiał się przed działaniem niż Fable.
Jak stosować: W playbooku zapisz wprost reguły w rodzaju „najpierw plan, potem działanie” i „test po każdej edycji” — Opus nie dogoni Fable, ale będzie pracował mocniej.
Na co uważać: Wymuszanie długiego planowania przy prostych zadaniach tylko wydłuża pracę bez korzyści.
7.Brak własnych danych? Pożycz cudze sesje
Na czym polega: Na Hugging Face (i nie tylko) użytkownicy opublikowali swoje sesje z Fabłem 5 — pełnoprawny materiał do tej samej analizy.
Jak stosować: Przeprowadź całe ćwiczenie na cudzych rozmowach, jeśli twoja historia z najlepszym modelem jest zbyt krótka.
Na co uważać: Wnioski z obcych projektów nie przełożą się jeden do jednego na twoje zadania i styl pracy.
8.Playbook podłącz na kilka sposobów: hook, skill, CLAUDE.md albo tag
Na czym polega: Plik .md ze zdestylowanymi wnioskami można wstrzykiwać do każdej sesji automatycznie albo przywoływać na żądanie.
Jak stosować: Hook na starcie sesji, gdy reguły mają działać zawsze; linijki w CLAUDE.md jako stały element kontekstu; tag lub przeciągnięcie pliku, gdy potrzebujesz go okazjonalnie.
Na co uważać: Zbyt obszerny dokument wczytywany na starcie potrafi przytłoczyć model — trzymaj playbook zwięzły.
9.Metoda jest niezależna od modelu
Na czym polega: Ten sam proces — destylacja, analiza porównawcza, playbook — zadziała dla Claude, Codexa i modeli open source.
Jak stosować: Wybierz najlepszy model, po którym masz zapisy, jako wzorzec i porównaj z nim model, którego używasz na co dzień.
Na co uważać: Im większa przepaść między modelami, tym mniej da się przenieść.
10.Można zacząć od gotowego playbooka autora
Na czym polega: Autor udostępnia w opisie filmu własny playbook, wszystkie prompty i link do otwartego zbioru danych.
Jak stosować: Jeśli nie chcesz robić analizy sam, weź jego syntezę jako punkt wyjścia i dopasuj do swojego warsztatu.
Na co uważać: Cudze wnioski to skrót — analiza na własnych sesjach będzie lepiej trafiona w twoje projekty.
Redakcyjne tłumaczenie
Życie po Fable
Jeśli cierpisz na objawy odstawienia po Fable 5 — albo po prostu żałujesz, że nie zdążyłeś się z nim pobawić, zanim przepadł — ostatnie dni były dla ciebie pewnie ciężkie. Zdążyliśmy zobaczyć, choć na moment, jak wygląda superinteligentny badacz na poziomie doktora, który pracuje prosto w twoim edytorze.
Nie pomogę ci odzyskać mocy Fable, bo ta siedzi w samym modelu. Znalazłem jednak sposób, by modele Claude i Codex, z których korzystasz na co dzień, zaczęły zachowywać się wyraźnie bardziej jak Fable — i to w zaledwie kilku krokach. To samo podejście można zastosować do modeli open source, które staną się przez to po prostu bardziej użyteczne. Skoro na superinteligencję trzeba poczekać, oto najbliższa jej alternatywa.
Złoto ukryte w plikach JSONL
Mało kto wie, że zdecydowana większość rozmów — zarówno z Codexem, jak i z Claude Code — zapisuje się na twoim komputerze w plikach JSONL. To kolosalne archiwa pełne wywołań narzędzi i metadanych, a w tych metadanych kryje się prawdziwe złoto do wydobycia. Plik pokazany na ekranie to jedna sesja z takimi właśnie metadanymi: tutaj widać wszystkie moje wywołania narzędzi MCP. (Informacja dodatkowa: MCP, czyli Model Context Protocol, to otwarty standard podłączania zewnętrznych narzędzi i danych do modeli językowych.) Głębiej znajdziesz prompty, które wysyłałeś do modelu, jego odpowiedzi, plany, które sobie układał, i narzędzia, które przy tym uruchamiał.
Pomysł jest taki: każ Claude Code przejść przez wszystkie twoje rozmowy i zamienić surowy zrzut w kompletny podręcznik zachowań — playbook — który możesz wręczyć praktycznie każdemu modelowi, open source albo zamkniętemu. Taki dokument można wstrzykiwać na starcie sesji mechanizmem zwanym hookiem albo odwoływać się do niego w trakcie rozmowy, żeby model zachowywał się o wiele bliżej Fable. (Informacja dodatkowa: hook w Claude Code to reguła uruchamiana automatycznie przy określonym zdarzeniu, na przykład na początku sesji.)
Najpierw odchudź dane
Jak widać, większość takiego pliku jest dla nas kompletnie nieprzydatna. Teoretycznie można by załadować do rozmowy setki JSONL-i, ale niepotrzebnie zapchamy kontekst informacjami, które nic nie wnoszą. Zamiast tego — i za chwilę pokażę, jak to zrobić w terminalu — każ Claude Code napisać serię skryptów, które zawczasu przesiewają dane, zostawiają wyłącznie to, co istotne, i poddają to analizie różnic w zachowaniu poszczególnych modeli. Dzięki temu z tysięcy linii zostaje ledwie ułamek — i to właśnie nim karmimy modele.
Sedno triku: każdy plik oznacza, który model wysłał którą odpowiedź. Można więc odcedzić rozmowy Opusa 4.8 od rozmów z Fabłem 5 i zobaczyć, jak bardzo różniło się ich zachowanie — jakie narzędzia wywoływały, jak rozkładały sobie pracę — a potem tę różnicę naśladować.
Nie masz własnych danych? Pożycz cudze
A jeśli ledwo zdążyłeś zamienić z Fabłem słowo? Wtedy nie masz czego analizować. Jest jednak wyjście: pod tym linkiem na Hugging Face — a podobnych zbiorów jest więcej — ludzie opublikowali swoje sesje z Fabłem 5. Możesz na nich przeprowadzić dokładnie to samo ćwiczenie, nawet jeśli dotyczą cudzych projektów, nie twoich. Nie trzeba zapisywać adresu: wrzucę go razem z kilkoma innymi rzeczami do drugiego linku w opisie.
Krok 1. Zmierz skalę
Przechodzimy do terminala. Przeprowadzę cię przez kilka promptów, które prowadzą do pliku-syntezy — a z nim zrobisz, co zechcesz. Zacznij od pytania: ile plików JSONL mam łącznie ze wszystkich sesji? Pytam o to, żeby poznać skalę zjawiska — ile plików obejmuje cała moja historia korzystania z narzędzia. Istotne zastrzeżenie: Fable 5 będzie tylko niewielkim ułamkiem tego zbioru, więc zaraz każę się skupić właśnie na tym filtrze. U mnie wyszło blisko trzy tysiące plików JSONL ze wszystkich projektów.
Krok 2. Napisz skrypt odchudzający
Gdy już znasz skalę, wyślij prompt w tym stylu. Powiedz wprost: balastem w tych plikach są wyniki działania narzędzi, pełne zawartości plików i wyjścia poleceń, które wracają echem do kontekstu. Napisz mi mały skrypt w Pythonie — nazwa dowolna — który bierze plik sesji Claude Code i wycina ten cały ciężar. Zostaw znaczniki czasu, informację, o który model chodzi, czego chciałem i co odpowiedział asystent.
Jeśli robisz to pierwszy raz, każ mu przetworzyć jeden konkretny plik — upewnisz się, że wynik ma dokładnie taki format, jakiego oczekujesz. Po przejściu dostaniesz plik wynikowy; zajrzyj do niego i sprawdź dokładnie. U mnie zatarłem część danych osobistych i została czysta wymiana zdań między mną a agentem. Można też dorzucić kolejne metadane, na przykład pełną listę wywołań narzędzi — widać w niej co do joty, jakie narzędzie asystent uruchomił, w jakiej kolejności i przy jakim modelu.
Krok 3. Złóż korpus rozmów jednego modelu
Mając to, przechodzisz do wyłuskania rozmów właściwego modelu. Wyślij prompt, w którym tłumaczysz, że każda rozmowa ma pole z nazwą modelu — właśnie je widzieliśmy. Potem: wyciągnij z całej mojej historii, ze wszystkich projektów, każdą turę, która przyszła od Claude Fable 5 — dokładnie pod taką nazwą — i złóż wszystko w jeden wspólny korpus. W efekcie powstaje kompletny zapis każdej rozmowy z tym modelem wraz z całym otaczającym ją kontekstem.
Krok 4. Analiza zachowań, ale w liczbach
Do tego poproś o syntezę. Ja piszę: „Daj mi wzorce zachowań jako konkretne, zmierzone liczby, a nie same wrażenia”. Chodzi o coś namacalnego zamiast nieuchwytnego, subiektywnego oglądu jakości rozmowy. Ponieważ wcześniej zbudowaliśmy już przykładowy skrypt, droga od tego etapu do gotowego pliku idzie znacznie szybciej. Powstaje dokument zbierający artefakty ze wszystkich dziesięciu tysięcy rekordów; widać w nim liczbę wiadomości, rozbicie użycia narzędzi na liczby i kolejność pracy.
Jedna z rzeczy, które warto przejąć — dla Opusa, Codexa czy modeli open source — to dyscyplina, z jaką Fable dobierał właściwe narzędzie we właściwym momencie. Z jego rytmów da się sporo wynieść. Analizie podlega nawet rytm jego pracy: przejścia między różnymi poleceniami bash, łączenie kroków w łańcuchy, sposób, w jaki czytał i edytował pliki. Wszystko to było odrobinę elegantsze, bardziej dopracowane i precyzyjne niż to, co robi Opus.
Krok 5. Zestaw modele obok siebie
I teraz kluczowe rozróżnienie. Wybierz model, z którym pracowałeś przed pojawieniem się Fable — powiedzmy Opus 4.8, może Opus 4.7 albo Haiku — i powiedz: „Wykonaj dokładnie tę samą analizę zachowań dla [nazwa modelu] i zestaw oba raporty obok siebie. Pokaż mi różnice w rytmie pracy, w tempie wywołań narzędzi, w sekwencjach akcji i we wskaźnikach takich jak liczba odczytów przed edycją czy testy po edycji”. Chodzi o odtworzenie całej struktury, w jakiej Fable wykonywał zadania.
Po zebraniu pełnego przeglądu agent zmodyfikuje swój skrypt i wróci z podsumowaniem — porównaniem Fable 5 i Opusa 4.8 wykonanym na twoim komputerze. Jeśli twojej historii brakuje rozmiarów do takiej analizy, użyj otwartego zbioru, o którym wspomniałem wcześniej.
Przy samym dole raportu widać, że przy bardzo podobnych problemach Opus 4.8 potrzebował znacznie więcej tur. Często nie zastanawia się przed działaniem tak długo, jak Fable. Tego nie zmienimy, bo wypływa z samych wag modelu. Ale jeśli zdołasz skłonić Opusa, by dłużej myślał i staranniej planował — bardziej się zastanawiał — wciąż nie dostaniesz wydajności Fable 5, ale zauważalnie mocniejszą pracę Opusa.
Krok 6. Zamień wnioski w playbook i podepnij go
Po zakończonej analizie każ zebrać wszystkie kluczowe wnioski o tym, jak Opus mógłby zachowywać się bardziej jak Fable, w osobnym pliku — playbooku. A potem? Otwórz zupełnie nową sesję i odnieś się do tego pliku przez tag, albo podepnij go do hooka. Możesz przywołać agenta Claude Code Guide i w nowej sesji terminala poprosić o wdrożenie. Możesz po prostu przeciągnąć plik do okna albo napisać: „Chcę korzystać z wniosków z pliku [nazwa].md i chcę, żeby zawsze trafiał do kontekstu na starcie sesji”. W tym duchu: „CC, agent Claude Code Guide, podepnij hook do zdarzenia rozpoczęcia sesji, który za każdym razem wstrzyknie ten plik do kontekstu”.
Można to również zamienić w skill albo w kilka linijek w pliku CLAUDE.md, wczytywanych automatycznie przy każdej sesji. (Informacja dodatkowa: CLAUDE.md to plik z instrukcjami, który Claude Code sam dopisuje do kontekstu na początku sesji w danym katalogu; skill to z kolei pakiet instrukcji, który agent przywołuje, gdy zadanie pasuje do jego opisu.) Dróg integracji jest kilka i wybór zależy od tego, jak na co dzień pracujesz. Sedno pozostaje jedno: możesz podnieść wyniki wszystkich swoich modeli, wręczając im taki playbook.
Na koniec
Ułatwię ci sprawę: oddaję do dyspozycji także własny playbook. Jeśli nie chcesz przechodzić całego procesu, weź po prostu syntezę tego, co zaobserwowałem we własnych sesjach Claude Code.
I to w zasadzie wszystko. Mocy Fable 5 nie sklonujemy, ale można zrobić kilka rzeczy, żeby w międzyczasie — zanim sprawa się rozstrzygnie — podkręcić modele, które mamy pod ręką. Jak wspominałem, wszystkie prompty z tego filmu, link do otwartego zbioru danych i mały przewodnik, który właśnie widzieliście, znajdziecie w drugim linku w opisie. A jeśli chcesz zawsze być o krok przed innymi w tematach takich jak Claude Code, Codex i przepływy agentowe w ogóle, zajrzyj do pierwszego linku — do mojej społeczności dla tych, którzy chcą testować nowości jako pierwsi. To oni zobaczyli zapowiedź tego triku, zanim złożyłem go w całość. Jeśli film ci pomógł, będę wdzięczny za łapkę w górę i komentarz — to pomaga zasięgowi i całemu kanałowi. Do zobaczenia następnym razem.