Krátká verze
- Pět týdnů jsem svého kódovacího agenta provozoval v rozdělení: hlavní model, Opus a později Fable, čte, rozhoduje a reviduje, a pracovní agent píše kód podle písemného zadání. Říkám tomu vzor architekt a je to teď veřejná skill: architect-skill na GitHubu , licence MIT.
- Hlavní model přestal psát. Za 49 architektonických session upravil zdrojový soubor 6krát při 1 467 promptech. Ve 275 běžných session za stejné týdny upravil 244 souborů při 3 081 promptech. To je 0,4 proti 7,9 na 100 promptů.
- Celkový počet tokenů na prompt neklesl. Dva týdny rostl, a to výrazně, pak se vrátil tam, kde jsou běžné session. Změnilo se jen to, kdo je utratil: podíl Opusu na tokenech pracovníků klesl ze 100 % na zhruba 4 % a od 14. září stojí prompt v architektonické session 364 tis. vážených tokenů na hlavním modelu, 205 tis. u pracovníků Sonnet a 80 tis. u pracovníků Opus.
- Právě na tomto rozdělení záleží u předplatného. Claude Max měří svůj týdenní limit pro všechny modely podle sazby každého modelu, takže token Sonnetu ho čerpá na 40 % toho, co token Opusu, a Fable má vlastní, přísnější týdenní limit, kterého se žádný pracovník nedotkne.
- Zkoušel jsem také směrovat pracovníky na DeepSeek přes bezhlavý Claude Code. Při ceníkových cenách vyšel stejný provoz na 10 $ místo 202 $ u Sonnetu nebo 505 $ u Opusu. U předplatného tato úspora neexistuje, protože předplatné je už zaplacené. Opustil jsem to. Pokud platíte za token, čtěte tu část i tak, protože jde právě o ta čísla.
Toto je třetí článek ze série. První měřil, co jedno nastavení udělalo s kontextovým oknem, o 17 % méně tokenů , a druhý vysvětluje, kolik stojí kontextové okno a proč. Tento je o té druhé páce: ne o tom, jak velký kontext je, ale který model ho drží.
Co je ten vzor
Session kódovacího agenta dělá dva druhy práce. Myslí: čte kódovou základnu, zjišťuje, co změnit, rozhoduje o názvech, signaturách a okrajových případech, kontroluje diff. A píše: vytváří kód, spouští testovací soubor, opravuje lint. Právě myšlení je to, za co si špičkový model zaslouží svou cenu. Psaní ne. Většina z něj je určena rozhodnutím, které mu předcházelo, a menší model vykoná rozhodnutý plán zhruba stejně dobře jako velký.
Skill tedy session rozděluje. Hlavní model je architekt. V hlavní smyčce dělá všechno kromě úpravy zdrojového souboru:
- Vyptá se na požadavek a prozkoumá kódovou základnu.
- Udělá návrhová rozhodnutí: přístup, tok dat, názvy, signatury, okrajové případy. Nejbližší existující vzor, který se dá napodobit. Nejmenší změna, která řeší příčinu.
- Rozloží práci na řezy, z nichž každý vlastní disjunktní množinu souborů.
- Napíše jedno implementační zadání na každý řez.
- Zkontroluje vrácený diff, spustí kontroly, udělá commit.
Pracovník je subagent s čistým kontextovým oknem. Dostane zadání a nic jiného, napíše kód, spustí testovací soubory, které zadání uvádí, a vrátí krátkou strukturovanou zprávu. Pak se jeho kontext zahodí. Nikdy se nestane součástí historie hlavní session, což je důležitější, než to zní: všechno, co hlavní session přečte, se znovu posílá při každém dalším volání, takže pracovník, který ve svém vlastním kontextu přečte dvanáct souborů a testovací log, drží to všechno mimo účet architekta.
Zadání je celá smlouva. Moje má sedm polí a skill je hlavně o tom je dobře vyplnit:
## Implementation brief: <slice>
Goal: one sentence, observable outcome
Context: what exploration found: excerpts, the pattern to mirror, line anchors, gotchas
Files: paths to create/modify, exclusive ownership for this slice
Design: the decided approach: data flow, names, signatures, edge cases
Constraints: project rules that apply: style, layers, security
Out of scope: what not to touch, including files owned by other slices
Verify: exact commands and expected outcome
Zadání obsahuje rozhodnutí, ne možnosti. Pokud stále vážím dva přístupy, ještě nejsem připraven delegovat.
Existuje jedna výjimka. Delegování má fixní režii: sepsání zadání, start pracovníka, čtení zprávy, kontrola diffu. Oprava překlepu, hodnota v konfiguraci, zvýšení verze, smazání mrtvého klíče, jednořádková oprava a její regresní test: u těch architekt upravuje přímo, protože zadání by stálo víc než samotná úprava. Kritérium jsou náklady, ne počet řádků. Ve chvíli, kdy úprava potřebuje návrhový úsudek nebo se dotýká cesty, kterou repo označuje za kritickou, jde k pracovníkovi.
Připraveni rozšířit své podnikání?
Začněte svou bezplatnou zkušební verzi ještě dnes a viďte výsledky během několika dní.
Proč předplatné mění aritmetiku
Pokud platíte za token, je to jednoduché. Opus 5 má ceníkovou cenu 5 $ za milion vstupních tokenů a 25 $ za milion výstupních; Sonnet 5 pak 2 $ a 10 $. Každý token implementace, který se přesune z Opusu na Sonnet, stojí 40 % toho, co stál.
Já platím předplatné a tam je situace jiná a podle mě silnější. Claude Max má dva týdenní limity, ne jeden: limit přes všechny modely, který čerpá každý token podle sazby daného modelu, a samostatný, přísnější limit, který čerpá jen Fable. Opus vlastní limit nemá. Z toho plynou dva efekty rozdělení. Práce, kterou udělá pracovník Sonnet, čerpá společný limit na 40 % sazby, jakou by čerpal pracovník Opus, takže přesun dvou třetin tokenů session na Sonnet prodlouží týden, i když celkový počet tokenů zůstane stejný. A když je architektem Fable, každý token, který neutratí psaním, je token, který zůstane na limitu, jenž se vyčerpá první. Takže i kdyby vzor architekt utratil přesně stejný počet tokenů jako běžná session, kdo je utratí, by pořád rozhodovalo o tom, kdy týden skončí.
To “i kdyby” nakonec odvedlo hodně práce.
Co říkají přepisy
Claude Code zapisuje každou session do přepisu ve formátu JSONL a každé spuštění pracovníka do souboru vedle, v adresáři session. Mám je všechny od 19. srpna: 324 interaktivních session se třemi a více prompty, z nichž 49 použilo ten vzor, tedy spustilo agenta-implementátora nebo mu poslalo zadání. Tokeny se váží stejně jako účet: čerstvý vstup 1, zápisy do cache 1,25 nebo 2, čtení z cache 0,1. Běhy CI jsou vyloučeny.
Čtěte to zleva doprava a první dva týdny to není příběh úspěchu.
V týdnu od 24. srpna stála architektonická session 1,40 mil. vážených tokenů na prompt. Běžné session ve stejném týdnu stály 0,42 mil. Třiapůlkrát víc a téměř celý přebytek byl oranžový: pracovníci Opus. Dal jsem pracovníkům dobrý model a žádná pravidla, a chovali se jako dobrý model bez pravidel. Medián spuštění pracovníka Opus byl ten týden 176 tahů. Několik z nich spustilo celou backendovou testovací sadu, což do kontextu vloží asi 100 kB výstupu, který se znovu posílá při každém dalším tahu. Jedna session se šesti pracovníky ze 14. září, už když jsem začal věci utahovat, přesto spálila 245 mil. vstupních tokenů za 1 585 tahů, aby vyprodukovala asi šest tisíc řádků diffu. Kešování promptů celou dobu fungovalo s 91,6% mírou zásahu. Účet byl o objemu, ne o ceně.
Pruh s pracovníky ukazuje, kde pravidla zabrala. Tři z nich odvedly většinu práce a napsal jsem je do definic agentů, ne do zadání, takže platí, ať si je pamatuju, nebo ne:
- Pracovník nikdy nespouští celou testovací sadu. Spouští testovací soubory, které uvádí jeho zadání. Kontroly spouští architekt.
maxTurnsje v definici agenta zastropováno, 140 pro Sonnet a 160 pro Opus. Řez, který potřebuje 250 tahů, dostal špatné zadání.- Řez zůstává pod zhruba dvanácti soubory a zadání pod zhruba 8 kB. Zadání se také znovu posílá při každém tahu.
V týdnu od 31. srpna byl medián spuštění pracovníka 57 tahů a 0,8 mil. vážených tokenů. Od 14. září, kdy jsem výchozí směrování přepnul na Sonnet, to bylo 40 tahů a 0,6 mil. a od té doby žádný pracovník nespustil celou sadu.
Celkový počet na prompt následoval: 711 tis., 425 tis., 684 tis., 483 tis. za poslední čtyři týdny, proti běžným session s 505 tis., 425 tis., 318 tis., 431 tis. Architektonické session teď stojí zhruba tolik co běžné session. Ve dvou ze čtyř týdnů o něco víc, v jednom o něco méně. Co za to kupují, ukazují následující dva grafy.
Přihlaste se k odběru newsletteru
Získejte nejnovější tipy, trendy a nabídky zdarma.
Hlavní model přestal psát
Toto je číslo, které jsem chtěl změnit, a změnilo se. V běžných session provedl hlavní model 244 volání Edit nebo Write na zdrojové soubory při 3 081 promptech. V architektonických session jich bylo 6 při 1 467 promptech. Těch 6 jsou samé výjimky pro malé úpravy, které umím vysvětlit.
Pracovníci mezitím byli produktivní. 85 spuštění pracovníků provedlo 2 510 úprav zdrojových souborů. Když sečtu hlavní smyčku a pracovníky, architektonická session vyprodukovala 2 516 úprav kódu z 1 467 promptů; běžné session 943 z 3 081. Na jednu úpravu kódu utratila architektonická session celkem 403 tis. vážených tokenů a 330 tis. na modelu z řady Opus. Běžná session utratila 1 410 tis. a 1 324 tis. S tím srovnáním chci být opatrný, protože obě populace nedělají stejnou práci: session se klasifikuje jako architektonická podle toho, že deleguje kód, takže architektonické session jsou konstrukčně zaměřené na kódování, zatímco běžné session zahrnují průzkum, revize a ladění, které nikdy nic neupraví. Čtěte to jako “ten vzor dokáže napsat hodně kódu na token”, ne jako tvrzení o čtyřnásobné efektivitě.
Čistší tvrzení je rozdělení podle modelů. Od 14. září stojí prompt v architektonické session 364 tis. vážených tokenů v hlavní smyčce, 205 tis. u pracovníků Sonnet a 80 tis. u pracovníků Opus. Podíl pracovníků Opus na všech tokenech pracovníků byl v srpnu 100 % a v týdnu od 21. září asi 4 %. Na plánu Max to znamená, že se společný týdenní limit čerpá sazbou Sonnetu místo Opusu u téměř veškeré implementační práce a nic z toho se nedotýká limitu Fable.
Dvě věci se nezlepšily a radši to řeknu, než abych nechal grafy naznačovat opak. Vlastní kontext hlavní session se nezmenšil: architektonické session se kompaktovaly 8,7krát na 100 promptů proti 4,7 u běžných session, protože architekt před zadáním hodně čte. A vzor je u malých úkolů pomalejší v reálném čase, protože start pracovníka a jeho zpráva jsou minuty, které neplatíte, když prostě uděláte tu úpravu. Výjimka pro malé úpravy existuje proto, že první verze skillu žádnou neměla, a přistihl jsem se, jak píšu 3kB zadání na dvouřádkovou změnu.
Zacházka s DeepSeekem
Když byli pracovníci na Sonnetu, další zjevnou otázkou bylo, jestli vůbec musejí být modelem Claude. Od 13. do 18. září jsem pracovníka nasměroval na DeepSeek V4.1 Flash přes bezhlavý Claude Code s ANTHROPIC_BASE_URL nastavenou na kompatibilní endpoint, nejdřív přes OpenRouter a pak nativně. Stejný formát zadání, stejný formát zprávy, stejný architekt. 2 732 volání, 431 mil. vstupních tokenů, z toho 88 % čtení z cache, 1,7 mil. výstupních tokenů.
Při ceníkových cenách z 22. září stojí tento provoz asi 10 $ na DeepSeeku mimo špičku, 21 $ ve špičce, 202 $ na API Sonnetu a 505 $ na API Opusu. Kdybych platil za token, tohle by byl titulek článku a nechal bych to.
Neplatím za token a v tom je celý argument. Předplatné Max stojí 100 $ měsíčně, ať využiju 30 % týdenního limitu, nebo 100 %. Přesun provozu pracovníků na DeepSeek ten účet nesnížil ani o cent. Přidal k němu druhý účet 10 až 21 $ týdně, aby ušetřil kapacitu na plánu, jehož kapacitu jsem už zaplatil. Popletl jsem si “levnější než API” s “levnější než to, co platím”, a to není totéž, když platíte paušálně. Správné srovnání pro předplatitele je DeepSeek proti druhému předplatnému, a tam druhé předplatné Claude nebo plán ChatGPT s Codexem stojí zhruba tolik co měsíc mírného používání DeepSeeku a přináší vlastní týdenní limit, vlastní model a žádné měření, které byste museli hlídat.
Kvalita byla ta druhá polovina. Pět backendových řezů se vrátilo v pořádku a bylo zacommitováno tak, jak byly. Jeden frontendový řez odstranil exportovaný symbol a nechal všechny jeho konzumenty nedotčené, takže strom se nezkompiloval a pozdější řez to musel uklidit. To je přesně ta chyba, kterou má model vykonávající specifikaci a kterou nemá model, jenž tvar komponenty odvozuje od jejích sourozenců, a skill to teď říká: změny sdíleného API povrchu jdou na Sonnet a pravidlo pro pracovníka zní “nikdy neodstraňuj ani nepřejmenuj exportovaný symbol, aniž bys ve stejném běhu přenesl všechny jeho konzumenty”. DeepSeek Flash je dobrý vykonavatel. Vzor architekt potřebuje pracovníka, který si všimne, když zadání konzumenty podcenilo, a to je jediná věc, kterou zadání dodat nedokáže.
Směrovací tabulka má dnes tedy dva řádky. Rutinní práce, backendová práce podle podrobného zadání s testy, které je třeba splnit, frontendová práce, která sleduje existující návrhovou gramatiku, a jakákoli změna sdíleného API povrchu jdou na sonnet-implementer. Práce, jejíž obtížnost je v uvažování, jde na opus-implementer: asynchronní závod, refaktoring na více místech, jehož správnost závisí na místech, která zadání nedokáže vyjmenovat, doplňovací migrace, kterou neprokáže žádný jednotlivý test. Směrujte podle tvaru, nikdy podle rizika. Riziko mění to, jak tvrdě se diff reviduje a jestli ho podepíše člověk. Nikdy nemění to, kdo ho píše.
Smyčka revizí, kde vzor vydělává, nebo prodělává
Zpráva pracovníka je tvrzení. Smyčka revizí ve skillu je krátká a každý řádek vznikl z toho, že jsem se spálil:
- Přečtěte zprávu a skutečný
git diff. Zkontrolujte diffstat, který pracovník uvádí, proti tomu, co vidíte vy. - Když na tvrzení záleží, spusťte klíčové ověření sami.
- Našli jste problém? Pošlete opravu stejnému pracovníkovi. Ještě má svůj kontext a naváže tam, kde skončil. Neopravujte to ručně, nespouštějte nového.
- Dvě neúspěšné opravy znamenají, že zadání bylo nedostatečné, ne že model je příliš malý. Rozložte to, doplňte chybějící výňatek do pole Context a spusťte znovu. Nešplhejte k většímu modelu, protože ten stejné nedorozumění zimplementuje plynuleji.
- Než cokoli přijmete, spusťte omezené kontroly: dotčené testy, linter na dotčených souborech, jakýkoli skript na konvence, který repo má.
V přepisech jsem poslal zhruba jednu opravu na spuštění pracovníka, 52 na 85 spuštění, a 7 spuštění Opusu narazilo na svůj limit 160 tahů, každé na řezu, který bych teď rozdělil. To jsou ta dvě čísla, která sleduju. Když opravy na spuštění rostou, moje zadání jsou líná. Když pracovníci narazí na limit, moje řezy jsou příliš velké.
Co si z toho vzít
Pokud platíte za token: dejte drahý model na rozhodování a revize, levný na implementaci a než si vyberete který levný, spočítejte si provoz pracovníků v ceníkových cenách. Ten graf se čtyřmi sloupci je ten argument.
Pokud platíte předplatné: ten vzor vám počet tokenů nesníží. Přesune implementační tokeny na model, který společný týdenní limit čerpá nejpomaleji, nechá limit Fable na práci, kterou má dělat jen Fable, a zastaví vašemu nejdražšímu modelu utrácení tahů za psaní. Nepřidávejte bokem měřené API, abyste “ušetřili” kapacitu, kterou jste už koupili. Když vám dojde kapacita pracovníků, kupte si druhé předplatné.
Ať tak či onak, pravidla, díky kterým to fungovalo, byla ta nudná. Žádné celé testovací sady u pracovníka. Zastropovat tahy. Malé řezy, krátká zadání. Opravit stejného pracovníka jednou, pak opravit zadání.
Skill, tři definice agentů a ochranný hook najdete na github.com/LivinTribunal/architect-skill pod licencí MIT. Doprovodný skill, který pracovníkovi říká, jak psát kód, aby ladil s repem, do kterého přichází, je grain-skill , a článek o něm je kód v souladu s repem .
Metodika
Všechno, co článek popisuje, je na github.com/LivinTribunal/architect-skill : samotný skill, šablona zadání, směrovací tabulka, tři definice agentů-implementátorů s jejich limity tahů a pravidly pro kontext a ochranný hook. Nainstalujte si to a máte nastavení, ze kterého vznikla čísla níže.
Session jsou přepisy Claude Code ve formátu JSONL od 19. srpna do 22. září 2026, entrypoint cli, tři a více uživatelských promptů. Session se klasifikuje jako architektonická, pokud spustila opus-implementer, opus-implementer-xhigh nebo sonnet-implementer, spustila pracovníka ds-slice, vyvolala skill architekt nebo poslala zprávu obsahující implementační zadání agentovi pro obecné použití, což je způsob, jak fungovaly první týdny, než pojmenovaní agenti existovali. Spuštění pracovníků jsou přepisy subagentů v adresáři každé session. Využití je deduplikováno podle id požadavku a váženo: čerstvý vstup 1, pětiminutový zápis do cache 1,25, hodinový zápis do cache 2, čtení z cache 0,1. “Úprava kódu” je volání Edit nebo Write na soubor .py, .ts, .tsx, .js, .sql nebo podobný zdrojový soubor, kromě markdownu a čehokoli pod ~/.claude. Ceny DeepSeeku jsou nativní ceníkové ceny z 22. září 2026, mimo špičku a ve špičce, s čtením z cache za sazbu zásahu do cache a zápisy do cache účtovanými jako čerstvý vstup; ceny API Claude jsou zveřejněné ceníkové ceny Opus 5 a Sonnet 5 s čtením z cache za desetinu vstupu. Týden od 21. září jsou dva dny dat.
