Rozbudowane harnessy podnoszą koszty agentów kodujących, ale nie poprawiają wyników

Twórcy narzędzi takich jak Claude Code czy OpenCode chętnie chwalą się wzrostem wyników po zmianie harnessu, czyli warstwy złożonej z promptu systemowego, narzędzi i zarządzania kontekstem, która pozwala modelowi pracować w repozytorium kodu. Badanie opisane przez The Decoder pokazuje, że te deklaracje w dużej mierze mierzą szum pomiarowy. Praca dwojga badaczy z Uniwersytetu Shandong nosi tytuł „What does a harness buy? Mostly tokens”, czyli mniej więcej: „Co kupuje harness? Głównie tokeny”.

Różnice mieszczą się w szumie

Autorzy zwracają uwagę, że dotychczasowe porównania, w których harnessy dzieliło ponad 20 punktów, opierały się niemal zawsze na pojedynczym przebiegu. Tymczasem samo powtórzenie identycznej konfiguracji na SWE-bench Verified potrafi dać wynik różniący się nawet o sześć punktów. Zhipu AI reklamuje własny harness jako lepszy od Claude Code o 2,4 punktu, a to mieści się w tym zakresie szumu. Dodatkowo harnessy bywają różnie podpinane do benchmarku, co jeszcze utrudnia porównania.

Badacze uruchomili pięć modeli (Qwen3.6, Qwen3.8, Deepseek-V4-Flash, GLM-5.3-Flash i HY4-Preview) w trzech harnessach w ich oficjalnych wersjach: Claude Code, OpenCode i mini-SWE-agent. Ten ostatni daje modelowi wyłącznie narzędzie Bash i nie zarządza kontekstem. Dwa pozostałe oferują wyspecjalizowane narzędzia do plików i wyszukiwania, długie prompty systemowe oraz automatyczną kompresję historii. Claude Opus 5 posłużył tylko jako punkt odniesienia, wyłącznie w Claude Code. Testy objęły 45 najtrudniejszych zadań z SWE-bench Verified oraz pulę 447 dodatkowych, a część konfiguracji powtórzono, by zmierzyć szum.

Wszystkie przebiegi odbywały się offline. We wstępnych testach z dostępem do sieci w 71 proc. prób modeli Deepseek i Qwen poprawka została pobrana wprost z GitHuba zamiast rozwiązana samodzielnie. Modele Claude robiły to niemal wcale. Badacze odrzucili te wyniki i zaznaczają, że nie twierdzą, iż ktokolwiek trenował na danych testowych. Wzorzec był jednak na tyle wyraźny, że odcięli sieć we wszystkich dalszych próbach.

Na puli 447 zadań najcięższy Claude Code i najlżejszy mini-SWE-agent dzieliło mniej niż dwa punkty, dla obu testowanych modeli. W paśmie pięciu punktów uznano je za statystycznie równoważne. Harnessy zużywały dwa do trzech razy więcej tokenów niż najszczuplejsza opcja dla danego modelu, a odsetek rozwiązanych zadań mieścił się w granicach niepewności pomiaru.

Podobnie wyglądały wskaźniki zmiany wyniku na poziomie pojedynczych zadań. Między dwoma przebiegami tej samej konfiguracji mediana odsetka zadań, w których zmienia się wynik, wynosi 13 proc. Przy zamianie harnessu jest to również 13 proc., a przy zamianie modelu już 22 proc. Autorzy piszą, że różnica między harnessami zachowuje się jak „kolejne losowanie tego samego szumu”.

Małe próby ograniczają też czułość porównań. Przy 45 zadaniach nawet 13-punktowa różnica wychodzi tylko w połowie przypadków, a przy 447 wiarygodnie wykrywalne stają się różnice rzędu pięciu punktów. Deklarowane przez Zhipu 2,4 punktu nie przechodzi żadnego z tych progów, podobnie jak wiele innych reklamowanych usprawnień.

Jedyny wyjątek: OpenCode

Jedyny mierzalny efekt harnessu to stała strata OpenCode, który na dużej puli zadań przegrywa z pozostałymi nawet o dziewięć punktów. Mniej więcej połowa tej różnicy wynika z limitu długości odpowiedzi. Gdy model przekroczy go w środku rozumowania, Claude Code każe mu kontynuować, a OpenCode kończy krok, co zwykle oznacza porażkę. Dodanie do OpenCode analogicznego promptu nie pomogło, bo to samo zadanie rzadko wywołuje to samo przepełnienie przy ponownej próbie. Reszty luki autorzy nie umieją wyjaśnić, odnotowują tylko, że w OpenCode modele przerywają pracę znacznie wcześniej. Dla lokalnie uruchamianych modeli OpenCode miał też dużo ciaśniejszy limit czasu niż Claude Code, co badacze sami oznaczają jako niekontrolowaną zmienną. Narzędzia wyszukiwania w OpenCode próbują przy pierwszym użyciu pobrać plik binarny i bez internetu przestają działać.

Rachunek wystawia prompt systemowy

Przy tym samym modelu, tych samych zadaniach i tym samym cenniku jedno zadanie może kosztować nawet trzy razy więcej, zależnie od harnessu. Wyniki narzędzi tego nie tłumaczą, bo wszystkie trzy harnessy zwracają podobną ilość tekstu na wywołanie. Różnica bierze się z promptu systemowego i opisów narzędzi, które są wysyłane przy każdym kroku. W Claude Code to około 16 600 tokenów, w OpenCode około 7000, a w mini-SWE-agent poniżej 1000. Według inżynierii wstecznej badaczy Claude Code zachowuje też w historii rozmowy treść rozumowania modelu. Po pierwszym wywołaniu kontekst rośnie we wszystkich harnessach w podobnym tempie.

Rozmiar promptu ustala więc koszt bazowy, a liczba kroków go mnoży. Co dominuje, zależy od modelu. Z GLM-5.3-Flash Claude Code kosztuje prawie dwa razy więcej niż mini-SWE-agent, a pojedyncza próba to 1,81 juana w Claude Code wobec 0,56 juana w OpenCode. Z Deepseek-V4-Flash mini-SWE-agent potrzebuje tylu dodatkowych kroków, że koszty obu wyrównują się. Niższe ceny tokenów z cache łagodzą różnice, ale nie zmieniają kolejności.

Harness Deepseeka z własnym modelem Deepseeka nie wypada lepiej niż pozostałe, a kosztuje najwięcej. Claude Opus 5 dawał identyczne wyniki nawet po usunięciu narzędzi z Claude Code. Wersja tego modelu sprzed roku rozwiązuje podobną liczbę zadań za mniej niż połowę ceny, ponieważ Extended Thinking nie było wtedy domyślnie włączone.

Właśnie myślenie okazało się jedynym przypadkiem, w którym wybór harnessu zmieniał wynik. Bez trybu thinking mini-SWE-agent z Qwen3.6 traci jedenaście punktów, podczas gdy Claude Code i OpenCode mieszczą się w szumie. HY4-Preview traci tyle samo w Claude Code. Autorzy przyznają, że ich siatka testowa jest zbyt mała, by wyjaśnić dlaczego.

Praca opiera się głównie na jednym benchmarku, a niewielka weryfikacja na Terminal-Bench 2.1 pokazała ten sam wzorzec. Najsilniejszy zamknięty model, Opus 5, działał tylko w Claude Code. Wniosek autorów jest taki, że harness kupuje „mniej sposobów na przegranie zadania i rachunek”, a nie wyższy odsetek rozwiązanych zadań. Postulują, by do każdego porównania harnessów dołączać powtórzenie tej samej konfiguracji, bo tylko tak widać, ile z różnicy to szum. Dane i skrypty analityczne są dostępne na GitHubie.

Wnioski pokrywają się z wcześniejszymi pracami, które The Decoder przywołuje w tekście. Jedna pokazała, że prosty plik Markdown pokonał złożony system umiejętności dla agentów kodujących, inna, że wybór frameworka może niemal potroić koszty przy tym samym modelu. O tych samych liczbach pisał też VentureBeat.