Představme si kolegu, který právě upravil několik souborů, spustil testy a v tu chvíli musí odejít. Náhradník dostane stručné shrnutí porady, ale neví, jestli testy doběhly a co jejich výsledek znamená. Přesně takovou organizační nepříjemnost dnes řeší i programovací AI. O kapacitě modelů se mluví v obřích číslech. O tom, jak si předávají rozdělanou práci, podstatně méně. Přitom právě na tom může stát rozdíl mezi plynulým pokračováním a dalším kolem vysvětlování.
Malý projekt catnap od Martina Lippa nabízí rozumnou odpověď: přestávku plánovat dřív, dokončit rozpracovaný krok a napsat si poznámku pro pokračování. Na Radyz jsme o něm informovali v rychlé zprávě o předání práce v Claude Code. Zajímavější než příslib úspor je ale samotný přístup. Agent, kterému svěřujeme delší úkol, potřebuje umět práci přerušit stejně poctivě, jako ji začal.
Plné okno není dobrý vedoucí projektu
Model při práci používá omezený prostor pro aktuální konverzaci a další podklady. Jak přibývají instrukce, přečtené soubory a výsledky nástrojů, tento prostor se zaplňuje. Jedním z řešení je zhutnění kontextu: starší průběh se nahradí kratší reprezentací a práce pokračuje. Problém je v tom, že dosažený kapacitní limit nemusí mít nic společného s vhodným okamžikem v úkolu.
Catnap podle aktuální dokumentace upozorní Claude Code ve výchozím nastavení při dosažení poloviny kontextového okna. Model má dokončit celek, na kterém pracuje, připravit předávací poznámku a vyvolat zkrácení konverzace. Při šedesáti procentech přijde důraznější pobídka. Jako pojistku projekt nastavuje automatické zkrácení samotného Claude Code na hodnotu 70 procent; tato interní hranice Claude Code se podle metodiky počítá z okna zmenšeného o rezervu pro výstup, nikoli z celé kapacity jako pobídky catnapu. Tyto hranice jsou nastavitelné. Nejde o větší paměť, ale o jiné načasování práce s tou stávající.
V běžném režimu projektu předávací poznámka nahrazuje standardní shrnutí Claude Code; spolu s ní se vracejí také uchovávané uživatelské zprávy a použité dovednosti. Rozsah jejich zachování má své limity. Dokumentace navíc popisuje prostředí spravovaných organizací, kde příslušný hook nemusí být dostupný a standardní shrnutí zůstává. Je proto přesnější mluvit o konkrétní integraci do Claude Code než o univerzálním léku na zapomínání AI.
Tenhle návrh se mi líbí právě svou obyčejností. Nečeká, až se model stane neomylným. Zavádí pracovní návyk, který by měl mít i člověk: nenechat po sobě otevřený úkol bez informace, kde skončil. Větší kontextové okno takový návyk nenahrazuje. Jen dovolí nashromáždit delší historii, kterou bude jednou stejně potřeba probrat.
Úsporu nepřinesla jen chytrá poznámka
Autor zveřejnil vlastní srovnání dokončených programovacích úloh, včetně metodiky a výsledků. Důležité je jeho poctivé rozlišení: velká část vykazované úspory proti výchozímu chování Claude Code pochází z dřívějšího zkracování konverzace. Když jako soupeře použil automatické zkrácení v podobném místě, celkové rozdíly byly v mezích variability těchto běhů. Samotné elegantnější předání tedy nelze prodávat jako prokázaný zdroj dramaticky nižšího účtu.
To je užitečná lekce pro mnohem širší nabídku AI doplňků. Pokud nástroj současně změní okamžik zásahu a způsob jeho provedení, srovnání s původním nastavením neřekne, která změna pomohla. Čtenář by neměl dostat jen vítězný sloupec. Potřebuje vědět, zda stejného ekonomického výsledku nelze dosáhnout jednodušší úpravou nastavení.
Ani počet zpracovaných tokenů není totéž co zaplacené peníze. Autorova metodika rozlišuje mimo jiné čtení z mezipaměti, nové zápisy a výstup modelu; tyto položky nemají stejnou cenu. Z levnějšího opakovaného čtení proto nelze udělat stejnou úsporu jako z odstraněného dražšího volání. A výpočet podle cen API není automaticky změnou limitu nebo faktury člověka s předplatným.
Podstatná hranice těchto výsledků je jednoduchá: jde o autorovy syntetické programovací úlohy, ne nezávislé měření práce několika vývojářských týmů. U menších rozdílů sám upozorňuje na malý počet běhů a značný rozptyl. Náš text je rozborem dokumentace a zveřejněné metodiky, nikoli provozní recenzí. Přesto má projekt hodnotu: ukazuje, co při hodnocení podobných nástrojů porovnávat.
Dobře si pamatovat nestačí. Musí se také odpovědět
Ještě zajímavější je test zachování instrukcí z 20. října. Autor nechal model pracovat na syntetických úkolech a průběžně mu v konverzaci sděloval pravidla a fakta. Po zkrácení se ptal, co si vybaví, bez otevírání souborů. V popsané náročnější variantě si model vybavil všech dvacet položek jak při použití catnapu, tak v kontrolních bězích s automatickým zkrácením. To je povzbudivé, ale není to důkaz, že se v libovolně dlouhé skutečné zakázce nikdy nic neztratí.
Test přitom odhalil jiný problém. Když se předávací poznámka připraví současně s poslední akcí, model ještě nemusel vidět její výsledek. Po návratu pak může navázat prací, ale zapomenout uživateli poslat odpověď, kterou mu dlužil. Autor tento jev ve starších bězích zaznamenal a v aktuálním kódu 0.3.10 upravil instrukci pro pokračování. V nově popsané sadě už odpověď na kroku se zkrácením dorazila ve všech sledovaných případech. Zároveň uvádí, že řídicí a vyhodnocovací skripty tohoto testu zatím v repozitáři nejsou.
Tady leží skutečně zajímavý detail. Agent si může správně vybavit pravidla a přesto nesplnit závazek vůči člověku. Paměť tedy není totéž co dokončená práce. Uživateli nepomůže, že systém uvnitř pokračuje vzorně, pokud nedostane výsledek, varování nebo jasnou informaci, že se stále čeká.
Předávací poznámka není potvrzení o provedení
Pro praxi bych z toho vyvodil přísnější pravidlo než jen „napiš shrnutí“. Dobré předání musí oddělit záměr, zahájenou akci a ověřený výsledek. V modelové situaci nestačí poznámka „otestovat změnu“. Potřebujeme vědět, které soubory se změnily, zda test už běží, kde hledat jeho výstup a co zatím nebylo potvrzeno. Poznámka „testy prošly“ je přípustná až tehdy, když jejich výsledek agent skutečně přečetl.
U čtení souboru je opakování obvykle jen zdržení. U odeslaného e-mailu, objednávky nebo publikace už může vytvořit druhý skutečný zásah. Proto bych po návratu od agenta chtěl nejprve ověřit stav předchozí akce, ne ji automaticky spustit znovu. To je naše redakční doporučení pro práci s agenty, nikoli bezpečnostní záruka catnapu nebo závěr autorova programovacího testu.
Pro tým, který si chce podobný postup ověřit, bych sledoval několik prostých věcí: zda se po přerušení neztratí platná instrukce, zda se znovu neprovede už hotová akce, kolik souborů musí agent opět načíst a zda uživatel dostane slíbenou odpověď. Teprve potom má smysl řešit rychlost přestávky a účet. Bleskové navázání na chybný stav není produktivita.
Vedle toho existuje další vrstva: dlouhodobé ukládání znalostí mimo právě otevřenou konverzaci. Tím se zabývá například OneMemory se sdílenými poznámkami mezi asistenty. Je to příbuzný, ale odlišný problém. Úložiště poznámek samo neurčí správný okamžik přerušení a dobře načasovaná přestávka sama nezaručí úplný archiv projektu.
Dospělost agenta poznáme i podle toho, jak přestane
Catnap je čerstvý projekt s kódem pod licencí MIT, nikoli nová schopnost samotného jazykového modelu. Jeho dokumentace otevřeně přiznává závislost na měnícím se rozhraní Claude Code i možnost ztráty detailů při zkrácení. Právě taková střízlivost je cennější než tvrzení, že si AI už všechno zapamatuje.
Od agentů chceme stále delší samostatnou práci. O to méně bychom měli tolerovat předání ve stylu „nějak už pokračuj“. Za mě je správně připravené přerušení součástí kvality výsledku, ne kosmetikou rozhraní. Model, který umí napsat další soubor, je užitečný. Agent, který po návratu přesně ví, co udělal, co pouze zamýšlel a co ještě dluží člověku, je podstatně blíž nástroji, na který se dá spolehnout.
