Anthropic znovu sáhl na příkaz /fork v Claude Code. Zní to jako kosmetika. Není. Během pár týdnů je to podruhé, co stejný příkaz znamená něco jiného, a tentokrát z něj vzniklo něco poctivě užitečného. /fork teď spustí agenta na pozadí, který si vezme celý váš kontext - stejný system prompt, nástroje, historii, model i prompt cache - a po doběhnutí vám hodí výsledek zpátky do sezení. Původní chování, tedy odštěpení konverzace do samostatného sezení, které si řídíte sami, se odstěhovalo pod /branch.
A tady mám první výhradu. Pamatujete si, jak se /fork jmenoval minulý měsíc? Já taky ne úplně jistě, a přesně v tom je problém. Changelog je neúprosný: nejdřív se /fork přejmenoval na /branch (verze 2.1.77), teď /fork dostal úplně nový význam. Kdo má starý příkaz v prstech, dnes ťukne /fork a dostane jiné chování než před pár týdny. Když pod oznámením čtu dotazy typu „a jak se to liší od /btw?“, čtu v nich také výtku za rychlost, s jakou Anthropic chrlí funkce, aniž by stíhal vymýšlet jména. Jeden z komentujících to shrnul přesně: brzy bude potřebovat AGI jen na to, aby si pamatoval, co který lomítkový příkaz tenhle týden dělá.
Co je na tom tedy doopravdy nové? Upřímně, míň, než se zdá. Děděný subagent existoval už dřív, schovaný za experimentálním přepínačem CLAUDE_CODE_FORK_SUBAGENT=1. Rozdíl proti běžnému subagentovi je jednoduchý: obyčejný subagent začíná jen s promptem, který mu dáte, kdežto forknutý si nese celou vaši konverzaci. Je to v podstatě klon předchozího promptu. Oznámení tedy hlavně bere starý flag a dělá z něj výchozí chování. K tomu přidává druhou, nenápadnější věc, totiž „návratovou cestu“. O tu komunita prosila už v březnu: starý /fork uměl konverzaci rozdvojit, ale závěry z vítězné větve se nedaly přivést domů. Teď se přivést dají. To je reálné zlepšení, a těší mě o to víc, že je to odpověď na konkrétní žádost lidí, kteří nástroj denně používají.
K čemu to v praxi je
Vezmu to z praxe, ne z dokumentace. /fork umí jako jediný z té trojice tohle: nese si celý váš nakumulovaný kontext, tedy architekturu, konvence, typy i bug, který zrovna řešíte, běží na pozadí a výsledek vrátí do hlavního sezení. Z toho mám jednoduché rozhodovací pravidlo. Když úkol potřebuje všechno, co jsme si v sezení zjistili a řekli, chci u toho dál pracovat a chci odpověď zpátky, sáhnu po /fork. Když je úkol samostatný a moje historie mu je k ničemu, pošlu obyčejného subagenta, je levnější a čistší. A když chci jednu cestu prozkoumat sám a ručně ji řídit, vezmu /branch a vydám se po ní pěšky. Fork pošle zvěda a sebere hlášení. Branch je výlet, který vedete vy.
Teď konkrétně, na TypeScript webové aplikaci. Představte si, že jste hodinu v sezení a stavíte datovou vrstvu nad TanStack Query. Máte zavedený vzor API klienta, ošetření chyb, pojmenování, sdílené typy. Chystáte se drátovat další komponentu a dojde vám, že k hooku, který jste právě dopsali, chcete testy. Tady je fork doma. Napíšete /fork napiš Vitest testy pro useCart hook, drž se konvencí z src/features/auth. Agent zdědí přesně ty konvence, o kterých jsme se v sezení bavili, jede na pozadí, vy stavíte dál a za chvíli vám do sezení spadne hotový testovací soubor. Žádné přepínání kontextu, žádné znovuvysvětlování vašeho stylu.
Druhý případ je riskantní refaktor. Dohadujete se sami se sebou, jestli přejít z Reduxu na Zustand. Hlavní niť tím zaneřádit nechci, takže /fork zkus migrovat cart store na Zustand a vrať diff a všechna tření s typy. Fork to zkusí s plnou znalostí tvaru vašeho store i vašich typů, vrátí verdikt a diff, a vy se rozhodnete. Hlavní sezení zůstane čisté.
Třetí případ je můj nejoblíbenější, totiž rozvětvené investigování nad nejasnou chybou. Např vám padá build na nejasné typové chybě a máte tři podezřelé: špatně nastavený strict v tsconfigu, kolizi verzí typů, nebo generikum, co se někde rozsypalo (abych sázel to, co se mi včera vysypalo). Forknete tři agenty, každý honí jednu hypotézu, všichni s plným kontextem vašeho build setupu. Sesbíráte tři hlášení a ušetříte si sériové zkoušení jedné věci po druhé.
A přesně tady se vyplatí ta nenápadná novinka, dědění prompt cache. Forknutý agent neplatí znovu „aktivaci“ cache, takže každá další paralelní větev je levnější. Bez toho by trojí rozeslání plného kontextu bylo drahé až běda a vy byste nejspíš zůstali poslušně v jedné lineární niti. A právě cena rozhoduje, jestli své úvahy reálně rozvětvíte. Pro agentní vývoj, kde je tou skutečnou měnou koherentní pracovní horizont, tohle je podstatné víc než samotný běh na pozadí.
Brainstorming a jeho háček
U brainstormingu je fork chytřejší, než se na první pohled zdá. Funguje to takhle. V sezení si vybudujete bohaté zarámování problému, tedy cíle, omezení i nápady, které jste už zavrhli. Pak vyšlete několik forků, každý jiným směrem. „Obhaj nudnou, prověřenou architekturu.“ „Obhaj agresivní, neotřelou variantu.“ „Co tohle rozbije v produkci pod zátěží?“ Každý startuje z vašeho plného kontextu, takže neomílá základy, a vrátí se s rozvinutým názorem. Vy pak syntetizujete. Bonus je, že se forky navzájem nevidí, takže se jeden na druhém neukotvují a dostanete tři nezávislé pohledy.
A teď ten háček, který vám jako musím rovnou naoslit, než to zapomenu. Všechny forky dědí vaše zarámování, a s ním i vaše předsudky. Když je prvotní úvaha cinklá, nefér, sklidíte tři cinklé odpovědi. Chci-li opravdu zpochybnit vlastní rámec, pošlu naopak čerstvého subagenta bez historie, právě proto, že není nakažený tím, jak o problému přemýšlím já. Fork tedy beru na prohloubení uvnitř svého rámce, čistého subagenta na jeho napadení a validaci.
O čem oznámení mlčí a jak to celé beru
Zbývají otázky, na které oznámení mlčí, a všechny jsou ryze praktické. Za prvé: sdílí fork prompt cache jen pro čtení, nebo mi může zápisem rozbít cache, o kterou se opírá hlavní sezení? Nevíme. U paralelních běhů je to učebnicový způsob, jak si ustřelit nohu. Za druhé: „výsledek se vrátí“, fajn, ale v jaké podobě? Jako shrnutí? Jako diff? Pro slučování zpět, hlavně u lidí bez programátorského zázemí, potřebuju detailní přehled. Co se změnilo, co prošlo testy, z čeho agent vycházel. Bez ní je fork černá skříňka, které mám slepě věřit. Za třetí: hladké rozhraní z videa (Agent View) terminál vedle hlavního agenta nezobrazí tak svižně, jak klip slibuje, a mezeru zatím lepí nástroje třetích stran. A přidám čtvrtou: kolik forků uběhne najednou a co to udělá s rate limity? I to oznámení nechává otevřené, a u rozvětveného vyšetřování na to narazíte jako první.
Směr se mi líbí bez výhrad. Delegovat úkol s plným kontextem a dostat výsledek zpátky je pro většinu práce použitelnější než posílat subagenta od nuly. Hodnota téhle funkce ale stojí a padá s prompt cache a s tím, jak průhledně si půjde výsledek zkontrolovat, než ho pustím do hlavní větve.
A na jednu věc nezapomínejte: u kódu nikdy nevěřím tomu, co fork napíše do shrnutí. „Hotovo, otestováno“ je věta. Důkaz je diff. Dokud Anthropic nedoplní, jak je to s koherencí cache a v jaké podobě se výsledek vrací, beru /fork jako dobře mířený prototyp, který běží naostro. Užitečný? Ano. Hotový? Ještě ne.