Migrer vers Kimi K3.1 Pro : corriger les erreurs 400, tenir compte du niveau d’effort maximal par défaut et ne pas mal saisir Highspeed

Kimi K3.1 Pro est disponible dans Kimi Code, sur l’API de Moonshot sous le nom kimi-k3.1-pro, et sur AIHubMix avec le même ID. Moonshot lui applique les mêmes contraintes de paramètres qu’à Kimi K3 : le code qui fonctionne déjà sur K3 devrait donc migrer avec un simple changement d’ID de modèle et une nouvelle session. Le code écrit pour K2.x a désormais une échéance sur la plateforme de Moonshot : à partir du 31 October 2026, Moonshot n’autorise plus les nouveaux utilisateurs inscrits à accéder à la série K2 et prévoit de la retirer d’ici la fin décembre. C’est aussi le code le plus susceptible de casser, car il a tendance à envoyer une température ou à désactiver le raisonnement, or aucun des deux n’est compatible avec K3.1 Pro. Enfin, le code qui ne définit jamais de niveau d’effort fonctionne au niveau maximal, ce qui consomme plus de tokens que prévu et, dans Kimi Code, davantage de quota qu’avec K3.

Cet article présente ce qui échoue de façon manifeste (les erreurs 400, plus une erreur 404), ce qui échoue discrètement (la facture, le cache, l’ID Highspeed), et comment configurer Claude Code et Codex pour K3.1 Pro via AIHubMix. Les règles de K3.1 Pro proviennent de la documentation des modèles Kimi Code de Moonshot et de sa référence des paramètres de modèle, qui précise que les deux ID de K3.1 Pro ont « les mêmes contraintes de paramètres que kimi-k3 ». Les règles attribuées à K3 proviennent des guides de Moonshot consacrés à K3 et n’ont pas été revérifiées sur K3.1 Pro. Les textes d’erreur sont cités de la documentation, de signalements publics, du test de K3 réalisé par AIHubMix en juillet et des vérifications de K3.1 Pro effectuées par AIHubMix le 24 October 2026. Ces vérifications ont couvert les ID principaux et les ID du canal de codage coding-kimi-k3.1-pro et coding-kimi-k3.1-pro-highspeed. Chaque affirmation indique sa source.

Quelle voie utilisez-vous ?

Sur l’API de Moonshot et sur AIHubMix, les ID sont kimi-k3.1-pro et kimi-k3.1-pro-highspeed. Dans Kimi Code, ce sont k3.1-pro et k3.1-pro-highspeed. Une configuration client observée le 21 October associait k3 et kimi-for-coding à un modèle k3.1, mais la documentation actuelle de Kimi Code répertorie k3 comme K3 et kimi-for-coding comme K2.8 Preview ; sélectionnez donc explicitement K3.1 Pro. Votre forfait compte aussi : dans Kimi Code, K3.1 Pro nécessite Plus ou supérieur (Pro pour le contexte 1M), et Highspeed nécessite Pro ou supérieur. Avec les anciens forfaits, il faut Moderato ou supérieur, et Allegretto pour le contexte 1M ainsi que pour Highspeed.

Les dates concernant K2 viennent de Moonshot. À partir du 31 October 2026, les modèles de la série K2 ne seront plus accessibles aux nouveaux utilisateurs inscrits, et leur retrait à tous est prévu d’ici la fin décembre 2026. Moonshot n’a annoncé aucune date de retrait pour K3. Le 24 October, AIHubMix répertoriait toujours K2.6 et K2.7 Code, sans date de retrait.

Les échecs manifestes

Raisonnement désactivé : erreur HTTP 400 ou absence totale de raisonnement

Ce que vous verrez : une erreur HTTP 400 dans Kimi Code. La documentation Kimi Code de Moonshot indique que les modèles K3.1 Pro « ne prennent en charge que le mode de raisonnement. Les requêtes avec le raisonnement désactivé sont rejetées. » La documentation ne donne pas le corps de l’erreur. Sur l’API de Moonshot, K3.1 Pro reprend les contraintes de K3, qui raisonne toujours. Via AIHubMix, il n’y a pas d’erreur 400 : le 24 October, thinking: {"type": "disabled"} a renvoyé le code 200 avec les deux ID principaux, sur Chat Completions et Messages, sans raisonnement dans la réponse. L’échec est donc silencieux : vérifiez que les réponses contiennent bien un raisonnement.

Origine : le code K2.x qui désactivait le raisonnement pour répondre plus vite, par exemple avec extra_body={"thinking": {"type": "disabled"}}, ainsi que les outils qui envoient un niveau d’effort off, none ou disabled (section suivante).

Correctif : supprimez cette option. Pour limiter la durée du raisonnement, envoyez plutôt reasoning_effort: "low".

Un bloc « enabled » résiduel est un cas différent. Lors de sa vérification du 24 October, AIHubMix a envoyé le bloc thinking: {"type": "enabled"} de K2.x à K3.1 Pro et obtenu le code 200, avec les ID principaux comme sur le canal de codage. La documentation de Moonshot qualifie thinking de « paramètre de requête réservé à K2.x », et un guide de dépannage tiers cite la présence d’un bloc résiduel comme cause d’erreurs 400 après le passage de K2.x à K3 : supprimez-le malgré tout.

Si vous gardez K2.7 Code comme solution de repli jusqu’à son retrait, laissez le raisonnement activé. Le guide de Moonshot consacré à Claude Code documente l’erreur 400 invalid thinking: only type=enabled is allowed for this model pour K2.7 Code lorsque le raisonnement est désactivé.

Valeurs d’effort : off, none et les valeurs non reconnues renvoient une erreur 400

Ce que vous verrez : une erreur HTTP 400 si le niveau d’effort est off, none, disabled ou une valeur que Kimi Code ne reconnaît pas. K3.1 Pro propose trois niveaux : low, high et max. La documentation Kimi Code de Moonshot indique comment ils correspondent aux valeurs envoyées par les outils tiers :

Pour K3.1 Pro, l’API de Moonshot ne documente que low, high et max, avec max comme valeur par défaut, sans décrire de correspondance. Sur AIHubMix, le 24 October, low, medium, high, max et xhigh ont tous renvoyé le code 200 avec les quatre ID de K3.1 Pro. Avec kimi-k3.1-pro, off et une valeur non reconnue ont aussi renvoyé le code 200, avec raisonnement, tandis que none a renvoyé le code 200 sans aucun raisonnement. Sur AIHubMix, ces cas échouent silencieusement au lieu de renvoyer une erreur 400.

Le problème moins visible : il n’existe pas de niveau medium. Un outil réglé sur medium utilise high, et un outil réglé sur xhigh utilise max, le niveau le plus coûteux.

Correctif : envoyez explicitement low, high ou max, et vérifiez ce que votre outil envoie réellement.

« température non valide : seule la valeur 1 est autorisée pour ce modèle »

Ce que vous verrez : 400 invalid temperature: only 1 is allowed for this model. Lors de sa vérification du 24 October, AIHubMix a obtenu exactement ce message de kimi-k3.1-pro et kimi-k3.1-pro-highspeed après avoir envoyé temperature: 0.2. Le même message avait été signalé sur l’API de Moonshot pour K3 le 3 October 2026, et sur l’endpoint Kimi Code pour k3 le 21 October.

Pourquoi : la référence des paramètres de Moonshot applique à K3.1 Pro les contraintes de K3 : température fixée à 1.0, top_p à 0.95, n à 1 et les deux pénalités à 0 ; toute autre valeur renvoie une erreur. K2.6 avait aussi une valeur fixe, 0.6 lorsque le raisonnement était désactivé : le code qui envoie encore 0.6 est donc le suspect habituel.

L’exception qui masque le problème : lors de la même vérification, le canal de codage d’AIHubMix a accepté temperature: 0.2. Du code testé uniquement sur ce canal peut donc encore échouer avec les ID principaux ou sur l’API de Moonshot.

Le piège qui le masque encore davantage : de nombreux frameworks reconnaissent les modèles Kimi grâce au préfixe kimi- et suppriment le paramètre de température. Les ID Kimi Code k3.1-pro et k3.1-pro-highspeed n’ont pas ce préfixe, pas plus que les ID du canal de codage d’AIHubMix, qui commencent par coding-. Un problème signalé dans Hermes Agent a révélé exactement ce cas avec K3. Le chemin de conversation principal omettait la température, mais un appel auxiliaire à k3 en envoyait toujours une et obtenait systématiquement l’erreur 400.

Correctif : n’envoyez aucun des paramètres temperature, top_p, n, presence_penalty ou frequency_penalty. Identifiez la famille du modèle, et non un préfixe de nom.

Pour vérifier une route, envoyez une requête avec une température :

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

Le 24 October, cette requête a renvoyé l’erreur 400 ci-dessus. Exécutez-la avec chaque ID de modèle utilisé par votre code : le canal de codage a répondu 200 à la même requête.

Codex via AIHubMix : erreur 404 sur l’API Responses

Ce que vous verrez : une erreur HTTP 404 avec le message The model kimi-k3.1-pro is not available on this endpoint.. Lors de sa vérification du 24 October, AIHubMix l’a obtenue avec l’API Responses pour les deux ID principaux, tandis que Chat Completions et Messages répondaient normalement.

Correctif : Codex ne prend en charge que l’API Responses ; indiquez donc coding-kimi-k3.1-pro, qui a répondu aux requêtes Responses lors de la même vérification. AIHubMix présente le canal de codage comme une préversion d’évaluation déconseillée en production ; quelques requêtes ont renvoyé une erreur 404 temporaire, « The requested resource was not found ». Réessayez une fois avant d’entamer le débogage. Utilisez ce canal jusqu’à ce qu’AIHubMix ajoute la prise en charge de l’API Responses pour les ID principaux. Claude Code utilise Messages et fonctionne avec les ID principaux.

Limites de stop

Ce que vous verrez : le test de K3 réalisé par AIHubMix en juillet a renvoyé les deux messages suivants :

• 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

Pourquoi : K3 accepte au maximum cinq séquences d’arrêt, chacune pouvant faire jusqu’à 32 octets, et l’API Messages applique les mêmes limites à stop_sequences. Moonshot impose les mêmes contraintes de paramètres à K3.1 Pro ; attendez-vous donc aux mêmes limites.

Correctif : réduisez la liste. Notez que 32 octets représentent moins de 32 caractères en chinois ou en japonais.

Codex sur l’API de Moonshot : « web_search.search_context_size is not supported » (guide K3)

Ce que vous verrez : 400 web_search.search_context_size is not supported, cité du guide Codex de Moonshot, rédigé pour K3. Via le canal de codage d’AIHubMix, une requête Responses contenant ce champ a renvoyé le code 200 le 24 October ; cette erreur provient donc de l’endpoint de Moonshot.

Correctif : supprimez search_context_size de la configuration Codex ou de la définition de l’outil. Codex ne l’envoie pas par défaut.

Les échecs silencieux

Ils ne renvoient pas d’erreur. Vous les remarquerez plus tard, sur la facture, dans le quota de votre forfait ou dans la qualité des réponses.

Niveau d’effort et sessions

• Le niveau maximal est celui par défaut, et c’est nouveau dans Kimi Code. K3.1 Pro utilise max par défaut. Dans Kimi Code, K3 utilisait high par défaut ; une session qui ne définit jamais de niveau d’effort raisonne donc davantage, consomme plus de tokens et épuise le quota plus vite. Sur l’API de Moonshot, K3 et K3.1 Pro utilisent tous deux max par défaut. Le raisonnement est facturé comme une sortie : lors du test de création d’un jeu à partir d’une seule invite, effectué par AIHubMix sur K3 en juillet, le raisonnement représentait 73% des 74,994 tokens de complétion.
• Un faible niveau d’effort peut tout de même générer des milliers de tokens de réflexion. Lors d’un contrôle ponctuel effectué sur AIHubMix le 24 octobre, une consigne demandant une explication de 600 mots a amené K3.1 Pro à raisonner pendant 5,561 à 7,356 tokens avec low avant de répondre, et une exécution a atteint la limite de 8,192 tokens. K3 a raisonné pendant 3,013 à 7,051 tokens sur la même consigne : ce comportement n’est donc pas nouveau avec K3.1 Pro, mais low n’est pas un mode économique pour l’un ou l’autre ; prévoyez une valeur généreuse pour max_completion_tokens. Il ne s’agit que d’une consigne et de trois exécutions par modèle sur les principaux ID d’AIHubMix : faites des mesures sur votre propre charge de travail.
• Passer à K3.1 Pro au milieu d’une ancienne session nuit à la qualité. La documentation Kimi Code de Moonshot déconseille de passer aux nouveaux modèles « au sein d’une session K3 existante, K2.8 Preview ou K2.7 Code Highspeed » : cela dégrade la qualité des réponses et réduit les succès du cache. Démarrez une nouvelle session.
• Changer de modèle ou de niveau d’effort invalide le cache. La documentation Kimi Code de Moonshot le précise pour les deux, et la documentation de K3 indiquait que changer de niveau d’effort « invalide les succès du cache de préfixe ». Choisissez le modèle et le niveau au démarrage de la session.

Highspeed

• Une faute de frappe dans l’ID Highspeed vous fait utiliser un modèle plus lent. Dans Kimi Code, un ID Highspeed incorrect « bascule silencieusement vers K2.8 Preview, sans réflexion — aucun gain de vitesse ». Copiez l’ID à l’identique et vérifiez dans vos journaux quel modèle a été utilisé.
• Highspeed accélère uniquement la génération du modèle. Moonshot indique que K3.1 Pro Highspeed est environ 2–3× plus rapide que K3.1 Pro, avec des capacités identiques. Lors du contrôle ponctuel d’AIHubMix, sa génération était environ 1.6–1.8× plus rapide que celle de Pro. Les appels d’outils et les scripts ne sont pas accélérés du tout : le gain est donc faible lors d’un tour principalement consacré à la lecture de fichiers et à l’exécution de tests, tandis que les plans Kimi Code consomment environ deux fois plus de quota.

Protocoles

• Les proxys peuvent modifier le comportement. La documentation Kimi Code de Moonshot avertit : « La traduction de protocole par des outils proxy peut entraîner des variations du comportement du modèle. » Utilisez pour chaque outil le protocole qu’il prend en charge : Messages pour Claude Code, Responses pour Codex. Le 24 octobre, AIHubMix a renvoyé le raisonnement, sous forme de reasoning_content et de blocs thinking, avec Chat Completions et Messages sur les quatre ID K3.1 Pro. Responses fonctionnait sur le canal coding, avec un élément reasoning, et renvoyait l’erreur 404 mentionnée plus haut sur les principaux ID.
• La sortie structurée de l’API Messages s’est améliorée. Lors du test de K3 effectué par AIHubMix en juillet, /v1/messages ignorait un schéma et renvoyait du texte libre. Le 24 octobre, une requête du même type adressée à K3.1 Pro, avec un schéma JSON dans output_config.format et une consigne qui ne demandait pas de JSON, a renvoyé {"city":"Paris"} sur les quatre ID. Il ne s’agit que d’un schéma à un champ : validez la sortie avant de réutiliser JSON avec Messages. L’autre particularité de Messages observée en juillet — un arrêt sur séquence renvoyé sous la forme end_turn avec stop_sequence: null — n’a pas été retestée.

Requêtes longues

• Des délais d’expiration courts font échouer même des requêtes assez modestes. Lors du contrôle ponctuel, les réponses complètes de K3.1 Pro avec low ont pris 80 à 99 secondes. Un client sans streaming avec un délai d’expiration de 60 secondes aurait échoué à chaque exécution, et une nouvelle tentative aurait de nouveau facturé le même raisonnement. Sur l’API de Moonshot, la limite de sortie par défaut de K3.1 Pro est de 131,072 tokens, avec un maximum de 1,048,576, et la génération d’un jeu sur K3 par AIHubMix en juillet a duré 2,541 secondes en une seule requête. Utilisez le streaming et réglez les délais d’expiration en minutes.

Points repris des guides K3

Voici les points tirés des guides K3 :

• Supprimer reasoning_content dégrade la qualité des échanges à plusieurs tours. Le message complet de l’assistant, y compris reasoning_content et tool_calls, doit être renvoyé sans modification. Le code qui ne conserve que content continue de fonctionner, mais Moonshot avertit que la qualité des réponses devient instable.
• Si vous supprimez le message des outils dynamiques, ceux-ci disparaissent. K3 permet de charger des outils en cours de conversation au moyen d’un message système sans contenu. Le serveur ne le conserve pas : il faut donc le renvoyer à chaque requête. Sur AIHubMix, cela fonctionne avec Chat Completions : le 24 octobre, kimi-k3.1-pro a appelé un outil injecté de cette manière. Lors du test de K3 par AIHubMix en juillet, l’API Messages ignorait un outil injecté.

Règles de facturation faciles à manquer

Les tarifs ci-dessous sont ceux d’AIHubMix, tirés de ses pages de modèles, par million de tokens :

Sur AIHubMix, K3.1 Pro coûte 30% moins cher que K3 pour les entrées et les entrées mises en cache, et 26% moins cher pour les sorties. Highspeed coûte deux fois plus cher que Pro pour les entrées et les sorties, au même tarif pour les entrées mises en cache. L’ID du canal coding a une tarification distincte : $0.88 pour les entrées, $3.23 pour les sorties et $0.132 pour les entrées mises en cache.

Un tarif inférieur ne garantit pas une facture moins élevée. Prenons la génération d’un jeu à partir d’une seule consigne sur K3, testée par AIHubMix en juillet : 74,994 tokens de sortie, en supposant 5,000 tokens d’entrée. Pour les mêmes nombres de tokens, le coût est d’environ $1.08 sur K3, $0.80 sur K3.1 Pro (5,000 × $2.00 + 74,994 × $10.50, par million) et $1.59 sur Highspeed. Le nombre de tokens varie selon la consigne (le contrôle ponctuel plaçait K3.1 Pro et K3 dans la même fourchette avec low) : faites des mesures avant d’établir votre budget.

La documentation de l’API Moonshot facture les écritures dans le cache de K3.1 Pro en fonction du TTL, de 5 minutes ou de 1 heure, comme pour K3. Les tarifs publiés de K3, tirés du guide de mise en cache du contexte de Moonshot, illustrent le fonctionnement :

Moonshot indique que la facturation distincte des écritures dans le cache n’a pas augmenté le coût total de K3 : leur coût était déjà inclus dans le prix des entrées. Les requêtes utilisant le TTL par défaut de 5 minutes coûtent donc autant qu’avant.

Il s’agit des tarifs directs de Moonshot. Les pages de modèles d’AIHubMix n’indiquent que les prix des entrées, des sorties et des entrées mises en cache, sans tarif distinct pour les écritures dans le cache, et ne précisent pas comment est facturée une écriture avec un TTL de 1 heure. AIHubMix transmet bien le TTL : le 24 octobre, une requête Messages avec un TTL cache_control de premier niveau réglé sur 1h a indiqué son écriture comme des tokens de cache d’une heure, et une requête Chat Completions avec prompt_cache_options a été acceptée.

• La mise en cache est automatique. Pour K3, le TTL par défaut est de 5 minutes. Lors des vérifications d’AIHubMix le 24 octobre, une requête répétée de 93 tokens a été entièrement mise en cache sur le canal coding, mais pas sur les principaux ID. Avec une requête de 7,658 tokens, le deuxième appel à kimi-k3.1-pro a renvoyé 7,424 tokens mis en cache, avec Chat Completions comme avec Messages.
• Le TTL de 1 heure, sur l’API de Moonshot, coûte $3.00 de plus par million de tokens à écrire, aux tarifs de K3. Chaque succès du cache permet d’économiser $2.70 : selon les calculs de Moonshot, l’opération devient donc rentable dès le deuxième succès.
• Le TTL est fixé à la première écriture (K3). Vous ne pouvez pas prolonger une entrée de 5 minutes à une heure. Vous devez d’abord attendre son expiration.
• Les tableaux de bord des coûts ont besoin d’un nouveau champ (K3). Les écritures dans le cache apparaissent sous prompt_tokens_details.cache_write_tokens dans Chat Completions, input_tokens_details.cache_write_tokens dans Responses et cache_creation_input_tokens dans Messages.
• Le raisonnement est comptabilisé comme une sortie. Pour K3, les tokens de réflexion sont facturés au tarif des sorties, quel que soit le niveau d’effort. AIHubMix n’indique pas de tarif distinct pour le raisonnement de K3.1 Pro.

Étapes pour réduire la facture :

1. Définissez reasoning_effort pour chaque charge de travail, au lieu de reprendre max. Essayez low pour les recherches rapides et la classification, et high pour les tâches de programmation courantes.
2. Gardez le modèle et le niveau d’effort fixes pour chaque session, et démarrez une nouvelle session si vous changez l’un ou l’autre.
3. Placez d’abord les éléments stables : la consigne système, les définitions des outils et le contexte du dépôt. Ajoutez ensuite le tour qui change.
4. Utilisez Highspeed lorsque l’attente de la sortie du modèle constitue le goulot d’étranglement, et non pour les boucles dominées par les appels d’outils.
5. Surveillez la part du raisonnement dans les tokens de complétion. Si elle dépasse constamment la moitié pour des tâches simples, réduisez le niveau d’effort.

Agents dotés de véritables autorisations

Le problème signalé avec Hermes Agent montre comment un bug de migration peut devenir un problème de sécurité. Son classificateur « smart approval » appelait k3 avec une température, et chaque appel renvoyait une erreur 400. Selon la personne ayant signalé le problème, le classificateur « passe en mode d’autorisation (fail-open) à chaque appel » : le contrôle de sécurité ne remplissait plus son rôle, sans que rien ne semble anormal dans la conversation principale.

K3.1 Pro conserve ce déclencheur et en ajoute un autre. Les appels de classificateur sont précisément ceux que les équipes rendent rapides et peu coûteux en réglant une température basse ou en désactivant la réflexion, et aucune de ces deux options ne fonctionne sur K3.1 Pro : la température peut renvoyer une erreur 400 à chaque appel, et sur AIHubMix, une requête sans réflexion est revenue sans raisonnement. Si un contrôle de sécurité s’exécute sur K3.1 Pro, utilisez reasoning_effort: "low" pour accélérer les choses, décidez du comportement en cas d’erreur de l’API et faites échouer le contrôle par défaut.

Quelques autres points comptent pour les agents qui agissent de manière autonome :

• Les appels forcés d’outils fonctionnent. K3.1 Pro prend en charge tool_choice: "required", que K2.x rejetait. Vous pouvez donc abandonner les solutions de contournement utilisées avec K2.x pour forcer un appel d’outil.
• La recherche Web intégrée n’est pas prête pour la production (K3). Le guide K3 de Moonshot indique que sa recherche Web « est en cours de mise à jour et n’est pas recommandée pour les workflows de production à court terme ». Partez du même principe pour K3.1 Pro, jusqu’à ce que Moonshot indique le contraire. Via AIHubMix, une boucle de recherche avec K3.1 Pro n’a pas abouti le 24 octobre : le modèle a demandé $web_search, et le renvoi du résultat a produit 400 Invalid request: tokenization failed.
• Les images doivent être encodées en base64. K3 ne récupère pas les images à partir d’URL publiques, et le 24 octobre, kimi-k3.1-pro sur AIHubMix en a rejeté une avec 400 Invalid request: unsupported image url : un agent qui transmet des liens vers des captures d’écran obtient donc une erreur. L’autre option de Moonshot, un ID de fichier obtenu par son propre service de téléversement, n’est pas prise en charge par AIHubMix : une référence ms:// a renvoyé une erreur 404. Une image en base64 a fonctionné. K3.1 Pro accepte également les entrées vidéo dans Kimi Code.

Outils de programmation : Claude Code et Codex

Claude Code utilise l’API Anthropic Messages, à laquelle les principaux ID d’AIHubMix ont répondu le 24 octobre. Codex utilise l’API Responses, à laquelle seul le canal coding a répondu. Les guides pérennes d’AIHubMix couvrent l’installation et la configuration de base. Voici uniquement les changements propres à K3.1 Pro.

La colonne Codex utilise l’identifiant du canal coding jusqu’à ce que les identifiants principaux répondent sur l’API Responses. Toute valeur d’effort envoyée par un outil en dehors de ces trois valeurs est convertie comme indiqué dans le tableau des niveaux d’effort ci-dessus.

Claude Code

Suivez le guide de configuration de Claude Code dans settings.json. Définissez ensuite chaque niveau de modèle, pas seulement le principal :

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

Problèmes connus, d’après la documentation Kimi Code de Moonshot, son guide Claude Code (rédigé pour K3) et les tests d’AIHubMix :

• Démarrez une nouvelle session. Ne faites pas passer une session K3 en cours à K3.1 Pro. Ouvrez-en une nouvelle pour repartir avec un cache et une qualité de sortie vierges.
• Les niveaux non configurés échouent sans avertissement. Claude Code utilise différents niveaux pour la conversation principale, les résumés et les sous-agents. Moonshot avertit que si vous n’en configurez que certains, les autres « échouent sans avertissement ». Vous pouvez attribuer un modèle moins coûteux au niveau Haiku pour les tâches en arrière-plan.
• Les paramètres obsolètes l’emportent. Les anciennes valeurs du bloc env de ~/.claude/settings.json prennent le dessus sur les variables exportées dans votre shell.
• Contexte de 1M. Le guide K3 de Moonshot utilise kimi-k3[1m] pour que Claude Code considère la fenêtre de contexte comme faisant 1M. kimi-k3.1-pro[1m] fonctionne de la même façon avec AIHubMix : Claude Code supprime le suffixe avant l’envoi, et AIHubMix a répondu à la requête ainsi obtenue, avec l’en-tête de contexte 1M, le 24 octobre. Seul Claude Code comprend ce suffixe. Envoyé comme identifiant de modèle depuis n’importe quel autre client, kimi-k3.1-pro[1m] renvoie une erreur 400.
• Niveau d’effort. K3.1 Pro utilise déjà max par défaut, le niveau que le guide K3 de Moonshot recommandait avec CLAUDE_CODE_EFFORT_LEVEL=max. Pour les tâches courantes, high consomme moins de jetons. Quel que soit le niveau envoyé par Claude Code, il est converti comme indiqué dans le tableau des niveaux d’effort, et AIHubMix a accepté les cinq valeurs testées.
• Niveaux Highspeed. Si vous attribuez le modèle kimi-k3.1-pro-highspeed à un niveau, recopiez l’identifiant à l’identique. Dans Kimi Code, une faute de frappe entraîne silencieusement un repli vers un autre modèle ; sur AIHubMix, un identifiant mal saisi renvoie une erreur 400.

Codex

Codex ne prend en charge que l’API Responses : wire_api = "responses" est donc obligatoire. Le guide de configuration config.toml de Codex explique le reste. Pour 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"

• Déclarez la fenêtre de contexte. Sans model_context_window, Codex utilise les métadonnées par défaut d’un modèle qu’il ne connaît pas. Le guide Codex de Moonshot, rédigé pour K3, indique que l’avertissement Model metadata for kimi-k3 not found qui en résulte est attendu et sans conséquence.
• Niveau d’effort. Les niveaux propres à Codex comprennent medium et xhigh. Selon la correspondance de Kimi Code, ils sont exécutés respectivement comme high et max, et AIHubMix a accepté les deux le 24 octobre. Définissez low, high ou max pour savoir quel niveau vous payez.
• Les canaux diffèrent. Le canal coding a accepté une température rejetée par les identifiants principaux. Lorsque les identifiants principaux commenceront à répondre sur Responses, relancez le test rapide avant de basculer.
• Pas de search_context_size. Si votre configuration le définit, supprimez-le (voir les erreurs explicites).
• Redémarrez après les modifications. Codex ne lit config.toml qu’au démarrage. Si CC Switch gère votre configuration Codex, il risque d’écraser vos modifications.

Un test rapide de 15 minutes

Effectuez-le une fois avec chaque outil, dans un petit dépôt doté d’une suite de tests :

1. Démarrez une nouvelle session avec K3.1 Pro. Ne reprenez pas une session qui utilisait K3 ou un autre modèle.
2. Demandez : « Ajoute un test unitaire pour une fonction de ce dépôt, exécute les tests et corrige tout échec. »
3. Voici à quoi ressemble une exécution réussie : le modèle lit des fichiers et lance les tests (les appels d’outils fonctionnent). Il poursuit après avoir pris connaissance des résultats, ce qui montre que le raisonnement et les résultats des outils lui sont bien renvoyés. Les tests finissent par réussir, et aucune erreur 400 ou 404 n’apparaît dans la session.
4. Dans le journal d’utilisation d’AIHubMix, vérifiez que l’identifiant de modèle est bien celui que vous avez défini et que les requêtes suivantes affichent des jetons d’entrée mis en cache pour le préfixe stable. Si ce n’est jamais le cas, un élément de votre préfixe change à chaque tour.
5. Notez la durée du tour et le nombre de jetons générés. Ces valeurs vous serviront de référence pour choisir un niveau d’effort et évaluer si Highspeed en vaut la peine.

Liste de contrôle de migration

• Utilisez l’identifiant de K3.1 Pro : kimi-k3.1-pro sur l’API de Moonshot et AIHubMix, k3.1-pro dans Kimi Code ; pour Codex via AIHubMix, utilisez coding-kimi-k3.1-pro pour le moment.
• Migrez le code K2.x avant que Moonshot ne retire la série K2 à la fin de décembre 2026 ; les nouveaux comptes Moonshot perdent l’accès à K2 à partir du 31 octobre.
• Démarrez une nouvelle session pour K3.1 Pro au lieu de basculer une ancienne session.
• Supprimez temperature, top_p, n et les deux pénalités de tous les chemins d’appel, y compris les appels auxiliaires.
• Supprimez tous les paramètres de désactivation du raisonnement, y compris les valeurs d’effort off, none et disabled, ainsi que les blocs de raisonnement K2.x restants.
• Envoyez l’effort sous la forme low, high ou max ; medium est exécuté comme high, et xhigh comme max.
• Gardez le modèle et le niveau d’effort fixes pendant toute une session.
• Recopiez l’identifiant Highspeed à l’identique et vérifiez le modèle dans votre journal d’utilisation.
• Limitez les listes d’arrêt à cinq entrées de 32 octets maximum.
• Renvoyez le message complet de l’assistant, y compris reasoning_content et tool_calls, et renvoyez les messages d’outil dynamiques.
• Diffusez les longues requêtes en continu et définissez les délais d’expiration en minutes.
• Validez la sortie structurée avant de renvoyer le JSON vers l’API Messages.
• Mettez à jour le suivi des coûts pour tenir compte du champ distinct des écritures en cache.
• En cas d’erreur d’API, faites en sorte que les contrôles de sécurité échouent de manière sûre.
• Effectuez le test rapide dans chaque outil de programmation.

FAQ

Pourquoi K3.1 Pro renvoie-t-il une erreur HTTP 400 ?
Les causes les plus courantes sont une température différente de 1, la désactivation du raisonnement ou une valeur d’effort off, none, disabled ou inconnue. La première est due aux règles d’échantillonnage fixes de K3, conservées dans K3.1 Pro ; les autres sont documentées dans la documentation Kimi Code de Moonshot. Sur les identifiants principaux d’AIHubMix, seule la température a renvoyé une erreur 400 le 24 octobre ; les autres requêtes ont renvoyé 200, et la désactivation du raisonnement ou la valeur none a produit une réponse sans raisonnement.

Puis-je désactiver le raisonnement ?
Non. K3.1 Pro ne fonctionne qu’en mode raisonnement. Définissez reasoning_effort sur low pour limiter la durée du raisonnement.

La température est-elle toujours rejetée ?
Oui, sur l’API de Moonshot et sur les identifiants principaux d’AIHubMix, qui ont renvoyé « invalid temperature: only 1 is allowed for this model » le 24 octobre 2026. Lors du même test, le canal coding d’AIHubMix a accepté une température de 0.2. Omettez la température sur toutes les routes.

Quand les modèles K2 vont-ils disparaître ?
À partir du 31 octobre 2026, les nouveaux utilisateurs inscrits chez Moonshot ne pourront plus utiliser les modèles de la série K2, et Moonshot prévoit de tous les retirer d’ici la fin de décembre 2026. AIHubMix proposait encore K2.6 et K2.7 Code le 24 octobre, sans date de retrait annoncée.

Pourquoi mon quota Kimi Code s’épuise-t-il plus vite ?
K3.1 Pro utilise par défaut le niveau d’effort max, alors que K3 utilisait high par défaut dans Kimi Code, et Highspeed consomme environ deux fois plus de quota que le modèle standard. Choisissez un niveau d’effort inférieur pour les tâches courantes et gardez-le fixe pendant toute une session.

Pourquoi Highspeed n’est-il pas plus rapide ?
L’identifiant est peut-être mal saisi : dans Kimi Code, cela entraîne silencieusement un repli vers K2.8 Preview sans raisonnement. Il se peut aussi que les appels d’outils dominent la durée du tour. Highspeed n’accélère que la génération du modèle.

Quel identifiant de modèle AIHubMix Codex doit-il utiliser ?
coding-kimi-k3.1-pro pour le moment, sur l’API Responses à l’adresse aihubmix.com/v1, avec wire_api défini sur responses. Le 24 octobre, les identifiants principaux ont renvoyé une erreur 404 sur l’API Responses. AIHubMix présente le canal coding comme une version d’évaluation préliminaire, non destinée à la production.

Poursuivre la lecture : la série Kimi K3.1 Pro

• Avant de migrer, vérifiez si la mise à niveau en vaut vraiment la peine, des changements apportés au coût d’une tâche réelle : Kimi K3.1 Pro vs K3 : les nouveautés, le coût et les utilisateurs concernés par le changement
• Si cette migration vous amène à envisager d’autres options, voici une comparaison de K3.1 Pro avec Qwen 4 et Claude Fable 5.5, avec le coût d’une création front-end sur chaque modèle : Kimi K3.1 Pro vs Qwen 4 vs Claude Fable 5.5 : qualité front-end, coût par tâche et examen des promesses
• Si le quota et le prix de Highspeed vous font vous demander si la variante rapide en vaut le coût, la question du rapport entre vitesse et prix fait l’objet d’un article dédié : Kimi K3.1 Pro vs K3.1 Pro Highspeed : une vitesse multipliée par 2–3 vaut-elle un prix multiplié par 2 ?

Sources

• Kimi Code : configuration du modèle
• Moonshot AI : référence des paramètres du modèle
• AIHubMix : page du modèle Kimi K3.1 Pro
• AIHubMix : guide pratique de Kimi K3
• Problème Hermes Agent #142365 : dérive du profil du point de terminaison Kimi Code