Migracja do Kimi K3.1 Pro: napraw błędy 400, zwróć uwagę na domyślny poziom max i nie pomyl nazwy Highspeed

Kimi K3.1 Pro jest już dostępny w Kimi Code, w API Moonshot jako kimi-k3.1-pro oraz w AIHubMix pod tym samym identyfikatorem. Moonshot stosuje wobec niego te same ograniczenia parametrów co w przypadku Kimi K3, dlatego kod działający już na K3 można przenieść, zmieniając identyfikator modelu i rozpoczynając nową sesję. Kod napisany dla K2.x ma już wyznaczony termin migracji na platformie Moonshot: od 31 października 2026 r. seria K2 nie będzie dostępna dla nowo zarejestrowanych użytkowników, a jej wycofanie planowane jest do końca grudnia. Ten kod najczęściej też będzie sprawiał problemy, ponieważ zwykle wysyła parametr temperature albo wyłącza tryb thinking, a K3.1 Pro nie obsługuje żadnego z tych rozwiązań. Z kolei kod, który w ogóle nie ustawia poziomu effort, działa na poziomie max, co zużywa więcej tokenów, niż można się spodziewać, a w Kimi Code także większą część limitu niż w przypadku K3.

W tym artykule omawiamy, co powoduje jawne błędy (400 oraz jeden 404), co zawodzi po cichu (rachunek, cache i identyfikator Highspeed) oraz jak skonfigurować Claude Code i Codex do pracy z K3.1 Pro przez AIHubMix. Zasady dotyczące K3.1 Pro pochodzą z dokumentacji modeli Kimi Code Moonshot oraz z dokumentacji referencyjnej parametrów modeli, według której oba identyfikatory K3.1 Pro podlegają „tym samym ograniczeniom parametrów co kimi-k3”. Zasady oznaczone jako dotyczące K3 pochodzą z przewodników Moonshot po K3 i nie zostały ponownie zweryfikowane dla K3.1 Pro. Treści błędów zacytowano z dokumentacji, publicznych zgłoszeń, lipcowego testu K3 przeprowadzonego przez AIHubMix oraz testów K3.1 Pro przeprowadzonych przez AIHubMix 24 października 2026 r. Testy objęły główne identyfikatory oraz identyfikatory kanału kodowania coding-kimi-k3.1-pro i coding-kimi-k3.1-pro-highspeed. Przy każdym twierdzeniu wskazano jego źródło.

Z której ścieżki korzystasz?

W API Moonshot i w AIHubMix obowiązują identyfikatory kimi-k3.1-pro oraz kimi-k3.1-pro-highspeed. W Kimi Code są to k3.1-pro i k3.1-pro-highspeed. Konfiguracja klienta zauważona 21 października przypisywała k3 i kimi-for-coding do modelu k3.1, ale aktualna dokumentacja Kimi Code wymienia k3 jako K3, a kimi-for-coding jako K2.8 Preview, dlatego wybierz jawnie K3.1 Pro. Znaczenie ma również Twój plan: w Kimi Code K3.1 Pro wymaga planu Plus lub wyższego (do kontekstu 1M potrzebny jest Pro), a Highspeed wymaga planu Pro lub wyższego. W przypadku starszych planów wymagany jest Moderato lub wyższy, a do kontekstu 1M i Highspeed — Allegretto.

Daty dotyczące K2 pochodzą od Moonshot. Od 31 października 2026 r. modele z serii K2 nie będą już dostępne dla nowo zarejestrowanych użytkowników, a wszystkie mają zostać wycofane do końca grudnia 2026 r. Moonshot nie ogłosił daty wycofania K3. 24 października AIHubMix nadal oferował K2.6 i K2.7 Code, bez podanej daty wycofania.

Jawne błędy

Wyłączony tryb thinking: HTTP 400 albo całkowity brak rozumowania

Co zobaczysz: błąd HTTP 400 w Kimi Code. W dokumentacji Kimi Code Moonshot podaje, że modele K3.1 Pro „obsługują wyłącznie tryb thinking. Żądania z wyłączonym trybem thinking są odrzucane”. Dokumentacja nie zawiera treści odpowiedzi błędu. W API Moonshot K3.1 Pro podlega ograniczeniom K3, a K3 zawsze przeprowadza rozumowanie. W AIHubMix nie występuje błąd 400: 24 października żądanie z thinking: {"type": "disabled"} zwróciło kod 200 dla obu głównych identyfikatorów, zarówno przez Chat Completions, jak i Messages, ale odpowiedź nie zawierała rozumowania. To cicha awaria, więc sprawdzaj odpowiedzi pod kątem braku rozumowania.

Skąd się bierze: z kodu K2.x, który wyłączał tryb thinking, aby szybciej uzyskać odpowiedź, na przykład za pomocą extra_body={"thinking": {"type": "disabled"}}, oraz z narzędzi, które wysyłają poziom effort off, none lub disabled (więcej w następnej sekcji).

Naprawa: usuń przełącznik. Aby ograniczyć długość myślenia, zamiast tego ustaw reasoning_effort: "low".

Pozostały blok „enabled” to inny przypadek. W teście AIHubMix z 24 października wysłano parametr K2.x thinking: {"type": "enabled"} do K3.1 Pro i uzyskano kod 200 zarówno dla głównych identyfikatorów, jak i kanału kodowania. Dokumentacja Moonshot określa thinking jako „parametr żądania dostępny wyłącznie w K2.x”, a poradnik rozwiązywania problemów innego dostawcy wymienia pozostawiony blok jako przyczynę błędów 400 po przejściu z K2.x na K3, dlatego i tak go usuń.

Jeśli do czasu wycofania K2.7 Code ma pozostać planem awaryjnym, nie wyłączaj w nim trybu thinking. W przewodniku Moonshot dotyczącym Claude Code udokumentowano błąd 400 invalid thinking: only type=enabled is allowed for this model dla K2.7 Code z wyłączonym trybem thinking.

Wartości effort: off, none i nieznane wartości zwracają błąd 400

Co zobaczysz: błąd HTTP 400, gdy wartość effort to off, none, disabled albo wartość nierozpoznawana przez Kimi Code. K3.1 Pro ma trzy poziomy: low, high i max. W dokumentacji Kimi Code Moonshot wyjaśnia, jak są mapowane wartości wysyłane przez narzędzia innych dostawców:

Dokumentacja API Moonshot określa dla K3.1 Pro tylko wartości low, high i max, przy czym max jest wartością domyślną; nie opisuje mapowania. W AIHubMix wartości low, medium, high, max i xhigh zwróciły kod 200 dla wszystkich czterech identyfikatorów K3.1 Pro w teście z 24 października. Dla kimi-k3.1-pro wartości off i nieznana wartość również zwróciły kod 200 wraz z rozumowaniem, a none zwróciło kod 200, ale w ogóle bez rozumowania. W AIHubMix te błędy występują po cichu, a nie w postaci błędu 400.

Cicha pułapka: nie ma poziomu medium. Narzędzie ustawione na medium przechodzi na high, a ustawione na xhigh — na max, czyli najdroższy poziom.

Naprawa: jawnie ustaw low, high lub max i sprawdź, co faktycznie wysyła Twoje narzędzie.

„Nieprawidłowa wartość temperature: dla tego modelu dozwolona jest tylko wartość 1”

Co zobaczysz: 400 invalid temperature: only 1 is allowed for this model. W teście AIHubMix z 24 października dokładnie taki błąd zwróciły kimi-k3.1-pro i kimi-k3.1-pro-highspeed po wysłaniu temperature: 0.2. Ten sam komunikat zgłoszono w związku z API Moonshot dla K3 3 października 2026 r. oraz w związku z endpointem Kimi Code dla k3 21 października.

Dlaczego: w dokumentacji referencyjnej parametrów Moonshot przypisuje K3.1 Pro ograniczenia K3: temperature jest na stałe ustawione na 1.0, top_p na 0.95, n na 1, a oba parametry penalty na 0; inne wartości powodują błąd. W K2.6 również obowiązywała stała wartość — 0.6 przy wyłączonym trybie thinking — dlatego zwykle problem powoduje kod, który nadal wysyła 0.6.

Wyjątek, który może to ukryć: w tym samym teście kanał kodowania AIHubMix zaakceptował temperature: 0.2. Kod przetestowany wyłącznie na tym kanale może nadal zawodzić na głównych identyfikatorach lub w API Moonshot.

Pułapka, która jeszcze bardziej utrudnia wykrycie problemu: wiele frameworków rozpoznaje modele Kimi po prefiksie kimi- i usuwa dla nich parametr temperature. Identyfikatory Kimi Code k3.1-pro i k3.1-pro-highspeed nie mają tego prefiksu; nie mają go również identyfikatory kanału kodowania AIHubMix, które zaczynają się od coding-. W zgłoszeniu dotyczącym Hermes Agent wykryto dokładnie ten problem w K3. Główna ścieżka czatu pomijała parametr temperature, ale wywołanie pomocnicze do k3 nadal go wysyłało i za każdym razem kończyło się błędem 400.

Naprawa: w ogóle nie wysyłaj parametrów temperature, top_p, n, presence_penalty ani frequency_penalty. Rozpoznawaj rodzinę modelu, a nie prefiks jego nazwy.

Aby sprawdzić daną ścieżkę, wyślij jedno żądanie z parametrem temperature:

curl https://aihubmix.com/v1/chat/completions \
  -H "Authorization: Bearer $AIHUBMIX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "kimi-k3.1-pro", "temperature": 0.2, "messages": [{"role": "user", "content": "hi"}]}'

24 października spowodowało to powyższy błąd 400. Sprawdź w ten sposób każdy identyfikator modelu używany przez Twój kod: kanał kodowania odpowiedział na to samo żądanie kodem 200.

Codex przez AIHubMix: błąd 404 w API Responses

Co zobaczysz: błąd HTTP 404 z komunikatem The model kimi-k3.1-pro is not available on this endpoint. W teście AIHubMix z 24 października wystąpił on w API Responses dla obu głównych identyfikatorów, podczas gdy Chat Completions i Messages działały normalnie.

Naprawa: Codex obsługuje wyłącznie API Responses, więc ustaw coding-kimi-k3.1-pro, które w tym samym teście odpowiedziało na żądania Responses. AIHubMix określa kanał kodowania jako wersję testową, która nie jest zalecana do użytku produkcyjnego. Niektóre żądania zwróciły przejściowy błąd 404 z komunikatem „The requested resource was not found”, więc ponów żądanie jeden raz, zanim zaczniesz diagnozować problem. Korzystaj z tego rozwiązania do czasu, aż AIHubMix doda obsługę API Responses dla głównych identyfikatorów. Claude Code używa Messages i działa z głównymi identyfikatorami.

Limity stop

Co zobaczysz: w lipcowym teście K3 przeprowadzonym przez AIHubMix pojawiły się dwa następujące komunikaty:

• Invalid request: stop array too long. Expected an array with maximum length 5, but got an array with length 6 instead
• Invalid request: stop sequence must not be longer than 32, but got 33 instead

Dlaczego: K3 obsługuje maksymalnie pięć sekwencji stop, z których każda może mieć do 32 bajtów; API Messages stosuje te same ograniczenia do stop_sequences. Moonshot przypisuje K3.1 Pro te same ograniczenia parametrów, więc należy oczekiwać takich samych limitów.

Naprawa: skróć listę. Pamiętaj, że 32 bajty to mniej niż 32 znaki w języku chińskim lub japońskim.

Codex w API Moonshot: „web_search.search_context_size is not supported” (przewodnik po K3)

Co zobaczysz: 400 web_search.search_context_size is not supported — komunikat z przewodnika Moonshot dotyczącego Codex, napisanego dla K3. W kanale kodowania AIHubMix żądanie Responses zawierające to pole zwróciło 24 października kod 200, więc ten błąd pochodzi z endpointu samego Moonshot.

Naprawa: usuń search_context_size z konfiguracji Codex lub definicji narzędzia. Codex nie wysyła go domyślnie.

Ciche awarie

Nie powodują błędów. Wychodzą na jaw później — na rachunku, w limicie planu albo w jakości wyników.

Poziomy effort i sesje

• Wartością domyślną jest max — i to nowość w Kimi Code. Domyślnym poziomem K3.1 Pro jest max. W Kimi Code domyślnym poziomem K3 był high, więc sesja, w której nie ustawiono poziomu effort, wykonuje teraz bardziej wnikliwe rozumowanie, zużywa więcej tokenów i szybciej wyczerpuje limit. W API Moonshot zarówno K3, jak i K3.1 Pro mają domyślny poziom max. Rozumowanie jest rozliczane jako tokeny wyjściowe: w lipcowym teście AIHubMix, podczas tworzenia gry w jednym promptcie z użyciem K3, 73% z 74,994 tokenów uzupełnienia stanowiło rozumowanie.
• Niski poziom wysiłku nadal może oznaczać tysiące tokenów rozumowania. W ramach wyrywkowego testu AIHubMix z 24 października prompt z prośbą o 600-wyrazowe wyjaśnienie sprawił, że K3.1 Pro przeanalizował 5,561–7,356 tokenów przy ustawieniu low, zanim odpowiedział, a jeden przebieg osiągnął limit 8,192 tokenów. K3 przeanalizował ten sam prompt, wykorzystując 3,013–7,051 tokenów, więc nie jest to nowość w K3.1 Pro, ale ustawienie low nie jest trybem oszczędnym w żadnym z tych modeli; pozostaw hojny limit max_completion_tokens. Test obejmował jeden prompt i po trzy przebiegi każdego modelu na głównych ID AIHubMix, więc wykonaj pomiary dla własnego obciążenia.
• Przejście na K3.1 Pro w ramach starej sesji obniża jakość. Dokumentacja Kimi Code od Moonshot odradza przełączanie na nowe modele „w ramach istniejącej sesji serii K3, K2.8 Preview lub K2.7 Code Highspeed”: obniża to jakość wyników i zmniejsza liczbę trafień w pamięci podręcznej. Rozpocznij nową sesję.
• Zmiana modelu lub poziomu wysiłku unieważnia pamięć podręczną. Dokumentacja Kimi Code od Moonshot mówi o obu tych przypadkach, a dokumentacja K3 informowała, że zmiana poziomu wysiłku „unieważnia trafienia w pamięci podręcznej prefiksów”. Wybierz model i poziom na początku sesji.

Highspeed

• Błędnie wpisane ID Highspeed oznacza wolniejszy model. W Kimi Code nieprawidłowe ID Highspeed „po cichu przełącza na K2.8 Preview bez rozumowania — bez przyspieszenia”. Skopiuj ID dokładnie i sprawdź, jaki model widnieje w logach.
• Highspeed przyspiesza tylko generowanie odpowiedzi przez model. Według Moonshot K3.1 Pro Highspeed działa około 2–3× szybciej niż K3.1 Pro, oferując identyczne możliwości. W wyrywkowym teście AIHubMix generował odpowiedzi około 1.6–1.8× szybciej niż Pro. Wywołania narzędzi i skrypty wcale nie działają szybciej, więc korzyść jest niewielka w przypadku tury zdominowanej przez czytanie plików i uruchamianie testów, a plany Kimi Code zużywają około dwa razy więcej limitu.

Protokoły

• Proxy mogą zmieniać zachowanie modelu. Dokumentacja Kimi Code od Moonshot ostrzega: „Tłumaczenie protokołu za pomocą narzędzi proxy może powodować różnice w zachowaniu modelu”. Używaj z każdym narzędziem protokołu, którego ono wymaga: Messages dla Claude Code, Responses dla Codex. 24 października AIHubMix zwracał odpowiedzi przez Chat Completions i Messages dla wszystkich czterech ID K3.1 Pro, dołączając rozumowanie jako reasoning_content oraz bloki thinking. Responses działał na kanale kodowania, zwracając element reasoning, a na głównych ID zwracał wspomniany wcześniej błąd 404.
• Obsługa ustrukturyzowanych danych w API Messages uległa poprawie. W lipcowym teście AIHubMix na K3 endpoint /v1/messages ignorował schemat i zwracał zwykły tekst. 24 października podobne żądanie do K3.1 Pro, ze schematem JSON w output_config.format i promptem, który nie prosił o JSON, zwróciło {"city":"Paris"} dla wszystkich czterech ID. Test obejmował schemat z jednym polem, więc sprawdź poprawność wyniku, zanim przeniesiesz obsługę JSON do Messages. Innej osobliwości Messages zaobserwowanej w lipcu — trafienie sekwencji zatrzymującej zwracane jako end_turn z stop_sequence: null — nie testowano ponownie.

Długie żądania

• Przy krótkich limitach czasu zawodzą nawet umiarkowane żądania. W wyrywkowym teście pełne odpowiedzi K3.1 Pro przy ustawieniu low powstawały w 80–99 sekund. Klient bez streamingu z limitem 60 sekund nie poradziłby sobie w żadnym przebiegu, a ponowienie żądania oznaczałoby ponowne opłacenie tego samego rozumowania. W API Moonshot domyślny limit wyjściowy K3.1 Pro wynosi 131,072 tokenów i może sięgać 1,048,576, a w lipcowym teście AIHubMix zbudowanie gry na K3 zajęło 2,541 sekund w ramach jednego żądania. Korzystaj ze streamingu i ustawiaj limity czasu w minutach.

Przeniesione z przewodników po K3

Poniższe informacje pochodzą z przewodników po K3:

• Pominięcie reasoning_content obniża jakość w rozmowach wieloturowych. Pełną wiadomość asystenta, w tym reasoning_content i tool_calls, należy bez zmian odesłać w kolejnym żądaniu. Kod, który zachowuje tylko content, nadal będzie działać, ale Moonshot ostrzega, że jakość wyników może być niestabilna.
• Jeśli pominiesz wiadomość, dynamiczne narzędzia znikną. W K3 możesz ładować narzędzia w trakcie rozmowy za pomocą wiadomości systemowej bez treści. Serwer jej nie zachowuje, więc trzeba ją ponownie wysyłać z każdym żądaniem. W AIHubMix działa to przez Chat Completions: 24 października model kimi-k3.1-pro wywołał narzędzie wstrzyknięte w ten sposób. W lipcowym teście K3 w AIHubMix API Messages zignorowało wstrzyknięte narzędzie.

Łatwe do przeoczenia zasady rozliczeń

Poniższe ceny pochodzą ze stron modeli AIHubMix i są podane za milion tokenów:

W AIHubMix K3.1 Pro jest o 30% tańszy od K3 dla tokenów wejściowych i wejściowych z pamięci podręcznej, a dla wyjściowych — o 26%. Highspeed kosztuje dwa razy więcej niż Pro za tokeny wejściowe i wyjściowe, przy tej samej stawce za tokeny z pamięci podręcznej. ID kanału kodowania ma osobny cennik: $0.88 za wejście, $3.23 za wyjście i $0.132 za tokeny z pamięci podręcznej.

Niższa stawka nie gwarantuje niższego rachunku. Weźmy lipcowy test AIHubMix, w którym na podstawie jednego promptu zbudowano grę na K3: 74,994 tokenów wyjściowych przy założeniu 5,000 tokenów wejściowych. Przy takiej samej liczbie tokenów koszt wynosi około $1.08 na K3, około $0.80 na K3.1 Pro (5,000 × $2.00 + 74,994 × $10.50 za milion) i około $1.59 na Highspeed. Liczba tokenów zależy od promptu (w wyrywkowym teście K3.1 Pro i K3 osiągnęły podobne wartości przy ustawieniu low), więc przed ustaleniem budżetu wykonaj pomiary.

Dokumentacja API Moonshot przewiduje naliczanie opłat za zapisy w pamięci podręcznej K3.1 Pro zależnie od TTL — 5 minut lub 1 godzina — tak samo jak w K3. Opublikowane stawki K3 z przewodnika Moonshot po buforowaniu kontekstu pokazują, jak działa ten model:

Moonshot informuje, że rozdzielenie kosztu zapisu w pamięci podręcznej nie podniosło łącznego kosztu K3: koszt zapisu był już uwzględniony w cenie wejściowej, więc żądania z domyślnym TTL wynoszącym 5 minut kosztują tyle samo co wcześniej.

To bezpośrednie stawki Moonshot. Strony modeli AIHubMix podają wyłącznie ceny za wejście, wyjście i tokeny wejściowe z pamięci podręcznej, bez osobnej stawki za zapis w pamięci podręcznej, i nie informują, jak rozliczany jest zapis z TTL wynoszącym 1 godzinę. AIHubMix przekazuje jednak wartość TTL: 24 października żądanie Messages z głównym parametrem cache_control ustawionym na TTL 1h wykazało zapis jako tokeny pamięci podręcznej z TTL wynoszącym 1 godzinę, a żądanie Chat Completions z prompt_cache_options zostało przyjęte.

• Buforowanie odbywa się automatycznie. W K3 domyślny TTL wynosi 5 minut. Podczas testów AIHubMix z 24 października powtórzone żądanie z promptem liczącym 93 tokeny wróciło w całości z pamięci podręcznej na kanale kodowania, ale nie na głównych ID. W przypadku promptu liczącego 7,658 tokenów drugie wywołanie kimi-k3.1-pro zwróciło 7,424 tokeny z pamięci podręcznej zarówno przez Chat Completions, jak i Messages.
• TTL wynoszący 1 godzinę w API Moonshot kosztuje przy stawkach K3 o $3.00 więcej za zapis każdego miliona tokenów. Każde trafienie oszczędza $2.70, więc według obliczeń Moonshot inwestycja zwraca się już przy drugim trafieniu.
• TTL ustala się przy pierwszym zapisie (K3). Nie można przedłużyć wpisu z 5 minut do godziny. Trzeba poczekać, aż wygaśnie.
• Panele kosztów potrzebują nowego pola (K3). Zapisy w pamięci podręcznej są raportowane jako prompt_tokens_details.cache_write_tokens w Chat Completions, input_tokens_details.cache_write_tokens w Responses i cache_creation_input_tokens w Messages.
• Rozumowanie jest częścią wyjścia. W K3 tokeny rozumowania są rozliczane według stawki za wyjście na każdym poziomie wysiłku. AIHubMix nie podaje osobnej ceny za rozumowanie w K3.1 Pro.

Sposoby na obniżenie rachunku:

1. Ustawiaj reasoning_effort osobno dla każdego rodzaju obciążenia, zamiast dziedziczyć wartość max. Wypróbuj low do wyszukiwania informacji i klasyfikacji, a high do typowych zadań programistycznych.
2. Utrzymuj ten sam model i poziom wysiłku w obrębie sesji, a przy zmianie któregokolwiek z nich rozpocznij nową sesję.
3. Umieść najpierw stabilne elementy: prompt systemowy, definicje narzędzi i kontekst repozytorium. Następnie dodaj zmienną część tury.
4. Korzystaj z Highspeed wtedy, gdy wąskim gardłem jest oczekiwanie na odpowiedź modelu, a nie w pętlach zdominowanych przez wywołania narzędzi.
5. Obserwuj udział rozumowania w tokenach uzupełnienia. Jeśli przy prostych zadaniach stale przekracza połowę, obniż poziom wysiłku.

Agenci z rzeczywistymi uprawnieniami

Problem Hermes Agent pokazuje, jak błąd migracji może stać się problemem bezpieczeństwa. Jego klasyfikator „inteligentnego zatwierdzania” wywoływał k3 z parametrem temperature, a każde wywołanie kończyło się błędem 400. Jak ujął to zgłaszający, klasyfikator „przy każdym wywołaniu eskaluje (fail-open)”: kontrola bezpieczeństwa przestała spełniać swoje zadanie, choć w głównym czacie nic nie wyglądało nieprawidłowo.

W K3.1 Pro nadal występuje ten mechanizm, a dochodzi jeszcze jeden. To właśnie w wywołaniach klasyfikatora zespoły często starają się uzyskać szybkość i niski koszt, ustawiając niską wartość temperature albo wyłączając thinking — ale w K3.1 Pro nie działa ani jedno, ani drugie: parametr temperature może powodować błąd 400 przy każdym wywołaniu, a w AIHubMix żądanie z wyłączonym thinking zwróciło wynik bez rozumowania. Jeśli kontrola bezpieczeństwa działa na K3.1 Pro, użyj reasoning_effort: "low", aby przyspieszyć działanie, określ reakcję na błąd API i skonfiguruj tryb fail-closed.

W przypadku agentów działających samodzielnie liczy się jeszcze kilka kwestii:

• Wymuszone wywołania narzędzi działają. K3.1 Pro obsługuje tool_choice: "required", odrzucane przez K2.x, więc można zrezygnować z obejścia K2.x wymuszającego wywołanie narzędzia.
• Wbudowane wyszukiwanie w sieci nie jest gotowe do użycia produkcyjnego (K3). Przewodnik Moonshot po K3 informuje, że wyszukiwanie w sieci „jest aktualizowane i w najbliższym czasie nie jest zalecane w środowiskach produkcyjnych”. Traktuj je tak samo w K3.1 Pro, dopóki Moonshot nie poinformuje inaczej. W AIHubMix pętla wyszukiwania w K3.1 Pro nie zakończyła się 24 października: model zażądał użycia $web_search, a odesłanie wyniku zwróciło 400 Invalid request: tokenization failed.
• Obrazy wejściowe wymagają formatu base64. K3 nie pobiera publicznych adresów URL obrazów, a 24 października kimi-k3.1-pro w AIHubMix odrzucił jeden z nich błędem 400 Invalid request: unsupported image url, więc agent przekazujący linki do zrzutów ekranu otrzyma błąd. Druga opcja Moonshot, czyli identyfikator pliku z własnego mechanizmu przesyłania plików, nie jest obsługiwana przez AIHubMix: odwołanie ms:// zwróciło 404. Obraz w formacie base64 zadziałał. K3.1 Pro obsługuje też wejście wideo w Kimi Code.

Narzędzia programistyczne: Claude Code i Codex

Claude Code korzysta z API Anthropic Messages, na które główne ID AIHubMix odpowiadały 24 października. Codex korzysta z API Responses, na które odpowiadał tylko kanał kodowania. Instalację i podstawową konfigurację opisano w ponadczasowych przewodnikach AIHubMix. Poniżej wymieniono tylko zmiany dotyczące K3.1 Pro.

Kolumna Codex używa identyfikatora kanału coding, dopóki główne identyfikatory nie zaczną odpowiadać w Responses API. Każda wartość effort spoza tej trójki, którą prześle narzędzie, jest mapowana zgodnie z powyższą tabelą effort.

Claude Code

Skorzystaj z przewodnika po ustawieniach settings.json w Claude Code. Następnie ustaw każdy poziom modelu, a nie tylko główny:

{
  "env": {
    "ANTHROPIC_BASE_URL": "https://aihubmix.com",
    "ANTHROPIC_AUTH_TOKEN": "sk-your-aihubmix-key",
    "ANTHROPIC_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "kimi-k3.1-pro",
    "ANTHROPIC_DEFAULT_FABLE_MODEL": "kimi-k3.1-pro",
    "CLAUDE_CODE_SUBAGENT_MODEL": "kimi-k3.1-pro"
  }
}

Znane problemy, opisane w dokumentacji Kimi Code od Moonshot, przewodniku Moonshot po Claude Code (napisanym dla K3) oraz testach AIHubMix:

• Rozpocznij nową sesję. Nie przełączaj działającej sesji K3 na K3.1 Pro. Otwórz nową, aby pamięć podręczna i jakość wyników zaczęły od czystego stanu.
• Nieustawione poziomy zawodzą po cichu. Claude Code używa różnych poziomów dla głównego czatu, podsumowań i podagentów. Moonshot ostrzega, że skonfigurowanie tylko niektórych z nich sprawia, iż pozostałe „zawodzą po cichu”. Poziom Haiku możesz przypisać do tańszego modelu do zadań wykonywanych w tle.
• Nieaktualne ustawienia mają pierwszeństwo. Stare wartości w bloku env pliku ~/.claude/settings.json zastępują zmienne wyeksportowane w powłoce.
• Kontekst 1M. W przewodniku Moonshot po K3 użyto kimi-k3[1m], aby Claude Code traktował okno jako 1M. kimi-k3.1-pro[1m] działa tak samo przez AIHubMix: przed wysłaniem Claude Code usuwa sufiks, a AIHubMix 24 października obsłużył wynikowe żądanie, włącznie z nagłówkiem określającym kontekst 1M. Tylko Claude Code rozpoznaje ten sufiks. Jeśli prześlesz kimi-k3.1-pro[1m] jako identyfikator modelu z dowolnego innego klienta, otrzymasz błąd 400.
• Effort. K3.1 Pro domyślnie używa już poziomu max, który w przewodniku Moonshot po K3 zalecano ustawiać za pomocą CLAUDE_CODE_EFFORT_LEVEL=max. W rutynowych zadaniach poziom high zużywa mniej tokenów. Dowolny poziom wysłany przez Claude Code jest mapowany zgodnie z tabelą effort, a AIHubMix zaakceptował wszystkie pięć testowanych wartości.
• Poziomy Highspeed. Jeśli przypisujesz poziom do kimi-k3.1-pro-highspeed, skopiuj identyfikator dokładnie. W Kimi Code literówka powoduje cichy powrót do modelu domyślnego; w AIHubMix błędny identyfikator zwraca błąd 400.

Codex

Codex obsługuje wyłącznie Responses API, więc wymagane jest wire_api = "responses". Pozostałe ustawienia opisano w przewodniku po config.toml w Codex. W przypadku K3.1 Pro:

# At launch (24 October 2026), the main ID kimi-k3.1-pro returned 404 on the Responses API.
# Use the coding-channel ID until AIHubMix adds it. AIHubMix labels the
# coding channel an evaluation preview, not for production.
model = "coding-kimi-k3.1-pro"
model_provider = "aihubmix"
model_context_window = 1048576
model_reasoning_effort = "high"

[model_providers.aihubmix]
name = "AIHubMix"
base_url = "https://aihubmix.com/v1"
env_key = "AIHUBMIX_API_KEY"
wire_api = "responses"

• Określ okno kontekstu. Bez model_context_window Codex korzysta z domyślnych metadanych modelu, którego nie zna. W przewodniku Moonshot po Codex, napisanym dla K3, wyjaśniono, że ostrzeżenie Model metadata for kimi-k3 not found jest oczekiwane i nieszkodliwe.
• Effort. Własne poziomy Codex obejmują medium i xhigh. Zgodnie z mapowaniem Kimi Code działają one odpowiednio jako high i max, a AIHubMix zaakceptował oba 24 października. Ustaw low, high lub max, aby wiedzieć, za który poziom płacisz.
• Kanały się różnią. Kanał coding zaakceptował parametr temperature, który główne identyfikatory odrzucały. Zanim przełączysz się na główne identyfikatory, gdy zaczną odpowiadać przez Responses, ponownie przeprowadź test dymny.
• Bez search_context_size. Jeśli konfiguracja go ustawia, usuń ten parametr (zob. błędy jawne).
• Po zmianach uruchom ponownie. Codex odczytuje config.toml tylko przy starcie. Jeśli konfiguracją Codex zarządza CC Switch, może nadpisać wprowadzone zmiany.

15-minutowy test dymny

Uruchom go raz dla każdego narzędzia, w małym repozytorium z zestawem testów:

1. Rozpocznij nową sesję na K3.1 Pro. Nie kontynuuj sesji rozpoczętej na K3 ani innym modelu.
2. Poproś: „Dodaj test jednostkowy dla jednej funkcji w tym repozytorium, uruchom testy i napraw wszystkie błędy”.
3. Oto oznaki powodzenia: model odczytuje pliki i uruchamia testy (wywołania narzędzi działają). Po zapoznaniu się z wynikami kontynuuje pracę, co pokazuje, że rozumowanie i wyniki narzędzi są przekazywane z powrotem. Kończy z zaliczonymi testami, a w całej sesji nie pojawia się żaden błąd 400 ani 404.
4. W dzienniku użycia AIHubMix sprawdź, czy identyfikator modelu jest zgodny z ustawionym i czy późniejsze żądania wykazują tokeny wejściowe z pamięci podręcznej dla stabilnego prefiksu. Jeśli ich nie ma, coś w prefiksie zmienia się przy każdej turze.
5. Zanotuj czas trwania tury i liczbę tokenów wyjściowych. To punkt odniesienia przy wyborze poziomu effort i ocenie, czy Highspeed się opłaca.

Lista kontrolna migracji

• Używaj identyfikatora K3.1 Pro: kimi-k3.1-pro w API Moonshot i AIHubMix, k3.1-pro w Kimi Code; na razie w Codex przez AIHubMix używaj coding-kimi-k3.1-pro.
• Przenieś kod korzystający z K2.x, zanim Moonshot wycofa serię K2 pod koniec grudnia 2026 r.; nowe konta Moonshot stracą dostęp do K2 od 31 października.
• Rozpocznij nową sesję dla K3.1 Pro zamiast przełączać starą.
• Usuń temperature, top_p, n oraz obie kary ze wszystkich ścieżek wywołań, w tym wywołań pomocniczych.
• Usuń wszystkie przełączniki wyłączające thinking, w tym wartości effort off, none i disabled, oraz pozostałe bloki thinking z K2.x.
• Ustaw effort na low, high lub max; medium działa jak high, a xhigh jak max.
• Nie zmieniaj modelu ani poziomu effort w trakcie sesji.
• Skopiuj dokładnie identyfikator Highspeed i sprawdź model w dzienniku użycia.
• Ogranicz listy stop do pięciu wpisów o długości najwyżej 32 bajtów.
• Przekazuj z powrotem pełną wiadomość asystenta, w tym reasoning_content i tool_calls, oraz ponownie wysyłaj dynamiczne wiadomości narzędzi.
• Włącz strumieniowanie dla długich żądań i ustaw limity czasu w minutach.
• Sprawdź poprawność ustrukturyzowanego wyjścia, zanim przeniesiesz JSON z powrotem do Messages API.
• Zaktualizuj śledzenie kosztów, aby uwzględniało osobne pole zapisu do pamięci podręcznej.
• W razie błędów API kontrole bezpieczeństwa powinny domyślnie odrzucać operację.
• Uruchom test dymny w każdym narzędziu do programowania.

Często zadawane pytania

Dlaczego K3.1 Pro zwraca błąd HTTP 400?
Najczęstsze przyczyny to wartość temperature inna niż 1, wyłączony thinking albo effort o wartości off, none, disabled lub nieznanej. Pierwszy problem wynika z ustalonych zasad próbkowania K3, które zachowano w K3.1 Pro; pozostałe opisano w dokumentacji Kimi Code od Moonshot. W przypadku głównych identyfikatorów AIHubMix tylko temperature zwracało 24 października błąd 400; pozostałe zwracały 200, a ustawienie thinking na off lub none powodowało brak reasoning w odpowiedzi.

Czy mogę wyłączyć thinking?
Nie. K3.1 Pro działa wyłącznie w trybie thinking. Ustaw reasoning_effort na low, aby skrócić rozumowanie.

Czy parametr temperature nadal jest odrzucany?
Tak, w API Moonshot oraz w przypadku głównych identyfikatorów AIHubMix, które 24 października 2026 r. zwróciły komunikat „invalid temperature: only 1 is allowed for this model”. Podczas tego samego testu kanał coding AIHubMix zaakceptował wartość temperature równą 0.2. Pomijaj temperature na każdej ścieżce.

Kiedy modele K2 zostaną wycofane?
Od 31 października 2026 r. nowo zarejestrowani użytkownicy Moonshot nie będą mogli korzystać z modeli serii K2, a Moonshot planuje wycofać je wszystkie do końca grudnia 2026 r. 24 października AIHubMix nadal udostępniał K2.6 i K2.7 Code, bez podanej daty wycofania.

Dlaczego limit Kimi Code wyczerpuje się szybciej?
K3.1 Pro domyślnie używa poziomu effort max, podczas gdy w Kimi Code K3 domyślnie korzystał z high, a Highspeed zużywa około dwa razy więcej limitu niż zwykły model. Do rutynowych zadań ustaw niższy poziom effort i nie zmieniaj go w trakcie sesji.

Dlaczego Highspeed nie działa szybciej?
Być może wpisano błędny identyfikator, przez co Kimi Code po cichu przełącza się na K2.8 Preview bez thinking, albo czas tury pochłaniają głównie wywołania narzędzi. Highspeed przyspiesza tylko generowanie odpowiedzi przez model.

Jakiego identyfikatora modelu AIHubMix powinien używać Codex?
Na razie coding-kimi-k3.1-pro w Responses API pod adresem aihubmix.com/v1, z wire_api ustawionym na responses. 24 października główne identyfikatory zwracały w Responses API błąd 404. AIHubMix oznacza kanał coding jako wersję ewaluacyjną, nieprzeznaczoną do produkcji.

Czytaj dalej: seria Kimi K3.1 Pro

• Zanim przeprowadzisz migrację, sprawdź, czy w ogóle warto aktualizować model — poznaj zmiany i koszt wykonania jednego rzeczywistego zadania: Kimi K3.1 Pro vs K3: co się zmieniło, ile to kosztuje i kto powinien się przełączyć
• Jeśli migracja skłania Cię do rozważenia alternatyw, porównujemy K3.1 Pro z Qwen 4 i Claude Fable 5.5, w tym koszt jednej kompilacji front-endu w każdym modelu: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5: jakość front-endu, koszt zadania i weryfikacja szumu medialnego
• Jeśli limit i cena Highspeed każą Ci się zastanawiać, czy szybszy wariant się opłaca, osobny artykuł odpowiada na pytanie o kompromis między szybkością a ceną: Kimi K3.1 Pro vs K3.1 Pro Highspeed: czy 2–3× większa szybkość jest warta 2× wyższej ceny?

Źródła

• Kimi Code: konfiguracja modelu
• Moonshot AI: dokumentacja parametrów modelu
• AIHubMix: strona modelu Kimi K3.1 Pro
• AIHubMix: praktyczny przewodnik po Kimi K3
• Problem #142365 w Hermes Agent: rozbieżności w profilu endpointu Kimi Code