AIDiveWstęp: te same testy, dwa razy więcej licznika, pięć limitów
Ultracode to słowo kluczowe albo przełącznik, który zamienia jedną prośbę wpisaną w Claude Code w cały zespół agentów. W teście w parach, na tej samej specyfikacji, oba runy przeszły te same ukryte testy, a run z ultracode zużył ponad dwa razy więcej licznika sesji. Powodem nie jest mądrzejszy model: to jedno zdanie, które harness dokleja do instrukcji, i trzy zabezpieczenia, które wyłącza.
Ten artykuł omawia cztery rzeczy:
- test w parach, odczytany na liczniku planu;
- mnożnik tokenów w kilku kolejnych parach;
- jeden rodzaj zadania, w którym zespół znalazł 66 podłożonych błędów, a pojedynczy agent 14;
- pięć ustawień, które ograniczają run, zanim zje ci cały tydzień, w tym jedno, które zatrzymuje go na samym limicie użycia.
Co włącza ultracode: słowo kluczowe, przełącznik, workflow agentów
Ultracode to dwa przełączniki. Wpisanie ultracode w jednym prompcie uruchamia to jedno zadanie jako workflow, bez ruszania poziomu effort sesji. Przestawienie przełącznika przez polecenie /effort sprawia, że Claude planuje workflow dla każdego istotnego zadania, więc jedna prośba może zamienić się w kilka workflow z rzędu.
Workflow to skrypt, który Claude pisze sam dla siebie; ten skrypt uruchamia zespół agentów w fazach. Na maleńkiej piaskownicy (kilka plików z niechlujną obsługą promise, prośba o przegląd tylko do odczytu) Claude przejrzał pliki, rozesłał workflow nazwany "unhandled promise audit", a pod polem promptu pojawił się wiersz zadania z paskiem postępu, liczbą agentów, czasem trwania i rosnącą sumą tokenów. Polecenie /workflows wypisuje jeden wiersz na agenta z jego własnym licznikiem tokenów oraz klawisze do pauzy, zatrzymania lub restartu.
W tym runie każdy finder przeczytał około 45 000 tokenów, zanim w ogóle ruszyli weryfikatorzy, i to dla kilku linii kodu.
Każda sesja ma też wytyczną rozmiaru, czyli liczbę agentów, poniżej której Claude ma się trzymać:
| Wytyczna rozmiaru | Zalecana liczba agentów |
|---|---|
| small (domyślna na Pro) | mniej niż 5 |
| medium | mniej niż 10 |
Każdy agent wysyła własne zapytania ponad twoją rozmową. Workflow nigdy nie jest jednym rachunkiem; to jeden rachunek na agenta, a licznik liczy każdy z nich.
Test w parach: te same 136 testów, 8 procent kontra 18 i brak końca
Programista zmierzył koszt na najwyższym planie subskrypcji w czystym układzie: ta sama specyfikacja małej aplikacji arkuszowej, ten sam model na tym samym effort, jeden zwykły run i jeden run z ultracode. Oba oceniono ukrytymi testami, czyli testami, których model nigdy nie widzi. Oba zaliczyły wszystkie 136.
| Run | Zakończenie | Zużyty limit sesji | Zaliczone testy |
|---|---|---|---|
| Zwykły | sam, po 25 min | 8 % | 136 / 136 |
| Ultracode | ucięty przez zegar po 76 min, nadal sprawdzał | 18 % | 136 / 136 |
W runie z ultracode Claude napisał skrypt, którego jedynym zadaniem było uruchomienie zespołu: naliczono 12 agentów, testerów, kilku sędziów, a później paru "breakerów", którzy mieli zepsuć stronę. Jeden z nich znalazł prawdziwy błąd w pasku formuły, który po kliknięciu innej komórki wciąż pokazywał stary tekst.
Na minutę run z ultracode zużywał limit mniej więcej tak szybko jak zwykły, średnio nieco wolniej. Nie spalał szybciej; po prostu się nie zatrzymywał. Ultracode nie robi Claude'a mądrzejszym, każe mu sprawdzać, a za każde sprawdzenie płacisz. To jedna para na małej specyfikacji, a drugi run ucięto zegarem, ale obraz jest jasny: ta sama odpowiedź, ponad dwa razy więcej okna sesji, a cały dodatkowy czas poszedł na sprawdzanie.
Dlaczego to kosztuje: jedno zdanie i trzy wyłączone zabezpieczenia
Model jest ten sam. Zmienia się tekst, który podaje mu harness; harness to sam Claude Code, jego narzędzia i instrukcje wokół modelu.
Gdy ultracode jest włączony, Claude Code ładuje materiał referencyjny, zanim model napisze jakikolwiek workflow. Ten tekst każe modelowi domyślnie uruchamiać workflow dla każdego istotnego zadania i zawiera zdanie, które tłumaczy rachunek: "The goal is the most exhaustive, correct answer you can produce, and token cost is not a constraint." To własny tekst harnessu, a publiczne zgłoszenie na GitHubie cytuje te same linie.
Jednocześnie wyłączają się trzy zabezpieczenia:
- Ostrzeżenie o dużym workflow, które normalnie pojawia się, gdy run planuje zbyt wielu agentów, nie wyświetla się.
- Limit sesji na liczbę agentów działających jednocześnie nie jest egzekwowany dla agentów, które spawnuje Claude.
- W trybie auto pierwsze uruchomienie nigdy nie trafia do zatwierdzenia.
Wytyczna rozmiaru to rada, nie limit: ustawiona na small (mniej niż 5 agentów) w piaskownicy, run z ultracode i tak uruchomił 9. Dla uczciwości: to zdanie jest ustawieniem domyślnym, które model nadal może rozważyć, a zabezpieczenia wyłączono celowo z myślą o bardzo dużych zadaniach. Odpowiedź mieści się w jednej linii: ultracode nie zmienia modelu, zmienia instrukcje na "zespół do wszystkiego, a koszt nie jest ograniczeniem".
Mnożnik: trzy pary, drabina effort, para 30x
Drugi programista przeprowadził kilka par pojedynczy agent kontra workflow na planie Pro, na skryptach w stylu przeglądu, odczytując licznik użycia przed i po każdym z nich.
| Miara | Pojedynczy agent | Workflow |
|---|---|---|
| Tokeny na jednym skrypcie przeglądu | około 115 000 | 972 000 |
| Mnożnik tokenów w parach | 1x | do 18x, za mniej więcej te same ustalenia |
| Ruch licznika | 1x | do 3x |
| Czas ścienny | prawie identyczny | prawie identyczny |
Workflow nie skończył szybciej; wydał więcej, a ty czekałeś tyle samo. Jedyne miejsce, w którym równoległość się opłaciła, to zestaw niezależnych zadań badawczych, gdzie agenci skończyli szybciej, nadal za ponad dwa razy więcej tokenów.
Trzeci test zbudował kilka małych aplikacji na każdym poziomie effort, po cenach API. Każdy szczebel drabiny mniej więcej podwajał rachunek, a ultracode wylądował na kilkukrotności kosztu max, nigdy nie wychodząc na prowadzenie. Większość tych tokenów to odczyty z cache, te tanie; maleńki ułamek tokenów wyjściowych stanowił prawie połowę kosztu.
Jeszcze jedna para, scena miasta: pojedynczy agent potrzebował około godziny i kilku dolarów w cenie API. Run z ultracode zajął większość doby, dziesiątki subagentów i około 30 razy większy koszt.
To są odczyty licznika w liczbach całkowitych, aplikacje od zera po cenach API i jedna scena miasta, więc żadna z nich sama nie jest tabelą wyników. Razem pokazują za każdym razem ten sam wzorzec: rozgałęzienie kupuje sprawdzanie i pokrycie, nie lepszą odpowiedź, chyba że zadanie dzieli się na niezależne kawałki.
Gdzie fan out się opłaca: zestaw testów jako sędzia i reguła w jednej linii
Niektóre zadania naprawdę mają taki kształt: migracja, audyt, przegląd całej bazy kodu.
Bun został przepisany z Zig na Rust za pomocą około 50 dynamicznych workflow w Claude Code, działających nieprzerwanie przez 11 dni. To ponad pół miliona linii Zig, od startu do przejścia całego zestawu testów na każdej platformie w tych samych dniach. O sukcesie zdecydowała nie liczba agentów, tylko sędzia: ogromny istniejący zestaw testów mówił "zdał" lub "nie zdał" bez niczyjej opinii.
Polowanie Anthropic na błędy pokazuje to samo. W dużej bazie kodu podłożono siedemdziesiąt błędów i kilka razy uruchomiono pojedynczego agenta.
| Agent | Znalezione błędy z 70 |
|---|---|
| Pojedynczy agent (3 runy) | 14, 15, 27 |
| Workflow (3 runy) | 66 w każdym runie |
Jedno zastrzeżenie: ten test działał na Claude Managed Agents, produkcie API, a nie w Claude Code, i nie podano kosztu.
Wątek premierowy dodaje inne zgłoszone sukcesy, a wszystkie wyglądają podobnie: przegląd względem pliku reguł, tłumaczenie całej bazy kodu, porządkowanie stosu zeskanowanych stron. Wpis premierowy mówi to wprost: większość tradycyjnych zadań programistycznych nie potrzebuje panelu pięciu recenzentów.
Reguła: rozgałęziaj tylko wtedy, gdy wynik ocenia zestaw testów lub zbiór reguł, a zadanie dzieli się na niezależne kawałki. Wszystko inne uruchamiaj zwyczajnie, na high. Tester z testu w parach powiedział to samo własnymi słowami: zostaw to na zadania, w których sprawdzanie jest pracą, jak migracja obejmująca setki plików.
Pięć ustawień, które ograniczają run
Każdy limit siedzi w miejscu, które już znasz.
| # | Ustawienie | Gdzie | Efekt |
|---|---|---|---|
| 1 | workflowSizeGuideline: "small" |
/config w sekcji Dynamic workflow size lub settings.json |
rada (mniej niż 5 agentów), obniża też próg ostrzeżenia o dużym workflow |
| 2 | CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS |
zmienna środowiskowa, wyeksportowana przed startem | domyślnie do 16 agentów naraz; ustawione na 4, reszta czeka w kolejce, co zwalnia spalanie bez zabijania runu |
| 3 | CLAUDE_CODE_WORKFLOW_SUBAGENT_MODEL |
zmienna środowiskowa | uruchamia każdego agenta workflow na jednym wybranym modelu, podczas gdy inne subagenty zachowują swoje; tańszy model robi tańsze sprawdzanie |
| 4 | słowo kluczowe ultracode, nigdy przełącznik |
w prompcie; nigdy klucz ultracode w settings |
słowo kluczowe uruchamia jedno zadanie jako workflow i kończy; przełącznik robi to stałym aż do wyłączenia |
| 5 | autoContinueAtUsageLimit |
settings | włączone: run, który trafi na limit, pauzuje, czeka na reset i jedzie dalej, więcej niż raz; wyłączone: agenci padają na ścianie i run się tam kończy |
Do tego trzy nawyki. Wpis premierowy mówi, że budżet zapisany w prompcie, jak "use 10k tokens", wyznacza limit. Po każdym runie /usage pokazuje, jaka część ostatniego użycia poszła na subagentów i workflow, z ostrzeżeniem, gdy dominują. Jeśli run wygląda źle w trakcie, panel /workflows i klawisz x go zatrzymują, a wykonana już praca zwykle zostaje.
Nic z tego nie robi agenta tańszym. To ogranicza, ilu agentów run może wydać i jak długo może wydawać.
Run poza kontrolą, limity i werdykt
Jedno publiczne zgłoszenie pokazuje, jak znika cały tydzień. Skrypt napisany przez model, na największym planie, uruchomił 221 agentów w niecałą godzinę. Po pierwszym błędzie limitu sesji skrypt dalej rozsyłał zadania i w ciągu kilku kolejnych minut wystartowało jeszcze 189 agentów. Tabela autora zgłoszenia liczy dziesiątki milionów tokenów w fazach przed ścianą.
| Faza | Tokeny, z cache |
|---|---|
| Ground | 11 063 801 |
| Find | 35 885 272 |
| Merge | 516 226 |
| Razem | 47 465 299 |
Winna była jedna linia w wygenerowanym skrypcie, fallback, który mówił: jeśli agent nic nie zwrócił, użyj surowej listy i jedź dalej. Merge się nie powiódł, a run szedł dalej. Ta wersja jest wcześniejsza niż pauza na limicie użycia, a autor zgłoszenia mówi, że te tokeny nie pochodziły od agentów, którzy padli. Sufit współbieżności by ten run przerzedził, a wyłączone auto-continue zakończyłoby go na ścianie.
Werdykt: przy tym samym zadaniu, z tymi samymi zaliczonymi testami, ultracode zużył ponad dwa razy więcej licznika niż zwykły run. Nie dlatego, że jest mądrzejszy, tylko przez wstrzyknięte zdanie i zabezpieczenia, które wyłącza. Opłaca się, gdy wynik ocenia zestaw testów lub zbiór reguł, a kawałki na siebie nie czekają. Wszędzie indziej wpisujesz go i płacisz za sprawdzanie. Pięć ustawień ogranicza, ile run może wydać: wytyczna rozmiaru, sufit współbieżności, model workflow, słowo kluczowe zamiast przełącznika i zatrzymanie na limicie.
