O czym jest ten film
- Agent Hermes urósł do 211 tys. gwiazdek na GitHubie w pięć miesięcy, a analiza 1300 komentarzy z Reddita wskazuje, że główną przyczyną migracji jest pamięć, nie liczba integracji.
- Wbudowana pamięć Claude Code jest — zdaniem autora — słaba: zapisuje niewiele, wstrzykuje niewiele, a wyszukuje po słowach kluczowych w ostatnich 30 dniach sesji.
- Autor zamiast przesiadać się na Hermesa odtworzył jego najlepszą cechę (pamięć) wewnątrz Claude Code — wszystko na istniejącym planie subskrypcyjnym, bez zewnętrznego serwera.
- Każdy system pamięci autor ocenia trzema pytaniami: przechowywanie (storage), wstrzykiwanie (injection) i przywoływanie (recall).
- Z Hermesa przejął trzy koncepcje: „zamrożony snapshot” wstrzykiwany na starcie sesji, automatyczne decydowanie przez agenta co zapisać oraz zapisywanie wszystkiego (streszczenie + pełny transkrypt).
- Wskazuje wady samego Hermesa: pętla samo-przepisywania skilli (ryzyko nadpisania dobrych danych), osobny runtime na serwerze oraz twarde limity znaków w pamięci.
- Największy nacisk kładzie na recall: własne rozwiązanie wyszukuje semantycznie (wektory, PGlite + pgvector), a nie tylko po słowach kluczowych jak Hermes (FTS5).
- System cytuje źródła — dokładne słowa, autora decyzji i datę — a gdy nie wie, ma to przyznać, nie zmyślać.
- Potrafi zaimportować dotychczasową historię Claude Code (komenda
npm run memory import sessions), streścić ją Claude Haiku i osadzić jako pamięć od pierwszego dnia. - Zapowiada „TeamOS” — pamięć z tagowaniem właściciela i filtrowaniem zapytań, by członkowie zespołu widzieli tylko swoje projekty; darmowy plan budowy jest w opisie filmu.
Redakcyjne tłumaczenie
Dlaczego ludzie przesiadają się na Hermesa
Agent Hermes urósł od zera do 211 tysięcy gwiazdek na GitHubie w zaledwie pięć miesięcy. Ktoś przeanalizował 1300 komentarzy z Reddita o tym, dlaczego ludzie przechodzą na niego z OpenClaude — i najczęstsza odpowiedź może zaskakiwać. Nie chodziło o liczbę integracji ani nawet o samobudujące się skille. Chodziło o zdolność zapamiętywania absolutnie wszystkiego, a to akurat jest tym, co Claude Code robi najgorzej.
Zamiast się przesiadać, postanowiłem wziąć system pamięci, przez który ludzie porzucają Claude Code i OpenClaude, zachować jego najlepsze części, naprawić to, co Hermes robi źle, i odbudować całość wewnątrz Claude Code. Efekt jest taki, że Claude pamięta decyzję sprzed pół roku, mówi dokładnie, z której rozmowy ona pochodzi, i robi to wszystko na twoim istniejącym planie. Nic z tego nie wymaga zewnętrznego serwera, stawiania VPS-a ani kolejnej subskrypcji. Kompletny plan, według którego Claude może to zbudować za ciebie, także udostępniam.
(Informacja dodatkowa: „gwiazdka” na GitHubie to zapisanie repozytorium do obserwowanych — nieformalny wskaźnik popularności projektu, a nie liczba użytkowników.)
Nie ma sensu prowadzić rozmów z Claude’em, jeśli zapomina on, co powiedziałeś. A domyślnie, według stanu na lipiec 2026, wbudowana pamięć Claude Code jest naprawdę słaba. Rynek to zauważył i zaczął mnożyć frameworki — otwarte i płatne — wokół tego konkretnego problemu. Hermes wystartował w lutym i jest najszybciej rosnącym otwartym agentem 2026 roku.
Firma Kilo przeanalizowała 1300 komentarzy na forum OpenClaude. Najczęściej powtarzana pochwała to „łatwiejsza konfiguracja, lepsza pamięć”. Około 30% przesiadek jako powód podaje właśnie domyślne ustawienia pamięci. Jeden z recenzentów ujął to trafnie: „Zapamiętywanie kontekstu jest warte więcej niż tysiąc integracji”. Trudno się nie zgodzić. Inny opis: „Hermes jest jak młodszy współpracownik, który nigdy niczego nie zapomina”. A bardziej całościowo: te narzędzia przenoszą ograniczony kontekst między sesjami, nawet gdy dodają funkcje pamięci. Hermes tak naprawdę konkuruje z samym modelem sesji. Jego teza jest taka, że kolejna warstwa wartości leży w ciągłości, a nie tylko w lepszej wydajności czatu. Anthropic może ulepszać modele, ile chce, ale wartość tkwi w ciągłości rozmów i w wiernym przywoływaniu tego, co było wcześniej.
Trzy pytania: przechowywanie, wstrzykiwanie, przywoływanie
Jeśli oglądałeś moje poprzednie filmy o pamięci, wiesz, że każdy system pamięci rozkładam na trzy pytania.
Pierwsze to przechowywanie (storage): kiedy pojawia się coś naprawdę istotnego, jak i gdzie zostaje to zapisane? Drugie to wstrzykiwanie (injection): gdy startuje sesja, jakie informacje ładują się automatycznie jako szybko dostępna pamięć krótkoterminowa? Trzecie to przywoływanie (recall): gdy pytasz o coś starego, jak system to odnajduje i czy robi to dobrze — czy znajduje za każdym razem, gdy zadajesz właściwe pytanie?
Claude Code domyślnie zapisuje pojedyncze rzeczy, które sam uzna za ważne, do indeksu memory.md, wstrzykuje niemal nic — tylko Claude.md i ten ubogi indeks memory.md — a przy przywoływaniu przetrząsa poprzednie pliki sesji (domyślnie z ostatnich 30 dni) po słowach kluczowych. Jeśli więc nie wpiszesz dokładnie tego samego słowa, sesja ani powiązana z nią pamięć się nie znajdą.
Stało się jasne: gdy chcesz agenta, który autonomicznie kontynuuje twoje zadania w stylu osobistego asystenta, dostęp do wcześniejszego kontekstu i trwała pamięć są absolutnie kluczowe.
Dlaczego nie używać po prostu Hermesa
Skoro tak, to czemu nie skorzystać z Hermesa od razu? Bo — dla mnie osobiście — ma on ograniczenia, których możesz nie chcieć doświadczyć.
Po pierwsze, pętla samo-przepisywania. Jedna z najbardziej znanych zalet Hermesa jest zarazem jego największym ryzykiem. Jest wiele zgłoszeń o tym, że Hermes przecenia własne wyniki, gdy edytuje swoje skille, i w efekcie nadpisuje dobre informacje — dane, które być może sam napisałeś albo które były poprawne. Użytkownicy dobudowują bramki zatwierdzania i mechanizmy wycofywania, żeby to okiełznać.
Po drugie, to całkowicie inny runtime niż Claude Code — osobny proces żyjący na serwerze lub VPS-ie, z własnym rozliczaniem modelu, własną powierzchnią bezpieczeństwa i własnym cyklem aktualizacji. Wszystko to trzeba aktualizować, utrzymywać i umieć poprawnie skonfigurować.
Po trzecie, sama pamięć ma ograniczenia — twarde limity znaków, które kompresują lub podmieniają wpisy do tego stopnia, że jeden użytkownik zbudował wtyczkę tylko po to, by jego stałe instrukcje nie znikały za każdym razem.
Podsumowując: Hermes udowodnił, że popyt na pamięć istnieje, ale nie udowodnił, że do tych samych efektów potrzebny jest właśnie jego setup. Dlatego zadaliśmy pytanie: czemu nie zbudować tego samemu w Claude Code i mieć coś w pełni odpornego na przyszłość, gdzie pod spodem masz po prostu pliki, które kontrolujesz i możesz przenieść do dowolnego systemu — Claude Code, Codex czy innego?
Gdy przedestylować sławiony system pamięci Hermesa, sprowadza się on do kilku plików Markdown wstrzykiwanych na starcie sesji, agenta zapisującego rozmowy do streszczenia z limitem znaków oraz indeksu wyszukiwania po dawnych rozmowach — który też działa po słowach kluczowych. I tyle. Skoro to takie proste do odtworzenia, wolę mieć to na własność w Claude Code niż przyjmować wszystkie wymienione ograniczenia Hermesa.
Daje to trzy przewagi. Po pierwsze — pełna przenośność: to tylko pliki w folderach, więc wędrują z tobą przez Claude Code, Codex i każdy kolejny interfejs. Po drugie — taniość: żadnego VPS-a, żadnych drugich modeli, wszystko na planie subskrypcyjnym Claude. Po trzecie — to twoje: lokalne, na twojej maszynie, bez powierzchni bezpieczeństwa, o które musisz się martwić, i bez zależności od zewnętrznego systemu.
Co przejęliśmy z Hermesa — trzy koncepcje
Koncepcja pierwsza: zamrożony snapshot. To faza wstrzykiwania. Rzeczy takie jak twój cennik, aktywni klienci czy bieżące decyzje nie powinny być za każdym razem wyciągane z pamięci długoterminowej — powinny już siedzieć w pamięci krótkoterminowej. Hermes wstrzykuje taki wyselekcjonowany snapshot na starcie sesji, więc zrobiliśmy tak samo. Mamy plik memory.md z limitem rozmiaru (maksymalnie 2500 znaków), który przy każdym starcie ładuje się po cichu do sesji, obok „duszy”, profilu i dzisiejszych wspomnień. Limit ustawiliśmy celowo — podobnie jak Hermes — by zapobiec przeciążeniu kontekstu.
Koncepcja druga: przechowywanie. To nie ty masz decydować, co zostaje zapamiętane — powinien to robić agent, na podstawie świeżości informacji i całego kontekstu, rozstrzygając, co trafia do pamięci krótkoterminowej, a co do długoterminowej. Hermes sam sobie podpowiada, by utrwalić wiedzę po zakończonej turze. My robimy podobnie: po każdej turze uruchamiamy hook, który ocenia, czy coś warto zachować jako trwały fakt — decyzję, zmianę ceny, preferencję. Takie rzeczy są promowane do pliku memory.md z limitem 2500 znaków; system sprawdza duplikaty i podmienia wpisy na najświeższe i najtrafniejsze. Obok tego mamy skill „meta-memory write”, który możesz czytać i edytować — reguły, co ma być zapisywane, są twoje. Definiujesz je w czasie, a agent po prostu ich przestrzega.
(Informacja dodatkowa: „hook” to skrypt uruchamiany automatycznie w reakcji na zdarzenie — tutaj po każdej wymianie zdań z modelem.)
Koncepcja trzecia: zapisywanie wszystkiego. Nic nie ma być tracone. Hermes przechowuje każdą sesję w lokalnej bazie i przeszukuje własne dawne rozmowy po surowych wiadomościach — bez streszczania. My, niezależnie od wyselekcjonowanego snapshotu, po każdej turze tworzymy streszczenie, do którego dołączony jest kompletny transkrypt rozmowy. Streszczenie trafia do pamięci długoterminowej niezależnie od ważności, a wraz z nim pełne transkrypty sesji — dzięki temu możesz przywołać dowolną informację, o której kiedykolwiek rozmawiałeś, odwołać się do dokładnej rozmowy albo doładować dodatkowy kontekst. To system idealnego przywoływania.
Cztery rzeczy, których Hermesowi brakuje w przywoływaniu
O przechowywaniu i wstrzykiwaniu w Hermesie mówiliśmy dużo, ale to właśnie recall jest w nim odrobinę ułomny — i uznaliśmy, że to na tyle ważne, że trzeba to rozbudować.
Po pierwsze, wyszukiwanie po znaczeniu, nie tylko po słowach kluczowych. Hermes przywołuje dawne sesje z bazy SQLite za pomocą tzw. wyszukiwania FTS5 — czyli w praktyce dopasowania słów kluczowych. Na jego własnym GitHubie jest nawet otwarte zgłoszenie: „Wyszukiwanie sesji opiera się wyłącznie na dopasowaniu słów kluczowych FTS5”. Oznacza to, że agent znajdzie dawną rozmowę tylko wtedy, gdy zapytanie zawiera dokładnie te słowa, których użyłeś. Zapytasz o „przetwarzanie płatności” — i nie znajdzie rozmowy o Stripe, o ile dosłownie nie padło słowo „Stripe”.
(Informacja dodatkowa: FTS5 to moduł pełnotekstowego wyszukiwania w SQLite; działa na słowach, nie na znaczeniu.)
My uznaliśmy, że recall musi być semantyczny — po znaczeniu. Nasze rozwiązanie osadza wszystko jako wektory w lokalnym zestawie PGlite i pgvector, więc szuka jednocześnie po znaczeniu i po słowach kluczowych, przeranżowuje wyniki, by dać ci najtrafniejsze, a nawet rozszerza kontekst na sąsiadujące fragmenty rozmowy. Uczciwie: do Hermesa da się dobudować zewnętrzne wtyczki pamięci, np. Mem0 czy Honcho, dla pamięci semantycznej — ale to kolejna usługa do utrzymania i nie ma jej w standardzie.
(Informacja dodatkowa: osadzanie wektorowe [embedding] zamienia tekst na liczby tak, by teksty o podobnym znaczeniu leżały blisko siebie; pgvector to rozszerzenie umożliwiające takie wyszukiwanie w bazie.)
Po drugie, ile informacji wyciąga, gdy już trafi na właściwą pamięć. Chcieliśmy, by system w pełni cytował źródła: jakie dokładnie padły słowa, kto podjął decyzję i kiedy. A jeśli tego nie wie — ma to powiedzieć, a nie zmyślać. Zainspirował nas tu Garry Tan z Y Combinatora i jego „Gbrain”. To szczególnie ważne przy pamięci zespołowej: gdy decyzja jest twojego kolegi, a nie twoja, musisz rozumieć stojące za nią myślenie i to, gdzie ta rozmowa naprawdę zmierzała. Dlatego po przeranżowaniu wyników wyciągamy całość i cytujemy dokładnie transkrypt, z którego pochodzą.
Po trzecie, import wcześniejszej historii — żeby nie zaczynać od zera. Używasz Claude Code od trzech czy sześciu miesięcy? Hermes nie potrafi zaimportować twoich wcześniejszych rozmów. Nawet przy przenosinach z OpenClaude przenosi ustawienia, wspomnienia, skille i klucze API, ale nie te wcześniejsze rozmowy. Podobnie w samym Claude Code — nie ma ścieżki do tej historii, a domyślnie i tak zapisuje tylko 30 dni. W praktyce w dniu instalacji Hermesa baza rozmów jest pusta, pamięć jest pusta, a miesiące historii Claude Code pozostają niezapamiętane.
Zajęliśmy się tym wprost: importujemy istniejącą historię sesji i od razu zamieniamy ją w pamięć — długo- i krótkoterminową, przeszukiwalną po znaczeniu, cytowaną i użyteczną od pierwszego dnia. Powiedzmy, że masz 30 dni historii — uruchamiasz jedną komendę: npm run memory import sessions. System wykrywa wszystkie źródła: np. 19 rozmów z ostatnich 30 dni w bieżącym workspace i 30 rozmów z ostatnich 30 dni w całej historii Claude Code — i wybierasz, z którego źródła zaciągnąć i zarchiwizować pamięć. Wybierając np. całą historię Claude Code, uruchamiasz proces, który używa Claude Haiku do streszczania rozmów, przechodzi przez całą historię, streszcza i osadza wszystko w pamięci długoterminowej. Co ważniejsze, zaciąga też pełne transkrypty rozmów w oszczędnym formacie JSON, byśmy mogli do nich później wrócić.
System zapisuje osobny plik pamięci dla każdej daty — ze streszczeniem podjętych decyzji, otwartymi wątkami i wszystkimi sesjami z danego dnia. Dzięki temu przy przywoływaniu przechodzimy przez kompletną „drabinę recall”, która schodzi coraz głębiej, aż znajdzie informację pasującą znaczeniowo do zapytania, i potrafi wskazać oraz zacytować dokładne źródło, rozszerzając je do pełnego transkryptu sesji.
Gdy pytam na przykład „Kiedy ostatnio pytałem o moją markę?”, system zwraca najwyżej rankowane rozmowy na ten temat i — dzięki przeranżowanym wynikom rozszerzonym do pełnej historii — odpowiada: ostatni raz naprawdę pytałeś o markę dzisiaj, podaje datę i dokładne pytanie. Dodaje, że wcześniej nie było dnia, w którym o markę pytałeś bezpośrednio — była wcześniejsza aktywność, ale w innym kontekście: dotyczyła konfigurowania kontekstu marki, a nie zadawania o nią pytania. Dostaję pełne podsumowanie tego, czego szukałem, wraz z informacją, że są inne dopasowania, które jednak nie pasują ściśle.
Po czwarte, zakresowanie pamięci dla zespołów i klientów. Chcesz, by praca jednego klienta była odizolowana od pracy drugiego, a nowy członek zespołu widział tylko to, co powinien — tylko wspomnienia otagowane projektami, do których należy. Jeden wspólny mózg, każde wspomnienie otagowane właścicielem, każde zapytanie filtrowane po tym, kto pyta. Nazywamy to wewnętrznie TeamOS — rozwinięcie idei Gbrain Garry’ego Tana o to, jak przenieść ją do Claude Code, ale w wielu członkach zespołu naraz: dzieląc się tam, gdzie trzeba, i zachowując prywatność tam, gdzie nie. Wersję beta TeamOS udostępniliśmy w naszej społeczności i testujemy ją, by poznać jej ograniczenia i rozwijać ją dalej.
Podsumowanie
Powodem, dla którego ludzie sięgają po Hermesa, jest pamięć. Pamięć rozkłada się na trzy pytania: przechowywanie, wstrzykiwanie i przywoływanie. Logikę przechowywania i wstrzykiwania przejęliśmy z Hermesa i wdrożyliśmy u siebie. Recall uznaliśmy za niewystarczający dla naszych zastosowań biznesowych, więc oparliśmy jego logikę na innych systemach pamięci — Mem Search, Mem Palace i kilku innych — i zrobiliśmy to wszystko na planie subskrypcyjnym, wewnątrz Claude Code. Nie potrzebujemy drugiego asystenta, który jest czarną skrzynką do instalacji.
Jeśli chcesz wdrożyć podobną pamięć, w opisie pod filmem załączyłem całkowicie darmowy plan budowy własnego systemu pamięci w stylu Hermesa. A jeśli wolisz pominąć budowę i mieć pamięć załadowaną od pierwszego dnia — to już działa w Agentic OS w naszej społeczności; to instalacja jedną linią, więc uruchomisz system w jakieś 10 minut, z wczytaną całą wcześniejszą historią rozmów.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Pamięć bije integracje
Na czym polega: Analiza 1300 komentarzy pokazała, że użytkownicy przesiadają się na Hermesa głównie dla trwałej pamięci, a nie dla liczby integracji („zapamiętywanie kontekstu jest warte więcej niż tysiąc integracji”).
Jak stosować: Oceniając narzędzia AI do pracy, stawiaj ciągłość i wierne przywoływanie kontekstu wyżej niż listę wtyczek i konektorów, których zwykle i tak nie używasz.
Na co uważać: To teza autora poparta jedną analizą (firmy Kilo) — potraktuj liczby (211 tys. gwiazdek, 30% przesiadek) jako wskazówkę popularności, nie jako twardy dowód wyższości technicznej.
2.Trzy pytania jako rama oceny pamięci
Na czym polega: Każdy system pamięci warto rozbić na przechowywanie (co i gdzie się zapisuje), wstrzykiwanie (co ładuje się automatycznie na starcie) i przywoływanie (jak odnajduje stare informacje).
Jak stosować: Zanim wybierzesz lub zbudujesz system pamięci, odpowiedz na te trzy pytania osobno — pozwala to szybko zlokalizować słabe ogniwo (u autora był to recall).
Na co uważać: Dobra odpowiedź na dwa pytania nie ratuje trzeciego. Świetne przechowywanie jest bezużyteczne, jeśli recall nie znajduje danych na sensowne zapytanie.
3.Domyślna pamięć Claude Code jest słaba
Na czym polega: Według stanu na lipiec 2026 Claude Code zapisuje niewiele, wstrzykuje głównie Claude.md i ubogi memory.md, a przeszukuje sesje po słowach kluczowych i domyślnie tylko z ostatnich 30 dni.
Jak stosować: Nie licz, że wbudowana pamięć zapamięta decyzje sprzed miesięcy — jeśli tego potrzebujesz, dobuduj własną warstwę lub eksportuj kluczowe ustalenia do stałych plików.
Na co uważać: To ocena z konkretnej daty i szybko zmienia się między wersjami — zweryfikuj limit 30 dni i mechanikę indeksu w swojej aktualnej instalacji, zanim się na tym oprzesz.
4.Semantyczny recall zamiast słów kluczowych
Na czym polega: Wyszukiwanie po słowach kluczowych (FTS5 w Hermesie) nie znajdzie rozmowy o Stripe, gdy pytasz ogólnie o „przetwarzanie płatności”. Osadzenia wektorowe wyszukują po znaczeniu.
Jak stosować: Do pamięci długoterminowej używaj wyszukiwania hybrydowego — semantycznego (wektory, np. pgvector) plus słów kluczowych — i przeranżowuj wyniki, by na wierzch wyszło to najtrafniejsze.
Na co uważać: Wyszukiwanie semantyczne bywa „zbyt kreatywne” i zwraca luźno powiązane trafienia — łącz je z filtrem słów kluczowych i cytowaniem źródła, by odróżnić realne dopasowanie od skojarzenia.
5.Zamrożony snapshot z twardym limitem znaków
Na czym polega: Najważniejsze, stale potrzebne fakty (cennik, aktywni klienci, bieżące decyzje) trzymaj w pamięci krótkoterminowej wstrzykiwanej na starcie — u autora to plik memory.md z limitem 2500 znaków.
Jak stosować: Wydziel mały, ograniczony rozmiarem plik „always-on” z tym, co musi być pod ręką od pierwszej sekundy sesji, i celowo ogranicz jego wielkość.
Na co uważać: Limit chroni przed przeciążeniem kontekstu, ale przy podmianie wpisów łatwo stracić coś ważnego — pilnuj logiki deduplikacji i miej długoterminową kopię wszystkiego poza snapshotem.
6.Niech agent decyduje, co zapamiętać — ale wg twoich reguł
Na czym polega: Po każdej turze hook ocenia, czy padło coś trwałego (decyzja, zmiana ceny, preferencja) i promuje to do pamięci krótkoterminowej; reguły „co zapisać” są w edytowalnym skillu.
Jak stosować: Zautomatyzuj zapisywanie faktów po każdej wymianie, ale trzymaj reguły w czytelnym, edytowalnym pliku, który dopracowujesz w czasie — nie zdawaj się w pełni na intuicję modelu.
Na co uważać: To dokładnie miejsce, gdzie Hermes „przecenia własne wyniki” i nadpisuje dobre dane. Zadbaj o sprawdzanie duplikatów, a przy ważnych wpisach rozważ bramkę zatwierdzania lub wersjonowanie.
7.Zapisuj wszystko: streszczenie plus pełny transkrypt
Na czym polega: Niezależnie od wyselekcjonowanego snapshotu, każda tura trafia do pamięci długoterminowej jako streszczenie z dołączonym kompletnym transkryptem — nic nie ginie.
Jak stosować: Archiwizuj pełne transkrypty w oszczędnym formacie (np. JSON) obok streszczeń, by móc wrócić do dokładnych słów, a nie tylko do skróconej wersji zdarzeń.
Na co uważać: Pełne transkrypty rosną szybko — zaplanuj miejsce, format i sposób indeksowania, inaczej recall spowolni, a koszt osadzania wektorów urośnie.
8.Cytowanie źródeł zamiast zmyślania
Na czym polega: System przy przywoływaniu podaje dokładne słowa, autora decyzji i datę, a gdy nie wie — ma to przyznać. Szczególnie istotne przy pamięci zespołowej.
Jak stosować: Wymuś w promptach recall, by odpowiedź zawsze zwracała cytat i metadane źródła (kto, kiedy), a przy braku dopasowania jawnie mówiła „nie znaleziono”.
Na co uważać: Sama instrukcja „nie zmyślaj” nie gwarantuje jej przestrzegania — powiąż odpowiedź twardo z konkretnym transkryptem, by cytat był weryfikowalny, a nie wygenerowany.
9.Import istniejącej historii, by nie zaczynać od zera
Na czym polega: Komenda npm run memory import sessions wykrywa źródła, streszcza dawne rozmowy Claude Haiku i osadza je w pamięci, zaciągając też pełne transkrypty — pamięć jest gotowa od pierwszego dnia.
Jak stosować: Przy wdrażaniu nowego systemu pamięci najpierw zaimportuj dotychczasową historię, zamiast startować z pustą bazą — inaczej tracisz miesiące wcześniejszych ustaleń.
Na co uważać: Claude Code domyślnie trzyma tylko 30 dni historii, więc importuj jak najwcześniej. Streszczenia robione tańszym modelem (Haiku) mogą gubić niuanse — zachowaj transkrypty do weryfikacji.
10.Buduj na plikach — przenośność ważniejsza niż wygoda gotowca
Na czym polega: Cały system to pliki w folderach, więc przenosi się między Claude Code, Codex i kolejnymi interfejsami, działa na istniejącej subskrypcji i nie ma zewnętrznej powierzchni bezpieczeństwa.
Jak stosować: Projektując własną pamięć, trzymaj dane w otwartym, przenośnym formacie plikowym, który kontrolujesz — unikniesz uzależnienia od jednego runtime’u i drugiej subskrypcji.
Na co uważać: To także materiał promujący płatną społeczność i „Agentic OS” autora — darmowy jest jedynie plan budowy w opisie. Zanim uznasz to za gotowe rozwiązanie, licz się z tym, że sam musisz zbudować i utrzymać całą tę infrastrukturę (PGlite, pgvector, hooki, import).