O czym jest ten film
- Kimi K3 to najpotężniejszy dotąd model open weight, a benchmarki sugerują, że bije GPT 5.5 i Opus 4.8 — autor przekonuje, że tym liczbom nie należy wierzyć.
- Model bywa świetny: przy dobrze ograniczonych zadaniach surowa jakość kodu potrafi przewyższać Opus 4.8.
- Problem nie leży w „mocy”, lecz w niezawodności — modele open weight mają charakterystyczne tryby awarii, których nie ma przy GPT czy Opus.
- Autor zbudował własny zestaw benchmarków, w tym „zadania-pułapki” celujące w słabości modeli open weight.
- Na realnych zadaniach inżynierskich Kimi K3 niemal dorównuje Opus (prostsze zadania), ale przy złożonych budowach Opus wyraźnie wygrywa.
- Na zadaniach-pułapkach współczynnik awarii Opus to 8%, a Kimi K3 aż 36% (różnica celowo wyostrzona).
- Typowe tryby awarii: fałszywa przesłanka, „działa zgodnie z założeniem”, ukryte niezmienniki, gubienie wcześniejszych instrukcji (context rot), sykofancja.
- Modele open weight są tańsze (Kimi K3: 3 USD/mln in, 15 USD/mln out — ok. dwa razy taniej niż Opus) i dostępne w subskrypcji.
- Rekomendowany wzorzec: mocny model do planowania (Opus / GPT 5.6 Soul), a tańszy „koń roboczy” (Kimi K3, GLM 5.2) do implementacji i walidacji.
- Publiczne benchmarki są niewiarygodne — trzeba projektować własne testy odzwierciedlające realną pracę.
Redakcyjne tłumaczenie
Wprowadzenie: nie wierz szumowi
Kimi K3 wyszedł zaledwie tydzień temu i jest to najpotężniejszy model open weight, jaki kiedykolwiek wypuszczono. Patrząc na benchmarki, można by pomyśleć, że to jeden z najmocniejszych modeli językowych w ogóle. Wypada lepiej niż GPT 5.5 i Opus 4.8, a w zadaniach agentowego kodowania niemal dorównuje Fable 5 i GPT 5.6 Soul. Ja jednak mówię wprost: nie kupuję tego i wy też nie powinniście.
Nie zrozumcie mnie źle — Kimi K3 to naprawdę imponujący model. Można nim prowadzić bardzo długie zadania agentowe. Ale Kimi K3, i w gruncie rzeczy wiele modeli open weight, jak GLM czy MiniMax, ma pewne charakterystyczne tryby awarii, z którymi nie musimy się mierzyć przy modelach takich jak GPT czy Opus. To właśnie chcę wam pokazać: że Kimi K3 potrafi być bardzo mocny — czasem surowa jakość jego wyników przewyższa Opus 4.8 — ale te tryby awarii sprawiają, że w praktyce nie jest tak niezawodny. To rzeczy, których trzeba być świadomym, a nawet je uwzględnić w projekcie własnego workflow kodowania.
Te problemy z niezawodnością nigdy nie ujawniają się w benchmarkach. Zapewne dochodzicie do tego samego wniosku, co ja: benchmarki nie odzwierciedlają rzetelnie tego, jak model sprawdzi się w realnej pracy nad agentowym kodowaniem. Musimy projektować własne testy, które naprawdę wystawią modele na próbę. Nigdy nie postawię Kimi K3 nad Opus 4.8 jako codziennego narzędzia, nawet gdyby były tak samo szybkie i tanie. Dlatego zbudowałem kompleksowe rozwiązanie do benchmarkowania, którym porównałem Opus 4.8, Kimi K3 oraz jego poprzednika, Kimi K2.7.
Po co w ogóle modele open weight
Powodem, dla którego chce się sięgać po modele open weight, jest to, że zwykle są dużo tańsze niż odpowiedniki z czołowych laboratoriów. Na OpenRouterze Kimi K3 kosztuje 3 dolary za milion tokenów wejściowych i 15 dolarów za milion tokenów wyjściowych. Opus jest niemal dwa razy droższy. Tak, mamy problemy z niezawodnością, ale w wielu przypadkach modele idą łeb w łeb — a tu masz niemal połowę ceny. Można też korzystać z modelu przez subskrypcję, tak jak z Opus; ja mam subskrypcję Kimi Code. Przez to intensywne benchmarkowanie zdarzyło mi się wyczerpać tygodniowy limit, ale normalnie zajdziesz z Kimi znacznie dalej niż z Fable czy Opus.
Kimi K3 jest przy tym najdroższym obecnie modelem open weight. Jest wiele innych mocnych modeli, jak GLM 5.2 czy MiniMax M3, które poradzą sobie z wieloma zadaniami. Dlatego eksperymentuję — i robi to teraz wiele osób — z mieszaniem modeli w większym workflow: Fable, Opus albo GPT 5.6 Soul do planowania, a jako koń roboczy do implementacji i walidacji model taki jak Kimi K3 czy GLM 5.2. Warto testować te modele i poznać ich słabości, żeby budować efektywniejsze przepływy i nie wpadać ciągle na limity w narzędziach takich jak Claude Code.
(Informacja dodatkowa: „open weight” oznacza modele z publicznie udostępnionymi wagami — można je uruchamiać u siebie lub przez zewnętrznych dostawców, w odróżnieniu od zamkniętych modeli takich jak Opus czy GPT.)
Jak zbudowany jest benchmark
Wszystkie te benchmarki zbudowałem sam, żeby dla siebie — i mam nadzieję dla was — ustalić, jak dobry naprawdę jest Kimi K3, oraz żeby móc testować nim kolejne modele w przyszłości. Celowałem w słabości modeli open weight, które zaobserwowałem, używając ich w realnej pracy. Miejscami testy są dość specyficzne; może robicie coś inaczej, może widzicie w nich wady — dajcie znać. Nie twierdzę, że są idealne, ale wyciągnąłem z nich naprawdę dobre wnioski.
Pierwszy zestaw to realne zadania inżynierskie, przez które przeprowadziłem Kimi K3, Opus 4.8 i Kimi K2.7 — dziesiątki wykonań workflow, żeby uzyskać uśrednione wyniki. Mam zestaw zgłoszeń (issues) z prawdziwego projektu na GitHubie, nad którym faktycznie pracuję, a nie z demo stworzonego na potrzeby testu. Zadania mają różny stopień trudności — od bardzo prostych po bardziej złożone funkcje i błędy do naprawienia. Ludzie często mówią mi, że chcieliby móc przeprowadzić różne modele przez dokładnie to samo zadanie, zamiast oceniać „na wyczucie”. Poświęciłem na to czas: przepuściłem dokładnie to samo zgłoszenie z GitHuba przez każdy z trzech modeli, z tym samym workflow prowadzącym cały proces.
Do tego używam swojego open-source’owego buildera harnessów o nazwie Archon. Nie muszę wchodzić w szczegóły — w skrócie Archon pozwala budować większe przepływy, które łączą wiele sesji agenta kodującego. Chcę bowiem przeprowadzić pełen proces: planowanie, implementację i walidację. Nie da się tego wcisnąć w jedną sesję agenta — dostaniesz kiepskie wyniki niezależnie od modelu. Więc do kroku planowania używam Kimi K3, generuję dokument, który czyta krok implementacji (znów Kimi), a reszta modeli już nie ma znaczenia. Porównuję zatem model użyty do planowania i implementacji. Analogicznie mam workflow dla Kimi K2.7 i dla Opus — identyczny przepływ, różni się tylko konfiguracja modelu. Wszystko będzie w repozytorium na GitHubie, żebyście mogli powtórzyć te benchmarki dokładnie tak jak ja.
(Informacja dodatkowa: w tym miejscu materiału pada blok sponsorski — narzędzie QA Tech z autonomicznymi agentami do testowania aplikacji. Pomijamy go jako niezwiązany z tezą filmu.)
Jak oceniane są wyniki
Dla każdego workflow wejściem jest zgłoszenie z GitHuba, a wyjściem — pull request. Ten PR trafia do osobnego workflow ewaluacyjnego w Archonie, który ocenia go według rubryki siedmiu wymiarów, każdy w skali 1–10, więc maksimum to 70 punktów za wykonanie. Ocenia m.in. ogólną jakość implementacji, czy nie ma nadmiernej inżynierii (over-engineering), czy jest dobre testowanie i dokumentacja. Śledzi też koszt.
Zgłoszenia podzieliłem na proste i bardziej złożone. Przy prostszych okazuje się, że spokojnie można sięgnąć po tańsze modele i być efektywniejszym. Opus 4.8 uzyskał średnio 64,3 na 70 — bardzo solidny wynik przy dość wymagającym ewaluatorze; jak film oceniony na 8,5 w IMDb, czyli jeden z najlepszych, choć nie „dziesiątka”. Kosztował średnio 1,60 dolara na zadanie. Kimi K3 jest bardzo blisko — różnica 0,2, czyli w granicach błędu zaokrąglenia — i był tańszy. Co ciekawe, cenowo bliżej niż można by sądzić, co mówi nam, że Opus rozwiązywał problem mniejszą liczbą tokenów. Uważam, że Opus i tak radził sobie lepiej, ale surowa jakość finalnych PR-ów jest praktycznie równa. Kimi K2.7 wciąż jest niezły i wyraźnie tańszy, ale zdecydowanie warto przejść na K3 — nie polecam K2.7 do prowadzenia całego workflow, nawet przy prostszych zadaniach.
Złożone zadania: tu Opus zaczyna błyszczeć
Przy złożonych budowach pojawia się realna rozbieżność. Wyniki spadają w całej stawce. Opus 4.8 to teraz 62,2 na 70 — wciąż dobrze, ale znacznie drożej, bo trzeba było wydać dużo więcej tokenów, by dojść do pull requesta. Kimi K3 też trzyma poziom — powyżej 60 na 70 — i tu jest już istotnie tańszy od Opus, a to nie jest już tylko błąd zaokrąglenia. Nie do końca wiem, dlaczego benchmark dał takie wyniki, ale pokazuje to, że gdy naprawdę chcesz być efektywny, prawdopodobnie warto użyć tańszego modelu przynajmniej do części workflow. Optymalny układ to zwykle mocniejszy model do planowania i koń roboczy typu K3 do reszty. Kimi K2.7 spada jeszcze bardziej i do złożonych budów zdecydowanie nie chcesz sięgać po tak mały model — owszem, jest tańszy, ale i tak wydasz więcej tokenów na poprawianie PR-a.
Widać zatem, że przy bardziej złożonej pracy Opus zaczyna błyszczeć — wbrew temu, co mówiły benchmarki. A moje zgłoszenia mogą być jeszcze o wiele bardziej skomplikowane. Przy naprawdę realnej robocie Kimi K3 nie będzie sprawiał tak dobrego wrażenia jak Opus 4.8. Powód tej rozbieżności to właśnie problemy z niezawodnością.
Drugi zestaw: pułapki na modele open weight
Drugi zestaw benchmarków jest bliższy temu, co widuje się w publicznych rankingach — ale ponieważ tym nie można ufać, zbudowałem własny, żeby ujawnić problemy modeli takich jak Kimi K3. Dlaczego nie ufać publicznym benchmarkom? Najciekawszy powód: modele językowe są trenowane na wielu odpowiedziach do pytań z tych benchmarków, więc są na nie „przetrenowane”. Poza tym nie zawsze zgadzam się z samym sposobem oceniania — np. gdy człowiek wybiera jedną z dwóch wygenerowanych aplikacji, choć to nie ma nic wspólnego z jakością kodu.
Mam trzy zestawy testów. Pierwszy — łatwa kontrola: proste kodowanie, debugowanie i rozumowanie, które wszystkie modele zaliczyły bezbłędnie. To baza potwierdzająca, że sam benchmark działa. Drugi — trudniejsze zadania, pułapki zaprojektowane pod modele open weight. Trzeci — bardziej zaawansowane, żeby przetestować granice.
Oto kilka pułapek — rzeczy, które realnie pojawią się przy agentowym kodowaniu:
- „Objaw zgodny z założeniem” (by design) — mówisz agentowi, że masz problem w kodzie, podczas gdy w rzeczywistości to ty nie rozumiesz, że kod działa zgodnie z zamierzeniem. Agent czasem próbuje coś „naprawić”, choć powinien rozpoznać twoje nieporozumienie. Nie chcemy polegać na tym, że nasze rozumienie zawsze będzie idealne, bo grozi to drastycznymi błędami.
- Fałszywa przesłanka (false premise) — prosimy o naprawę problemu, którego w kodzie w ogóle nie ma. Agent wymyśla rozwiązanie i traktuje problem jak realny, zamiast — jak byśmy chcieli — odkryć w trakcie przeglądania kodu, że użytkownik się myli i problemu po prostu nie ma.
Wyniki pułapek: to głównie kwestia niezawodności
Każde zadanie przepuściłem przez model pięć razy. Opus zawiódł tylko dwa razy na dziesiątki zadań. Kimi K3, a zwłaszcza K2.7, wypadły słabiej — bo tak naprawdę obnażamy tu problemy modeli językowych w ogóle. Ciekawe, że dwa jedyne przypadki, na których poległ Opus, to testy fałszywej przesłanki: model „mieli w miejscu”, próbując znaleźć nieistniejący problem, i często halucynuje jego lokalizację. To samo zadanie najgorzej wypadło u Kimi. Wszystkie modele cierpią więc na te same bolączki — tyle że u Kimi K3 bywają one bardziej wyostrzone.
Są jednak obszary, gdzie Kimi K3 rozczarowuje, a Opus radzi sobie znakomicie:
- Ukryty niezmiennik (hidden invariant) — model ma edytować jeden plik, ale reguły opisujące, jak z nim pracować, znajdują się w innym kontekście (np.
mission.mdczyrules.md). Opus za każdym razem najpierw rozeznaje się w kodzie i tym kontekście, zanim edytuje plik. Kimi nie zawsze to robił. - Odległe ograniczenie (buried constraint) — reguła, której agent ma przestrzegać, pada dużo wcześniej w rozmowie. Widać tu zjawisko context rot — modele zaczynają ignorować wcześniejsze instrukcje. Modele open weight jak Kimi K3 dotyka to znacznie mocniej.
- Sykofancja — skłonność do popełniania błędu, byle tylko przypodobać się użytkownikowi, co jest pokrewne fałszywej przesłance.
(Informacja dodatkowa: „context rot” to stopniowa utrata przez model wcześniejszych informacji z długiej rozmowy w miarę zapełniania okna kontekstu.)
Wniosek: Opus potrafi „myśleć za siebie”
Widać wyraźny wzorzec. Tam, gdzie modele open weight wypadają gorzej, Opus 4.8 potrafi bardziej myśleć samodzielnie i eksplorować. Umie powiedzieć ci, że się mylisz (rozpoznać fałszywą przesłankę), umie zebrać potrzebny kontekst, zanim zacznie edytować plik (zrozumieć ukryte niezmienniki). Kimi K3 raczej rzuca się od razu do działania — robi dokładnie to, co mu każesz, ale nie myśli za siebie i nie eksploruje tego, co mogłoby pomóc.
Dlatego przy dobrze zdefiniowanych, wąsko zakrojonych zadaniach Kimi K3 poradzi sobie równie dobrze jak Opus 4.8, a czasem lepiej — i to widać w publicznych benchmarkach. Ale przy realnej pracy, gdzie nie mamy pełnej pewności, brakuje właściwych wskazówek albo agent musi eksplorować znacznie więcej kontekstu, wyraźnie lepsze są Opus 4.8 i modele takie jak GPT 5.6 Soul.
Problem nie leży więc w zdolnościach — surowa jakość wyników, zwłaszcza przy ograniczonych zadaniach, bywa u Kimi nawet lepsza niż u Opus. Chodzi o to, że potrzebujemy modelu, który naprawdę myśli za siebie i sam wczytuje potrzebny kontekst, bez prowadzenia go za rękę na każdym kroku. I tu Opus błyszczy.
To wzmacnia myśl, którą powtarzam: mocniejszego modelu używaj do planowania — bo to właśnie na etapie planowania zidentyfikujesz fałszywe przesłanki i niezbędne niezmienniki. Kiedy już je wychwycisz i skorygujesz, implementację oddaj koniowi roboczemu, który sprawnie przepcha solidną realizację. Będę powtarzał ten proces dla nowych modeli, by pomagać wam ustalać, które modele naprawdę się liczą i gdzie pasują w waszym workflow AI.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Nie ufaj publicznym benchmarkom przy wyborze modelu do pracy
Na czym polega: Publiczne rankingi zawyżają możliwości modeli open weight, bo modele bywają „przetrenowane” na typowych pytaniach benchmarkowych, a sama metodyka oceny często nie mierzy jakości kodu.
Jak stosować: Zbuduj mały, własny zestaw testów opartych na twoich realnych zadaniach i zgłoszeniach; przepuszczaj przez niego każdy nowy model, zanim wpuścisz go do produkcji.
Na co uważać: Twój własny benchmark też ma wady — autor sam przyznaje, że pułapki celowo wyostrzają różnice. Nie traktuj pojedynczego wyniku jako werdyktu absolutnego.
2.Kimi K3 dorównuje Opus przy prostych, dobrze opisanych zadaniach
Na czym polega: Przy prostszych zgłoszeniach Kimi K3 uzyskał niemal identyczny wynik jak Opus (różnica w granicach błędu) i był tańszy.
Jak stosować: Do rutynowych, wąsko zakrojonych zadań spokojnie używaj tańszego Kimi K3 — oszczędzisz koszt i limity, nie tracąc jakości.
Na co uważać: „Proste” znaczy naprawdę dobrze zdefiniowane. Im więcej niedopowiedzeń i kontekstu do eksploracji, tym szybciej ta równość znika.
3.Przy złożonych budowach Opus wyraźnie wygrywa
Na czym polega: Na skomplikowanych zadaniach pojawia się realna rozbieżność jakości — Opus radzi sobie lepiej, choć drożej.
Jak stosować: Do trudnych, wielowątkowych zadań, gdzie błąd jest kosztowny, wybieraj mocniejszy model, nawet jeśli zapłacisz więcej tokenów.
Na co uważać: Wyższy koszt Opus częściowo bierze się z większej liczby zużytych tokenów — budżetuj to z góry przy dużych zadaniach.
4.Mieszaj modele: mocny do planowania, tańszy do implementacji
Na czym polega: Optymalny układ to potężny model (Opus, GPT 5.6 Soul) na etap planowania i tańszy koń roboczy (Kimi K3, GLM 5.2) na implementację i walidację.
Jak stosować: Rozbij workflow na osobne sesje/kroki i przypisz różne modele do planowania i wykonania — najlepiej przez harness łączący sesje agentów.
Na co uważać: To działa tylko wtedy, gdy plan naprawdę wyłapie pułapki i niezmienniki. Słaby plan przekazany koniowi roboczemu da słabą implementację.
5.Nie wciskaj całego procesu w jedną sesję agenta
Na czym polega: Autor rozdziela planowanie, implementację i walidację na osobne sesje, bo upchnięcie wszystkiego w jedną daje kiepskie wyniki niezależnie od modelu.
Jak stosować: Zbuduj przepływ, w którym plan zapisywany jest do dokumentu czytanego przez kolejny krok — to porządkuje kontekst i poprawia jakość.
Na co uważać: Więcej kroków to więcej punktów styku i tokenów; upewnij się, że przekazywany dokument planu jest kompletny i jednoznaczny.
6.Uważaj na fałszywą przesłankę i „działa zgodnie z założeniem”
Na czym polega: Gdy prosisz o naprawę nieistniejącego problemu (lub czegoś, co działa poprawnie), agenty — zwłaszcza open weight — wymyślają rozwiązanie i halucynują lokalizację błędu.
Jak stosować: Formułuj zadania jako pytania do zbadania, nie rozkazy („sprawdź, czy X jest problemem”), i pozwól modelowi zakwestionować twoje założenie na etapie planowania.
Na co uważać: Nawet Opus poległ właśnie na fałszywej przesłance — żaden model nie jest tu odporny. Sam weryfikuj, czy problem faktycznie istnieje.
7.Zabezpiecz ukryte niezmienniki i reguły projektu
Na czym polega: Reguły w plikach typu rules.md czy mission.md, wpływające na to, jak edytować dany plik, bywają ignorowane — Kimi K3 nie zawsze rozeznawał kontekst przed edycją.
Jak stosować: Jawnie wskazuj agentowi, by przed edycją zapoznał się z kluczowymi plikami reguł; przy modelach open weight dołączaj te reguły wprost do promptu implementacji.
Na co uważać: Nie zakładaj, że model sam „rozejrzy się po kodzie” jak Opus — koń roboczy zwykle rzuca się od razu do działania.
8.Licz się z context rot przy modelach open weight
Na czym polega: Instrukcje podane wcześniej w rozmowie są z czasem ignorowane; modele open weight jak Kimi K3 dotyka to mocniej.
Jak stosować: Umieszczaj krytyczne ograniczenia blisko właściwego zadania, powtarzaj je i skracaj kontekst; nie licz na to, że reguła sprzed wielu tur nadal działa.
Na co uważać: Im dłuższe zadanie agentowe, tym większe ryzyko — a to właśnie długie zadania są sztandarową zaletą Kimi K3.
9.Modele open weight są bardziej sykofanckie
Na czym polega: Skłonność do popełnienia błędu, byle przypodobać się użytkownikowi, spokrewniona z uleganiem fałszywej przesłance.
Jak stosować: Zachęcaj model do niezgody i kwestionowania twoich założeń; unikaj sugerowania w prompcie z góry, jaka odpowiedź „ci pasuje”.
Na co uważać: Potwierdzenie od modelu nie jest dowodem poprawności — dodatkowo weryfikuj krytyczne decyzje niezależnym krokiem lub testami.
10.Chodzi o niezawodność, nie o surową moc
Na czym polega: Kimi K3 bywa jakościowo lepszy od Opus przy ograniczonych zadaniach; różnica leży w zdolności samodzielnego myślenia i wczytania potrzebnego kontekstu bez prowadzenia za rękę.
Jak stosować: Wybieraj model według charakteru pracy — dobrze zdefiniowana i wąska: tańszy model; niepewna, eksploracyjna, kontekstowo bogata: mocniejszy model.
Na co uważać: Ogólny współczynnik awarii Kimi K3 na pułapkach (36% vs 8% Opus) był celowo wyostrzony — nie przenoś tej liczby wprost na własne zadania, ale traktuj kierunek jako realny.