O czym jest ten film
- Premiera Kimi K3.1 Pro — chińskiego modelu, którego cennik wyraźnie podgryza zachodnią czołówkę („frontier”), przy ułamku ich stawek.
- Benchmarki: 65,7 pkt w Terminal Bench 4.0 (GPT6 Asteris: 58,2), najlepszy wynik wśród modeli frontier w teście 20 wielogodzinnych zadań programistycznych bez internetu (51,7 pkt — blisko pięć punktów przewagi nad Opusem 5.5).
- Kimi Codebench 3.0 „long horizon”: 61,2 vs 58,5 dla Opusa; Humanity’s Last Exam: 70 vs 67,7 — najwyżej ze wszystkich znanych modeli frontier.
- Metodologia porównania: identyczne prompty, ten sam zestaw narzędzi, każdy model pracował we własnym środowisku kodowania na maksymalnym poziomie wysiłku (Kimi Code vs Claude Code).
- Średni czas budowy ośmiu zadań: Kimi 29 min 41 s, Opus 47 min 2 s — różnica blisko 40%.
- Praktyczne dema: symulator klawiatury mechanicznej 3D, zderzenie galaktyk, strona o sprzęcie nurkowym sterowana scrollem, wyburzanie wieżowca, klon Minecrafta i gra o zabijaniu tytanów.
- Opus 5.5 dwa razy na osiem zadań dostarczył w ogóle niedziałający produkt — najpewniej nie zweryfikował efektu końcowego, mimo pracy w trybie maksymalnym.
- Prezentacja interfejsu kimi.ai i funkcji Swarm: jednym poleceniem zadanie można zlecić setkom agentów naraz.
- Werdykt: Kimi ustępuje Opusowi jakością pojedynczych realizacji, ale pracuje spójniej i kosztuje połowę jego ceny (2 dol. za milion tokenów wejściowych, 10 dol. za milion wyjściowych).
10 najważniejszych takeaways — z kontekstem zastosowania
1.Benchmarki traktuj jako wstępną selekcję, nie werdykt
Na czym polega: Kimi K3.1 Pro plasuje się w czołówce niemal wszystkich kluczowych testów (m.in. najwyższy wynik na Humanity’s Last Exam wśród modeli frontier), a mimo to w praktyce regularnie ustępuje Opusowi jakością detali — i odwrotnie: topowy Opus potrafił dostarczyć całkiem niesprawny produkt.
Jak stosować: Listę kandydatów wyznaczaj po benchmarkach, ale decyzję podejmuj dopiero po dwóch–trzech własnych próbach na typowych zadaniach (strona produktowa, skrypt, automatyzacja), porównanych widentycznie: ten sam prompt, te same narzędzia.
Na co uważać: Wysoki wynik w teście nie mówi nic o tym, czy model sprawdzi swoje dzieło przed oddaniem — to trzeba wymusić promptami albo samemu.
2.Czas wykonania bywa równie ważny jak jakość
Na czym polega: W ośmiu zadaniach Kimi budował średnio 29 min 41 s, Opus 5.5 — 47 min 2 s. To różnica blisko 40% przy porównywalnym (a bywało, że niższym) poziomie wykonania.
Jak stosować: Przy pracy seryjnej — wielu iteracjach, wariantach dla klienta, zadaniach nocnych — licz nie tylko cenę tokenów, ale całkowity czas oczekiwania na wynik; często to on decyduje o realnej wydajności.
Na co uważać: Szybciej nie znaczy lepiej. W kilku demach Opus oferował wyraźnie wyższą jakość wizualną, więc czas oszczędzaj świadomie, tam gdzie dopracowanie ma mniejsze znaczenie.
3.Policz, ile płacisz za ostatnie kilka procent jakości
Na czym polega: Kimi kosztuje 2 dol. za milion tokenów wejściowych i 10 dol. za milion wyjściowych — Opus 5.5 dwa razy tyle. W testach różnice sprowadzały się często do detali: kolor tła symulacji, nieco bardziej realistyczna geometria klawiszy.
Jak stosować: Zadania masowe i rutynowe (wiele wariantów stron, szkice, prototypy) przenoś na tańszy model, a droższy zostaw tam, gdzie szczytowa jakość realnie przekłada się na pieniądze.
Na co uważać: Im wyższa półka, tym drożej kosztuje każdy dodatkowy procent jakości — ale przy trudnych zadaniach ten procent potrafi zdecydować o powodzeniu projektu.
4.Model nie sprawdzi własnej pracy sam z siebie
Na czym polega: Opus 5.5 dwa razy na osiem dem oddał niedziałający efekt (strona, która się nie ładuje; gra, w której postać nie może się ruszyć), choć pracował na maksymalnym poziomie wysiłku. Autor przypuszcza, że po prostu nie „przeczytał” własnego dzieła na koniec.
Jak stosować: Do każdego dłuższego zlecenia wstawiaj jawny krok końcowy: „przed oddaniem uruchom efekt, przetestuj i napraw błędy”. Przy zadaniach autonomicznych ustawiaj punkty kontrolne zamiast czekać na koniec.
Na co uważać: Im droższy model i wyższy tryb, tym większa pokusa odpuścić sprawdzanie — a właśnie wtedy niewykryty błąd kosztuje najwięcej.
5.Długie, autonomiczne zadania to mocna strona Kimi
Na czym polega: W testach długodystansowych — 20 wielogodzinnych zadań inżynierskich bez dostępu do internetu oraz Kimi Codebench 3.0 „long horizon” — Kimi wyprzedza wszystkie modele frontier, w tym Opusa o trzy–pięć punktów.
Jak stosować: Spróbuj zlecać Kimi zadania „na noc”: większe refaktoryzacje, migracje, generowanie wielu spójnych artefaktów — tam gdzie liczy się wytrzymałość, nie błyskotliwość.
Na co uważać: Te testy biegną bez internetu, więc mierzą trzymanie kontekstu, a nie pracę na świeżych danych — przy zadaniach wymagających aktualnych informacji wyniki mogą wyglądać zupełnie inaczej.
6.Efekt „wow” potrafi maskować słabą wydajność
Na czym polega: Wersja strony od Opusa — z pływającym rekinem i efektami 3D — była wyraźnie przyjemniejsza w przewijaniu, ale też wyraźnie wolniejsza: wygląda na to, że zasoby nie zostały zoptymalizowane.
Jak stosować: Oceniaj wygenerowane strony na słabszym sprzęcie i wolnym łączu; w promptach określaj ograniczenia wprost (jak autor: „wyłącznie SVG i HTML, zero zewnętrznych zasobów”).
Na co uważać: Animacje i cienie potrafią zjeść płynność — użytkownik odejdzie z powodu przycięć szybciej niż z powodu braku rekina.
7.Interakcje testuj osobno, bo wygląd niczego nie gwarantuje
Na czym polega: Gra od Kimi wyglądała dobrze, ale osie sterowania były pomylone („góra” przesuwała postać w dół), przez co była w praktyce niegrywalna. Wersja od Opusa była i piękna, i w pełni grywalna.
Jak stosować: Po każdej generacji przejdź krótką checklistę podstawowych interakcji: ruch, klik, scroll, zachowanie po zmianie ustawień — dopiero potem oceniaj oprawę graficzną.
Na co uważać: Model potrafi poprawnie opisać działanie, którego nigdy nie uruchomił — nie ufaj opisowi, tylko próbie.
8.Roje agentów do zadań seryjnych
Na czym polega: Funkcja Swarm w Kimi pozwala jednym poleceniem zlecić pracę setkom agentów; autor kazał wygenerować dziesięć niezależnych stron produktowych dla fikcyjnych marek, a agent sam dopytał o szczegóły (zróżnicowana oferta, odrębne style, katalog) i ruszył z produkcją.
Jak stosować: Używaj roju wszędzie tam, gdzie potrzebujesz wariantów do porównania — strony, opisy, kampanie — zamiast iterować kolejne wersje z jednym agentem.
Na co uważać: Setki agentów szybko zjadają limity; zaczynaj od małej liczby wariantów i pilnuj abonamentu.
9.Krótsze „myślenie” to niższy rachunek i szybsza odpowiedź
Na czym polega: Ślady rozumowania Kimi są wyraźnie krótsze niż u modeli Claude czy OpenAI. Chińscy dostawcy tną tokeny podczas rozumowania (pomijają podmioty, dopełnienia), bo konkurują z zachodnimi modelami dysponującymi znacznie większą mocą obliczeniową.
Jak stosować: Przy dużych wolumenach mierz realne zużycie tokenów „myślenia” — krótszy ślad często obniża rachunek i skraca oczekiwanie, bez zauważalnej straty jakości.
Na co uważać: Skrócone rozumowanie może gubić niuanse w wieloetapowych problemach — koniecznie przetestuj je na swoich najtrudniejszych przypadkach.
10.Przetestuj model na abonamencie, zanim ruszysz na API
Na czym polega: Autor prowadził całe porównanie na planach abonamentowych, nie na API, i odnotowuje, że Kimi ma bardzo hojne limity w ramach planu.
Jak stosować: Zanim zwiążesz projekt produkcyjny z konkretnym API, „przepal” abonament na własnych zadaniach i policz, ile realnie mieści się w limicie — to najtańszy możliwy due diligence.
Na co uważać: Warunki planów bywają zmienne i rzadko odpowiadają kosztom API przy dużej skali; wynik z abonamentu traktuj jako orientacyjny.
Redakcyjne tłumaczenie
Start: premiera i plan testu
Kimi K3.1 Pro właśnie weszło na rynek. (Informacja dodatkowa: Kimi to model chińskiego laboratorium Moonshot AI.) Ma dopracowaną stronę startową i cennik, który mocno podgryza zachodnie modele z absolutnej czołówki, tzw. frontier. W tym materiale przeprowadzam Kimi K3.1 Pro przez pełny test: zestawiam go od deski do deski z modelem frontier — Opusem 5.5 — a potem pokazuję, jak narzędzie tego typu może realnie poprawić wasze życie i biznes. Po drodze zobaczycie prawdziwe dema: projektowanie, UX, gry, zastosowania biznesowe — w zasadzie wszystko, czego potrzeba, żeby samodzielnie podjąć decyzję.
Zaczynamy od benchmarków, ale od razu zaznaczam: w przypadku współczesnych modeli to tylko mały fragment układanki. Z suchych liczb da się wyciągnąć ograniczone wnioski, więc przejdę po nich szybko, a właściwy ciężar przeniosę na testy funkcjonalne.
Benchmarki: liczby na start
Ze strony Kimi widać, że w całej serii testów model plasuje się na poziomie zachodniej czołówki:
- Terminal Bench 4.0 — Kimi K3.1 Pro zdobywa 65,7 pkt wobec 58,2 pkt dla GPT6 Asteris. To wynik niemal równy Opusowi 5.5 i, szczerze mówiąc, jeden z najważniejszych benchmarków współczesnego programowania z pomocą AI.
- Zadania długodystansowe — Kimi osiąga najlepszy wynik ze wszystkich obecnych modeli frontier: 51,7 pkt, czyli niemal pięć punktów przewagi nad Opusem 5.5. Dla niewtajemniczonych: ten test to 20 wielogodzinnych zadań inżynierskich wykonywanych bez dostępu do internetu.
- Kimi Codebench 3.0, wariant „long horizon” — 61,2 pkt wobec 58,5 dla Opusa 5.5. Ta sama idea: długie, samodzielne zadania agentowe.
- Humanity’s Last Exam — 70 pkt wobec 67,7 dla Opusa 5.5: najwyższy wynik wśród znanych modeli frontier. (Informacja dodatkowa: Humanity’s Last Exam uchodzi za jeden z najtrudniejszych egzaminów ogólnej wiedzy dla modeli, tworzony przez ekspertów z wielu dziedzin.)
To tyle, jeśli chodzi o liczby. Czas na praktykę.
Zasady porównania i czas budowy
Przygotowałem stronę zbierającą dema wygenerowane przez oba modele: Kimi K3.1 i Opusa 5.5. Zasady były proste — dokładnie ten sam prompt, dokładnie ten sam zestaw narzędzi, a każde z nich pracowało we własnym środowisku kodowania, ustawionym na maksymalny poziom wysiłku: Kimi w Kimi Code, Claude w Claude Code. (Informacja dodatkowa: „harness”, czyli środowisko kodowania, to narzędzie w rodzaju Claude Code — agent w terminalu, który sam pisze, uruchamia i poprawia kod.) Żadnego efektu nie oceniłem z góry; oba zadania liczyły się w tle, dopóki się nie skończyły.
Pierwsza twarda liczba: średni czas budowy. Kimi K3.1 Pro — 29 minut 41 sekund. Opus 5.5 — 47 minut i 2 sekundy. Już na starcie widać wyraźną rozbieżność. Oczywiście czas to nie to samo co jakość, więc bierzemy na oględziny.
Demo 1. Symulator klawiatury mechanicznej
Pierwszy test to replika symulacji klawiatury mechanicznej — projektu znanego jako Loom. To, co widzicie, to trójwymiarowa wizualizacja w całości zbudowana przez Kimi K3.1. Działa próbnik kolorów: od naturalnego grafitu, przez piaskowy, po odcień wydm na klawiszach. Ciemniejszy wariant „nokturn” wygląda naprawdę efektownie. Można też przełączyć klawisze na głośne, „klikane”. A najfajniejsze — czego w ogóle się nie spodziewałem — na tej klawiaturze da się pisać. Nie włączam dźwięku, żeby nie zepsuć nagrania, ale klawisze reagują. Jest też widok rozłożenia klawiatury na części — bardzo dopracowany, wyraźnie bardziej zaawansowany, niż początkowo zakładałem. Na końcu całość trafia do koszyka.
Przechodzę do Opusa 5.5 — i nie żartuję: strona się nie ładuje. Model, który pracował o połowę dłużej, w jakiś sposób zepsuł zbudowanie projektu i nawet nie sprawdził, czy działa. Wysyłam mu szybką wiadomość z prośbą o naprawę. Krótko mówiąc: na tym etapie Kimi kładzie Opusa na łopatki.
Po naprawie wygląda to tak. Wersja od Opusa 5.5 ma wyższą wierność wizualną: klawisze w lepszej rozdzielczości, podkładka lepszej jakości. Zmiana kolorów działa praktycznie identycznie, jest parę dodatkowych odcieni, ale to drobiazg. Gdy piszemy, odpalają się ładne animacje; przełączniki występują w kilku wariantach (różnią się dźwiękiem); można też podmienić podkładkę pod klawiaturę.
Stawiam obie wersje obok siebie i oddalam kamerę. Różnica? Mniejsza, niż można by sądzić. Wersja Opusa wygląda odrobinę bardziej realistycznie, geometria klawiszy jest nieco bardziej wyrafinowana — ale uwzględniając, że Kimi K3.1 Pro kosztuje ułamek jego ceny, wynik jest więcej niż przyzwoity.
Demo 2. Zderzenie galaktyk
Kolejny test: symulacja zderzenia dwóch galaktyk. Licznik pokazuje upływające miliony lat, a w środku pełnoskalowa symulacja na ponad 200 tysięcy gwiazd — brzeg jednej galaktyki zostaje wessany przez czarną dziurę drugiej. Wychodzą z tego spektakularne fontanny materii. Odtwarzamy w prędkości 1x: galaktyki wyraźnie się deformują, ich jądra zbliżają się do siebie. Prawdziwego zderzenia galaktyk nigdy nie oglądałem, ale zakładam, że wyglądałoby mniej więcej tak.
Wersja od Opusa 5.5 jest pod względem urody w innym ligowym wymiarze: galaktyki od Kimi sprawiały wrażenie trochę kreskówkowych, tu zaś mamy klimat prawdziwego kosmosu. Moim zdaniem to jednak raczej kwestia gustu niż jakości wykonania — nie liczyłem cząstek w żadnym z projektów. Funkcjonalność jest praktycznie identyczna, więc po prostu oglądamy, jak galaktyki robią swoje — po co w końcu oglądacie takie nagrania? Po oddaleniu kamery widać ciekawą nadstrukturę, wszystko da się przyspieszyć i zwolnić. Krótko mówiąc: nie ma powodu sądzić, że Kimi poradził sobie źle. Realnie różni się głównie kolor tła.
Demo 3. Strona nurkowa sterowana scrollem
Trzeci test: strona sterowana scrollem, rzekomo sprzęt do nurkowania głębinowego marki „Abyssal”. Nie pali oczami, ale kluczowe jest zastrzeżenie: zabroniłem korzystania z zewnętrznych zasobów. Nie wolno było podrobić efektu w generatorze obrazów — całość musiała być w stu procentach generowanym SVG i HTML-em. I dokładnie tak jest: przewijamy przez całą stronę zbudowaną wyłącznie z SVG i HTML.
Opus 5.5 poszedł o krok dalej: po stronie pływa żywy rekin, a całość napędza efekt 3D. Jest jednak haczyk, którego nie widać na nagraniu — strona wyraźnie się tnie. Najwyraźniej zasoby nie zostały zoptymalizowane. Z drugiej strony przewijanie wersji Opusa jest po prostu przyjemniejsze niż u Kimi K3.1 Pro.
Demo 4. Wyburzenie wieżowca
Czwarta pozycja: wyburzanie wieży — oto „Kestrel Tower”. Można się przybliżyć: sam budynek jest zaprojektowany poprawnie, choć okolica wygląda dość surowo — miasto jest jakby gołe. Odpalamy symulację: naciskamy spacery… to jest spację i ładunki burzą konstrukcję od dołu do góry, a szkło sypie się na ziemię. To prawdziwa symulacja fizyczna, która zajęła sporo mocy obliczeniowej — a na koniec dostajemy nawet powtórkę zniszczenia, jak w transmisji sportowej.
W wersji Opusa 5.5 budynek stoi w pełnoprawnym mieście — czego Kimi 3.1 nie zrobiło. Odpalamy zniszczenie. Warto odnotować, że Opus wygenerował irytujące dźwięki, których u Kimi nie było — i to był plus Kimi. Animacja jest zdecydowanie wyższej jakości, choć słupy dymu wydają mi się lekko śmieszne.
Demo 5. Minecraft
Obowiązkowy punkt programu: Minecraft od Kimi. Zrobiony pięknie — szczerze, nie mam właściwie uwag. Zdumiewające, z jaką łatwością te modele budują dziś gry tego typu. Cieniowanie bardzo wysokiej klasy; gaszę światło — nocny skok do wody wygląda mrocznie i klimatycznie. Wskaźnika tlenu co prawda nie ma, ale obraz pod wodą zaczyna się rozmywać — robi to naprawdę dobre wrażenie. Można sprintować, a kamera ma poręczną funkcję automatycznego oddalenia.
Porównuję z „Beyond the Veil” od Opusa 5.5 — i niestety: nie mogę się ruszyć. Serio, postać nie jest w stanie zrobić kroku do przodu. Mimo że wizualnie jest przepięknie — „złota godzina” wygląda znakomicie — z gry nie da się korzystać. To już druga wpadka Opusa na tej liście ośmiu dem. Domyślam się, że po prostu nie sprawdził swojej pracy na koniec — co tym bardziej rozczarowuje, bo działał w trybie maksymalnym.
Demo 6. Zabijanie tytanów
Skoro mowa o Minecraftach, nie obędzie się bez zabijania tytanów. Kimi K3.1 odtworzyło grę, którą jakiś czas temu sam zrobiłem. Sterowanie jest, delikatnie mówiąc, tragiczne: w rozsądny sposób się w to nie zagra, bo naciśnięcie „góry” przesuwa postać w dół — za to lewo i prawo działają tak, jak powinny. Gra się więc myli.
Wersja od Opusa 5.5 jest o klasę lepsza — i szczerze: bardzo zabawna i bardzo ładna. Mam wrażenie, że nawet ja nie zrobiłbym tego lepiej; gra, którą pierwotnie stworzyłem i która zdobyła sporą popularność, przy tej wersji po prostu blednie. Cienie znakomite — model mógł realnie wykorzystać fragmenty wcześniejszego projektu Minecrafta. Ogółem: solidnie. Dziesięć na dziesięć, zagrałbym jeszcze raz.
Środowisko kimi.ai: interfejs i roje agentów
Podobnie jak Claude Code czy Codex, Kimi ma własne środowisko kodowania na kimi.ai — pokażę, jak wygląda w praktyce. Na starcie ikonka przypominająca konsolę PlayStation z uroczym ludzikiem Kimi: klik prowadzi na stronę modelu Kimi K3.1 Pro. Poniżej pole „zadaj pytanie albo powierz zadanie agentowi” — komunikacja jak z każdym poważnym modelem do kodu.
Ciekawostka: interfejs wita animowaną postacią — kulką z mrugającymi oczami. Trochę w duchu innych produktów; wszystkie agenty z czołówki zmierzają w stronę wyglądu maksymalnie przyjaznego i nieprzytłaczającego — zważywszy na ich realne możliwości, jest w tym sporo strategii.
Po kliknięciu w zakładkę „myślenie zakończone” zobaczycie ślad rozumowania. Dla zwykłego „cześć” sprowadza się on do czegoś w rodzaju: „pytanie proste, narzędzia zbędne, użytkownik pisze po angielsku — odpowiedzieć krótko i ciepło”. Różnica względem modeli Claude czy OpenAI rzuca się w oczy: Kimi pisze znacznie krócej. Powód jest ciekawy — chińskie modele są po prostu bardziej oszczędne algorytmicznie podczas rozumowania. Muszą konkurować ze znacznie większymi zachodnimi modelami, dysponującymi dużo większą mocą obliczeniową i liczbą parametrów, więc szukają sposobów na cięcie tokenów podczas myślenia. W praktyce pomijają podmioty, dopełnienia i inne elementy zdania. Dla kogoś, kto kiedyś pasjonował się lingwistyką, to fascynujące zjawisko.
Pod spodem jest panel funkcji: dodawanie plików i obrazów, wtyczki, umiejętności, a także Swarm — funkcja charakterystyczna dla Kimi. Jednym kliknięciem można zlecić zadanie setkom agentów, które ruszają zbierać informacje. Wpisuję: „przygotuj dziesięć niezależnych stron produktowych dla fikcyjnych produktów”. Zamiast rozmawiać z jednym agentem, deleguję całość do roju — działa to natywnie, bez żadnej konfiguracji; Kimi samo tworzy potrzebną liczbę agentów. Uwaga: w tej chwili używam wariantu Kimi K3.1 Pro High, a poziom wysiłku — dokładnie jak w Claude czy Codex — można dowolnie zmieniać.
W trakcie pracy agent zadał mi pytanie przez poręczny panel: odpowiadam, że chcę zróżnicowany zestaw produktów, każdy w odrębnym stylu, z katalogiem — i rusza produkcja.
Werdykt: cena, jakość, spójność
Ogółem: modele są naprawdę solidne. Kimi K3.1 Pro nie jest w wielu zadaniach tak dobre jak Opus 5.5, ale za to pracowało bardziej spójnie — mniej zdolne, lecz stabilniejsze. Do tego 2 dolary za milion tokenów wejściowych i 10 za milion wyjściowych. Opus 5.5 kosztuje dwa razy tyle. I to jest właściwe pytanie: czy jest dwa razy lepszy? Im wyższa półka jakości, tym więcej znaczy nawet niewielki procent poprawy w efekcie końcowym — ale wszystko wskazuje na to, że Kimi K3.1 Pro udowodniło swoją pozycję poważnego gracza i realnie nadaje się do pracy z wiedzą: od kodu po analizy.
Ważne zastrzeżenie: całe porównanie prowadziłem na abonamentach, nie na API. Kimi ma przy tym bardzo hojne limity w ramach planu.
To tyle w tym materiale. Dziękuję za obejrzenie — do zobaczenia w następnym, i nie zapomnijcie zasubskrybować kanał.