⚡ Szybki werdykt
Moonshot/Kimi wypuszcza Kimi K3-256K: ta sama zdolność co pełny K3, wyrzucone wejście wideo, okno kontekstu ścięte do 256K. Na pierwszy rzut oka „wersja okrojona". Po przeliczeniu rachunku w społeczności deweloperów werdykt jest jednak zadziwiająco zgodny — to pragmatyczna kontrola kosztów, bo to właśnie długi kontekst jest największym pożeraczem budżetu w coding.
W coding największa pozycja na rachunku to nie input i output — to kontekst. Skok z 50K do miliona tokenów podbija średnie zużycie o cały rząd wielkości i, o ile cache nie jest ekstremalnie tani, długie okno działa jak skrytobójca na tokeny. Kimi wciska ten najdroższy przełącznik w pozycję OFF już na poziomie konfiguracji modelu — za Ciebie.
💸 Dlaczego długi kontekst tyle kosztuje
Fakt, który weryfikuje się w kółko: w coding, dopóki cena cache nie spadnie, główną pozycją kosztu całej sesji jest część tokenowa zajęta przez kontekst. Im szersze okno, tym w każdej rundzie przepychasz coraz większą górę tokenów.
Tylko że to zdanie ma warunek — długi kontekst jest „tylko umiarkowanie drogi" wtedy, gdy trafienia w cache są wystarczająco tanie. Na rynku są dokładnie dwie firmy, które zepchnęły cenę cache w dół: DeepSeek i MiMo. Tylko u nich milionowe okno jest „do udźwignięcia". U reszty cennik za długi kontekst jest po prostu absurdalny, więc racjonalnym wyborem zawsze pozostaje krótkie okno.
Prosta arytmetyka: sesja z limitem 1M to średnio jakieś 500K. Porównaj z 50K — różnica w koszcie to pełne 10x.
Kto zaciska zęby przy 100K i sam zbiera okno, trzyma średnią na 50K. Kto zasypia i czeka, aż harness sam skompresuje przy 990K, ma średnią 500K. Ten sam „model z długim kontekstem", a różnica w koszcie — 10x. Nawet w oknie 256K, jak pójdziesz jedną rozmową do 200K, płacisz 4x więcej niż przy bazie 50K.
To wszystko przestaje boleć tylko wtedy, gdy trafienia w cache są tanie. Niestety u zdecydowanej większości modeli cena cache jest równie wysoka, więc główna pozycja na rachunku i tak zostaje przy kontekście, a długie okno z definicji pcha koszty w górę. Świadome ograniczenie okna pozwala harnessowi (warstwie agenta) automatycznie pilnować rozmiaru — i rachunek leci mocno w dół.
🧠 Większość nie ma pojęcia o „zarządzaniu kontekstem"
Głębszy problem leży w nawykach. Spora część użytkowników nie ma w ogóle odruchu świadomego zarządzania kontekstem — całkowicie polegają na automatycznej kompresji w harnessie, do tego biorą najdroższy model i ciągną jedno okno do 1M, dopóki samo nie skompresuje.
Przy takim scenariuszu „kilka rund i limit leży" jest wynikiem niemal pewnym. To narzekanie z grupy Feishu Kims — że „mało używasz, kilka rund i przepali" — prawie na pewno bierze się stąd dokładnie. Oficjalne ogłoszenie w tej grupie mówi otwarcie: „90% scenariuszy nie przekracza 256K". Odwróć to — aż 10% urwisów pali długim kontekstem K3.
I jeszcze jeden smaczek: w dokach K3 jest napisane wprost „przed przejściem na K3 zacznij nową sesję". Sensowna wskazówka, tylko sporo osób w ogóle tego nie skapnęło — wzięli istniejącą sesję z 200K+ na pokładzie, przepięli ją na K3 i pchnęli do 1M, aż w końcu system sam skompresował. Takiego scenariusza nie wytrzyma żadna subskrypcja. Ten komentarz w dokach wygląda bardziej jak prewencyjne gaszenie pożaru PR-owego.
GPT 5.6 Sol w Codex podniósł domyślny Context Window z 272K na 372K — i od razu dostał serię griefów, że „tokeny nie dychają". Tibo wrzucił nawet post, że różnica w Auto Compact między obiema widełkami nie jest aż tak duża, ale ostatecznie się nie wytrzymało i default wycisnęli z powrotem. Wyciągnięcie okna na maksa domyślnie to projektowanie pod własną klęskę.
🔍 „Mam cache hit 98%" to w rzeczywistości sygnał alarmowy
W społeczności regularnie pojawia się chwalenie, że cache hit wynosi 98% albo 99%, z wnioskiem: „czyli używam oszczędnie". Ten instynkt jest niemal na pewno odwrócony.
Na poziomie harnessa cache hit rate nie różni się drastycznie między dostawcami. Nietypowo wysoki wynik zazwyczaj oznacza dokładnie jedno — mocno jedziesz na długim kontekście, a długie okno to najdroższy kawałek rachunku. Więc „wysoki cache hit" przetłumaczone na ludzki: „najwięcej korzystam z tego, co kosztuje najwięcej".
Krótko mówiąc: nie każdy scenariusz potrzebuje długiego kontekstu. Naucz się świadomie sterować oknem — i te drogie modele staną się jeszcze jako tako użyteczne. A jeśli jesteś w typie „jedno okno do 1M i czekam, aż się samo skompresuje" — to poza DeepSeek i MiMo każdy model przepali Ci budżet.
🏷️ Czy wersja 256K będzie tańsza? Prawie na pewno nie
Wielu zgaduje, czy ten nowy model ID przyjdzie z niższą ceną. Prawie na pewno nie — cena zostaje ta sama. Oficjalny mnożnik ceny bierze się głównie z kosztów długiego wejścia i trafień w cache, a nie z obniżki samego modelu.
W ujęciu średnim różnica wychodzi około 3x. Tylko większość sesji i tak nie dobija do pełnego miliona, więc oficjalnie podano zachowawcze „szacunkowo 2x".
Przy limicie 256K średnia długość Context to jakieś 150K; przy limicie 1M średnio 600K — sam koszt cache rozjeżdża się 4x. Jeden Prompt to przeciętnie 8 rund wiadomości, przy założeniu 4K wejścia i 600 tokenów wyjścia na rundę — realny udział inputu i outputu w rachunku jest niski.
Czyli skok opłacalności bierze się z samego odcięcia długiego kontekstu na poziomie konfiguracji modelu, a nie z niższej ceny.
Dlatego Kimi wypuszcza osobną wersję i odcina długi kontekst już w konfiguracji — tylko tak naprawdę podnosi się opłacalność realnych zadań użytkownika.
📊 Testy: zużycie limitu mniej więcej jedna trzecia pełnej wersji
Kilka rzeczy z komentarzy warto odnotować:
- Ciekawostka: Codex i Cursor pod spodem podpięte są do modeli 1M, ale realnie użytkowego okna masz tam 2–300K.
- Ile tracisz na okrojonej wersji: ktoś wziął to samo zadanie — wersja 256K zużywa około 1/3 limitu pełnej wersji, bo długi kontekst sam z siebie pompuje zużycie tokenów. Przy tym samym standardzie ukończenia zużycie limitu na tym samym zadaniu to jakieś 40% wyjściowego.
- Długie taski: w kimi cli puszczone zadanie na godzinę-dwie zjadło w skali tygodnia 5,53% limitu; wcześniej standard to 10%+ na godzinę.
- Czy widać to na jakości: tak — po review wchodzi retusz i poprawki, pełna wersja robi to prawie bez powrotów.
- Wideo i 1M: wyrzucenie wejścia wideo i okna 1M tnie zapotrzebowanie na moc obliczeniową przynajmniej o połowę.
Dla użytkowników pakietu 199 — gdzie limit i tak jest obiektywnie za mały — okrojona wersja pozwala trochę poluzować pas. I co kluczowe: K3 MAX w wersji 1M nadal jest dostępny, w przeciwieństwie do ChatGPT, gdzie bez rozliczenia API nie dobierzesz się do 1M.
Czyli poza taną półką dostajesz dodatkowo jeszcze jedną opcję do wyboru (przy okazji odciążając moc obliczeniową po stronie dostawcy). Same plusy, żadnego minusa.
🎯 W jednym zdaniu
Dla zdecydowanej większości długie okno to skrytobójca na tokeny — z wyjątkiem DeepSeek i MiMo, gdzie cache jest ekstremalnie tani, każdy inny model po cichu wysysa Ci saldo.
Kimi K3-256K jednym ograniczeniem na poziomie konfigu pilnuje postawy wydawania za użytkownika. Dla teamu, który zawsze ma za mało mocy obliczeniowej, to ruch przyzwoity. Prawdziwie drogi nigdy nie jest sam model — tylko to „nieskończone", o którym myślisz, że Cię na nie stać.
Post bazuje na publicznej dyskusji w społeczności deweloperów wokół premiery Kimi K3-256K oraz na testach z komentarzy. Liczby i opinie pochodzą ze społeczności — traktuj je orientacyjnie; ostateczne cenniki i zasady rozliczeń publikuje Moonshot/Kimi.