Kimi K3 w praktyce: doświadczenia użytkowników i porównanie z Claude Code

Jak zakończył się eksperyment autora#

Kimi K3 zadebiutował 16 lipca 2026 roku. Ma 2,8 biliona parametrów, okno kontekstowe o pojemności miliona tokenów, otwarte wagi i pierwsze miejsce w ślepym porównaniu modeli frontendowych. Wszystkie szczegóły dotyczące architektury, testów porównawczych i cen zebrałem w pełnej recenzji Kimi K3 kontra Claude Code, więc nie będę ich tu powtarzać.

Na końcu tamtej recenzji napisałem: ryzyko polega na stracie dnia na konfigurację, a korzyść to niższy rachunek od drugiego tygodnia. Przeprowadziłem eksperyment na własnych zadaniach.

Pierwsze kilka godzin rzeczywiście ekscytuje. Model chętnie podejmuje się zadania, tworzy spójne rozwiązania frontendowe i nie waha się przy dużych plikach. Dlatego napisałem na kanale, że jestem mile zaskoczony. Problemy ujawniły się podczas długich sesji, pracy z wieloma agentami, kolejnych rund edycji i wieczornej pracy w terminalu.

Ostatecznie wróciłem do poprzedniego rozwiązania. Oto co doprowadziło mnie do tej decyzji — z liczbami i odnośnikami do źródeł pierwotnych, aby można było wszystko samodzielnie sprawdzić.

Dlaczego testy porównawcze pokazują, że Kimi K3 wygrywa z Claude’em?#

Oto testy porównawcze, w których Kimi K3 wyprzedza Claude Fable 5:

Serwis llm-stats zebrał wyniki testów; każdy wiersz przedstawia porównanie z Claude Fable 5.

Liczby są prawdziwe. We wszystkich 35 testach ujętych w tym samym zestawieniu Claude Fable 5 wygrywa 22, Kimi K3 dwanaście, a jeden kończy się remisem.

Ciekawsze jest to, w czym Kimi K3 wypada słabiej. Jego strata w testach programistycznych jest niewielka i wynosi 4–5 punktów. Gorzej radzi sobie z wiedzą i rozumowaniem: w HLE Claude uzyskuje przewagę niemal 10 punktów. Właśnie w tych obszarach długie zadanie napotyka przeszkodę: najpierw trzeba zrozumieć, a dopiero potem można pisać.

Moonshot opisuje to w głównej części wpisu o premierze:

Dlaczego w praktyce Kimi K3 wydaje się dwa razy wolniejszy?#

Liczby pochodzą z porównania Kimi K3 z Claude Opus 4.8 — to wersja Claude’a, dla której dysponują pełnym pomiarem szybkości.

Kimi K3 odpowiada wcześniej, więc w krótkiej rozmowie subiektywnie wydaje się szybszy. W pracy czas upływa na czymś innym: czekaniu, aż nadejdzie cała odpowiedź. Pod tym względem model osiąga prawie o połowę niższą szybkość, a przy długiej odpowiedzi różnica narasta do kilku minut.

Kimi Code reklamuje szybkość 180–260 tokenów na sekundę, a ta liczba wygląda przekonująco w porównaniu z moimi 34.7. Dotyczy ona wersji o wysokiej szybkości poprzedniej generacji: K2.7 Code HighSpeed. Kimi K3 w ogóle nie ma takiej wersji, a niezależny test mierzy właśnie Kimi K3.

Sesja, która przerywa pracę po siódmym błędzie i zużywa tokeny na powtarzanych wywołaniach, świadczy o błędzie w inżynierii kontekstu; wybór modelu jest tu kwestią drugorzędną. Cała konfiguracja opiera się na trzech filarach: klon AI + Drugi Mózg + inżynieria kontekstu. To trzy filary, bez których AI halucynuje.

Gdzie trafiają tokeny, skoro nie można wyłączyć rozumowania?#

Można obniżyć poziom wysiłku; dokumentacja wymienia trzy: low, high i maximum. Nie można jednak całkowicie wyłączyć rozumowania: dokumentacja wyraźnie mówi, że w Kimi K3 rozumowanie i przechowywanie jego historii są zawsze włączone. Przy bezpośrednich wywołaniach API domyślny jest najwyższy poziom, a większość programów pośredniczących go nie zmienia.

Każda tura dodaje tysiące tokenów wyjściowych w cenie $15 za milion. Ponadto Moonshot wymaga odesłania całej wiadomości asystenta, łącznie z historią rozumowania, a te tokeny wyjściowe w kolejnej turze stają się tokenami wejściowymi.

Płacisz więc dwa razy za to samo rozumowanie: najpierw gdy model je zapisuje, a potem gdy odsyłasz je do modelu.

W ogólnym indeksie Kimi K3 zużywa o 21% mniej tokenów wyjściowych niż poprzednik, K2.6. W porównaniu z własną poprzednią wersją model stał się oszczędniejszy. Claude nadal zużywa mniej przy tych samych zadaniach.

Prompt „hi” jest rozliczany jako 86 tokenów. W tle znajduje się ukryty prompt systemowy o długości około 85 tokenów, za który płacisz przy każdym żądaniu.

Osobno opisałem, jak obliczać zużycie i gdzie sprawdzać pozostałe saldo: ile tokenów oferują Claude Pro i Max. Zasady obliczeń są tam takie same; zmieniają się tylko ceny.

Co się dzieje, gdy model utknie w rozumowaniu?#

Wygląda to tak: model zaczyna myśleć, ale zamiast rozwijać myśl, tekst wpada w powtarzanie — najpierw tego samego słowa, potem fragmentów sylab, bez końca. Zadanie staje, a licznik tokenów nadal się kręci.

Zgłoszenie z 28 lipca na liście znanych problemów Moonshot opisuje, jak Kimi K3 próbował sześć razy z rzędu odczytać ten sam plik, siedem razy otrzymał odmowę „no-op call, file hasn’t changed since the previous read”, a potem zakończył turę tak, jakby nic się nie stało. Autor w systemie zgłoszeń Kimi CLI wymienia cztery odmiany podobnego zawieszenia — odczytywanie, zastępowanie, testowanie i analizowanie — i podsumowuje je jednym zdaniem:

Moonshot wprost wskazuje przyczynę. Model był trenowany w trybie zachowującym historię rozumowania i musi otrzymywać w całości swoje wcześniejsze rozumowanie. Jeśli historia dotrze niekompletna, model próbuje odtworzyć odpowiedź, generuje to samo wywołanie narzędzia i rozpoczyna kolejną pętlę.

Autor analizy w zewnętrznym routerze żądań podaje tę samą diagnozę: Kimi jest na tyle rygorystyczny, że odrzuca żądania z niekompletną historią rozumowania. Zewnętrzny program pośredniczący nie wie o tej rygorystyczności i skraca historię.

Dlaczego konfiguracja wieloagentowa rozpada się przy Kimi K3?#

Oficjalna dokumentacja Moonshot mówi to wprost: ich API nie obsługuje jeszcze WebFetch. Innymi słowy, Claude Code, który zwykle łączy się z internetem, by pobrać stronę, nie może tego zrobić w Kimi K3. Obejściem problemu jest ręczne wklejenie treści albo podłączenie narzędzia innej firmy.

Claude Code może ładować narzędzia na żądanie i umieszcza w historii blok usługi typu tool_reference. Kimi nie akceptuje tego typu i zwraca błąd 400. Robi to bez żadnego wyjaśnienia, nie podając ani nazwy pola, ani przyczyny:

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

Dla porównania, tak wygląda ten sam błąd w natywnym API Anthropic, gdzie serwer przynajmniej podaje nazwę pola i akceptowane typy:

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

Ta różnica ma znaczenie. Pierwszej wiadomości nie da się zdiagnozować: ani klient, ani osoba za nim nie potrafią ustalić, który blok został odrzucony. Właśnie na to skarżą się autorzy zgłoszeń. Twórcy narzędzi do przełączania dostawców już sugerują, by domyślnie wyłączać opóźnione ładowanie narzędzi dla Kimi albo oznaczyć API Moonshot jako nieobsługujące tych bloków.

Konsekwencje opisuje osobne zgłoszenie, otwarte 17 lipca i wciąż bez odpowiedzi. Autor napotkał ten błąd siedem razy podczas jednej sesji. Sesja przetrwała pierwsze sześć wystąpień, a siódme zakończyło ją na dobre: później nawet wpisanie zwykłego tekstu „continue” powodowało awarię. Autor osobno zaznacza, że wcale nie zbliżył się do limitu kontekstu, więc wyjaśnienie „historia była za długa” nie pasuje.

Oto podsumowanie typów bloków akceptowanych i odrzucanych przez API Moonshot:

Słowo „zgodny” opisuje tu wyłącznie format żądania. Cała reszta jest inna: akceptowane typy bloków, wymagana zawartość historii oraz dostępne narzędzia.

Czego nie da się przenieść do Kimi K3?#

Sekcja dotycząca ograniczeń w poście o premierze mówi dosłownie:

Deweloper modelu mówi: używajcie naszego klienta; nie gwarantujemy, jak będzie działać cudzy.

Drugi punkt w tej samej sekcji wyjaśnia jeszcze jedną rzecz, którą przypisywałem uporowi modelu:

Mój plik CLAUDE.md został napisany z myślą o odwrotnym zachowaniu: zapytaj, przedstaw plan i poczekaj na potwierdzenie. Instrukcje nadal tam są, ale czyta je teraz model o innym temperamencie.

Jeśli chcesz korzystać z jednego pliku reguł dla kilku agentów, omówiłem tę konfigurację osobno: jeden plik instrukcji dla Claude Code, Codex i Cursor.

Ile naprawdę kosztuje Kimi K3?#

Na początek ceny, które przemawiają na korzyść Kimi K3:

Ceny Kimi pochodzą z dokumentacji buforowania kontekstu; prawa kolumna przedstawia ceny Claude Opus 5 z 30 lipca 2026 roku.

Cache Kimi jest automatyczny, nie można go wyłączyć, a jego identyfikację umożliwia hash na początku żądania. Każda edycja promptu systemowego lub listy narzędzi całkowicie czyści cache wiadomości.

Oto co Claude Code robi podczas zwykłego dnia pracy:

1. Łączy i rozłącza zewnętrzne narzędzia w miarę postępów zadania.
2. Ładuje narzędzia na żądanie, kiedy są potrzebne.
3. Uruchamia podagentów z innym zestawem narzędzi.
4. Dodaje plik z instrukcjami do promptu systemowego.
5. Odbudowuje historię podczas kompresji kontekstu.

Każdy punkt tej listy resetuje początek żądania, a tym samym cache. Tokeny wejściowe znów kosztują $3 za milion zamiast 30 centów — dziesięć razy więcej. Do tego dochodzi ciągłe rozumowanie w cenie $15 za milion tokenów wyjściowych, a te same tokeny wracają jako wejściowe w następnej turze. W ten sposób model o niskiej cenie katalogowej może wygenerować niespodziewany rachunek.

Według zagregowanych danych OpenCode, w niemal 280,000 aktywnych sesjach średni koszt sesji Kimi K3 wynosi $1.86, przy średnim wolumenie 3.1 miliona tokenów. Ta liczba zakłada, że 93% tokenów wejściowych trafia do cache. Zmień początek żądania, a przestanie dotyczyć ciebie.

Plany Kimi kosztują $19, $39, $99 i $199. Limit pochodzi ze wspólnej puli dla całego członkostwa, resetuje się co tydzień bez przenoszenia niewykorzystanej części i korzysta z przesuwającego się okna pięciogodzinnego. W recenzji planów napisano, że cztery terminale uruchamiające Kimi K3 ze stale włączonym rozumowaniem szybko zużywają limit pięciogodzinny.

Limit programistyczny w planie za $99 jest porównywalny z planem Anthropic za $200, co jest sprzeczne z moim stanowiskiem. Kimi jest tańszy za token, ale wieczorny rachunek tego już nie pokazuje.

W czym Kimi K3 obiektywnie jest dobry?#

1. Frontend. Pierwsze miejsce w ślepym porównaniu przeprowadzonym przez aktywnych programistów. Tworzy schludne układy i ma całkiem niezłe wyczucie.
2. Skala. Okno kontekstowe o pojemności miliona tokenów, a długie pliki go nie przytłaczają. Analizowanie dużego repozytorium i mapowanie jego struktury to zadania w sam raz dla niego.
3. Pierwsza odpowiedź. Czas do pierwszego tokena jest o połowę krótszy niż w Claude. W krótkiej rozmowie różnica jest zauważalna i przyjemna.
4. Cena za token. Około 60% ceny Claude Opus 5. Jeśli początek żądania się nie zmienia, zapewnia realne oszczędności przy dużych, powtarzalnych obciążeniach.
5. Otwarte wagi. Model nie jest przypisany do jednego dostawcy.

Ostatnia zaleta ma pewne zastrzeżenie. Uruchamianie takiego modelu w domu jest nierealne: nawet po kompresji jego wagi zajmują terabajty. Otwartość oznacza tu niezależność od pojedynczego dostawcy.

Jak samodzielnie przetestować to wszystko w jeden wieczór#

1. Skonfiguruj dostęp zgodnie z instrukcjami. Trzy zmienne środowiskowe i zamiany modeli w zależności od poziomu opisałem w recenzji Kimi K3 kontra Claude Code. Sprawdź konfigurację poleceniem /status: Kimi nie pojawi się w menu wyboru modelu, bo zawiera ono wbudowaną listę aliasów, której nie musisz zmieniać.
2. Usuń stary klucz. Jeśli wcześniej ustawiono ANTHROPIC_API_KEY, usuń go. W połączeniu z ANTHROPIC_AUTH_TOKEN powoduje konflikt i bez powodu otrzymasz błąd autoryzacji.
3. Od razu wyłącz opóźnione ładowanie narzędzi. Zrób to przed pierwszym uruchomieniem, a nie po awarii pierwszej sesji.
4. Nie zmieniaj modeli w trakcie zadania. Jeśli rozpocząłeś pracę na Kimi K3, dokończ ją na Kimi K3. To samo dotyczy sytuacji odwrotnej. To bezpośrednie wymaganie Moonshot, które zacytowałem wyżej.
5. Użyj prawdziwego zadania ze swojej pracy. Takiego, nad którym pracowałeś wczoraj, z całym bałaganem i niedokończonymi wątkami. Gra w węża nie pokaże różnicy: ujawnia się ona dopiero podczas dłuższej pracy.
6. Zapisz dwie liczby. Ile minut to zajęło i ile pieniędzy wydałeś tego wieczoru. Porównaj je ze zwykłym wieczorem pracy z Claude’em.
7. Osobno śledź czas bezczynności. Gdy agent się zawiesza, zapętla się przy odczytywaniu tego samego pliku albo zwraca błąd — to również część kosztu.

Jeśli wieczorny rachunek okaże się wyższy od oczekiwanego, niemal zawsze winny jest cache: policz, ile razy tego wieczoru resetował się początek żądania. Cena za token ma niewielkie znaczenie.

Co ostatecznie zostawiłem#

Czytelnicy kanału, którzy testowali model razem ze mną, niezależnie doszli do tej samej konfiguracji: zlecają Kimi K3 inspekcję repozytorium i przygotowanie drugiej opinii, a główną pracę zostawiają agentowi, którego już znają. Ta konfiguracja się sprawdza, bo nie wymaga przenoszenia programu pośredniczącego ani psucia tego, co już działa.

Można to ująć tak: jedno kompletne zadanie trafia do Kimi K3, a długi łańcuch obejmujący narzędzia i podagentów — do Claude Code. Im więcej przełączeń między narzędziami wymaga zadanie, tym wyższy jest koszt Kimi K3 i tym większe ryzyko awarii sesji.

Osobno opisałem, jak przydzielić role dwóm agentom, żeby ich ze sobą nie pomylić: trzy sposoby pracy z dwoma agentami.

Testy porównawcze odpowiadają na pytanie: „kto jest mocniejszy w warunkach laboratoryjnych?”. Rachunek za wieczór i lista ukończonych zadań odpowiadają na pytanie: „kto jest mocniejszy w twoim przypadku?”. Jeśli odpowiedzi są różne, zaufaj tej drugiej: sam ją obliczyłeś, a nie dział marketingu.

Po przeanalizowaniu wszystkiego wyciągnąłem własny wniosek: cokolwiek ludzie mówią o nowych modelach, lider pozostaje liderem. Claude Code nadal jest moim głównym silnikiem.

Pełna konfiguracja vibe codingu: klon AI + Drugi Mózg + inżynieria kontekstu.