Idle compaction w Claude Code oszczędza cache, ale wznawia pracę na podstawie podsumowania
Funkcja idle compaction w Claude Code może teraz podsumować dużą sesję, zanim wygaśnie jej cache promptu, nawet gdy okno kontekstowe nie jest pełne. Domyślnie funkcja obejmuje sesje zawierające co najmniej 200 000 tokenów. Jej podstawowy kompromis jest wyraźny: Claude wraca do tańszego, krótszego kontekstu, ale kontynuuje pracę na podstawie wygenerowanego podsumowania, a nie każdego oryginalnego kroku rozmowy.
Inżynierka Anthropic, Lydia Hallie, opisała to zachowanie w październikowym 2026 r. poście o idle compaction. Użytkownicy mogą wyłączyć tę funkcję, dodając "idleCompaction": false do pliku ustawień Claude Code. Mogą też zmienić minimalny próg kontekstu za pomocą CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS.
Ta kontrola pojawiła się po tym, jak deweloperzy zgłaszali nieoczekiwane kompakcje w długo działających sesjach. Ich obawa nie dotyczyła samego istnienia kompakcji. Claude Code już wcześniej podsumowywał rozmowy zbliżające się do limitów kontekstu. Spór dotyczył tego, czy licznik bezczynności powinien zastępować wciąż użyteczny transkrypt, aby obniżyć koszt powrotu po wygaśnięciu cache.
Idle Compaction w Claude Code zmienia znaczenie wznawiania
Wznowiona sesja może zachować swoją tożsamość, jednocześnie tracąc dosłowną historię, która pierwotnie ją ukształtowała.
Claude Code przechowuje wiadomości sesji lokalnie i umożliwia ich ponowne otwieranie za pomocą --continue lub --resume. Ta trwałość może sprawiać, że sesja przypomina stałą przestrzeń roboczą. Model rozumuje jednak wyłącznie na podstawie kontekstu wysłanego w bieżącym żądaniu, a nie wszystkich artefaktów zapisanych na dysku.
Przewodnik Anthropic dotyczący okna kontekstowego wyjaśnia, że aktywny kontekst obejmuje historię rozmowy, zawartość plików, wyniki poleceń, instrukcje projektu, pamięci, umiejętności oraz instrukcje systemowe. W miarę gromadzenia tych materiałów Claude Code usuwa starsze wyniki narzędzi, a ostatecznie podsumowuje rozmowę.
Kompakcja polega na zastępowaniu starszego materiału konwersacyjnego krótszym podsumowaniem. Sesja pozostaje dostępna, a Claude może kontynuować pracę. Model nie otrzymuje już jednak każdego zastąpionego kroku słowo w słowo.
Nowy mechanizm bezczynności zmienia moment, w którym może dojść do takiego zastąpienia. Tradycyjna automatyczna kompaktacja reaguje na kurczący się budżet kontekstu. Idle compaction reaguje natomiast na brak aktywności i czas cache promptu, pod warunkiem że sesja jest wystarczająco duża.
Użytkownicy zaczęli zgłaszać komunikat „Compacted while idle, before the prompt cache expired” po pozostawieniu sesji bez nadzoru. Raporty wiązały wdrożenie z Claude Code 2.1.286, choć zachowanie było częściowo kontrolowane przez przełącznik po stronie serwera. Oznacza to, że samo zainstalowanie konkretnej wersji klienta nie musiało ujawniać pełnego stanu wdrożenia.
Domyślne minimum podawane przez Hallie i omawiane w publicznym repozytorium Anthropic wynosi 200 000 tokenów. To próg kwalifikacji, a nie obietnica, że kompaktacja nastąpi dokładnie wtedy, gdy rozmowa osiągnie 200 000 tokenów.
Kwalifikująca się sesja wymaga także odpowiednich warunków cache i wystarczająco długiego okresu bezczynności. Analiza społeczności w zgłoszeniu dotyczącym idle compaction wykazała, że licznik zbliża się do końca godzinnego okresu cache promptu. Użytkownicy obserwowali widoczne zdarzenie około 54–56 minut po ostatniej aktywności.
Te szczegóły czasowe pochodziły od uczestników zgłoszenia analizujących zachowanie klienta i wykonujących lokalne testy. Publiczna dokumentacja Claude Code od Anthropic początkowo nie zawierała pełnej specyfikacji idle compaction. Czytelnicy powinni zatem rozróżniać trzy poziomy dowodów: opis kompakcji Anthropic, ogłoszenie inżynierki oraz analizę szczegółów implementacji przez społeczność.
Zweryfikowana konsekwencja produktowa pozostaje jasna we wszystkich tych źródłach. Po idle compaction Claude wznawia pracę ze skompresowanego stanu rozmowy. Oryginalny transkrypt może nadal istnieć lokalnie, ale jego pełna zawartość nie jest już automatycznie obecna w kontekście roboczym modelu.
To rozróżnienie ma znaczenie, ponieważ lokalna trwałość i uwaga modelu rozwiązują różne problemy. Zapisany transkrypt wspiera audyt i odzyskiwanie informacji. Aktywny kontekst określa, co Claude może uwzględnić w następnej odpowiedzi.
Funkcja wymienia wierność kontekstu na wydajność cache
Idle compaction przenosi pracę z potencjalnie zimnego powrotu do ostatniego okna ciepłego cache, akceptując utratę informacji z podsumowania, aby ograniczyć wielokrotne przetwarzanie kontekstu.
Cache promptów pozwala kolejnym żądaniom ponownie wykorzystać zgodne prefiksy wejściowe. Trafienie w cache zwykle wymaga mniej przetwarzania wejścia niż odtworzenie tego samego dużego prefiksu po wygaśnięciu wpisu cache. Długie sesje Claude Code tworzą wyjątkowo duże prefiksy możliwe do ponownego wykorzystania, ponieważ każdy krok może zawierać wcześniejsze wiadomości, aktywność narzędzi i materiały projektu.
Dokumentacja Anthropic dotycząca prompt caching opisuje czas życia cache oraz odmienne traktowanie zapisów i odczytów cache. Długa sesja, która ostygnie, może wymagać od Claude Code ponownego przetworzenia istotnego prefiksu, gdy użytkownik wróci.
Idle compaction próbuje interweniować przed tym momentem. Gdy duży prefiks pozostaje w cache, Claude Code może poprosić model o jego podsumowanie. Późniejsze żądanie rozpoczyna się od krótszego podsumowania oraz instrukcji i materiałów projektu, które Claude Code przywraca.
Mechanizm ten sprzyja wydajności, gdy użytkownik zamierza wrócić do dużej sesji po przerwie. Zamiast wracać z całym starym kontekstem, użytkownik wraca ze skompresowaną reprezentacją wymagającą przetworzenia mniejszej liczby tokenów.
Kosztem jest wierność informacji. Podsumowania zachowują wybrane fakty i decyzje, lecz nie gwarantują dokładnego zachowania każdego ograniczenia, odrzuconej opcji, obserwacji z testu czy korekty w rozmowie.
Anthropic przyznaje istnienie tego ogólnego ograniczenia w dokumentacji dotyczącej kontekstu. Firma wskazuje, że podczas kompakcji zachowywane są żądania i kluczowe fragmenty kodu, lecz szczegółowe instrukcje z wcześniejszej rozmowy mogą zostać utracone.
To ostrzeżenie nabiera większego znaczenia w sesji programistycznej z agentem. Subtelna instrukcja może określać, która ścieżka migracji jest dozwolona. Odrzucona hipoteza może powstrzymać Claude przed powtarzaniem kosztownego dochodzenia. Drobna anomalia w teście może wyjaśniać, dlaczego pozornie oczywista poprawka jest niebezpieczna.
Dla mechanizmu podsumowującego takie szczegóły mogą wyglądać na drugorzędne, a mimo to pozostawać decydujące dla kolejnego kroku programistycznego. Podsumowanie może trafnie opisywać szeroki cel projektu, a jednocześnie pomijać dowody ograniczające jego implementację.
Ryzyko rośnie wraz z długością eksploracyjnych sesji. Deweloper może poprosić Claude o sprawdzenie kilku modułów, porównanie konkurencyjnych projektów, uruchomienie testów i porzucenie dwóch podejść. Ostateczny kierunek może zależeć od negatywnych wyników rozproszonych po wynikach poleceń i krótkich korektach.
Po kompaktacji Claude może pamiętać, że wybrano jedno podejście, nie zachowując wszystkich powodów niepowodzenia alternatyw. Może wtedy odtworzyć wiarygodne wyjaśnienie, które różni się od faktycznego przebiegu dochodzenia.
Nie oznacza to, że kompaktacja jest z natury wadliwa. Żaden system zarządzania kontekstem o skończonej pojemności nie może zachowywać nieograniczonej historii dosłownie. Spór dotyczy czasu i intencji użytkownika.
W pobliżu twardego limitu kontekstu podsumowanie zapobiega zatrzymaniu sesji. Przed wygaśnięciem cache produkt wybiera jednak wydajność, mimo że sesja może nadal dysponować znaczną pozostałą pojemnością kontekstową.
To główny przeciwnik w tej historii: wydajność cache kontra wierność kontekstu. Nie chodzi o Claude Code przeciwko innemu asystentowi programistycznemu. Każdy długo działający agent musi w końcu zarządzać ograniczonym kontekstem, lecz wyzwalacz bezczynności wyjątkowo wyraźnie uwidacznia równowagę wybraną przez Anthropic.
Dlaczego deweloperzy sprzeciwiali się automatycznemu podsumowaniu
Sprzeciw koncentrował się na nieogłoszonej zmianie stanu, a nie na samym istnieniu kompresji kontekstu.
Deweloper, który ręcznie wpisuje /compact, wie, że Claude podsumuje wcześniejszą rozmowę. Polecenie może uwzględniać priorytet, na przykład zachowanie decyzji dotyczących API lub nierozwiązanych błędów testów. Ten moment tworzy naturalną granicę przeglądu.
Idle compaction usuwa tę bezpośrednią możliwość wyboru. Użytkownik może wyjść na lunch, uczestniczyć w spotkaniu lub czekać na zewnętrzną informację zwrotną, a następnie wrócić do sesji, której aktywna historia uległa zmianie.
Oryginalne zgłoszenie na GitHubie opisywało wiele działających sesji kompaktowanych podczas bezczynności. Zgłaszający stwierdził, że podsumowania pomijały dokładne instrukcje, uzasadnienie decyzji i wcześniej uzgodnione metody. Inni użytkownicy zgłaszali ten sam komunikat, mimo że nie zbliżali się do skonfigurowanego progu kontekstu.
Są to relacje użytkowników, a nie kontrolowane pomiary dokładności podsumowań. Wskazują jednak na wiarygodne ryzyko produktowe, ponieważ dokumentacja Anthropic już stwierdza, że podczas kompakcji mogą zostać utracone wcześniejsze szczegóły.
Początkowa implementacja komplikowała także monitorowanie. Według testów udokumentowanych w zgłoszeniu wczesne idle compactions pojawiały się w metadanych hooków jako manual, mimo że żaden użytkownik nie wpisał /compact.
Hooki Claude Code pozwalają zespołom uruchamiać automatyzację przed lub po zdefiniowanych zdarzeniach. Myląca etykieta wyzwalacza utrudnia odróżnienie świadomego działania użytkownika od przejścia sterowanego zegarem.
Według współpracownika Anthropic w repozytorium Claude Code 2.1.290 zmienił ten wyzwalacz na auto. Odróżnia to idle compaction od jawnie wywoływanego /compact, ale nie rozróżnia w pełni idle compaction od zwykłej automatycznej kompakcji opartej na progu.
Ta niejednoznaczność ma znaczenie dla zespołów używających hooków do zachowywania stanu roboczego. Hook może potrzebować jednej polityki przed awaryjną kompaktacją przy limicie kontekstu, a innej przed kompaktacją wynikającą z bezczynności i cache.
Dyskusja w zgłoszeniu wnioskowała o odrębny wyzwalacz idle. Zgodnie z raportowanym zachowaniem w wersji 2.1.290 zarówno zdarzenia bezczynności, jak i progu kontekstu mogły pojawiać się jako auto. Powiadomienie w terminalu identyfikowało zdarzenie bezczynności dla człowieka, lecz ten komunikat nie musiał być uwzględniony w danych wejściowych hooka.
Szersza lekcja produktowa dotyczy niewidocznej optymalizacji. Deweloperzy zwykle akceptują optymalizację, gdy zmienia ona opóźnienia lub wykorzystanie zasobów bez zmiany semantyki. Podsumowanie może zmieniać semantykę, ponieważ kolejne żądanie modelu otrzymuje inne dowody.
To sprawia, że idle compaction jest bliższe automatycznej migracji stanu niż zadaniu czyszczenia w tle. Identyfikator sesji pozostaje stabilny, podczas gdy podstawa rozumowania się zmienia.
Zespoły prowadzące migracje o wysokiej stawce, reagujące na incydenty lub realizujące rozszerzone przeglądy kodu mają powody, by ostrożnie traktować to przejście. Ich sesje często gromadzą ograniczenia, które pojedynczo są niewielkie, lecz łącznie istotne.
Krótsze sesje są mniej narażone, ponieważ pozostają poniżej minimalnego progu. Przepływy pracy już zbudowane wokół jawnych przekazań również obniżają koszt, ponieważ krytyczny stan istnieje poza transkryptem czatu.
Presja spada więc przede wszystkim na deweloperów, którzy traktują jedną długą sesję Claude Code jako stałego partnera projektu. Czerpią oni największe korzyści z ciągłości, ale też najwięcej tracą, gdy ciągłość staje się zależna od podsumowania bez zamierzonej granicy.
Ustawienie idleCompaction rozdziela dwa różne zabezpieczenia
Użytkownicy mogą wyłączyć idle compaction bez wyłączania automatycznej kompakcji, która chroni sesje zbliżające się do limitu kontekstu.
Według współpracownika Anthropic odpowiadającego w publicznym zgłoszeniu Claude Code 2.1.290 wprowadził dedykowane ustawienie. Użytkownik później potwierdził, że opcja działała w wersji 2.1.291.
Podstawowa konfiguracja wygląda następująco:
Claude Code obsługuje ustawienia w kilku zakresach, w tym na poziomie użytkownika, projektu, lokalnego projektu oraz zasad zarządzanych. Dokumentacja Anthropic settings reference wyjaśnia ich lokalizacje i kolejność pierwszeństwa.
Preferencję obowiązującą dla całego użytkownika można umieścić w osobistym pliku ustawień. Zespół pracujący nad repozytorium może przechowywać ustawienia projektu pod kontrolą wersji, gdy wszyscy powinni korzystać z tego samego zachowania. Ustawienie lokalnego projektu może je nadpisać bez zmiany współdzielonej konfiguracji repozytorium.
Najważniejsze rozróżnienie dotyczy idleCompaction i autoCompactEnabled. Pierwsze ustawienie odnosi się do nowej ścieżki opartej na zegarze. Drugie reguluje szersze zachowanie automatycznej kompaktyzacji.
Ustawienie "idleCompaction": false zachowuje zwykłą kompaktyzację przy osiągnięciu progu, zgodnie z zachowaniem opisanym dla wersji 2.1.290. Jest to przydatne dla programistów, którzy chcą zabezpieczenia blisko pełnego okna kontekstu, ale nie akceptują podsumowywania opartego na cache podczas przerw.
To rozdzielenie bezpośrednio odpowiadało na najważniejszą prośbę użytkowników. Zanim pojawił się dedykowany przełącznik, szersze wyłączenie automatycznej kompaktyzacji mogło również usunąć zabezpieczenie chroniące sesję przed osiągnięciem limitu kontekstu.
Użytkownicy powinni sprawdzić zainstalowaną wersję, zanim założą, że klucz działa. Uruchom:
Publiczne zgłoszenie wskazuje, że ustawienie pojawiło się w wersji 2.1.290, podczas gdy jeden użytkownik wyraźnie potwierdził jego działanie w 2.1.291. Organizacje korzystające z zarządzanych instalacji mogą również otrzymywać aktualizacje według kontrolowanego harmonogramu.
Serwerowa bramka funkcji daje kolejny powód do ostrożności. Ustawienie idleCompaction na true nie musi oznaczać, że Anthropic włączy funkcję dla każdego konta lub środowiska. Pozwala ono na zachowanie po stronie klienta, gdy spełnione są inne warunki kwalifikacji.
Ustawienie false jest istotną kontrolką dla użytkowników, którzy potrzebują rezygnacji z tej funkcji. Zespoły powinny nadal testować zachowanie w ramach własnej instalacji, typu konta i hierarchii zasad.
Ustawienie zarządzane może mieć pierwszeństwo przed wyborem użytkownika. Jest to właściwe dla organizacji z centralną konfiguracją, ale oznacza, że edycja jednego lokalnego pliku może nie dać oczekiwanego rezultatu.
Najbezpieczniejszą metodą weryfikacji jest obserwacja zachowania. Potwierdź wersję klienta, sprawdź efektywne ustawienia i przetestuj opcję w niekrytycznej sesji, zanim zaczniesz na niej polegać podczas ważnej pracy.
Użytkownicy powinni także zachowywać trwałe instrukcje poza historią rozmowy. Anthropic zaleca umieszczanie stałych reguł w CLAUDE.md, który Claude Code ładuje jako kontekst projektu. Ta rada ma zastosowanie niezależnie od tego, czy kompaktyzacja bezczynności jest włączona, czy wyłączona, ponieważ zwykła kompaktyzacja przy zbliżaniu się do limitu nadal może wystąpić.
Przeszukiwalna baza wiedzy inżynierskiej może służyć podobnemu celowi dla zespołów ludzkich. Decyzje, ograniczenia i wyniki analiz stają się artefaktami, które można odzyskać, zamiast całkowicie zależeć od jednej sesji agenta.
Próg 200K można dostosować, ale nie jest limitem kontekstu
`CLAUDE_CODE_IDLE_COMPACT_MIN_TOKENS` zmienia moment, w którym sesja kwalifikuje się do kompaktyzacji bezczynności, a nie rozmiar okna kontekstu modelu.
Hallie podała, że minimum domyślnie wynosi 200 000 tokenów. Użytkownicy mogą podać inną wartość całkowitą poprzez konfigurację środowiska w ustawieniach Claude Code.
Na przykład:
Ten przykład podnosi próg kwalifikacji do 400 000 tokenów. Nie zapewnia większego okna kontekstu, nie rezerwuje 400 000 tokenów dla historii rozmowy ani nie gwarantuje, że kompaktyzacja uruchomi się natychmiast po osiągnięciu tego punktu.
Analiza publicznego zgłoszenia wskazywała dolną granicę 100 000 tokenów. Opisywano, że wartości poniżej tego progu są podnoszone do 100 000. Gdy toczyła się dyskusja, Anthropic nie udokumentowało w pełni zmiennej środowiskowej w publicznej dokumentacji ustawień, dlatego użytkownicy powinni traktować szczegóły implementacji jako zależne od wersji.
Podniesienie progu sprzyja wierności. Więcej dużych sesji może pozostawać bezczynnych bez podsumowania, chociaż powrót po wygaśnięciu cache może wymagać większego przetwarzania wejścia.
Obniżenie progu sprzyja wydajności cache. Więcej sesji kwalifikuje się do kompaktyzacji przed wygaśnięciem, zwiększając szansę, że użytkownicy wrócą do podsumowań zamiast pełnej historii rozmowy.
Właściwa wartość zależy od charakteru przepływu pracy, a nie wyłącznie od pojemności modelu. Długa sesja z powtarzalnym wyjściem narzędzi może zostać dobrze podsumowana. Krótsza dyskusja architektoniczna może zawierać gęste, wzajemnie zależne decyzje, które opierają się kompresji.
Liczba tokenów mierzy rozmiar, a nie znaczenie semantyczne. Sesja debugowania licząca 300 000 tokenów może obejmować tysiące jednorazowych wierszy logów. Przegląd bezpieczeństwa liczący 120 000 tokenów może zawierać liczne precyzyjne założenia dotyczące zagrożeń, które powinny pozostać dosłowne.
Właśnie dlatego konfigurowalne minimum pomaga, nie rozwiązując jednak głównego napięcia. Pozwala zespołom wybrać moment rozpoczęcia kompromisu, ale próg liczbowy nie potrafi rozpoznać, czy bieżąca rozmowa jest bezpieczna do podsumowania.
Programiści mogą ograniczyć ryzyko, tworząc wyraźne punkty kontrolne przed opuszczeniem sesji. Poproś Claude o zapisanie aktywnego celu, potwierdzonych ustaleń, odrzuconych podejść, zmienionych plików, stanu testów i następnego polecenia w notatce repozytorium.
Ta notatka nie powinna jedynie powtarzać zadania. Powinna zawierać dowody potrzebne do wznowienia pracy bez odtwarzania całej rozmowy.
Trwałe ograniczenia powinny znajdować się w CLAUDE.md lub innym autorytatywnym pliku projektu. Tymczasowe ustalenia powinny trafiać do zgłoszenia, dziennika pracy lub dokumentu przekazania. Wygenerowane podsumowania mogą wtedy wspierać ciągłość, nie stając się jedynym zapisem.
Zespoły mogą także używać /context, aby sprawdzić, co zużywa aktywne okno. Jeśli dominuje obszerne wyjście poleceń, bezpieczniejsze może być wyczyszczenie lub przeorganizowanie tego materiału niż pozwolenie ogólnemu podsumowaniu decydować o tym, co jest istotne.
Ręczne /compact nadal jest przydatne na naturalnych granicach. Anthropic twierdzi, że użytkownicy mogą dodawać instrukcje dotyczące zakresu, co daje mechanizmowi podsumowującemu lepszy cel zachowania informacji niż nieobserwowane zdarzenie bezczynności.
Szersza zasada jest prosta: jeśli to możliwe, wybieraj kompaktyzację wokół granic zadań. Progi tokenów zapobiegają awarii, ale granice określone przez człowieka lepiej odzwierciedlają strukturę pracy inżynierskiej.
Co zachowuje kompaktyzacja Claude Code, a czego nie może obiecać
Kompaktyzacja zachowuje roboczą reprezentację sesji, a nie bezstratną kopię jej historii rozumowania.
Dokumentacja Claude Platform firmy Anthropic definiuje kompaktyzację jako zastępowanie starszych tur rozmowy podsumowaniem napisanym przez model. Jej compaction overview wyjaśnia, że aplikacje kontynuują działanie, umieszczając zwrócony skompaktyzowany blok tam, gdzie wcześniej znajdowały się podsumowane wiadomości.
Claude Code obsługuje ten przepływ pracy wewnątrz produktu. Dokładna implementacja różni się od aplikacji bezpośrednio korzystającej z Claude API, ale rezultat koncepcyjny jest podobny: starsze dane wejściowe są reprezentowane przez wygenerowany tekst.
Dobre podsumowanie może zachować prośbę użytkownika, bieżący stan implementacji, ważne ścieżki plików, wyniki testów i pozostałe zadania. Może też radykalnie zmniejszyć ilość wcześniejszego materiału wysyłanego w kolejnych turach.
Nie może zagwarantować dosłownego zachowania każdej wymiany. Mechanizm podsumowujący musi wybrać informacje, uporządkować je i wyrazić w ramach mniejszego budżetu tokenów.
Historia rozumowania stanowi szczególne wyzwanie. Sesja programistyczna często zawiera łańcuch eliminacji. Claude bada jeden plik, formułuje hipotezę, widzi sprzeczne wyniki i zmienia kierunek.
Końcowe podsumowanie może zapisać przyjęte wyjaśnienie, jednocześnie kompresując ścieżkę, która je potwierdziła. Często to wystarcza, ale osłabia zdolność kolejnego modelu do zweryfikowania wniosku.
Wyjście narzędzi tworzy kolejny problem. Logi, błędy kompilatora, plany bazodanowe i ślady testów mogą zawierać drobne szczegóły, których znaczenie staje się widoczne dopiero później. Podsumowanie przygotowane przed tym późniejszym odkryciem nie może wiedzieć, który wiersz okaże się ważny.
Poprawki użytkownika również mogą stracić na sile. „Nie zmieniaj schematu” może pojawić się raz, a następnie nastąpią setki tur. Jeśli nie zostanie podniesione do rangi trwałej instrukcji, kompaktyzacja może zmniejszyć jego znaczenie lub je pominąć.
Dokumentacja Claude Code wyraźnie zaleca CLAUDE.md dla reguł, które muszą przetrwać. Obsługuje także sekcję „Compact Instructions”, która wskazuje mechanizmowi podsumowującemu, co należy zachować podczas kompaktyzacji.
Mechanizmy te ograniczają ryzyko, ale nie sprawiają, że podsumowania stają się bezstratne. Instrukcja kompaktyzacji nadal jest wskazówką dla modelu dokonującego selekcji. Plik instrukcji projektu jest silniejszy, ponieważ Claude Code może ponownie załadować go jako autorytatywny kontekst.
Programiści powinni zatem podzielić wiedzę sesyjną na trzy klasy. Trwałe reguły działania powinny znajdować się w instrukcjach projektu. Zweryfikowany stan inżynierski powinien należeć do plików lub śledzonych zapisów pracy. Eksploracja konwersacyjna może pozostać w transkrypcie i zaakceptować ewentualną kompresję.
Takie podejście poprawia również współpracę. Inny inżynier nie może niezawodnie przejąć nieudokumentowanych niuansów prywatnej rozmowy z agentem. Zwięzły plik przekazania zapewnia zarówno ludziom, jak i agentom wspólny punkt odzyskania.
Praktyczne pytanie nie brzmi, czy podsumowania są dobre, czy złe. Chodzi o to, czy dany fakt może bezpiecznie istnieć wyłącznie wewnątrz podsumowania.
Jeśli utrata szczegółu mogłaby spowodować niebezpieczną migrację, powtarzający się incydent lub nieważny wynik, zapisz go poza rozmową przed opuszczeniem sesji.
Trzy sygnały pokażą, czy kompaktyzacja bezczynności zasłuży na zaufanie
Kolejnym sprawdzianem będzie to, czy Anthropic potrafi uczynić korzyść wydajnościową obserwowalną, nie czyniąc ciągłości sesji nieprzewidywalną.
Pierwszym sygnałem jest oficjalna dokumentacja. Użytkownicy potrzebują stabilnego opisu kwalifikacji, czasu, obsługiwanych wersji, limitów progów, pierwszeństwa ustawień oraz interakcji z zasadami prompt-cache.
Dokumentacja wyjaśniłaby także, czy domyślne 200 000 tokenów obowiązuje konsekwentnie dla wszystkich modeli i kont. Jeśli Anthropic udokumentuje zmienną środowiskową oraz jej dolną granicę, zespoły będą mogły ją konfigurować bez polegania na archeologii zgłoszeń.
Taki rezultat wzmocniłby zaufanie do funkcji. Dalsze poleganie na postach społecznościowych i analizie binarnej osłabiłoby je, ponieważ nieudokumentowane kontrolki mogą zmienić się bez oczywistej ścieżki migracji.
Drugim sygnałem są odrębne metadane hooków. Dedykowany wyzwalacz idle pozwoliłby zespołom traktować kompaktyzację napędzaną zegarem inaczej niż zarówno ręczne polecenia /compact, jak i automatyczną kompaktyzację blisko limitu.
Organizacje mogłyby tworzyć migawki stanu przed zdarzeniem bezczynności, dołączać dostosowane instrukcje kompaktyzacji lub rejestrować telemetrię dotyczącą częstotliwości aktywacji funkcji. Jasna tożsamość zdarzenia ułatwiłaby także analizę incydentów.
Jeśli Anthropic utrzyma obie automatyczne ścieżki pod tą samą etykietą auto, administratorzy będą mieli ograniczoną widoczność przyczyn zmiany sesji. Zachowałoby to lukę między doświadczeniem terminalowym a interfejsami automatyzacji.
Trzecim sygnałem są dowody dotyczące jakości podsumowań w długich sesjach programistycznych. Raporty użytkowników wskazują na brakujące niuanse, ale publiczna dyskusja nie ustala ogólnego wskaźnika błędów.
Przydatna ocena mierzyłaby, czy podsumowania zachowują wyraźne ograniczenia, odrzucone hipotezy, oczekujące zadania, niepowodzenia testów, odwołania do plików i reguły bezpieczeństwa. Powinna również testować powtarzaną kompaktyzację, ponieważ błędy mogą się kumulować, gdy jeden skompresowany stan staje się wejściem dla kolejnego.
Pozytywny wynik wsparłby argument Anthropic dotyczący wydajności. Pokazałby, że większość kwalifikujących się sesji wznawia się wystarczająco dokładnie, aby uzasadnić automatyczną kompresję przed wygaśnięciem cache.
Negatywny wynik wzmocniłby argument za zachowaniem opt-in lub wyższymi domyślnymi progami. Mógłby także skłonić Claude Code do częściowej kompaktyzacji, która zachowuje ostatnie tury dosłownie, jednocześnie podsumowując starszy materiał.
Na razie programiści mają praktyczny wybór. Pozostaw automatyczne kompresowanie nieaktywnej sesji w Claude Code włączone, gdy niższy narzut przy wznawianiu jest ważniejszy niż dosłowna ciągłość. Podnieś próg tokenów, gdy kompromis ten jest uzasadniony tylko w przypadku bardzo dużych sesji.
Wyłącz je za pomocą "idleCompaction": false, gdy wstrzymana sesja musi zostać wznowiona z nienaruszoną dotychczasową aktywną historią. Standardowe kompresowanie przy limicie kontekstu może pozostać włączone jako odrębne zabezpieczenie.
Niezależnie od wybranej polityki nie traktuj długiego czatu jako jedynego zapisu kluczowego stanu prac inżynieryjnych. Umieszczaj trwałe ograniczenia w instrukcjach projektu, zachowuj zweryfikowane ustalenia w plikach i przygotowuj przekazanie obowiązków przed odejściem od pracy.
Kompresowanie nieaktywnej sesji w Claude Code ujawnia podstawową prawdę o agentach programistycznych: ciągłość sesji nie jest równoznaczna z doskonałą pamięcią. Przed kolejną dłuższą przerwą zdecyduj, czego faktycznie wymaga Twój proces pracy.
