Artificial Analysis Coding Agent Index stawia Claude na pierwszym miejscu, ale koszty zmieniają układ liderów

Artificial Analysis przyznało Claude Sonnet 5.5 pierwsze miejsce z wynikiem 68 punktów, lecz nowe rezultaty dotyczące agentów programistycznych przedstawiają znacznie mniej korzystny obraz kosztów.

Artificial Analysis Coding Agent Index plasuje Claude Code z Sonnet 5.5 przy maksymalnym wysiłku przed Gemini 4 Argon i GPT-6.1 Sol. Zwycięzca zużywa jednak na zadanie znacznie więcej czasu, tokenów i środków na API niż jego najbliżsi nowi rywale.

Ta różnica zmienia praktyczną decyzję zespołów programistycznych. Claude prowadzi w złożonym benchmarku, podczas gdy Codex z GPT-6.1 Sol oferuje niemal porównywalne wyniki przy wykorzystaniu ułamka zmierzonych zasobów. Gemini 4 Argon zajmuje pozycję pośrednią, łącząc wysoki wynik łączny z zauważalną przewagą w długoterminowych zadaniach programistycznych.

Oryginalny wpis o benchmarku przedstawia te trzy wydania jako nowych liderów. Bazowe wyniki potwierdzają ich znaczenie, lecz nie uzasadniają prostego podium z trzema miejscami. Inne konfiguracje, w tym Claude Opus 5.5, również znajdują się blisko czołówki.

Co ważniejsze, każdy wynik dotyczy modelu, ustawienia rozumowania oraz środowiska agenta. Ranking nie testuje wyłącznie abstrakcyjnej inteligencji modelu. Testuje kompletne systemy programistyczne, takie jak Claude Code, Codex i Antigravity CLI.

To rozróżnienie stanowi sedno tej historii. Zespoły nie wybierają już wyłącznie modelu z najwyższym wynikiem. Wybierają, ile dodatkowego czasu i mocy obliczeniowej jest warte kolejne oczko w benchmarku.

Co zmieniło się w Artificial Analysis Coding Agent Index

Najnowsze wyniki wyraźniej niż wcześniejsze porównania modeli oddzielają przewagę benchmarkową od efektywności operacyjnej.

Artificial Analysis ocenia agentów programistycznych pod kątem pracy end-to-end, a nie pojedynczych pytań dotyczących uzupełniania kodu. Jego indeks łączy modyfikowanie repozytoriów, pracę w terminalu i rozumienie bazy kodu w jeden wynik.

Claude Code z Sonnet 5.5 przy maksymalnym wysiłku prowadzi z wynikiem 68 punktów. Jego wyniki składowe to 72 procent w DeepSWE v1.1, 66 procent w Terminal-Bench 4.0 oraz 67 procent w SWE-Atlas-QnA.

Antigravity CLI z Gemini 4 Argon uzyskuje 64 punkty. Osiąga 79 procent w DeepSWE, 56 procent w Terminal-Bench oraz 56 procent w pytaniach dotyczących repozytoriów.

Codex z GPT-6.1 Sol przy wysiłku xhigh uzyskuje 63 punkty. Ta konfiguracja notuje 73 procent w DeepSWE, 55 procent w Terminal-Bench oraz 61 procent w SWE-Atlas-QnA.

Między Claude a Sol jest więc zaledwie pięć punktów różnicy. Artificial Analysis zmierzyło jednak, że konfiguracja Claude zużywa około 8,7 raza więcej tokenów na zadanie. Działała też niemal sześć razy dłużej.

Zmierzony koszt API pokazuje jeszcze większą różnicę. Konfiguracja Claude przy maksymalnym wysiłku kosztuje na zadanie około 13,6 raza więcej niż Sol przy xhigh w Codex.

Gemini 4 Argon plasuje się między tymi skrajnościami. Jego zmierzony koszt wynosi około 5,6 raza tyle co Sol, podczas gdy przewaga w indeksie to jeden punkt. Zużywa około 4,3 raza więcej tokenów i potrzebuje ponad dwukrotnie więcej czasu.

Porównanie benchmarków opowiada zatem dwie historie. Claude ma najwyższy wynik złożony, podczas gdy Sol zapewnia najlepszą relację zmierzonego wyniku do kosztu spośród tych trzech konfiguracji.

Artificial Analysis podaje również kilka ustawień wysiłku dla Sonnet 5.5. To istotne, ponieważ maksymalny wysiłek nie jest domyślnym ustawieniem Claude Code.

Sonnet 5.5 przy wysiłku xhigh uzyskuje 63 punkty, dorównując głównemu wynikowi Sol. Zużywa ponad dwa razy więcej tokenów niż Sol, a jego zmierzony koszt jest ponad trzykrotnie wyższy.

Przy wysokim wysiłku Sonnet uzyskuje 55 punktów. Przy średnim wysiłku, będącym ustawieniem domyślnym w Claude Code, uzyskuje 46 punktów. Wyniki te pokazują, jak bardzo budżet rozumowania zmienia oceniany produkt.

Ten sam wzorzec pojawia się w wynikach Sol. GPT-6.1 Sol przy średnim wysiłku uzyskuje 61 punktów, zaledwie o dwa punkty mniej niż jego konfiguracja xhigh. Jego zmierzony koszt i czas działania również wyraźnie spadają.

Maksymalne rozumowanie nie zapewnia automatycznie najlepszego rezultatu. Wynik Sol przy xhigh przewyższa o trzy punkty jego wynik przy maksymalnym wysiłku w opublikowanej ocenie.

Ten nieintuicyjny rezultat przypomina, że benchmarki agentów zawierają element zmienności. Dłuższy czas wnioskowania może pomóc, ale może też prowadzić do dłuższych trajektorii, zbędnych wywołań narzędzi lub nieproduktywnego ponownego rozważania.

Nagłównym zwycięzcą pozostaje Claude Code z Sonnet 5.5 przy maksymalnym wysiłku. Bardziej istotna zmiana polega na tym, że kupujący mogą teraz zobaczyć, jak wysoko wyceniono jego ostatnie pięć punktów.

Benchmark mierzy systemy, a nie same modele

Wynik agenta programistycznego odzwierciedla interakcję między modelem, jego środowiskiem, narzędziami i budżetem rozumowania.

Coding Agent Index v1.5 wykorzystuje trzy komponenty o równej wadze. Według opublikowanej metodologii indeksu każdy komponent testuje inną część pracy programistycznej.

DeepSWE v1.1 obejmuje 113 długoterminowych zadań. Agenci muszą modyfikować istniejące repozytoria, podczas gdy oddzielne środowiska weryfikacyjne oceniają, czy ich zatwierdzone poprawki przechodzą testy.

Terminal-Bench 4.0 zawiera 66 zadań z obszarów takich jak inżynieria oprogramowania, uczenie maszynowe, bezpieczeństwo i administracja systemami. Agenci pracują w środowiskach wiersza poleceń, a następnie zestawy testów oceniają ich wyniki.

SWE-Atlas-QnA zawiera 124 pytania dotyczące repozytoriów. Zadania te mierzą, czy agent potrafi prześledzić nieznany kod i precyzyjnie wyjaśnić jego działanie.

Każde zadanie otrzymuje trzy próby. Artificial Analysis oblicza wyniki pass-at-one dla każdego komponentu, a następnie nadaje trzem komponentom równą wagę w indeksie złożonym.

Ta struktura jest szersza niż konwencjonalny test generowania kodu. Nagradza agentów, którzy potrafią analizować repozytoria, dobierać narzędzia, obsługiwać terminale, utrzymywać kontekst i wychodzić z błędów.

Sprawia też, że środowisko agenta ma znaczenie. Jest to warstwa oprogramowania łącząca model z plikami, terminalami, instrukcjami, zarządzaniem kontekstem i wykonywaniem narzędzi.

Claude Code, Codex i Antigravity CLI nie oferują identycznych przepływów pracy. Mogą inaczej pakować kontekst, zachęcać do odmiennych wzorców użycia narzędzi lub nakładać różne ograniczenia.

W konsekwencji benchmark nie może dowieść, że Sonnet 5.5 jest zawsze lepszym modelem programistycznym niż GPT-6.1 Sol. Ustala jedynie, że jedna testowana konfiguracja Claude Code uzyskała wyższy wynik niż jedna testowana konfiguracja Codex.

To rozróżnienie widać w wynikach składowych. Gemini 4 Argon prowadzi w tej trójce w DeepSWE z wynikiem 79 procent, mimo że ogólnie plasuje się poniżej Claude.

Sol nieznacznie przewyższa Sonnet przy maksymalnym wysiłku w DeepSWE. Claude buduje swoją ogólną przewagę dzięki Terminal-Bench i SWE-Atlas-QnA, gdzie osiąga większe różnice.

Wyniki opisują więc różne profile możliwości. Gemini wydaje się najsilniejsze w długoterminowych zmianach repozytoriów z benchmarku. Claude wygląda na bardziej zrównoważone w pracy z terminalem i rozumieniu repozytoriów.

Sol pozostaje konkurencyjny we wszystkich trzech obszarach, korzystając przy tym z mniejszej ilości zmierzonych zasobów. Nie wygrywa uwzględnionego komponentu z oboma rywalami, ale unika poważnej słabości.

Ta równowaga ma znaczenie w zastosowaniach produkcyjnych. Zespół utrzymujący duże repozytorium może wyżej cenić ukończenie poprawki niż odpowiadanie na pytania o repozytorium. Inny zespół może potrzebować niezawodnej pracy w terminalu w różnych środowiskach.

Pojedyncza liczba indeksu pomaga czytelnikom szybko zorientować się w sytuacji. Nie powinna zastępować wyników składowych przy wyborze narzędzia do określonego obciążenia.

Artificial Analysis agreguje również dane o tokenach, kosztach i czasie z tego samego zestawu benchmarków. Brakująca telemetria jest wyłączana z odpowiedniej średniej, zamiast być traktowana jako zero.

Jego kalkulacja kosztu uwzględnia zwykłe tokeny wejściowe, tokeny wejściowe z pamięci podręcznej, zapisy do pamięci podręcznej, tokeny rozumowania i wyjściowe, gdy dostawcy wyceniają te kategorie osobno. Reprezentuje koszt API rozliczany za token, a nie cenę subskrypcji.

Raportowany koszt nie obejmuje też kilku wydatków operacyjnych. Nie uwzględnia integracji inżynierskiej, przeglądu przez człowieka, konfiguracji środowiska, mechanizmów bezpieczeństwa ani konsekwencji wadliwej poprawki.

Wyłączenia te nie osłabiają porównania. Określają, na jakie pytanie może ono odpowiedzieć: ile wykorzystania modelu zużyli oceniani agenci w tym teście.

Wyjaśniają również, dlaczego najtańsze uruchomienie benchmarku nie zawsze prowadzi do najtańszego zaakceptowanego pull requesta. Słabszy wynik może generować dodatkowe koszty przeglądu, korekty i ponownego uruchomienia.

Zespoły powinny zatem oceniać zarówno bezpośredni koszt wnioskowania, jak i koszt na skuteczny rezultat. Opublikowany indeks dostarcza przydatnych składników, lecz nie oblicza tej pełnej miary biznesowej.

Claude Sonnet 5.5 wygrywa pod względem wydajności za wysoką premię efektywnościową

Przewaga Claude jest realna w ramach tego benchmarku, lecz maksymalny wysiłek zamienia niewielką przewagę punktową w duże zobowiązanie zasobowe.

Anthropic wypuścił Sonnet 5.5 28 września 2026 roku. Firma pozycjonuje go jako szybsze i tańsze uzupełnienie Opus 5.5 do ograniczonych codziennych zadań, debugowania i tworzenia dokumentów.

Informacje Anthropic o wydaniu modelu podkreślają regulowany poziom wysiłku. Niższe ustawienia stawiają na szybkość i oszczędność, podczas gdy wyższe dają modelowi więcej czasu na rozumowanie i sprawdzanie pracy.

Wyniki Artificial Analysis pokazują obie strony tego projektu. Przejście Sonnet ze średniego na maksymalny wysiłek podnosi jego wynik w indeksie z 46 do 68.

Ta poprawa o 22 punkty jest znacząca. Towarzyszy jej około 21 razy więcej tokenów, ponad dziesięciokrotnie dłuższy czas działania i niemal 23 razy wyższy zmierzony koszt API.

Maksymalny wysiłek generuje również bardzo długie trajektorie agenta. Artificial Analysis odnotowuje około 266 tur na zadanie oraz 27,7 miliona tokenów łącznie dla wiodącej konfiguracji.

Liczby te nie oznaczają, że każde rzeczywiste zadanie zużyje takie same zasoby. Pokazują średnie zachowanie w wymagającym zestawie benchmarków, obejmującym setki prób wykonania zadań.

Wyjaśniają też, jak model wygrywa. Najwydajniejsza konfiguracja nie generuje po prostu inteligentniejszej odpowiedzi przy tym samym budżecie. Spędza znacznie więcej czasu na interakcji ze swoim środowiskiem.

Ta strategia przynosi korzyści w wyniku złożonym. Claude wyprzedza Gemini o cztery punkty, a Sol o pięć. Uzyskuje też najlepsze w tej trójce wyniki w dwóch z trzech benchmarków składowych.

Premię trudniej uzasadnić, gdy do porównania wchodzą ustawienia Claude o niższym wysiłku. Sonnet przy xhigh dorównuje 63-punktowemu wynikowi Sol, lecz zużywa więcej tokenów, czasu i zmierzonych wydatków.

Przy wysokim wysiłku Claude pozostaje osiem punktów za Sol xhigh. Jego zużycie zasobów jest bliższe Sol, lecz różnica w wydajności staje się istotna.

Przy średnim wysiłku Claude jest znacznie tańszy i szybszy niż w maksymalnej konfiguracji. Jego wynik jest jednak o 17 punktów niższy niż Sol xhigh i o 18 punktów niższy niż Gemini.

Nie ma sprzeczności między tymi wynikami. Anthropic pozwala użytkownikom kupować więcej rozumowania w czasie testowym, a benchmark pokazuje, że dodatkowe rozumowanie może zwiększać ukończenie zadań.

Kompromis dotyczy skali. Indywidualny programista może zaakceptować długie i kosztowne uruchomienie dla trudnej migracji. Firma przetwarzająca tysiące rutynowych zmian staje przed innym rachunkiem.

Najlepsze ustawienie może też różnić się w trakcie jednego przepływu pracy. Zespół może używać średniego wysiłku do eksploracji, wysokiego do implementacji, a maksymalnego wyłącznie przy uporczywych niepowodzeniach.

Ta strategia routingu pozwoliłaby zachować dostęp do szczytowych możliwości Claude’a bez stosowania jego najwyższego budżetu zasobów do każdego zgłoszenia. Wymaga jednak pomiarów i jasnych zasad eskalacji.

Zwycięstwo Claude’a w benchmarku jest więc najbardziej istotne dla zadań, w których jakość ukończenia dominuje nad wszystkimi innymi ograniczeniami. Przykłady obejmują trudne poprawki między repozytoriami, ryzykowne migracje lub incydenty o wysokich kosztach niepowodzenia.

Jest mniej rozstrzygające w przypadku utrzymania systemów na dużą skalę. Aktualizacje zależności, niewielkie refaktoryzacje, generowanie testów i rutynowe poprawki błędów często premiują akceptowalną jakość przy przewidywalnym koszcie.

Dlatego Artificial Analysis Coding Agent Index nie powinien stać się skrótem w decyzjach zakupowych. Wynik 68 punktów reprezentuje konfigurację maksymalną, a nie automatyczne ustawienie domyślne.

GPT-6.1 Sol i Gemini 4 Argon wywierają presję na Claude’a z różnych stron

Sol rzuca wyzwanie Claude’owi pod względem efektywności, a Argon — w pracy z repozytoriami wymagającej długiego horyzontu działania.

OpenAI wprowadziło GPT-6.1 Sol 29 września, dzień po tym, jak Anthropic wydał Sonnet 5.5. Google poszło w jego ślady, prezentując Gemini 4 Argon 30 września.

To tempo dało Artificial Analysis trzy nowe konfiguracje z czołówki rynku do porównania w ciągu kilku dni. Ich pozycje w benchmarku ujawniają większe zróżnicowanie, niż sugerują opisy premier.

OpenAI opisuje Sol jako model niemal flagowy do programowania, obsługi komputera i pracy profesjonalnej przy niższych kosztach. Jego karta modelu Sol obsługuje pięć ustawień rozumowania — od niskiego po maksymalne.

W Coding Agent Index najlepszym przetestowanym ustawieniem Sol jest xhigh. Osiąga ono wynik 63, podczas gdy maksymalny wysiłek rozumowania uzyskuje 60.

Wynik ten podważa założenie, że największy budżet rozumowania jest zawsze najbezpieczniejszy. Sugeruje, że zespoły powinny testować ustawienia wysiłku w benchmarkach, zamiast domyślnie wybierać najwyższą etykietę.

Główną zaletą Sol jest spójność w przeliczeniu na jednostkę zasobów. Konfiguracja xhigh kończy przeciętne zadanie w około 15,5 minuty i zużywa 3,2 mln tokenów.

Claude przy maksymalnym wysiłku potrzebuje około 90 minut i 27,7 mln tokenów. Gemini wymaga około 34,5 minuty i 13,7 mln tokenów.

Sol wypada też konkurencyjnie w każdym komponencie. Jego wynik DeepSWE na poziomie 73 procent przewyższa 72 procent Claude’a, choć pozostaje za 79 procent Gemini.

Jego wyniki w Terminal-Bench i pytaniach dotyczących repozytoriów są nadal niższe niż u Claude’a. Te różnice składają się na pięciopunktową lukę w wyniku łącznym.

Dla wielu organizacji taka luka będzie akceptowalna. Niższe zużycie zasobów przez Sol pozwala na więcej prób, szersze wdrożenie lub dodatkową weryfikację w ramach tego samego budżetu.

Porównanie nie dowodzi, że Sol jest zawsze bardziej ekonomiczny. Ceny dostawców mogą się zmieniać, wzorce buforowania różnią się, a wewnętrzne obciążenia robocze mogą generować inne rozkłady tokenów.

Ustanawia jednak silną hipotezę wartą sprawdzenia. Jeśli zadania zespołu przypominają te z benchmarku, Codex z Solem może zapewnić lepszą równowagę między kosztem a wydajnością niż Claude przy maksymalnym wysiłku.

Gemini 4 Argon wywiera presję innego rodzaju. Google przedstawiło Argon jako model do długotrwałego rozumowania w złożonych profesjonalnych przepływach pracy.

Ogłoszenie Argon od Google opisuje wewnętrzne zastosowania związane z migracją kodu, optymalizacją pamięci, badaniami i cyberbezpieczeństwem. Przykłady te pozostają deklaracjami firmy, dopóki nie zostaną niezależnie odtworzone.

Coding Agent Index dostarcza niezależnych dowodów dla jednej części tej narracji. Wynik Argon na poziomie 79 procent w DeepSWE jest najwyższy spośród trzech wyróżnionych systemów.

Rezultat ten jest zgodny z naciskiem Google na pracę o długim horyzoncie. Sugeruje, że Argon zasługuje na uwagę przy rozbudowanych zmianach w repozytoriach, mimo że Claude prowadzi w całym indeksie.

Słabszy wynik Argon w pytaniach dotyczących repozytoriów obniża jego wynik łączny. Rezultat 56 procent oznacza stratę pięciu punktów do Sol i jedenastu do Claude’a.

Modelowi brakuje też zmierzonej efektywności Sol. Argon zyskuje jeden punkt w wyniku agregowanym względem Sol, wymagając jednocześnie ponad czterokrotnie większej liczby tokenów na zadanie.

Nie czyni to tej konfiguracji nieracjonalną. Wyższy wskaźnik ukończenia DeepSWE może przeważyć nad zużyciem zasobów w organizacjach mierzących się z trudną pracą implementacyjną.

Kluczowe jest dopasowanie do rodzaju obciążenia. Sol wygląda atrakcyjnie jako efektywny model uniwersalny, podczas gdy Argon daje silniejszy sygnał w zakresie długotrwałej modyfikacji repozytoriów.

Claude pozostaje liderem zrównoważonej wydajności przy swoim najbardziej agresywnym ustawieniu. Presja rynkowa pochodzi od rywali, którzy sprawiają, że różne części tej przewagi stają się mniej wartościowe.

To zdrowszy obraz konkurencji niż jeden uniwersalny ranking. Daje zespołom inżynieryjnym wyraźne opcje zamiast trzech niemal wymiennych marek modeli.

Zwiększa to także znaczenie utrzymywania przenośnych przepływów pracy. Zespoły powinny unikać wiązania promptów, praktyk przeglądu i przygotowywania kontekstu z jednym modelem, chyba że korzyść jest mierzalna.

Możliwość przeszukiwania zapisów wymagań, decyzji i wcześniejszych zmian może uczynić takie porównania bardziej spójnymi. Zespoły mogą wykorzystać bazę wiedzy dla zespołów inżynieryjnych, aby zachować ten kontekst między testami agentów.

Celem nie jest zmienianie modeli co tydzień. Chodzi o umożliwienie zmiany i oceny, gdy przesuwa się granica wydajności.

Czego liczby nie dowodzą

Pięciopunktowa przewaga w benchmarku nie gwarantuje lepszego kodu, bezpieczniejszego wdrożenia ani niższego całkowitego kosztu inżynieryjnego w rzeczywistej organizacji.

Artificial Analysis publikuje więcej szczegółów metodologicznych niż wielu operatorów rankingów. Dokumentuje zadania składowe, liczbę prób, metody punktacji i definicje efektywności.

Mimo to benchmark pozostaje próbką. Nie może reprezentować każdego języka, kształtu repozytorium, środowiska zależności, polityki bezpieczeństwa ani standardu przeglądu.

Indeks nadaje równe wagi swoim trzem komponentom. Rzeczywista firma rzadko ceni pytania o repozytoria, operacje terminalowe i ukończenie poprawek w dokładnie równych proporcjach.

Jedna organizacja może spędzać większość czasu nad usługami TypeScript z rozbudowanymi testami. Inna może utrzymywać wbudowany kod C, potoki danych lub regulowane systemy finansowe.

Ich wewnętrzny ranking może różnić się od publicznej tabeli wyników. Model, który wyróżnia się w DeepSWE, może nadal mieć trudności z autorskimi frameworkami lub słabo udokumentowanym starszym kodem.

Punktacja pass-at-one także spłaszcza istotne różnice jakościowe. Dwie poprawki mogą przejść automatyczny weryfikator, a mimo to różnić się pod względem łatwości utrzymania, bezpieczeństwa, czytelności lub dopasowania architektonicznego.

Może też zdarzyć się odwrotnie. Użyteczne częściowe rozwiązanie może nie spełnić jednego warunku weryfikatora i otrzymać ten sam binarny wynik co bezużyteczna próba.

SWE-Atlas-QnA wprowadza kolejną zależność. Artificial Analysis korzysta z automatycznego sędziego, aby ustalić, czy odpowiedzi dotyczące repozytorium spełniają wszystkie wymagane kryteria.

Automatyczne ocenianie umożliwia ewaluację na dużą skalę. Nadal może dziedziczyć niejednoznaczność, stronniczość modelu lub błędy oceniania, szczególnie w przypadku wyjaśnień mających kilka poprawnych sformułowań.

Uśrednione wyniki benchmarku ukrywają także rozrzut. Średni koszt nie pokazuje, czy większość zadań jest przewidywalna, podczas gdy niewielka grupa tworzy wyjątkowo długie trajektorie.

Ta zmienność ma znaczenie dla budżetowania. Usługa może tolerować umiarkowaną średnią, a jednocześnie cierpieć z powodu pojedynczych uruchomień, które zużywają nadmierną liczbę tokenów lub zajmują środowiska przez wiele godzin.

Zachowanie agenta może się również zmieniać po aktualizacjach produktu. Wybór narzędzi, kompresja kontekstu, logika ponawiania prób i ukryte instrukcje systemowe mogą się przesunąć bez nowej publicznej nazwy modelu.

Z tego powodu benchmark należy traktować jako pomiar z określonego momentu. Nie jest trwałą właściwością Claude Code, Codex, Antigravity CLI ani ich bazowych modeli.

Claude przy maksymalnym wysiłku ilustruje ryzyko odczytywania wyniku maksymalnego jako domyślnego doświadczenia. Konfiguracja objęta benchmarkiem jest znacznie bardziej zasobochłonna niż domyślne średnie ustawienie Claude Code.

Indeks porównuje także wydatki na API rozliczane za token. Limity subskrypcji, wynegocjowane stawki dla przedsiębiorstw, przetwarzanie regionalne i infrastruktura wewnętrzna mogą zmienić rzeczywistą ekonomię zespołu.

Brakuje też kosztów ludzkich. Wolniejszy agent może być akceptowalny, jeśli pracuje asynchronicznie. Szybszy agent może być cenniejszy, gdy programista czeka na informację zwrotną.

Obciążenie związane z przeglądem to kolejna nierozstrzygnięta zmienna. Tania poprawka wymagająca rozległej inspekcji może w rezultacie kosztować więcej niż droga poprawka zaakceptowana po krótkim przeglądzie.

Bezpieczeństwo zasługuje na podobną ostrożność. Żaden z czołowych wyników sam w sobie nie potwierdza, że agent przestrzega dostępu o najmniejszych uprawnieniach, opiera się złośliwym instrukcjom w repozytorium lub unika ujawnienia wrażliwego kontekstu.

Google ograniczyło początkową dostępność Argon, prowadząc etapowe prace nad bezpieczeństwem. Oznacza to, że dowody z jego publicznego użycia mogą pozostać skromniejsze, niż sugeruje zainteresowanie benchmarkiem.

Deklaracje dostawców również wymagają starannego przypisania. Anthropic, OpenAI i Google podkreślają korzystne wyniki ewaluacji z różnych zestawów testów i ustawień.

Wyniki te mogą być trafne, nie będąc jednocześnie bezpośrednio porównywalnymi. Różne środowiska testowe, zestawy zadań, budżety i zasady punktacji często wyłaniają różnych liderów.

Benchmark Artificial Analysis poprawia porównywalność, uruchamiając konfiguracje w jednym frameworku. Nie może jednak usunąć każdej różnicy wprowadzanej przez zastrzeżonych agentów i interfejsy modeli.

Liderzy inżynieryjni powinni odtworzyć niewielki wewnętrzny test przed standaryzacją. Użyteczny zestaw testowy obejmuje ukończone zgłoszenia, znane przypadki awarii i reprezentatywne ograniczenia repozytoriów.

Recenzenci powinni oceniać poprawność, niepotrzebne zmiany, bezpieczeństwo, pokrycie testami, jakość wyjaśnień i czas do akceptacji. Wydatki na tokeny należy rejestrować obok tych wyników.

Wynikową miarą powinna być zaakceptowana praca na dolara lub zaakceptowana praca na roboczogodzinę inżyniera. Publiczny wynik łączny może pomóc w wyborze kandydatów, ale nie zastąpi takiego pomiaru.

Trzy sygnały zdecydują, czy przewaga Claude’a ma znaczenie

O kolejnej fazie zdecyduje wydajność przy ustawieniach domyślnych, ekonomika zaakceptowanych zmian i stabilność benchmarków między aktualizacjami.

Pierwszym sygnałem jest wydajność przy praktycznych ustawieniach wysiłku. Maksymalne konfiguracje przyciągają nagłówki, lecz to ustawienia domyślne kształtują większość codziennego użycia.

Sonnet 5.5 przy średnim wysiłku uzyskuje wynik znacznie niższy od maksymalnego. W opublikowanych danych Sol traci jedynie dwa punkty przy przejściu z xhigh na medium.

Jeśli Anthropic zmniejszy tę lukę przy ustawieniach domyślnych, maksymalny wynik Claude’a wynoszący 68 punktów stanie się bardziej istotny dla zwykłych zespołów. Jeśli luka się utrzyma, argument efektywności Sol zyska na sile.

Drugim sygnałem jest koszt na zaakceptowaną zmianę. Publiczne benchmarki mierzą obecnie wydatki API na zadanie, a nie pełną drogę od zgłoszenia do kodu scalonego z główną gałęzią.

Zespoły powinny obserwować, czy dostawcy lub niezależni ewaluatorzy publikują wyniki skorygowane o przegląd. Powinny one obejmować ponowne uruchomienia, czas ludzkich poprawek i regresje wykryte po weryfikacji.

Premię Claude’a łatwiej uzasadnić, jeśli jego poprawki wymagają mniej przeglądu. Przewaga Sol stanie się silniejsza, jeśli jego niższe zużycie zasobów inferencyjnych nie powoduje dodatkowej pracy korekcyjnej.

Argon może prowadzić w tej mierze przy złożonych zmianach w repozytoriach, jeśli jego siła w DeepSWE przeniesie się do środowiska produkcyjnego. Sam wynik agregowany nie może odpowiedzieć na to pytanie.

Trzecim sygnałem jest stabilność rankingu. Agenci programistyczni zmieniają się wraz z aktualizacjami modeli, rewizjami środowisk testowych, zasad narzędziowych i ulepszeniami zarządzania kontekstem.

Stabilny lider powinien utrzymywać pozycję w powtarzanych uruchomieniach i kolejnych wersjach benchmarku. Duże zmiany po niewielkich aktualizacjach systemu obniżyłyby zaufanie do niewielkich różnic punktowych.

Artificial Analysis już publikuje wyniki komponentów, miary efektywności i rewizje metodologii. Przyszłe ponowne uruchomienia pokażą, czy pięciopunktowa różnica oznacza trwałe rozdzielenie, czy tymczasowe efekty konfiguracji.

Zespoły deweloperskie nie muszą czekać na idealny benchmark. Mogą już teraz podjąć decyzję w jasno określonych granicach.

Zacznij od reprezentatywnego zestawu wewnętrznych zadań. Porównaj Claude na więcej niż jednym poziomie nakładu pracy z Sol i Argon — tam, gdzie dostęp na to pozwala.

Utrzymuj spójne uprawnienia agenta, migawkę repozytorium i kryteria sukcesu. Rejestruj czas rzeczywisty, liczbę tokenów, niepowodzenia, czas przeglądu oraz to, czy końcowa zmiana została zaakceptowana.

Konfigurację wymagającą dużego nakładu pracy stosuj tylko wtedy, gdy zadanie uzasadnia eskalację. Rutynową pracę należy rozpoczynać od najmniej kosztownego ustawienia, które spełnia próg akceptacji zespołu.

Powtarzaj porównanie po istotnych aktualizacjach modeli lub środowiska testowego. Artificial Analysis Coding Agent Index jest użyteczny właśnie dlatego, że czołówka stale się zmienia.

Na razie jego przekaz jest jasny. Claude Sonnet 5.5 ma najwyższy opublikowany wynik spośród trzech nowych konfiguracji, ale nie zajmuje pierwszego miejsca według każdej praktycznej definicji.

GPT-6.1 Sol oferuje przekonujący profil efektywności, podczas gdy Gemini 4 Argon przewodzi tej trójce w pracy nad repozytoriami wymagającej długiego horyzontu działania. Właściwy wybór zależy od tego, jaki rezultat zespół ceni najbardziej.

Czy Twoja organizacja zapłaciłaby wysoką premię zasobową za dodatkowe pięć punktów indeksu, czy sfinansowałaby więcej prób i weryfikacji z Sol? Sprawdź to pytanie na podstawie własnych zmian scalonych z kodem, zanim wybierzesz ustawienie domyślne.