Claude Code subagents i routing modeli: tanie zbieranie, mocna synteza

TL;DR: Gdy dzielę pracę między kilku agentów, kosztownym błędem jest puszczanie każdego podzadania na najmocniejszym modelu z całą dotychczasową rozmową w kontekście. U mnie sprawdza się drabina modeli, a o wyborze szczebla decyduje koszt błędnej odpowiedzi i to, kto czyta wynik: najmocniejszy model do planów, incydentów, trudnego debugowania i wszystkiego, co czyta klient; model średni do sesji, które głównie przyjmują output narzędzi; szybki model do mechanicznych, w pełni opisanych zmian; najmniejszy wyłącznie jako subagent do wyszukiwania. Najpierw obniżam effort, dopiero potem model, model wybieram na starcie sesji, przed rozdzieleniem pracy robię pilotaż na 3-5 rekordach, a każdy subagent dostaje minimalną, samowystarczalną specyfikację. Subagenci utrzymują główny kontekst w czystości, ale nie zmniejszają łącznego rachunku.

Zadanie, które wydało budżet, zanim powstała jedna tabela

Problem, który zmusił mnie do spisania czegokolwiek, to szerokie zadanie badawcze: zebrać zestaw faktów o 58 kanałach z treściami i zamienić je w tabele porównawcze. Wyglądało na podręcznikowy przypadek dla równoległych agentów, więc podzieliłem je na trzy podzadania i uruchomiłem je jednocześnie. Wszystkie trzy dostały najmocniejszy model dostępny w tym narzędziu i wszystkie trzy odziedziczyły całą rozmowę sprzed podziału.

Limit użycia skończył się, zanim powstała jakakolwiek tabela. Punkt kontrolny, który zostawili agenci, zawierał zero liczb i nazwy dwóch kanałów. Pełny raport dostarczyła w końcu jedna sesja na najmocniejszym modelu, pracująca sekwencyjnie. Lekcja była niewygodna, ale prosta: szeroki zakres nie uzasadnia najmocniejszego modelu na każdym etapie. Zebranie 58 wierszy dat i liczb to nie ta część zadania, która wymaga osądu, a płacenie za nią najwyższej ceny trzy razy, z dużym odziedziczonym kontekstem przy każdym wywołaniu, to prosty sposób, żeby spalić budżet i zostać z niczym.

Co naprawdę daje orkiestracja wielu agentów?

Orkiestracja agentów AI polega na tym, że jedna koordynująca sesja dzieli zadanie między kilku agentów, z których każdy ma własne okno kontekstu, i zbiera ich wyniki. Przeceniana bywa oszczędność. Niedoceniana jest izolacja.

Subagent szuka i czyta we własnym oknie, a do głównej sesji wraca tylko jego końcowy raport, zwykle podsumowanie w granicach od tysiąca do dwóch tysięcy tokenów. To realna wartość: główna sesja zostaje skupiona i nie zapycha się zrzutami plików. Ale każdy subagent ładuje też własny system prompt i własną kopię instrukcji projektu, więc w łącznej liczbie tokenów nie jest darmowy. Kupuje izolację, a to inna korzyść.

Zmierzyłem, ile kosztuje konfiguracja agentów na starcie sesji w jednym z moich projektów. Jedenastu agentów projektowych dodało mniej niż dwa tysiące tokenów, bo na starcie ładują się tylko ich jednolinijkowe opisy; treść definicji ładuje się dopiero w subagencie, gdy ten startuje. Stała podłoga sesji, zanim padnie choć jedno słowo o zadaniu, to około 28 tysięcy tokenów system promptu, instrukcji i indeksu pamięci. A faktyczny rachunek zdominowało coś jeszcze innego: ponad 90% kosztu to ponowne czytanie kontekstu z cache w każdej turze długiej rozmowy. To zmienia rachunek. Subagent do jednego grepa to strata. Subagent, który przegląda czterdzieści plików i zwraca listę, to zysk, bo te czterdzieści plików nie trafia do kontekstu czytanego od nowa w każdej kolejnej turze. Więcej o tym, co i kiedy się ładuje, napisałem w tekście o tym, jak układam kontekst osobno dla każdego projektu.

Jakie opcje rozważyłem

• Najmocniejszy model do wszystkiego. Najprostsze, a sufit jakości jest najwyższy z możliwych. Kosztem jest wypalanie limitu i wolne tury przy pracy, która nigdy tego modelu nie potrzebowała. Opisany wyżej incydent pokazuje, jak to wygląda w większej skali.
• Najtańszy model do wszystkiego. Szybko i oszczędnie dla limitu, ale wykłada się dokładnie tam, gdzie to ważne: na kryteriach włączenia, niejednoznacznych rekordach i końcowej rekomendacji.
• Zmiana modelu w trakcie sesji, gdy zmienia się praca. Kusi, a po cichu kosztuje. Cache promptu jest osobny dla każdego modelu, więc zmiana w środku długiej sesji oznacza, że cały kontekst zostanie przeczytany od nowa po pełnej cenie na nowym modelu. Przy krótkiej sesji to bez znaczenia; przy długiej zjada oszczędność, o którą chodziło.
• Drabina wybierana na starcie sesji plus jawne kierowanie podzadań. Wymaga więcej namysłu, małego launchera i nawyku zapisywania modelu obok każdego podzadania. Tak właśnie pracuję.

Moja drabina modeli

W chwili pisania szczeble wyglądają tak. Ceny to proporcje cennikowej stawki API za milion tokenów, czyli liczba względna, która ma znaczenie przy decyzji, co gdzie skierować.

Po stronie OpenAI, w Codex CLI, ten sam układ przekłada się na trzy poziomy GPT-5.6: Sol do wymagającej pracy z kompletną specyfikacją, Terra jako środek, gdy Sol zjada limit, i Luna do mechaniki. Moim zdaniem Sol jest nieco słabszy od Fable przy otwartych problemach, więc dostaje zadania, w których rozpoznanie jest już zrobione i spisane. Jedna pułapka: Sol domyślnie ma niski effort rozumowania, co dawało mi płytkie odpowiedzi, więc każdy profil, który go używa, jawnie ustawia effort na high.

Reguła, której używam najczęściej, to model według tego, kto czyta wynik. Jeśli czyta klient, najmocniejszy model. Jeśli czytam ja i sprawdzę wynik, model średni. Jeśli wynik przetwarza maszyna, szybki. Druga reguła to najpierw niższy effort, potem niższy model: przy dobrze opisanej pracy pokrętło rozumowania to głównie dźwignia opóźnienia, więc najpierw je skręcam, a o szczebel niżej schodzę dopiero wtedy, gdy nawet tańszy effort kosztuje więcej, niż zadanie jest warte. Ten sposób myślenia opisałem w tekście o tym, jak dobieram effort i model do zadania. Pokrewna pułapka: przełącznik „fast mode” jest szybszy, a nie tańszy. To ten sam model, tylko serwowany szybciej.

Jak podzielić szerokie zadanie badawcze między tanie i mocne modele?

Po tym incydencie przestałem traktować zadanie badawcze jako jedną robotę i zanim wystartuje jakikolwiek agent, dzielę je na trzy warstwy:

Zasady wykonania, dzięki którym ten podział się opłaca:

1. Mocny model nie zbiera rekordów. Projektuje schemat, rozstrzyga wyjątki i pisze syntezę z gotowego materiału.
2. Minimalny kontekst przekazany subagentowi. Agent zbierający dostaje samowystarczalną specyfikację i nic więcej. Gdy narzędzie proponuje przekazanie rozmowy do subagenta, przekazuję zero tur albo najmniejszą liczbę, która wystarcza, i nigdy domyślnie całej historii. Odziedziczony kontekst był dużą częścią tego, co pogrążyło pierwotne zadanie.
3. Pilotaż na 3-5 rekordach w każdej grupie. Sprawdź kolumny, źródła i format na kilku przykładach, a potem puść pełne zbieranie na tanim modelu. Poprawka schematu po 58 wierszach to ponowne uruchomienie; po trzech to jedno zdanie.
4. Liczbowe kryterium wyjścia dla każdego podzadania. Na przykład: 20 wierszy, każde wymienione pole wypełnione, URL źródła przy każdej liczbie. Opis postępów to nie wynik.
5. Zapisuj partiami do jednego głównego pliku albo do rozłącznych plików roboczych, żeby pierwszy użyteczny punkt kontrolny istniał długo przed końcem całego zbierania.
6. Główna sesja sprawdza, a nie powtarza. Przegląda każdy niejednoznaczny przypadek i próbkę mechanicznego wyniku. Nie powtarza zbierania na mocnym modelu.
7. Zapisz model obok każdego podzadania, zanim je zlecisz. Jeśli nie ma powodu, żeby sięgać po najwyższy szczebel, domyślnie wybierasz szybki albo średni.

// illustrative shape of a sweep subtask
subtask: collect-release-dates
model: fast            // written down before delegation
effort: medium
fork_context: none     // self-contained spec only
pilot: 3 records, stop and report
exit: 20 rows, all fields, source URL per number
output: batch-02.json

Kryterium sukcesu dla szerokiego zadania badawczego zmieniło się na użyteczny, weryfikowalny zbiór danych, zanim skończy się limit. Elegancka synteza powstaje z tego zbioru, a nie zamiast niego.

Czy subagent powinien kiedykolwiek edytować kod?

U mnie nie. Subagent zasługuje na swoje miejsce, gdy jego wynik wraca jako raport, lista albo szkic: przeszukanie repozytorium, przegląd źródeł, audyt, pierwsza wersja tekstu, którą ktoś przejrzy. Zmiany w kodzie powstają w głównej sesji, z załadowanymi właściwymi instrukcjami projektu, przy pomocy wbudowanych subagentów do wyszukiwania i planowania oraz przeglądu. Gdy chcę drugiej implementacji albo drugiej opinii, uruchamiam ją jako osobną sesję CLI we własnym git worktree, co opisałem w tekście o równoległej pracy agentów kodujących na worktree. Chodzi o odpowiedzialność: subagent zwraca podsumowanie, a podsumowanie to kiepska podstawa do przeglądu diffa. Zmianę powinna wprowadzić ta sesja, która potem będzie musiała jej bronić.

Druga połowa routingu to przypięcie modelu do każdego agenta. W Claude Code model jest zapisany we frontmatterze definicji agenta, a nie w jego prompcie. Bez tego wpisu agent dziedziczy model sesji i to mnie ugryzło: w sesji na średnim modelu agenci piszący teksty dla klientów po cichu działaliby na średnim szczeblu. Dlatego oni są przypięci do najmocniejszego modelu, agenci zbierający i tworzący listy do szybkiego, a agenci analityczni, których wyniki czytam sam, działają na średnim.

# illustrative shape of an agent definition header
---
name: source-sweeper
description: Collects rows into a fixed schema. Returns a table, never edits code.
model: sonnet
---

Dwa szczegóły, które łatwo przeoczyć. Agenci dziedziczą też serwery MCP sesji, w której działają, więc agent potrzebujący serwera analitycznego musi działać w sesji uruchomionej z tym serwerem. A zmiana przypiętego modelu wymaga edycji definicji i restartu sesji.

Jeden przykład szybkiego szczebla przy prawdziwej pracy: specyfikacja małego zestawu testów jednostkowych trafiła do szybkiego poziomu Codex we własnym worktree. Skończył w 70 sekund na około 30 tysiącach tokenów, a wszystkie sześć testów przeszło za pierwszym uruchomieniem. Jakość niosła specyfikacja; model musiał ją tylko przepisać na kod.

Gdzie to zawodzi

Drabina to kwestia osądu. Umiejscowienie każdego modelu wynika z moich własnych zadań, a aktualizacja modelu może przesunąć szczebel. Launcher, który wybiera profil na podstawie słów kluczowych w opisie zadania, dobrze kieruje większość zadań, ale zadanie opisane bez żadnego z tych słów trafia do profilu domyślnego, co jest właściwym zachowaniem awaryjnym, a mimo to czasem złym wyborem. Do tego kara za utratę cache przy zmianie modelu w trakcie sesji oznacza, że sesja, która w połowie zmienia charakter, po prostu zostaje na szczeblu startowym, a rozwiązaniem jest nowa sesja.

Co powiedziałbym komuś, kto zaczyna jutro

• Kieruj według kosztu błędnej odpowiedzi. Najmocniejszy model do planów, incydentów i tekstów dla klientów; średni do sesji z dużą liczbą wywołań narzędzi; szybki do wykonywania specyfikacji; najmniejszy tylko do wyszukiwania.
• Obniż effort, zanim zejdziesz o model niżej.
• Wybierz model na starcie sesji. Cache promptu jest osobny dla każdego modelu, więc zmiana w trakcie sesji oznacza ponowne czytanie wszystkiego.
• Zrób pilotaż na 3-5 rekordach, a potem rozdziel pracę tanio, z liczbowym kryterium wyjścia dla każdego podzadania.
• Przekazuj jak najmniej kontekstu każdemu subagentowi.
• Używaj subagentów dla izolacji, a nie dla oszczędności, i tylko wtedy, gdy wynik wraca jako raport, lista albo szkic.
• Przypinaj model w definicji każdego agenta, bo inaczej po cichu odziedziczy to, na czym działa sesja.