Migreren naar Kimi K3.1 Pro: los de 400-fouten op, let op de standaardinstelling ‘max effort’ en typ Highspeed niet verkeerd

Kimi K3.1 Pro is beschikbaar in Kimi Code, via de API van Moonshot als kimi-k3.1-pro en op AIHubMix onder dezelfde ID. Moonshot geeft het dezelfde parameterbeperkingen als Kimi K3. Code die al op K3 werkt, kan dus overstappen met een wijziging van de model-ID en een nieuwe sessie. Voor code die is geschreven voor K2.x geldt nu een deadline op het platform van Moonshot: op 31 oktober 2026 sluit Moonshot de K2-serie af voor nieuwe gebruikersregistraties en het bedrijf is van plan de serie eind december uit te faseren. Juist die code loopt de meeste kans om stuk te gaan, omdat die vaak temperature instelt of thinking uitschakelt, en geen van beide werkt op K3.1 Pro. Code waarin geen effort-niveau is ingesteld, draait op max. Dat kost meer tokens dan je misschien verwacht en verbruikt in Kimi Code meer quotum dan K3 deed.

In dit artikel lees je wat duidelijke fouten oplevert (de 400-fouten en één 404), wat ongemerkt misgaat (de factuur, de cache en de Highspeed-ID) en hoe je Claude Code en Codex via AIHubMix instelt voor K3.1 Pro. De regels voor K3.1 Pro zijn afkomstig uit de modeldocumentatie van Kimi Code van Moonshot en de referentie voor modelparameters, waarin staat dat beide K3.1 Pro-ID's "dezelfde parameterbeperkingen hebben als kimi-k3". Regels die als regels voor K3 zijn aangeduid, komen uit de K3-handleidingen van Moonshot en zijn niet opnieuw gecontroleerd voor K3.1 Pro. De foutteksten zijn overgenomen uit de documentatie, openbare meldingen, de K3-test van AIHubMix in juli en de controles van AIHubMix voor K3.1 Pro op 24 oktober 2026. Die controles omvatten de hoofd-ID's en de ID's voor het coding-kanaal coding-kimi-k3.1-pro en coding-kimi-k3.1-pro-highspeed. Bij elke bewering staat waar die vandaan komt.

Welke route gebruik je?

Via de API van Moonshot en op AIHubMix zijn de ID's kimi-k3.1-pro en kimi-k3.1-pro-highspeed. In Kimi Code zijn dat k3.1-pro en k3.1-pro-highspeed. In een clientconfiguratie van 21 oktober werden k3 en kimi-for-coding gekoppeld aan een model k3.1, maar in de Kimi Code-documentatie staan nu k3 als K3 en kimi-for-coding als K2.8 Preview. Kies dus expliciet K3.1 Pro. Ook je abonnement is van belang: in Kimi Code vereist K3.1 Pro Plus of hoger (Pro voor de context van 1M), en Highspeed vereist Pro of hoger. Bij oudere abonnementen is dat Moderato of hoger, en Allegretto voor de context van 1M en voor Highspeed.

De K2-datums zijn afkomstig van Moonshot. Vanaf 31 oktober 2026 zijn K2-seriemodellen niet meer beschikbaar voor nieuwe gebruikersregistraties en alle modellen uit de serie worden naar verwachting eind december 2026 uitgefaseerd. Moonshot heeft geen uitfaseringsdatum voor K3 aangekondigd. Op 24 oktober vermeldde AIHubMix K2.6 en K2.7 Code nog, zonder uitfaseringsdatum.

De duidelijke fouten

Thinking uitgeschakeld: HTTP 400 of helemaal geen redenering

Wat je ziet: een HTTP 400 in Kimi Code. In de Kimi Code-documentatie van Moonshot staat dat K3.1 Pro-modellen "alleen de thinking-modus ondersteunen. Verzoeken met thinking uitgeschakeld worden afgewezen." De documentatie vermeldt niet de tekst van de foutmelding. Via de API van Moonshot gelden voor K3.1 Pro de beperkingen van K3, dat altijd redeneert. Via AIHubMix krijg je geen 400: op 24 oktober leverde thinking: {"type": "disabled"} bij beide hoofd-ID's een 200 op, via zowel Chat Completions als Messages, maar zonder redenering in het antwoord. Dat is een stille fout. Controleer dus of er redenering ontbreekt in de antwoorden.

Waardoor dit gebeurt: K2.x-code die thinking uitschakelde om sneller antwoord te krijgen, bijvoorbeeld met extra_body={"thinking": {"type": "disabled"}}, en tools die een effort-niveau van off, none of disabled versturen (zie het volgende gedeelte).

Oplossing: verwijder de schakelaar. Wil je thinking kort houden, verstuur dan reasoning_effort: "low".

Een achtergebleven blok met "enabled" is een ander geval. Bij de controle van AIHubMix op 24 oktober werd K2.x's thinking: {"type": "enabled"} naar K3.1 Pro verstuurd. Dat leverde 200 op, zowel bij de hoofd-ID's als via het coding-kanaal. In de documentatie van Moonshot wordt thinking "een aanvraagparameter die alleen voor K2.x geldt" genoemd. Ook noemt een handleiding voor probleemoplossing van derden een achtergebleven blok als oorzaak van 400-fouten na een overstap van K2.x naar K3. Verwijder het dus alsnog.

Houd je K2.7 Code als terugvaloptie tot de uitfasering, laat thinking dan ingeschakeld. In Moonshots Claude Code-handleiding staat de foutmelding 400 invalid thinking: only type=enabled is allowed for this model voor K2.7 Code wanneer thinking is uitgeschakeld.

Effort-waarden: off, none en onbekende waarden leveren 400 op

Wat je ziet: een HTTP 400 wanneer het effort-niveau off, none, disabled is of een waarde heeft die Kimi Code niet herkent. K3.1 Pro heeft drie niveaus: low, high en max. In de Kimi Code-documentatie van Moonshot staat hoe waarden die tools van derden versturen, hiernaar worden omgezet:

Voor K3.1 Pro documenteert Moonshots API alleen low, high en max, met max als standaardinstelling. Een omzetting wordt niet beschreven. Op 24 oktober leverden low, medium, high, max en xhigh op AIHubMix bij alle vier de K3.1 Pro-ID's een 200 op. Bij kimi-k3.1-pro leverden off en een onbekende waarde ook 200 op, met redenering, en leverde none 200 op zonder enige redenering. Op AIHubMix mislukken deze gevallen stil, niet met een 400.

De stille kant: er is geen medium-niveau. Een tool die op medium staat, krijgt high; een tool die op xhigh staat, krijgt max, het duurste niveau.

Oplossing: verstuur expliciet low, high of max en controleer wat je tool daadwerkelijk verstuurt.

"ongeldige temperatuur: voor dit model is alleen 1 toegestaan"

Wat je ziet: 400 invalid temperature: only 1 is allowed for this model. Bij de controle van AIHubMix op 24 oktober kwam precies deze fout terug van kimi-k3.1-pro en kimi-k3.1-pro-highspeed bij verzending van temperature: 0.2. Dezelfde tekst was op 3 oktober 2026 gemeld bij gebruik van K3 via de API van Moonshot en op 21 oktober bij gebruik van k3 via het Kimi Code-eindpunt.

Waarom: in de parameterreferentie van Moonshot gelden voor K3.1 Pro de beperkingen van K3: temperature is vast ingesteld op 1.0, top_p op 0.95, n op 1 en beide penalties op 0. Andere waarden geven een foutmelding. Ook K2.6 had een vaste waarde, namelijk 0.6 met thinking uitgeschakeld. Code die nog steeds 0.6 verstuurt, is dus de gebruikelijke verdachte.

De uitzondering die de fout verbergt: bij dezelfde controle accepteerde het coding-kanaal van AIHubMix temperature: 0.2. Code die alleen daar is getest, kan nog steeds stukgaan op de hoofd-ID's of via de API van Moonshot.

De valkuil die de fout nog beter verbergt: veel frameworks herkennen Kimi-modellen aan het prefix kimi- en laten temperature voor die modellen weg. De Kimi Code-ID's k3.1-pro en k3.1-pro-highspeed hebben dat prefix niet. Dat geldt ook voor de ID's van het coding-kanaal van AIHubMix, die beginnen met coding-. Een melding over Hermes Agent beschreef precies dit probleem bij K3. Het hoofdchatpad liet temperature weg, maar een hulpaanroep naar k3 verstuurde het nog wel en gaf elke keer een 400.

Oplossing: verstuur temperature, top_p, n, presence_penalty of frequency_penalty helemaal niet. Herken modellen aan hun modelfamilie, niet aan een prefix in de naam.

Controleer een route door één verzoek met een temperature te versturen:

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"}]}'

Op 24 oktober leverde dit de bovenstaande 400 op. Test dit voor elke model-ID die je code gebruikt: het coding-kanaal beantwoordde hetzelfde verzoek met 200.

Codex via AIHubMix: 404 op de Responses API

Wat je ziet: een HTTP 404 met The model kimi-k3.1-pro is not available on this endpoint. Bij de controle van AIHubMix op 24 oktober kwam deze fout van de Responses API voor beide hoofd-ID's, terwijl Chat Completions en Messages normaal antwoordden.

Oplossing: Codex werkt alleen met de Responses API. Stel daarom coding-kimi-k3.1-pro in. Bij dezelfde controle beantwoordde die ID verzoeken via Responses. AIHubMix bestempelt het coding-kanaal als een evaluatiepreview die niet wordt aanbevolen voor productie. Een paar verzoeken leverden tijdelijk de 404-fout "The requested resource was not found" op, dus probeer het nog één keer voordat je gaat debuggen. Gebruik dit totdat AIHubMix de Responses API voor de hoofd-ID's toevoegt. Claude Code gebruikt Messages en werkt met de hoofd-ID's.

stop-limieten

Wat je ziet: de K3-test van AIHubMix in juli leverde deze twee foutmeldingen op:

• 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

Waarom: K3 accepteert maximaal vijf stop-sequenties van elk maximaal 32 bytes. De Messages API past dezelfde controles toe op stop_sequences. Moonshot geeft K3.1 Pro dezelfde parameterbeperkingen, dus verwacht dezelfde limieten.

Oplossing: verkort de lijst. Houd er rekening mee dat 32 bytes minder zijn dan 32 tekens in het Chinees of Japans.

Codex via de API van Moonshot: "web_search.search_context_size is not supported" (K3-handleiding)

Wat je ziet: 400 web_search.search_context_size is not supported, overgenomen uit Moonshots Codex-handleiding, die voor K3 is geschreven. Via het coding-kanaal van AIHubMix leverde een Responses-verzoek met dit veld op 24 oktober een 200 op. Deze fout komt dus van het eigen eindpunt van Moonshot.

Oplossing: verwijder search_context_size uit je Codex-configuratie of tooldefinitie. Codex verstuurt deze parameter niet standaard.

De stille fouten

Deze fouten leveren geen foutmelding op. Je merkt ze later aan de factuur, het quotum van je abonnement of de kwaliteit van de uitvoer.

Effort en sessies

• De standaardinstelling is max, en dat is nieuw in Kimi Code. K3.1 Pro gebruikt standaard max. In Kimi Code was de standaardinstelling voor K3 high. Een sessie waarin nooit een effort-niveau wordt ingesteld, denkt nu dus grondiger na, verbruikt meer tokens en verbruikt het quotum sneller. Via de API van Moonshot is de standaardinstelling voor zowel K3 als K3.1 Pro max. Thinking wordt afgerekend als uitvoer: in de test van AIHubMix uit juli, waarin K3 in één prompt een spel bouwde, bestond 73% van de 74,994 completion-tokens uit thinking.
• Ook met low kunnen duizenden denktokens nodig zijn. Bij een steekproef van AIHubMix op 24 oktober redeneerde K3.1 Pro bij een prompt waarin om een uitleg van 600 woorden werd gevraagd eerst 5,561 tot 7,356 tokens op low voordat het antwoord gaf; bij één run werd de limiet van 8,192 tokens bereikt. K3 redeneerde bij dezelfde prompt 3,013 tot 7,051 tokens, dus dit is niet nieuw voor K3.1 Pro, maar low is bij geen van beide een goedkope modus; houd max_completion_tokens ruim. Dit betreft één prompt en drie runs per model op de hoofd-ID's van AIHubMix, dus meet dit voor je eigen workload.
• Overschakelen op K3.1 Pro binnen een oude sessie gaat ten koste van de kwaliteit. De documentatie van Moonshot voor Kimi Code raadt af om binnen een bestaande sessie met de K3-serie, K2.8 Preview of K2.7 Code Highspeed over te schakelen naar de nieuwe modellen: dit verslechtert de uitvoerkwaliteit en vermindert het aantal cache-hits. Begin een nieuwe sessie.
• Als je van model of inspanningsniveau verandert, wordt de cache ongeldig. Volgens de documentatie van Moonshot voor Kimi Code geldt dit voor beide; in de documentatie voor K3 stond ook dat het wijzigen van het inspanningsniveau 'hits in de prefixcache ongeldig maakt'. Kies het model en het niveau bij het begin van de sessie.

Highspeed

• Een verkeerd getypte Highspeed-ID levert je een trager model op. In Kimi Code valt een onjuiste Highspeed-ID 'stilzwijgend terug op K2.8 Preview zonder te denken — geen snelheidswinst'. Kopieer de ID exact en controleer welk model in je logs staat.
• Highspeed versnelt alleen de modeluitvoer. Moonshot geeft aan dat K3.1 Pro Highspeed ongeveer 2–3× zo snel is als K3.1 Pro, met identieke mogelijkheden. In de steekproef van AIHubMix lag de uitvoersnelheid op ongeveer 1.6–1.8× die van Pro. Toolaanroepen en scripts worden helemaal niet sneller. Daarom is de winst klein bij een beurt die vooral bestaat uit bestanden lezen en tests uitvoeren, terwijl Kimi Code-plannen ongeveer twee keer zoveel van het quotum verbruiken.

Protocollen

• Proxies kunnen het gedrag veranderen. De documentatie van Moonshot voor Kimi Code waarschuwt: 'Protocolvertaling via proxytools kan het modelgedrag beïnvloeden.' Gebruik voor elk hulpmiddel het protocol dat het spreekt: Messages voor Claude Code, Responses voor Codex. Op 24 oktober gaf AIHubMix op alle vier K3.1 Pro-ID's antwoorden via Chat Completions en Messages, inclusief de redenering als reasoning_content en als thinking-blokken. Responses werkte via het coding-kanaal, met een item reasoning, en gaf de hierboven genoemde 404 terug op de hoofd-ID's.
• Structured output via de Messages API is verbeterd. In de test van AIHubMix op K3 in juli negeerde /v1/messages een schema en gaf het vrije tekst terug. Op 24 oktober gaf hetzelfde type verzoek aan K3.1 Pro, met een JSON-schema in output_config.format en een prompt waarin niet om JSON werd gevraagd, op alle vier ID's {"city":"Paris"} terug. Het gaat om een schema met één veld, dus valideer de uitvoer voordat je JSON weer via Messages laat lopen. De andere eigenaardigheid van Messages in juli — een treffer op een stopreeks die als end_turn werd teruggegeven met stop_sequence: null — is niet opnieuw getest.

Lange verzoeken

• Korte time-outs laten zelfs vrij bescheiden verzoeken mislukken. In de steekproef duurden de volledige antwoorden van K3.1 Pro op low 80 tot 99 seconden. Een niet-streamende client met een time-out van 60 seconden zou bij elke run zijn vastgelopen, en een nieuwe poging zou dezelfde denktokens opnieuw kosten. Op de API van Moonshot is de standaardlimiet voor uitvoer van K3.1 Pro 131,072 tokens, met een maximum van 1,048,576, en de gamebuild op K3 van AIHubMix in juli duurde 2,541 seconden in één verzoek. Gebruik streaming en stel time-outs in minuten in.

Overgenomen uit de handleidingen voor K3

Deze punten komen uit de handleidingen voor K3:

• Als je reasoning_content weglaat, gaat de kwaliteit bij meerdere beurten achteruit. Het volledige assistentbericht, inclusief reasoning_content en tool_calls, moet ongewijzigd worden meegestuurd. Code die alleen content bewaart, blijft werken, maar Moonshot waarschuwt dat de uitvoerkwaliteit instabiel wordt.
• Dynamische tools verdwijnen als je hun bericht weglaat. Met K3 kun je tools halverwege een gesprek laden via een systeembericht zonder inhoud. De server bewaart dit bericht niet, dus het moet bij elk verzoek opnieuw worden meegestuurd. Op AIHubMix werkt dit via Chat Completions: op 24 oktober riep kimi-k3.1-pro een tool aan die op deze manier was ingevoegd. In de K3-test van AIHubMix in juli negeerde de Messages API een ingevoegde tool.

Factureringsregels die je makkelijk over het hoofd ziet

De onderstaande prijzen zijn die van AIHubMix, afkomstig van de modelpagina's, per miljoen tokens:

Bij AIHubMix is K3.1 Pro 30% goedkoper dan K3 voor invoer en invoer uit cache, en 26% goedkoper voor uitvoer. Highspeed kost voor invoer en uitvoer twee keer zoveel als Pro, maar hanteert hetzelfde tarief voor invoer uit cache. Voor de ID van het coding-kanaal gelden aparte prijzen: $0.88 voor invoer, $3.23 voor uitvoer en $0.132 voor invoer uit cache.

Een lager tarief garandeert geen lagere rekening. Neem de gamebuild van AIHubMix op K3 uit juli: één prompt leverde 74,994 uitvoertokens op, met 5,000 invoertokens als aanname. Bij hetzelfde aantal tokens kost dit ongeveer $1.08 op K3, ongeveer $0.80 op K3.1 Pro (5,000 × $2.00 + 74,994 × $10.50, per miljoen) en ongeveer $1.59 op Highspeed. Het aantal tokens verschilt per prompt (in de steekproef vielen K3.1 Pro en K3 bij low in hetzelfde bereik), dus meet dit voordat je een budget opstelt.

Volgens de API-documentatie van Moonshot worden de cachewrites van K3.1 Pro gefactureerd op basis van de TTL: 5 minuten of 1 uur, net als bij K3. De gepubliceerde tarieven voor K3, uit de handleiding voor contextcaching van Moonshot, laten zien hoe de tariefstructuur werkt:

Moonshot zegt dat het apart vermelden van cachewrites de totale kosten voor K3 niet verhoogde: de kosten voor het schrijven waren al opgenomen in de invoerprijs, dus verzoeken met de standaard-5-minuten-TTL kosten hetzelfde als voorheen.

Dit zijn de rechtstreekse tarieven van Moonshot. Op de modelpagina's van AIHubMix staan alleen prijzen voor invoer, uitvoer en invoer uit cache; er staat geen apart tarief voor cachewrites en ook niet hoe een write met een TTL van 1 uur wordt gefactureerd. AIHubMix geeft de TTL wel door: op 24 oktober werd bij een Messages-verzoek met een top-level cache_control-TTL van 1h de write gerapporteerd als cachetokens voor 1 uur, en werd een Chat Completions-verzoek met prompt_cache_options geaccepteerd.

• Caching gebeurt automatisch. Bij K3 is de standaard-TTL 5 minuten. Bij de controles van AIHubMix op 24 oktober kwam een herhaalde prompt van 93 tokens via het coding-kanaal volledig uit de cache, maar niet via de hoofd-ID's. Bij een prompt van 7,658 tokens leverde de tweede aanroep van kimi-k3.1-pro 7,424 gecachete tokens op, zowel via Chat Completions als via Messages.
• De TTL van 1 uur kost op de API van Moonshot bij de K3-tarieven $3.00 extra per miljoen tokens om te schrijven. Elke cachehit bespaart $2.70, dus volgens de berekening van Moonshot zelf is dit vanaf de tweede hit voordeliger.
• De TTL ligt vast vanaf de eerste write (K3). Je kunt een vermelding niet van 5 minuten naar 1 uur opwaarderen. Je moet wachten tot deze verloopt.
• Voor kostendashboards is een nieuw veld nodig (K3). Cachewrites verschijnen als prompt_tokens_details.cache_write_tokens in Chat Completions, input_tokens_details.cache_write_tokens in Responses en cache_creation_input_tokens in Messages.
• Redenering telt als uitvoer. Bij K3 worden denktokens tegen het uitvoertarief gefactureerd, ongeacht het inspanningsniveau. AIHubMix vermeldt geen afzonderlijk tarief voor redenering bij K3.1 Pro.

Zo verlaag je de rekening:

1. Stel reasoning_effort per workload in, in plaats van max over te nemen. Probeer low voor zoekopdrachten en classificatie, en high voor gewone programmeertaken.
2. Houd het model en het inspanningsniveau per sessie vast en begin een nieuwe sessie wanneer je een van beide wijzigt.
3. Zet de stabiele onderdelen vooraan: systeemprompt, tooldefinities en repositorycontext. Zet daarna de veranderende beurt.
4. Gebruik Highspeed wanneer wachten op de modeluitvoer de bottleneck is, niet voor loops die vooral tijd kwijt zijn aan toolaanroepen.
5. Houd het aandeel van het denken in de voltooiingstokens in de gaten. Blijft dit bij eenvoudige taken boven de helft, verlaag dan het inspanningsniveau.

Agents met echte machtigingen

Het probleem met Hermes Agent laat zien hoe een migratiebug een veiligheidsbug wordt. De 'smart approval'-classifier riep k3 aan met een temperatuurinstelling, en elke aanroep gaf een 400-fout. In de woorden van degene die het probleem meldde, 'schaalt de classifier bij elke aanroep op (fail-open)': de veiligheidscontrole deed zijn werk niet meer, terwijl er in de hoofdchat niets mis leek.

K3.1 Pro heeft dezelfde valkuil en voegt er nog een toe. Classifier-aanroepen zijn precies de aanroepen die teams snel en goedkoop proberen te maken door de temperatuur laag in te stellen of het denken uit te schakelen, maar bij K3.1 Pro werkt geen van beide: een temperatuurinstelling kan bij elke aanroep een 400-fout opleveren, en op AIHubMix kwam een verzoek met denken uit terug zonder redenering. Gebruik voor een veiligheidscontrole met K3.1 Pro reasoning_effort: "low" voor snelheid, bepaal wat er moet gebeuren bij een API-fout en laat de controle fail-closed werken.

Voor agents die zelfstandig handelen zijn nog een paar andere zaken van belang:

• Geforceerde toolaanroepen werken. K3.1 Pro ondersteunt tool_choice: "required", dat K2.x afwees, waardoor een workaround voor K2.x om een toolaanroep af te dwingen niet meer nodig is.
• De ingebouwde webzoekfunctie is nog niet klaar voor productie (K3). In de K3-handleiding van Moonshot staat dat de webzoekfunctie 'wordt bijgewerkt en op korte termijn niet wordt aanbevolen voor workflows in productie'. Ga bij K3.1 Pro hetzelfde ervan uit totdat Moonshot anders aangeeft. Via AIHubMix werd een zoeklus met K3.1 Pro op 24 oktober niet voltooid: het model vroeg om $web_search en toen het resultaat werd teruggestuurd, volgde 400 Invalid request: tokenization failed.
• Afbeeldingen moeten in base64 worden aangeleverd. K3 haalt geen afbeeldingen op via openbare URL's, en op 24 oktober wees kimi-k3.1-pro op AIHubMix er een af met 400 Invalid request: unsupported image url. Een agent die links naar schermafbeeldingen doorstuurt, krijgt dus een foutmelding. De andere optie van Moonshot, een bestands-ID uit de eigen bestandsupload, wordt niet aangeboden via AIHubMix: een verwijzing naar ms:// gaf een 404 terug. Een afbeelding in base64 werkte wel. K3.1 Pro accepteert in Kimi Code ook video-invoer.

Programmeertools: Claude Code en Codex

Claude Code gebruikt de Anthropic Messages API, waarop de hoofd-ID's van AIHubMix op 24 oktober antwoord gaven. Codex gebruikt de Responses API, waarop alleen het coding-kanaal antwoord gaf. De installatie en basisconfiguratie worden behandeld in de uitgebreide handleidingen van AIHubMix. Hieronder staat alleen wat er verandert voor K3.1 Pro.

De kolom Codex gebruikt de ID van het coding-kanaal totdat de hoofd-ID's verzoeken op de Responses API kunnen verwerken. Elke effort-waarde die een tool verstuurt buiten deze drie wordt omgezet zoals aangegeven in de bovenstaande effort-tabel.

Claude Code

Volg de handleiding voor Claude Code settings.json. Stel vervolgens elke modeltier in, niet alleen de hoofdmodeltier:

{
  "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"
  }
}

Bekende problemen, op basis van Moonshots Kimi Code-documentatie, de Claude Code-handleiding (geschreven voor K3) en tests van AIHubMix:

• Start een nieuwe sessie. Schakel een actieve K3-sessie niet over naar K3.1 Pro. Open een nieuwe sessie, zodat de cache en de uitvoerkwaliteit met een schone lei beginnen.
• Niet-ingestelde tiers mislukken stilzwijgend. Claude Code gebruikt verschillende tiers voor de hoofdchat, samenvattingen en subagents. Moonshot waarschuwt dat de overige tiers "stilzwijgend mislukken" als je er maar een paar configureert. Je kunt de Haiku-tier instellen op een goedkoper model voor achtergrondtaken.
• Verouderde instellingen hebben voorrang. Oude waarden in het blok env van ~/.claude/settings.json overschrijven variabelen die je in je shell hebt geëxporteerd.
• 1M-context. In Moonshots K3-handleiding wordt kimi-k3[1m] gebruikt, zodat Claude Code het contextvenster als 1M behandelt. kimi-k3.1-pro[1m] werkt via AIHubMix op dezelfde manier: Claude Code verwijdert het achtervoegsel vóór verzending en AIHubMix beantwoordde het resulterende verzoek, inclusief de 1M-contextheader, op 24 oktober. Alleen Claude Code begrijpt het achtervoegsel. Als je het vanuit een andere client als model-ID verstuurt, geeft kimi-k3.1-pro[1m] een 400-fout.
• Effort. K3.1 Pro gebruikt standaard al max, het niveau dat Moonshot in de K3-handleiding aanbeval met CLAUDE_CODE_EFFORT_LEVEL=max. Voor routinematig werk verbruikt high minder tokens. De waarde die Claude Code verstuurt, wordt omgezet zoals aangegeven in de effort-tabel; AIHubMix accepteerde alle vijf geteste waarden.
• Highspeed-tiers. Als je een tier instelt op kimi-k3.1-pro-highspeed, kopieer de ID dan exact. In Kimi Code valt een typefout stilzwijgend terug op een ander model; bij AIHubMix geeft een verkeerd gespelde ID een 400-fout.

Codex

Codex ondersteunt alleen de Responses API, dus wire_api = "responses" is vereist. De handleiding voor Codex config.toml behandelt de rest. Voor 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"

• Geef het contextvenster op. Zonder model_context_window valt Codex terug op de standaardmetadata voor een model dat het niet kent. In Moonshots Codex-handleiding, geschreven voor K3, wordt de waarschuwing Model metadata for kimi-k3 not found die hieruit voortkomt als verwacht en onschadelijk beschreven.
• Effort. De eigen niveaus van Codex zijn onder meer medium en xhigh. Volgens de Kimi Code-mapping worden die uitgevoerd als high en max; AIHubMix accepteerde beide op 24 oktober. Stel low, high of max in, zodat je weet voor welk niveau je betaalt.
• Kanalen verschillen. Het coding-kanaal accepteerde een temperature die de hoofd-ID's afwezen. Voer de rooktest opnieuw uit voordat je overschakelt, zodra de hoofd-ID's verzoeken via Responses kunnen verwerken.
• Geen search_context_size. Verwijder deze instelling als je configuratie die bevat (zie de duidelijke fouten).
• Start opnieuw op na wijzigingen. Codex leest config.toml alleen bij het opstarten. Als CC Switch je Codex-configuratie beheert, kan het je wijzigingen overschrijven.

Een rooktest van 15 minuten

Voer dit één keer per tool uit, in een kleine repository met een testsuite:

1. Start een nieuwe sessie met K3.1 Pro. Ga niet verder in een sessie die op K3 of een ander model draaide.
2. Vraag: "Voeg een unittests toe voor één functie in deze repository, voer de tests uit en herstel eventuele fouten."
3. Dit is een geslaagde test: het model leest bestanden en voert de tests uit (toolaanroepen werken). Het gaat verder nadat het de resultaten heeft gezien, wat laat zien dat redeneringen en toolresultaten worden teruggegeven. De tests slagen allemaal en er verschijnt nergens in de sessie een 400- of 404-fout.
4. Controleer in je AIHubMix-gebruikslogboek of de model-ID overeenkomt met de ID die je hebt ingesteld en of latere verzoeken gecachete invoertokens tonen voor de stabiele prefix. Als dat nooit gebeurt, verandert er bij elke beurt iets in je prefix.
5. Noteer de duur van de beurt en het aantal completion-tokens. Die vormen je uitgangspunt bij het kiezen van een effort-niveau en bij het beoordelen of Highspeed de moeite waard is.

Migratiechecklist

• Gebruik de ID van K3.1 Pro: kimi-k3.1-pro op Moonshots API en AIHubMix, k3.1-pro in Kimi Code; voor Codex via AIHubMix voorlopig coding-kimi-k3.1-pro.
• Migreer K2.x-code voordat Moonshot de K2-serie eind december 2026 uitfaseert; nieuwe Moonshot-accounts verliezen vanaf 31 October de toegang tot K2.
• Start een nieuwe sessie voor K3.1 Pro in plaats van een oude sessie om te schakelen.
• Verwijder temperature, top_p, n en beide penalties uit elk aanroeppad, inclusief helperaanroepen.
• Verwijder elke schakelaar om thinking uit te zetten, inclusief de effort-waarden off, none en disabled, en verwijder achtergebleven K2.x-thinkingblokken.
• Stel effort in op low, high of max; medium wordt uitgevoerd als high en xhigh als max.
• Houd het model en de effort gedurende een sessie ongewijzigd.
• Kopieer de Highspeed-ID exact en controleer het model in je gebruikslogboek.
• Beperk stoplijsten tot vijf items van maximaal 32 bytes.
• Geef het volledige assistant-bericht terug, inclusief reasoning_content en tool_calls, en stuur dynamische toolberichten opnieuw.
• Stream lange verzoeken en stel time-outs in minuten in.
• Valideer gestructureerde uitvoer voordat je JSON terugzet naar de Messages API.
• Werk de kostentracking bij voor het afzonderlijke cache-write-veld.
• Laat veiligheidscontroles bij API-fouten standaard weigeren.
• Voer de rooktest uit in elke coderingstool.

Veelgestelde vragen

Waarom geeft K3.1 Pro een HTTP 400-fout?
De gebruikelijke oorzaken zijn een temperature die niet 1 is, thinking dat is uitgeschakeld, of een effort-waarde van off, none, disabled of een onbekende waarde. De eerste oorzaak komt voort uit K3's vaste samplingregels, die K3.1 Pro behoudt; de andere worden beschreven in Moonshots Kimi Code-documentatie. Op de hoofd-ID's van AIHubMix gaf alleen temperature op 24 oktober een 400-fout; de overige verzoeken gaven 200 terug, en bij thinking off of none werd geen redenering teruggegeven.

Kan ik thinking uitschakelen?
Nee. K3.1 Pro werkt alleen in thinking-modus. Stel reasoning_effort in op low om het denken kort te houden.

Wordt temperature nog steeds afgewezen?
Ja, op Moonshots API en op de hoofd-ID's van AIHubMix, die op 24 October 2026 "invalid temperature: only 1 is allowed for this model" teruggaven. Het coding-kanaal van AIHubMix accepteerde tijdens dezelfde controle een temperature van 0.2. Laat temperature bij elke route weg.

Wanneer verdwijnen de K2-modellen?
Vanaf 31 October 2026 kunnen nieuw geregistreerde Moonshot-gebruikers de modellen uit de K2-serie niet meer gebruiken, en Moonshot is van plan ze allemaal eind december 2026 uit te faseren. AIHubMix vermeldde K2.6 en K2.7 Code op 24 oktober nog, zonder uitfaseringsdatum.

Waarom raakt mijn Kimi Code-tegoed sneller op?
K3.1 Pro gebruikt standaard max effort, terwijl K3 in Kimi Code standaard high gebruikte, en Highspeed telt ongeveer dubbel zoveel mee voor het tegoed als het reguliere model. Stel voor routinematig werk een lager effort-niveau in en houd dit gedurende een sessie ongewijzigd.

Waarom is Highspeed niet sneller?
Misschien is de ID verkeerd gespeld, waardoor Kimi Code stilzwijgend terugvalt op K2.8 Preview zonder thinking, of nemen toolaanroepen het grootste deel van de beurt in beslag. Highspeed versnelt alleen de modeluitvoer.

Welke AIHubMix-model-ID moet Codex gebruiken?
Voorlopig coding-kimi-k3.1-pro, via de Responses API op aihubmix.com/v1 met wire_api ingesteld op responses. De hoofd-ID's gaven op 24 oktober een 404-fout op de Responses API. AIHubMix bestempelt het coding-kanaal als een evaluatiepreview, niet voor productiegebruik.

Lees verder: de Kimi K3.1 Pro-serie

• Controleer voordat je migreert of de upgrade überhaupt de moeite waard is: van wat er is veranderd tot wat één echte taak kost: Kimi K3.1 Pro vs K3: Wat is er veranderd, wat kost het en wie zou moeten overstappen?
• Als je door de migratie alternatieven overweegt, lees dan hoe K3.1 Pro zich verhoudt tot Qwen 4 en Claude Fable 5.5, inclusief de kosten van één front-end-build met elk model: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5: front-endkwaliteit, kosten per taak en de hype getoetst
• Vraag je je door het tegoed en de prijs van Highspeed af of de snelle variant het waard is? De afweging tussen snelheid en prijs krijgt een eigen artikel: Kimi K3.1 Pro vs K3.1 Pro Highspeed: is 2–3× de snelheid 2× de prijs waard?

Bronnen

• Kimi Code: Modelconfiguratie
• Moonshot AI: Referentie voor modelparameters
• AIHubMix: Modelpagina van Kimi K3.1 Pro
• AIHubMix: Praktische handleiding voor Kimi K3
• Probleem #142365 van Hermes Agent: afwijking in het profiel van het Kimi Code-eindpunt