Fin de l’API Kimi K2 : migrer K2.7 Code vers K3.1 Pro

Migrez les applications qui utilisent kimi-k2.6 et kimi-k2.7-code vers kimi-k3.1-pro avant le retrait prévu fin décembre 2026. Définissez explicitement l’effort de raisonnement et le plafond de génération. Avant de basculer le trafic de production, vérifiez ensuite l’historique des appels d’outils et les frais de cache. Au 2026-11-05, les restrictions pour les nouveaux comptes sont déjà actives.

Quand l’API Kimi K2 cessera-t-elle de fonctionner ?

Les comptes existants éligibles conservent leur accès pour le moment. Ces avis ne donnent ni jour ni heure exacts pour l’arrêt.

L’avis sur la page des tarifs indique que K2 est indisponible pour les nouveaux inscrits depuis le 31 octobre 2026. Le retrait de tous les modèles K2 est prévu d’ici fin décembre 2026.

La liste actuelle des modèles emploie une formulation légèrement différente. Les utilisateurs inscrits avant le 1er novembre peuvent continuer à utiliser kimi-k2.6, kimi-k2.7-code et kimi-k2.7-code-highspeed. Leur retrait est attendu fin décembre 2026.

Si vous vous êtes inscrit autour de ces dates, vérifiez l’accès réel de votre compte. Ces formulations ne définissent pas un instant précis de coupure. Pour une nouvelle intégration, commencez directement avec K3.1 Pro.

Ne supposez pas que tous les échecs d’accès à K2 renvoient la même erreur. Le journal des modifications d’août confirme 404 « model not found » pour les modèles retirés kimi-k2.5 et moonshot-v1. Cette indication ne précise pas la réponse que renverra l’API lors du retrait de K2.6 ou K2.7 Code.

Adaptez les requêtes avant de basculer le trafic

Mettez à jour ensemble le corps des requêtes et le stockage des conversations. Le comparatif des paramètres Kimi décrit des différences qu’un simple remplacement du nom de modèle peut laisser passer.

Paramètre	`kimi-k2.6`	`kimi-k2.7-code`	`kimi-k3.1-pro`
Raisonnement	Activé par défaut ; peut être désactivé	Toujours activé	Toujours activé ; supprimez l’objet `thinking` de K2
`reasoning_effort`	Non pris en charge	Non pris en charge	Champ au premier niveau : `low`, `high` ou `max` ; valeur par défaut : `max`
`temperature`	Fixée à `1.0` avec raisonnement ; à `0.6` sans raisonnement	Fixée à `1.0`	Fixée à `1.0` ; omettez ce champ
Plafond de génération documenté par défaut	`max_tokens` : `32768`	`max_tokens` : `32768`	`max_completion_tokens` : `131072`

K2.7 Code imposait déjà le raisonnement et en conservait l’historique. Le changement est donc plus important pour les applications qui utilisaient K2.6 sans raisonnement.

Le guide de démarrage de K3.1 Pro fixe aussi top_p=0.95, n=1, presence_penalty=0 et frequency_penalty=0. Omettez ces champs ainsi que temperature. Vérifiez aussi les valeurs par défaut du client : il peut ajouter un paramètre d’échantillonnage que votre application n’a jamais défini.

Pour les nouvelles requêtes Chat Completions, utilisez max_completion_tokens. La référence de l’API marque max_tokens comme obsolète, sans annoncer sa suppression. K3.1 Pro accepte une valeur maximale de 1048576, dans la limite de l’espace disponible dans le contexte.

Un plafond de génération fixe une limite supérieure. Il ne signifie pas que chaque requête consommera autant de tokens. Choisissez une limite adaptée à la tâche au lieu de conserver la valeur par défaut, plus élevée.

Pour l’effort de raisonnement, commencez avec low pour vérifier la connexion ou rechercher une information précise. Essayez high pour les tâches de programmation courantes. Utilisez max si vos tests de non-régression justifient un raisonnement supplémentaire. low réduit l’effort sans désactiver le raisonnement.

Testez l’API et les appels d’outils avec une limite de génération

Testez directement l’API avant de déboguer la configuration d’un agent.

Créez une clé API sur Global Kimi Open Platform. Au 2026-11-05, les conditions d’accès exigent un rechargement réussi d’au moins $1. Utilisez une clé de la plateforme correspondant à https://api.moonshot.ai. Pour les erreurs de compte Kimi Code, commencez par le guide distinct sur les limites de Kimi Code.

Dans Bash, saisissez la clé sans l’afficher :

read -rs MOONSHOT_API_KEY && export MOONSHOT_API_KEY

La commande Bash suivante utilise la bibliothèque standard de Python 3. Elle envoie deux requêtes facturables et exécute une fonction de multiplication en local. Le plafond de génération 4096 concerne ce test arithmétique ; il ne sert pas de budget général pour les tâches de programmation.

python3 - <<'PY'
import json
import os
import urllib.error
import urllib.request

tools = [{
    "type": "function",
    "function": {
        "name": "multiply",
        "description": "Multiply two integers.",
        "parameters": {
            "type": "object",
            "properties": {
                "a": {"type": "integer"},
                "b": {"type": "integer"}
            },
            "required": ["a", "b"],
            "additionalProperties": False
        }
    }
}]

def chat(messages, choice):
    payload = {
        "model": "kimi-k3.1-pro",
        "messages": messages,
        "reasoning_effort": "low",
        "max_completion_tokens": 4096,
        "tools": tools,
        "tool_choice": choice
    }
    request = urllib.request.Request(
        "https://api.moonshot.ai/v1/chat/completions",
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "Authorization": "Bearer " + os.environ["MOONSHOT_API_KEY"],
            "Content-Type": "application/json"
        },
        method="POST"
    )
    try:
        with urllib.request.urlopen(request, timeout=120) as response:
            data = json.load(response)
    except urllib.error.HTTPError as error:
        raise SystemExit(f"HTTP {error.code}: check access and request parameters.")
    if data.get("model") != "kimi-k3.1-pro":
        raise RuntimeError("Unexpected response model.")
    if data["choices"][0]["finish_reason"] == "length":
        raise RuntimeError("Generation limit reached; do not accept this result.")
    return data

messages = [{
    "role": "user",
    "content": "Use multiply to calculate 6 times 7, then report the result."
}]
first = chat(messages, "required")
assistant = first["choices"][0]["message"]
calls = assistant.get("tool_calls") or []
if not calls:
    raise RuntimeError("Expected a tool call.")
messages.append(assistant)

for call in calls:
    function = call["function"]
    arguments = json.loads(function["arguments"])
    if function["name"] != "multiply":
        raise RuntimeError("Unexpected tool.")
    if not isinstance(arguments, dict) or set(arguments) != {"a", "b"}:
        raise RuntimeError("Unexpected arguments.")
    if any(type(arguments[key]) is not int for key in ("a", "b")):
        raise RuntimeError("Expected integer arguments.")
    result = arguments["a"] * arguments["b"]
    messages.append({
        "role": "tool",
        "tool_call_id": call["id"],
        "content": json.dumps({"result": result})
    })

final = chat(messages, "none")
choice = final["choices"][0]
answer = choice["message"].get("content") or ""
if choice["finish_reason"] != "stop" or not answer.strip():
    raise RuntimeError("Expected a completed final answer.")
print(answer)
print(json.dumps({"first": first["usage"], "final": final["usage"]}))
PY

Le résultat attendu est une réponse finale contenant 42, suivie des objets d’utilisation pour les deux requêtes. Le test rejette les appels d’outils manquants, un modèle inattendu, les arguments invalides, une génération tronquée et une réponse finale incomplète.

L’opération messages.append(assistant) conserve le message de réponse complet, y compris reasoning_content et tool_calls. Chaque résultat d’outil utilise ensuite le tool_call_id correspondant. Respectez cette règle de conservation de l’historique dans le stockage des conversations de production.

Le test utilise volontairement un appel d’outil obligatoire, puis une interdiction d’appel pour vérifier les deux étapes. Dans une boucle d’agent habituelle, utilisez auto si le modèle doit décider si un autre appel d’outil est nécessaire.

Si la requête échoue, choisissez la vérification suivante à l’aide de la référence des erreurs :

Pour 401, vérifiez la plateforme d’origine de la clé et le point d’accès, puis relancez le même test.
Pour 400 dans votre application existante, inspectez le JSON envoyé. Recherchez les anciens paramètres K2 thinking ou des valeurs qui remplacent les paramètres d’échantillonnage fixes.
Pour 404, vérifiez l’identifiant du modèle et les droits d’accès du compte. Ce code ne prouve pas une faute de frappe.
Pour finish_reason="length", considérez la réponse comme incomplète. Ajustez la tâche, l’effort de raisonnement ou le plafond de génération avant d’accepter le résultat.

Au 2026-11-05, BetterToken répertorie aussi kimi-k3.1-pro. Son API compatible OpenAI utilise https://www.bettertoken.ai/v1 avec votre propre clé API BetterToken. Vérifiez séparément ses tarifs actuels et les exigences de ses requêtes. Les règles de cache de Moonshot ne déterminent pas le comportement de cette passerelle.

Mettez à jour OpenCode et Claude Code

Modifiez tous les chemins qui peuvent sélectionner K2, y compris les tâches en arrière-plan et les sous-agents. La réussite de la conversation principale ne valide pas ces autres chemins.

OpenCode : sélectionnez le fournisseur Moonshot

Utilisez le fournisseur Moonshot AI intégré et actualisez son catalogue de modèles. Son identifiant est moonshotai, et il lit la clé dans MOONSHOT_API_KEY.

Les commandes suivantes correspondent à l’interface CLI d’OpenCode v1.19.5. Exécutez-les dans la même session Bash :

opencode models moonshotai --refresh
opencode run --model moonshotai/kimi-k3.1-pro --variant high \
  "Inspect the current project and identify the test command. Do not edit files."

La liste actualisée doit contenir moonshotai/kimi-k3.1-pro. La seconde commande doit produire une réponse propre au projet avec ce fournisseur et ce modèle. Si le modèle est absent, vérifiez la version installée du client et l’actualisation du catalogue avant de continuer.

La référence CLI décrit les deux options. Pour conserver le choix du modèle, définissez "model": "moonshotai/kimi-k3.1-pro" dans le fichier opencode.json du projet ou dans ~/.config/opencode/opencode.json. Si les deux fichiers existent, respectez les règles de priorité de la configuration.

La commande applique high pour cette exécution. Dans une session interactive, sélectionnez l’effort avec /variants avant d’envoyer le premier prompt. Si vous mettez aussi le client à niveau, consultez les changements de permissions d’OpenCode 2 avant d’autoriser des modifications du dépôt.

Claude Code : mettez à jour tous les alias de modèles

Moonshot décrit une connexion compatible avec Claude Code. La documentation Anthropic sur les passerelles précise qu’Anthropic ne prend pas en charge le routage de Claude Code vers des modèles autres que Claude. Cette connexion passe par l’adaptateur de Moonshot. Validez-la avec votre version installée du client.

Examinez d’abord ~/.claude/settings.json et les paramètres du projet. Corrigez les anciens points d’accès, données d’authentification, modèles et niveaux d’effort dans leurs blocs env. Moonshot avertit que les variables de ces fichiers peuvent prendre le pas sur celles exportées dans le terminal.

L’exemple actuel de Moonshot associe encore Haiku à kimi-k2.7-code. La configuration Bash suivante propose de faire pointer tous les niveaux de modèles indiqués vers la cible de migration :

unset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="https://api.moonshot.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="$MOONSHOT_API_KEY"
export ANTHROPIC_MODEL="kimi-k3.1-pro"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_FABLE_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_EFFORT_LEVEL="high"

claude --model kimi-k3.1-pro

Elle réutilise la clé exportée pour le test API. Recherchez les anciens paramètres K2 encore présents, notamment ANTHROPIC_SMALL_FAST_MODEL.

Exécutez /status et vérifiez l’URL de base ainsi que le modèle. Demandez ensuite une réponse simple, puis une tâche qui lit un fichier local. Confirmez l’effort réellement appliqué à l’aide des réglages du modèle.

Claude Code utilise le protocole Messages. Distinguez ces champs Kimi Messages de ceux de Chat Completions :

Fonction	Chat Completions	Kimi Messages
Effort de raisonnement	`reasoning_effort`	`output_config.effort`
Plafond de génération	`max_completion_tokens`	`max_tokens` obligatoire
Durée de conservation du cache	`prompt_cache_options.ttl`	`cache_control.ttl` dans l’objet de premier niveau

Ne renommez pas le champ max_tokens de Messages parce que son équivalent Chat Completions est obsolète.

Vérifiez les frais de cache sans compter deux fois les tokens

Répartissez les tokens d’entrée entre lectures du cache, écritures dans le cache et entrées hors cache. K3.1 Pro facture séparément les écritures dans le cache. Incluez ces frais dans votre calcul.

Pour Chat Completions, relevez les champs suivants :

Total en entrée : usage.prompt_tokens.
Lectures du cache : usage.prompt_tokens_details.cached_tokens.
Écritures dans le cache : usage.prompt_tokens_details.cache_write_tokens.
Total en sortie : usage.completion_tokens.

Selon les règles de comptabilisation de l’API, les trois catégories d’entrée ne se recoupent pas. Le total en sortie comprend déjà les tokens de raisonnement et de réponse.

Utilisez des tarifs dans une seule devise, par 1,000,000 tokens :

uncached = prompt_tokens - cached_tokens - cache_write_tokens

token_cost = (
    uncached * miss_rate
    + cached_tokens * hit_rate
    + write_5m * write_5m_rate
    + write_1h * write_1h_rate
    + completion_tokens * output_rate
) / 1_000_000

La somme write_5m + write_1h doit être égale à cache_write_tokens. Prenez les tarifs sur la page de tarification actuelle du fournisseur. Ce calcul estime les frais de tokens ; rapprochez-le de la facture.

Kimi utilise automatiquement un cache de 5m si vous omettez les options de cache. Pour des requêtes plus espacées, évaluez "prompt_cache_options": {"mode": "implicit", "ttl": "1h"}.

Le guide du cache précise qu’une entrée existante conserve sa durée de vie initiale. Envoyer 1h ne prolonge pas une entrée 5m encore active. Enregistrez les en-têtes de réponse Msh-Usage-Cache-Write-Tokens-5m et Msh-Usage-Cache-Write-Tokens-1h pour connaître les volumes réellement écrits.

Testez des requêtes répétées avec un préfixe représentatif et inchangé, c’est-à-dire une même partie initiale. Le test arithmétique peut être trop court pour montrer un effet utile du cache, car les blocs incomplets restent hors cache. Gardez le même effort de raisonnement pendant ce test : un changement invalide les correspondances avec le cache de préfixes.

Pour les applications qui reçoivent les réponses en flux, définissez aussi stream_options.include_usage=true. Suivez le guide des réponses en flux pour assembler les fragments de raisonnement, de réponse et d’appels d’outils. Lisez le dernier fragment contenant les statistiques d’utilisation, même si son tableau choices est vide.

Préparez les tests de non-régression avant la bascule

Ne transférez une petite part du trafic qu’après la réussite de vos tests d’acceptation existants sur le nouveau chemin.

Pour chaque comparaison, utilisez la même révision du dépôt, les mêmes prompts, les mêmes définitions d’outils et les mêmes commandes de test. Exécutez low, high et max dans des sessions séparées. Relevez la qualité de la tâche accomplie, le délai de réponse complet, les catégories d’entrée, le total en sortie, les nouvelles tentatives et le coût facturé.

Incluez les scénarios suivants dans les vérifications :

Une tâche sur plusieurs échanges qui dépend d’une réponse précédente de l’assistant.
Un appel d’outil suivi d’une nouvelle réponse du modèle.
Un appel d’outil reçu en flux, avec des arguments JSON répartis sur plusieurs fragments.
Une tâche proche du plafond de génération configuré.
Une tâche en arrière-plan ou un sous-agent qui pourrait conserver un alias K2.

Choisissez l’effort le plus faible qui respecte vos exigences de qualité et de délai. Si high échoue sur une tâche importante que max réussit de façon fiable dans vos tests, gardez max pour cette catégorie.

Conservez un retour possible vers K2 uniquement tant que le compte y a encore accès. Avant la période de retrait, testez une solution de repli qui ne dépend pas de K2. Supprimez les anciens identifiants K2 des tâches planifiées, des chemins de nouvelle tentative et de la configuration des agents.