Migration zu Kimi K3.1 Pro: 400-Fehler beheben, den Max-Effort-Standard beachten und Highspeed richtig schreiben

Kimi K3.1 Pro ist in Kimi Code, über Moonshots API unter kimi-k3.1-pro und bei AIHubMix unter derselben ID verfügbar. Moonshot setzt dafür dieselben Parameterbeschränkungen wie für Kimi K3 fest. Code, der bereits mit K3 läuft, sollte daher mit einer Änderung der Modell-ID und einer neuen Sitzung funktionieren. Für Code, der für K2.x geschrieben wurde, läuft die Frist auf Moonshots Plattform ab: Moonshot sperrt die K2-Serie dort ab dem 31. Oktober 2026 für neu registrierte Nutzer und plant, sie bis Ende Dezember einzustellen. Dieser Code geht auch am ehesten kaputt, da er häufig einen Temperaturwert sendet oder das Thinking deaktiviert – beides funktioniert mit K3.1 Pro nicht. Und Code, der nie eine Effort-Stufe festgelegt hat, läuft mit Max, was mehr Tokens kostet als erwartet und in Kimi Code mehr Kontingent verbraucht als K3.

Dieser Beitrag führt auf, was auffällig scheitert (die 400er sowie ein 404er), was unauffällig schiefgeht (die Rechnung, der Cache, die Highspeed-ID) und wie du Claude Code und Codex über AIHubMix für K3.1 Pro einrichtest. Die Regeln für K3.1 Pro stammen aus Moonshots Kimi-Code-Modelldokumentation und der Referenz zu Modellparametern, laut der für beide K3.1-Pro-IDs „dieselben Parameterbeschränkungen wie für kimi-k3“ gelten. Als Regeln für K3 gekennzeichnete Angaben stammen aus Moonshots K3-Leitfäden und wurden für K3.1 Pro nicht erneut überprüft. Fehlermeldungen sind den Dokumenten, öffentlichen Berichten, dem K3-Test von AIHubMix im Juli sowie den K3.1-Pro-Prüfungen von AIHubMix am 24. Oktober 2026 entnommen. Bei diesen Prüfungen wurden die Haupt-IDs und die Coding-Channel-IDs coding-kimi-k3.1-pro und coding-kimi-k3.1-pro-highspeed getestet. Bei jeder Aussage ist angegeben, woher sie stammt.

Welchen Weg nutzt du?

Bei Moonshots API und bei AIHubMix lauten die IDs kimi-k3.1-pro und kimi-k3.1-pro-highspeed. In Kimi Code sind es k3.1-pro und k3.1-pro-highspeed. Eine am 21. Oktober beobachtete Client-Konfiguration ordnete k3 und kimi-for-coding einem k3.1-Modell zu. In der aktuellen Kimi-Code-Dokumentation ist jedoch k3 als K3 und kimi-for-coding als K2.8 Preview aufgeführt. Wähle K3.1 Pro also ausdrücklich aus. Auch dein Tarif ist wichtig: In Kimi Code benötigt K3.1 Pro Plus oder höher (Pro für den 1M-Kontext), und für Highspeed ist Pro oder höher erforderlich. Bei älteren Tarifen brauchst du Moderato oder höher sowie Allegretto für den 1M-Kontext und Highspeed.

Die K2-Termine stammen von Moonshot. Ab dem 31. Oktober 2026 sind Modelle der K2-Serie für neu registrierte Nutzer nicht mehr verfügbar, und alle sollen bis Ende Dezember 2026 eingestellt werden. Moonshot hat keinen Einstellungstermin für K3 bekannt gegeben. AIHubMix führte K2.6 und K2.7 Code am 24. Oktober weiterhin ohne Einstellungstermin auf.

Die auffälligen Fehler

Thinking deaktiviert: HTTP 400 oder gar kein Reasoning

Was du siehst: einen HTTP-400-Fehler in Kimi Code. Laut Moonshots Kimi-Code-Dokumentation „unterstützen K3.1-Pro-Modelle ausschließlich den Thinking-Modus. Anfragen mit deaktiviertem Thinking werden abgewiesen.“ Die Dokumentation nennt den Fehlertext nicht. Bei Moonshots API unterliegt K3.1 Pro denselben Beschränkungen wie K3, und K3 führt immer Reasoning aus. Über AIHubMix gibt es keinen 400-Fehler: Am 24. Oktober lieferte thinking: {"type": "disabled"} für beide Haupt-IDs über Chat Completions und Messages den Status 200, aber die Antwort enthielt kein Reasoning. Dort handelt es sich also um einen unauffälligen Fehler. Prüfe die Antworten darauf, ob Reasoning fehlt.

Woher das kommt: K2.x-Code, der Thinking deaktiviert hat, um schneller zu antworten, etwa mit extra_body={"thinking": {"type": "disabled"}}, sowie Tools, die den Effort-Wert off, none oder disabled senden (siehe nächster Abschnitt).

Lösung: Entferne die Umschaltung. Wenn du das Thinking kurz halten möchtest, sende stattdessen reasoning_effort: "low".

Ein übrig gebliebener „enabled“-Block ist ein anderer Fall. Bei der Prüfung von AIHubMix am 24. Oktober wurde K2.x-thinking: {"type": "enabled"} an K3.1 Pro gesendet; die Antwort war 200 – sowohl bei den Haupt-IDs als auch beim Coding Channel. Moonshots Dokumentation bezeichnet thinking als „Anfrageparameter ausschließlich für K2.x“, und ein Fehlerbehebungsleitfaden eines Drittanbieters nennt einen übrig gebliebenen Block als Ursache für 400-Fehler nach dem Wechsel von K2.x zu K3. Entferne ihn also trotzdem.

Wenn du K2.7 Code bis zur Einstellung als Ausweichoption behältst, lass Thinking aktiviert. Moonshots Claude-Code-Leitfaden dokumentiert 400 invalid thinking: only type=enabled is allowed for this model für K2.7 Code, wenn Thinking deaktiviert ist.

Effort-Werte: off, none und unbekannte Werte führen zu 400

Was du siehst: einen HTTP-400-Fehler, wenn der Effort-Wert off, none, disabled oder ein von Kimi Code nicht erkannter Wert ist. K3.1 Pro hat drei Stufen: low, high und max. Moonshots Kimi-Code-Dokumentation beschreibt, wie Werte von Drittanbieter-Tools diesen Stufen zugeordnet werden:

Moonshots API dokumentiert für K3.1 Pro nur low, high und max, wobei max der Standardwert ist; eine Zuordnung wird nicht beschrieben. Bei AIHubMix lieferten low, medium, high, max und xhigh am 24. Oktober bei allen vier K3.1-Pro-IDs den Status 200. Bei kimi-k3.1-pro lieferten auch off und ein unbekannter Wert den Status 200, diesmal mit Reasoning; none lieferte den Status 200, jedoch ganz ohne Reasoning. Bei AIHubMix schlagen diese Werte unauffällig fehl, statt einen 400-Fehler auszulösen.

Der unauffällige Haken: Es gibt keine Stufe „medium“. Ein Tool, das auf medium eingestellt ist, erhält high; bei einem Tool mit xhigh wird max verwendet, die teuerste Stufe.

Lösung: Sende ausdrücklich low, high oder max und prüfe, was dein Tool tatsächlich überträgt.

„Ungültiger Temperaturwert: Für dieses Modell ist nur 1 zulässig“

Was du siehst: 400 invalid temperature: only 1 is allowed for this model. Bei der Prüfung von AIHubMix am 24. Oktober kam genau dieser Fehler von kimi-k3.1-pro und kimi-k3.1-pro-highspeed, als temperature: 0.2 gesendet wurde. Derselbe Text wurde am 3. Oktober 2026 für K3 bei Moonshots API und am 21. Oktober für k3 beim Kimi-Code-Endpunkt gemeldet.

Warum: Moonshots Parameterreferenz gibt für K3.1 Pro dieselben Beschränkungen wie für K3 an: temperature ist auf 1.0 festgelegt, top_p auf 0.95, n auf 1 und beide Penalties auf 0. Andere Werte führen zu einem Fehler. Auch K2.6 hatte einen festen Wert, nämlich 0.6 bei deaktiviertem Thinking. Code, der weiterhin 0.6 sendet, ist also der übliche Verdächtige.

Die Ausnahme, die den Fehler verdeckt: Der Coding Channel von AIHubMix akzeptierte bei derselben Prüfung temperature: 0.2. Code, der nur dort getestet wurde, kann bei den Haupt-IDs oder bei Moonshots API trotzdem scheitern.

Die Falle, die den Fehler noch besser verbirgt: Viele Frameworks erkennen Kimi-Modelle am Präfix kimi- und entfernen bei ihnen den Temperaturwert. Kimi Codes k3.1-pro und k3.1-pro-highspeed haben dieses Präfix nicht. Dasselbe gilt für die Coding-Channel-IDs von AIHubMix, die mit coding- beginnen. Ein Problembericht zu Hermes Agent stellte genau dieses Verhalten bei K3 fest. Der Hauptpfad für Chats ließ den Temperaturwert weg, aber ein Hilfsaufruf an k3 sendete ihn weiterhin und löste jedes Mal den 400-Fehler aus.

Lösung: Sende temperature, top_p, n, presence_penalty und frequency_penalty überhaupt nicht. Erkenne die Modellfamilie anhand des Modells, nicht anhand eines Namenspräfixes.

Um einen Endpunkt zu prüfen, sende eine Anfrage mit einem Temperaturwert:

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

Am 24. Oktober ergab das den oben genannten 400-Fehler. Teste es mit jeder Modell-ID, die dein Code verwendet: Beim Coding Channel lieferte dieselbe Anfrage den Status 200.

Codex über AIHubMix: 404 bei der Responses API

Was du siehst: einen HTTP-404-Fehler mit The model kimi-k3.1-pro is not available on this endpoint. Bei der Prüfung von AIHubMix am 24. Oktober trat er bei der Responses API für beide Haupt-IDs auf, während Chat Completions und Messages normal antworteten.

Lösung: Codex unterstützt nur die Responses API. Stelle es daher auf coding-kimi-k3.1-pro um, das bei derselben Prüfung auf Responses-Anfragen antwortete. AIHubMix kennzeichnet den Coding Channel als Evaluierungsvorschau, die nicht für den Produktiveinsatz empfohlen wird. Einige Anfragen lieferten vorübergehend den 404-Fehler „The requested resource was not found“. Versuche es daher einmal erneut, bevor du mit der Fehlersuche beginnst. Verwende den Coding Channel, bis AIHubMix die Responses API für die Haupt-IDs hinzufügt. Claude Code verwendet Messages und funktioniert mit den Haupt-IDs.

stop-Grenzwerte

Was du siehst: Beim K3-Test von AIHubMix im Juli wurden diese beiden Meldungen ausgegeben:

• 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

Warum: K3 akzeptiert höchstens fünf Stop-Sequenzen mit jeweils bis zu 32 Bytes, und die Messages API wendet dieselben Prüfungen auf stop_sequences an. Moonshot gibt für K3.1 Pro dieselben Parameterbeschränkungen an, daher sind dieselben Grenzwerte zu erwarten.

Lösung: Kürze die Liste. Beachte, dass 32 Bytes bei Chinesisch oder Japanisch weniger als 32 Zeichen entsprechen.

Codex bei Moonshots API: „web_search.search_context_size is not supported“ (K3-Leitfaden)

Was du siehst: 400 web_search.search_context_size is not supported – zitiert aus Moonshots Codex-Leitfaden, der für K3 geschrieben wurde. Über den Coding Channel von AIHubMix lieferte am 24. Oktober eine Responses-Anfrage mit diesem Feld den Status 200. Der Fehler tritt also bei Moonshots eigenem Endpunkt auf.

Lösung: Entferne search_context_size aus deiner Codex-Konfiguration oder Tool-Definition. Codex sendet diesen Parameter standardmäßig nicht.

Die unauffälligen Fehler

Diese Fehler lösen keine Meldungen aus. Sie zeigen sich erst später – auf der Rechnung, beim Kontingent deines Tarifs oder in der Ausgabequalität.

Effort und Sitzungen

• Der Standardwert ist max – und das ist neu in Kimi Code. K3.1 Pro verwendet standardmäßig max. In Kimi Code war der Standardwert für K3 high. Eine Sitzung, die nie einen Effort-Wert festlegt, denkt jetzt also intensiver nach, verbraucht mehr Tokens und leert das Kontingent schneller. Bei Moonshots API ist max sowohl für K3 als auch für K3.1 Pro der Standardwert. Thinking wird als Output abgerechnet: Beim einpromptigen Spiele-Build von AIHubMix mit K3 im Juli entfielen 73% der 74,994 Completion-Tokens auf Thinking.
• Auch bei niedrigem Aufwand können Tausende Thinking-Tokens anfallen. Bei einer Stichprobe auf AIHubMix am 24. Oktober führte ein Prompt mit der Bitte um eine 600 Wörter lange Erklärung dazu, dass K3.1 Pro vor der Antwort bei low 5,561 bis 7,356 Tokens lang nachdachte; bei einem Lauf wurde das Limit von 8,192 Tokens erreicht. K3 kam beim selben Prompt auf 3,013 bis 7,051 Tokens. Das ist also nicht neu bei K3.1 Pro, aber low ist bei keinem der beiden ein günstiger Modus. Setze max_completion_tokens großzügig an. Das war nur ein Prompt mit drei Läufen pro Modell über die Haupt-IDs von AIHubMix. Miss daher mit deinen eigenen Workloads.
• Der Wechsel zu K3.1 Pro innerhalb einer alten Sitzung kostet Qualität. In der Kimi-Code-Dokumentation rät Moonshot davon ab, „innerhalb einer bestehenden Sitzung mit der K3-Serie, K2.8 Preview oder K2.7 Code Highspeed“ zu den neuen Modellen zu wechseln: Das verschlechtert die Ausgabequalität und reduziert Cache-Treffer. Starte eine neue Sitzung.
• Ein Modell- oder Aufwandswechsel macht den Cache ungültig. Laut der Kimi-Code-Dokumentation von Moonshot gilt das für beides; schon in der K3-Dokumentation hieß es, dass ein Wechsel des Aufwands „Treffer im Prefix-Cache ungültig macht“. Lege Modell und Aufwandsstufe zu Beginn der Sitzung fest.

Highspeed

• Eine falsch eingegebene Highspeed-ID führt zu einem langsameren Modell. In Kimi Code fällt eine falsche Highspeed-ID „unbemerkt auf K2.8 Preview zurück, ohne Thinking – keine Geschwindigkeitssteigerung“. Kopiere die ID exakt und prüfe in deinen Logs, welches Modell angezeigt wird.
• Highspeed beschleunigt nur die Modellausgabe. Moonshot gibt für K3.1 Pro Highspeed eine etwa 2–3× höhere Geschwindigkeit als für K3.1 Pro an, bei identischen Fähigkeiten. In der Stichprobe von AIHubMix lief die Ausgabe etwa 1.6–1.8× so schnell wie bei Pro. Tool-Aufrufe und Skripte werden dadurch überhaupt nicht schneller. Bei einem Durchlauf, der vor allem aus dem Lesen von Dateien und dem Ausführen von Tests besteht, ist der Gewinn also gering, während Kimi-Code-Pläne etwa doppelt so viel Kontingent verbrauchen.

Protokolle

• Proxys können das Verhalten verändern. In der Kimi-Code-Dokumentation warnt Moonshot: „Die Protokollübersetzung durch Proxy-Tools kann zu abweichendem Modellverhalten führen.“ Gib jedem Tool das Protokoll, das es unterstützt: Messages für Claude Code, Responses für Codex. Am 24. Oktober lieferte AIHubMix bei Chat Completions und Messages auf allen vier K3.1-Pro-IDs die Reasoning-Ausgabe mit zurück: als reasoning_content und als thinking-Blöcke. Responses funktionierte über den Coding-Kanal mit einem reasoning-Element und gab bei den Haupt-IDs den oben genannten 404-Fehler zurück.
• Die strukturierte Ausgabe über die Messages-API funktioniert jetzt besser. Beim K3-Test von AIHubMix im Juli ignorierte /v1/messages ein Schema und gab freien Text zurück. Am 24. Oktober gab eine gleichartige Anfrage an K3.1 Pro mit einem JSON-Schema in output_config.format und einem Prompt, der nicht um JSON bat, auf allen vier IDs {"city":"Paris"} zurück. Das war ein Schema mit nur einem Feld. Validiere die Ausgabe daher, bevor du JSON wieder über Messages ausgibst. Die andere Messages-Eigenheit aus dem Juli wurde nicht erneut getestet: Ein Treffer auf eine Stoppsequenz wurde als end_turn mit stop_sequence: null zurückgegeben.

Lange Anfragen

• Kurze Timeouts führen schon bei mäßig umfangreichen Anfragen zu Fehlern. Bei der Stichprobe dauerten die vollständigen Antworten von K3.1 Pro mit low 80 bis 99 Sekunden. Ein nicht streamender Client mit einem Timeout von 60 Sekunden wäre bei jedem Lauf fehlgeschlagen; ein erneuter Versuch hätte dieselben Thinking-Kosten verursacht. Über Moonshots API liegt das standardmäßige Ausgabelimit von K3.1 Pro bei 131,072 Tokens und kann bis zu 1,048,576 betragen. Der Game-Build von AIHubMix mit K3 lief im Juli in einer einzelnen Anfrage 2,541 Sekunden lang. Nutze Streaming und setze Timeouts in Minuten.

Aus den K3-Leitfäden übernommen

Diese Hinweise stammen aus den K3-Leitfäden:

• Wenn du reasoning_content weglässt, leidet die Qualität bei mehreren Gesprächsrunden. Die vollständige Assistant-Nachricht muss unverändert zurückgesendet werden, einschließlich reasoning_content und tool_calls. Code, der nur content beibehält, läuft zwar weiterhin, aber Moonshot warnt vor schwankender Ausgabequalität.
• Dynamische Tools gehen verloren, wenn du ihre Nachricht weglässt. Bei K3 lassen sich Tools mitten im Gespräch über eine Systemnachricht ohne Inhalt laden. Der Server speichert sie nicht, deshalb muss sie mit jeder Anfrage erneut gesendet werden. Auf AIHubMix funktioniert das über Chat Completions: Am 24. Oktober rief kimi-k3.1-pro ein auf diese Weise eingeschleustes Tool auf. Beim K3-Test von AIHubMix im Juli ignorierte die Messages-API ein eingeschleustes Tool.

Abrechnungsregeln, die leicht zu übersehen sind

Die folgenden Preise stammen von den Modellseiten von AIHubMix und gelten pro Million Tokens:

Bei AIHubMix ist K3.1 Pro bei Eingaben und gecachten Eingaben 30% günstiger als K3, bei Ausgaben 26%. Highspeed kostet bei Eingaben und Ausgaben doppelt so viel wie Pro, der Preis für gecachte Eingaben ist gleich. Die ID des Coding-Kanals wird separat bepreist: $0.88 für Eingaben, $3.23 für Ausgaben und $0.132 für gecachte Eingaben.

Ein niedrigerer Preis pro Token garantiert keine kleinere Rechnung. Beim Game-Build von AIHubMix aus dem Juli mit einem einzigen Prompt auf K3 fielen 74,994 Ausgabe-Tokens an; für die Eingabe werden 5,000 Tokens angenommen. Bei denselben Tokenzahlen kostet der Lauf mit K3 etwa $1.08, mit K3.1 Pro etwa $0.80 (5,000 × $2.00 + 74,994 × $10.50 pro Million) und mit Highspeed etwa $1.59. Die Tokenzahlen variieren je nach Prompt (in der Stichprobe lagen K3.1 Pro und K3 bei low im selben Bereich), also miss erst, bevor du dein Budget festlegst.

Laut der API-Dokumentation von Moonshot werden Cache-Schreibvorgänge für K3.1 Pro nach TTL abgerechnet – 5 Minuten oder 1 Stunde, wie bei K3. Die veröffentlichten K3-Preise aus Moonshots Leitfaden zum Kontext-Caching veranschaulichen die Abrechnungsstruktur:

Moonshot zufolge erhöhte die separate Ausweisung von Cache-Schreibvorgängen die Gesamtkosten für K3 nicht: Die Kosten dafür waren bereits im Eingabepreis enthalten, sodass Anfragen mit der standardmäßigen TTL von 5 Minuten genauso viel kosteten wie zuvor.

Dies sind die direkten Preise von Moonshot. Auf den Modellseiten von AIHubMix werden nur Preise für Eingaben, Ausgaben und gecachte Eingaben aufgeführt, ohne separaten Preis für Cache-Schreibvorgänge. Auch wird nicht angegeben, wie ein Schreibvorgang mit einer TTL von 1 Stunde abgerechnet wird. AIHubMix übernimmt den TTL-Wert jedoch: Am 24. Oktober wurde bei einer Messages-Anfrage mit einer cache_control-TTL auf oberster Ebene von 1h der Schreibvorgang als Cache-Tokens mit einer Gültigkeit von 1 Stunde ausgewiesen; eine Chat-Completions-Anfrage mit prompt_cache_options wurde angenommen.

• Das Caching erfolgt automatisch. Bei K3 beträgt die standardmäßige TTL 5 Minuten. Bei den Prüfungen von AIHubMix am 24. Oktober wurde ein wiederholter Prompt mit 93 Tokens über den Coding-Kanal vollständig aus dem Cache bedient, bei den Haupt-IDs jedoch nicht. Bei einem Prompt mit 7,658 Tokens lieferte der zweite Aufruf von kimi-k3.1-pro 7,424 gecachte Tokens zurück – sowohl über Chat Completions als auch über Messages.
• Die TTL von 1 Stunde kostet bei Moonshots API zu den K3-Preisen $3.00 mehr pro Million Tokens für den Schreibvorgang. Jeder Treffer spart $2.70. Nach Moonshots eigener Rechnung lohnt es sich also ab dem zweiten Treffer.
• Die TTL wird beim ersten Schreibvorgang festgelegt (K3). Ein Cache-Eintrag lässt sich nicht von 5 Minuten auf 1 Stunde verlängern. Er muss erst ablaufen.
• Kosten-Dashboards brauchen ein neues Feld (K3). Cache-Schreibvorgänge erscheinen in Chat Completions als prompt_tokens_details.cache_write_tokens, in Responses als input_tokens_details.cache_write_tokens und in Messages als cache_creation_input_tokens.
• Reasoning zählt als Ausgabe. Bei K3 werden Thinking-Tokens auf allen Aufwandsstufen zum Ausgabepreis abgerechnet. AIHubMix weist für K3.1 Pro keinen separaten Reasoning-Preis aus.

So lässt sich die Rechnung senken:

1. Lege reasoning_effort je nach Workload fest, statt den Wert max zu übernehmen. Probiere low für Abfragen und Klassifizierung und high für alltägliche Programmieraufgaben.
2. Behalte Modell und Aufwand während einer Sitzung bei und starte eine neue Sitzung, wenn du eines von beiden änderst.
3. Platziere die stabilen Bestandteile zuerst: System-Prompt, Tool-Definitionen und Repository-Kontext. Danach kommt der sich ändernde Gesprächsschritt.
4. Nutze Highspeed, wenn die Wartezeit auf die Modellausgabe der Engpass ist, nicht bei Abläufen, die vor allem von Tool-Aufrufen bestimmt werden.
5. Behalte den Anteil der Thinking-Tokens an den Completion-Tokens im Blick. Liegt er bei einfachen Aufgaben dauerhaft über der Hälfte, reduziere den Aufwand.

Agenten mit echten Berechtigungen

Das Problem mit Hermes Agent zeigt, wie aus einem Migrationsfehler ein Sicherheitsproblem wird. Der „Smart Approval“-Klassifikator rief k3 mit einer Temperatur auf, und jeder Aufruf schlug mit 400 fehl. Laut der meldenden Person „stuft er bei jedem Aufruf hoch (Fail-open)“: Die Sicherheitsprüfung erfüllte ihren Zweck nicht mehr, und im Hauptchat sah trotzdem alles normal aus.

K3.1 Pro behält diesen Auslöser bei und fügt einen weiteren hinzu. Klassifikator-Aufrufe sind genau die Anfragen, die Teams durch eine niedrige Temperatur oder deaktiviertes Thinking schnell und günstig machen wollen; bei K3.1 Pro funktioniert beides nicht: Eine Temperatur kann bei jedem Aufruf einen 400-Fehler verursachen, und bei AIHubMix kam eine Anfrage ohne Thinking ohne Reasoning zurück. Wenn eine Sicherheitsprüfung auf K3.1 Pro läuft, verwende reasoning_effort: "low", um die Geschwindigkeit zu erhöhen, lege fest, was bei einem API-Fehler passieren soll, und sorge dafür, dass das System im Fehlerfall geschlossen bleibt.

Für Agenten, die eigenständig handeln, sind noch einige weitere Punkte wichtig:

• Erzwungene Tool-Aufrufe funktionieren. K3.1 Pro unterstützt tool_choice: "required", was K2.x ablehnte. Ein Workaround aus K2.x, um einen Tool-Aufruf zu erzwingen, ist daher nicht mehr nötig.
• Die integrierte Websuche ist noch nicht produktionsreif (K3). Im K3-Leitfaden von Moonshot heißt es, die Websuche „wird derzeit aktualisiert und wird in nächster Zeit nicht für Produktions-Workflows empfohlen“. Behandle sie bei K3.1 Pro genauso, bis Moonshot etwas anderes mitteilt. Über AIHubMix wurde eine K3.1-Pro-Suchschleife am 24. Oktober nicht abgeschlossen: Das Modell forderte $web_search an, und beim Zurücksenden des Ergebnisses kam 400 Invalid request: tokenization failed zurück.
• Bild-Eingaben erfordern Base64. K3 ruft keine öffentlich zugänglichen Bild-URLs ab. Am 24. Oktober lehnte kimi-k3.1-pro auf AIHubMix eine solche URL mit 400 Invalid request: unsupported image url ab. Ein Agent, der Links zu Screenshots übergibt, erhält also einen Fehler. Die andere Möglichkeit von Moonshot, eine Datei-ID aus dem eigenen Datei-Upload, wird von AIHubMix nicht unterstützt: Eine ms://-Referenz gab 404 zurück. Ein Base64-Bild funktionierte. K3.1 Pro akzeptiert in Kimi Code auch Video-Eingaben.

Programmier-Tools: Claude Code und Codex

Claude Code verwendet die Anthropic Messages API, auf die die Haupt-IDs von AIHubMix am 24. Oktober geantwortet haben. Codex verwendet die Responses API, auf die nur der Coding-Kanal geantwortet hat. Installation und Basiskonfiguration werden in den stets aktuellen Leitfäden von AIHubMix behandelt. Im Folgenden geht es nur um die Änderungen für K3.1 Pro.

Die Codex-Spalte verwendet die ID des Coding-Kanals, bis die Haupt-IDs über die Responses API antworten. Jeder Effort-Wert, den ein Tool über diese drei hinaus sendet, wird wie in der obigen Effort-Tabelle zugeordnet.

Claude Code

Folge der Anleitung zu Claude Code settings.json. Lege dann jede Modellstufe fest, nicht nur die Hauptstufe:

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

Bekannte Probleme laut Moonshots Kimi-Code-Dokumentation, Moonshots Claude-Code-Anleitung (verfasst für K3) und den Tests von AIHubMix:

• Starte eine neue Sitzung. Wechsle nicht in einer laufenden K3-Sitzung zu K3.1 Pro. Öffne eine neue Sitzung, damit Cache und Ausgabequalität unbelastet starten.
• Nicht konfigurierte Stufen schlagen unbemerkt fehl. Claude Code verwendet unterschiedliche Stufen für den Hauptchat, Zusammenfassungen und Sub-Agents. Moonshot warnt, dass bei der Konfiguration nur einiger Stufen die übrigen „unbemerkt fehlschlagen“. Für Hintergrundaufgaben kannst du die Haiku-Stufe einem günstigeren Modell zuweisen.
• Veraltete Einstellungen haben Vorrang. Alte Werte im env-Block von ~/.claude/settings.json überschreiben Variablen, die in Ihrer Shell exportiert wurden.
• 1M-Kontext. Moonshots K3-Anleitung verwendet kimi-k3[1m], damit Claude Code das Kontextfenster als 1M behandelt. kimi-k3.1-pro[1m] funktioniert über AIHubMix genauso: Claude Code entfernt das Suffix vor dem Senden, und AIHubMix beantwortete die daraus resultierende Anfrage am 24. Oktober, einschließlich des Headers für 1M-Kontext. Nur Claude Code versteht das Suffix. Wird kimi-k3.1-pro[1m] von einem anderen Client als Modell-ID gesendet, gibt es einen 400-Fehler zurück.
• Effort. K3.1 Pro verwendet standardmäßig bereits max, die Stufe, die Moonshots K3-Anleitung mit CLAUDE_CODE_EFFORT_LEVEL=max empfahl. Bei Routineaufgaben verbraucht high weniger Tokens. Jede Stufe, die Claude Code sendet, wird wie in der Effort-Tabelle zugeordnet; AIHubMix akzeptierte alle fünf getesteten Werte.
• Highspeed-Stufen. Wenn du eine Stufe auf kimi-k3.1-pro-highspeed setzt, kopiere die ID exakt. Bei Kimi Code führt ein Tippfehler unbemerkt zum Fallback; bei AIHubMix gibt eine falsch eingegebene ID einen 400-Fehler zurück.

Codex

Codex unterstützt ausschließlich die Responses API, daher ist wire_api = "responses" erforderlich. Die Anleitung zur Codex-config.toml deckt alles Weitere ab. Für K3.1 Pro gilt:

# 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"

• Lege das Kontextfenster fest. Ohne model_context_window greift Codex auf Standardmetadaten für ein unbekanntes Modell zurück. In Moonshots Codex-Anleitung für K3 wird die daraus resultierende Warnung Model metadata for kimi-k3 not found als erwartet und harmlos bezeichnet.
• Effort. Zu den eigenen Stufen von Codex gehören medium und xhigh. Laut der Zuordnung für Kimi Code werden sie als high und max ausgeführt; AIHubMix akzeptierte am 24. Oktober beide. Lege low, high oder max fest, damit du weißt, für welche Stufe du zahlst.
• Die Kanäle unterscheiden sich. Der Coding-Kanal akzeptierte eine Temperatur, die von den Haupt-IDs abgelehnt wurde. Wenn die Haupt-IDs über Responses antworten, führe den Smoke-Test erneut aus, bevor du wechselst.
• Kein search_context_size. Entferne es, falls deine Konfiguration diesen Wert festlegt (siehe die deutlichen Fehler).
• Starte nach Änderungen neu. Codex liest config.toml nur beim Start ein. Wenn CC Switch deine Codex-Konfiguration verwaltet, überschreibt es möglicherweise deine Änderungen.

Ein 15-minütiger Smoke-Test

Führe diesen Test einmal pro Tool in einem kleinen Repository mit Testsuite aus:

1. Starte eine neue Sitzung mit K3.1 Pro. Setze keine Sitzung fort, in der K3 oder ein anderes Modell verwendet wurde.
2. Bitte: „Füge für eine Funktion in diesem Repository einen Unit-Test hinzu, führe die Tests aus und behebe alle Fehler.“
3. Das sieht nach Erfolg aus: Das Modell liest Dateien und führt die Tests aus (Tool-Aufrufe funktionieren). Nach Anzeige der Ergebnisse arbeitet es weiter – ein Zeichen dafür, dass Reasoning und Tool-Ergebnisse zurückübermittelt werden. Am Ende sind alle Tests erfolgreich, und in der Sitzung gibt es weder einen 400- noch einen 404-Fehler.
4. Prüfe in deinem AIHubMix-Nutzungsprotokoll, ob die Modell-ID der von dir festgelegten entspricht und ob spätere Anfragen für das stabile Präfix zwischengespeicherte Input-Tokens ausweisen. Ist das nie der Fall, ändert sich etwas an deinem Präfix bei jedem Durchlauf.
5. Notiere die Dauer des Durchlaufs und die Completion-Tokens. Sie bilden deine Grundlage für die Wahl der Effort-Stufe und dafür, ob sich Highspeed lohnt.

Migrations-Checkliste

• Verwende die ID von K3.1 Pro: kimi-k3.1-pro bei Moonshots API und AIHubMix, k3.1-pro bei Kimi Code; für Codex über AIHubMix vorerst coding-kimi-k3.1-pro.
• Migriere K2.x-Code, bevor Moonshot die K2-Serie Ende Dezember 2026 einstellt; neue Moonshot-Konten verlieren ab dem 31. Oktober den Zugriff auf K2.
• Starte für K3.1 Pro eine neue Sitzung, statt eine alte zu wechseln.
• Entferne temperature, top_p, n und beide Penalties aus jedem Aufrufpfad, einschließlich Hilfsaufrufen.
• Entferne alle Schalter zum Deaktivieren des Denkens, einschließlich der Effort-Werte off, none und disabled, und lösche übrig gebliebene Thinking-Blöcke von K2.x.
• Sende effort als low, high oder max; medium wird als high und xhigh als max ausgeführt.
• Behalte Modell und Effort innerhalb einer Sitzung unverändert bei.
• Kopiere die Highspeed-ID exakt und überprüfe das Modell in deinem Nutzungsprotokoll.
• Beschränke Stop-Listen auf fünf Einträge mit höchstens 32 Bytes.
• Übermittle die vollständige Assistant-Nachricht zurück, einschließlich reasoning_content und tool_calls, und sende dynamische Tool-Nachrichten erneut.
• Übertrage lange Anfragen im Streaming-Modus und setze Timeouts in Minuten.
• Validiere strukturierte Ausgaben, bevor du JSON zurück zur Messages API verschiebst.
• Aktualisiere die Kostenerfassung für das separate Cache-Write-Feld.
• Sorge dafür, dass Sicherheitsprüfungen bei API-Fehlern standardmäßig fehlschlagen.
• Führe den Smoke-Test in jedem Coding-Tool aus.

FAQ

Warum gibt K3.1 Pro HTTP 400 zurück?
Die üblichen Ursachen sind eine andere Temperatur als 1, deaktiviertes Denken oder ein Effort-Wert wie off, none, disabled oder ein unbekannter Wert. Die erste Ursache geht auf die festen Sampling-Regeln von K3 zurück, die K3.1 Pro beibehält; die anderen sind in Moonshots Kimi-Code-Dokumentation aufgeführt. Bei den Haupt-IDs von AIHubMix führte am 24. Oktober nur die Temperatur zu einem 400-Fehler; die anderen Anfragen gaben 200 zurück, und bei deaktiviertem Denken oder none kam keine Reasoning-Ausgabe zurück.

Kann ich das Denken deaktivieren?
Nein. K3.1 Pro läuft ausschließlich im Thinking-Modus. Setze reasoning_effort auf low, um den Denkprozess kurz zu halten.

Wird temperature weiterhin abgelehnt?
Ja, bei Moonshots API und den Haupt-IDs von AIHubMix, die am 24. Oktober 2026 „invalid temperature: only 1 is allowed for this model“ zurückgaben. Der Coding-Kanal von AIHubMix akzeptierte bei derselben Prüfung eine Temperatur von 0.2. Lasse temperature bei jeder Route weg.

Wann verschwinden die K2-Modelle?
Ab dem 31. Oktober 2026 können neu registrierte Moonshot-Nutzer keine Modelle der K2-Serie mehr verwenden; Moonshot plant, sie alle bis Ende Dezember 2026 einzustellen. AIHubMix führte K2.6 und K2.7 Code am 24. Oktober noch auf, ohne ein Einstellungsdatum anzugeben.

Warum ist mein Kimi-Code-Kontingent schneller aufgebraucht?
K3.1 Pro verwendet standardmäßig max effort, während K3 bei Kimi Code standardmäßig high nutzte. Außerdem wird Highspeed ungefähr doppelt so stark auf das Kontingent angerechnet wie das reguläre Modell. Lege für Routineaufgaben einen niedrigeren Effort fest und behalte ihn innerhalb einer Sitzung bei.

Warum ist Highspeed nicht schneller?
Entweder ist die ID falsch eingegeben – bei Kimi Code wird dann unbemerkt auf K2.8 Preview ohne Thinking zurückgegriffen – oder Tool-Aufrufe machen den größten Teil des Durchlaufs aus. Highspeed beschleunigt nur die Modellausgabe.

Welche AIHubMix-Modell-ID sollte Codex verwenden?
Vorerst coding-kimi-k3.1-pro über die Responses API unter aihubmix.com/v1 mit wire_api auf responses gesetzt. Die Haupt-IDs gaben am 24. Oktober über die Responses API einen 404-Fehler zurück. AIHubMix kennzeichnet den Coding-Kanal als Evaluierungsvorschau, nicht für den Produktionseinsatz.

Weiterlesen: die Kimi-K3.1-Pro-Serie

• Prüfe vor der Migration, ob sich das Upgrade überhaupt lohnt – von den Änderungen bis zu den Kosten einer echten Aufgabe: Kimi K3.1 Pro vs K3: Was sich geändert hat, was es kostet und für wen sich der Wechsel lohnt
• Wenn du wegen der Migration Alternativen abwägst, findest du hier einen Vergleich von K3.1 Pro mit Qwen 4 und Claude Fable 5.5 sowie die Kosten eines Frontend-Builds mit jedem Modell: Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5: Frontend-Qualität, Kosten pro Aufgabe und ein Faktencheck zum Hype
• Wenn dich Kontingent und Preis von Highspeed fragen lassen, ob sich die schnelle Variante lohnt, behandelt ein eigener Beitrag die Frage nach Geschwindigkeit und Preis: Kimi K3.1 Pro vs K3.1 Pro Highspeed: Ist die 2–3× höhere Geschwindigkeit den doppelten Preis wert?

Quellen

• Kimi Code: Modellkonfiguration
• Moonshot AI: Referenz zu Modellparametern
• AIHubMix: Modellseite zu Kimi K3.1 Pro
• AIHubMix: Praxisleitfaden zu Kimi K3
• Hermes-Agent-Issue #142365: Abweichungen beim Kimi-Code-Endpunktprofil