Moonshot AI publie kimi-k2.7-code, un modèle de codage open-weight avec fenêtre 256k, raisonnement long et multimodalité native. Pour les équipes d’ingénierie, il promet des gains mesurables sur les tâches de code tout en réduisant les tokens de raisonnement interne.

Moonshot AI annonce kimi-k2.7-code le 2026-06-12, une nouvelle itération de sa famille Kimi orientée vers le développement logiciel. Le modèle arrive dans un contexte où les équipes cherchent à remplacer des assistants de code propriétaires par des briques open-weight, contrôlables, intégrables dans des pipelines internes et capables de gérer des dépôts volumineux. Sa promesse est claire : améliorer fortement les performances de codage par rapport à K2.6, tout en consommant moins de tokens pour le raisonnement interne.
Ce qui rend cette sortie intéressante pour les développeurs et les ingénieurs IA n’est pas seulement le score sur des benchmarks. kimi-k2.7-code combine une fenêtre de contexte de 256k, soit 262,144 tokens, une architecture native multimodale pour le texte, l’image et la vidéo, ainsi que des capacités d’agent avec ToolCalls, JSON Mode, Partial Mode et cache contextuel automatique. Il est disponible via API et dans Kimi Code IDE, avec des poids open-source publiés sur HuggingFace.
Pour les architectes qui comparent les modèles de code, le point central est le compromis entre qualité, coût d’inférence et intégration. Moonshot ne présente pas ici un simple chatbot de développement : kimi-k2.7-code vise les workflows de refactoring, de génération de patches, de revue de code, de RAG sur codebase et d’agents autonomes capables de planifier, d’appeler des outils et de produire des sorties structurées.
La fiche technique de kimi-k2.7-code met en avant une fenêtre de contexte de 256k, soit 262,144 tokens, avec support du long thinking et du deep reasoning. Pour une équipe qui travaille sur un dépôt legacy, cela change la manière de construire les prompts : il devient réaliste d’injecter des extraits longs de documentation, plusieurs fichiers sources, des traces d’exécution, des logs, des captures d’écran ou des vidéos de reproduction de bug dans un même contexte.
Le modèle est présenté comme ayant une architecture native multimodale. Contrairement à un système où la vision est greffée après coup, l’objectif ici est de traiter conjointement du texte, des images et de la vidéo. Pour les workflows de développement, cela ouvre des cas concrets : analyser une capture d’interface, lire un diagramme d’architecture, comprendre une démo vidéo, ou relier un message d’erreur terminal à un état visuel de l’application.
Côté paramètres, Moonshot communique le modèle comme open-weights. Le nombre exact de paramètres et la topologie MoE ne sont pas détaillés dans les informations disponibles. Il faut donc éviter de déduire une architecture spécifique : le fait marquant est que les poids sont ouverts, ce qui permet l’auto-hébergement, la quantification, l’évaluation privée et l’intégration dans des infrastructures d’inférence existantes. La génération précédente Kimi K2.6 avait été associée à des optimisations d’attention et à des ambitions très élevées en paramètres ; K2.7-code se concentre davantage sur l’efficacité applicative et les gains mesurés en codage.
Les gains annoncés par rapport à K2.6 sont significatifs. Sur Kimi Code Bench v2, kimi-k2.7-code affiche une amélioration de +21.8% par rapport à K2.6. Sur Program Bench, l’amélioration est de +11%. Sur MLS Bench Lite, le modèle gagne +31.5%. Ces trois métriques pointent dans la même direction : Moonshot cherche à améliorer la capacité du modèle à comprendre, modifier et produire du code dans des scénarios plus proches de tâches réelles que de simples questions isolées.
Le chiffre le plus opérationnel pour les équipes qui déploient des agents est la réduction de 30% des tokens utilisés pour le raisonnement interne par rapport à K2.6. Dans un workflow d’agent, le coût ne vient pas uniquement de la réponse finale : il vient aussi des étapes de planification, de vérification, de réflexion et d’appels d’outils. Réduire les tokens de raisonnement interne peut améliorer la latence, limiter la dérive des coûts et rendre les agents longs plus viables économiquement.
Pour les benchmarks classiques, Moonshot ne communique pas encore de scores publics détaillés pour MMLU, HumanEval ou SWE-bench Verified dans les informations fournies. Il faut donc les traiter comme N/A plutôt que d’inventer des chiffres. La comparaison concurrentielle doit également rester prudente : des rapports externes sur Kimi K2.6 indiquent des revendications de performance proches ou supérieures à Claude Opus 4.6 et GPT-5.4 sur certains benchmarks, mais pour kimi-k2.7-code, les données solides disponibles sont les deltas vs K2.6 et les capacités d’intégration.
Les prix vérifiés pour kimi-k2.7-code sont les suivants : Input à $0.95 par million de tokens, Output à $4.00 par million de tokens, et Input Cache Hit à $0.19 par million de tokens. La fenêtre de contexte officielle indiquée pour la tarification est de 262,144 tokens, ce qui correspond au contexte 256k annoncé. Ces prix doivent être lus comme des coûts par million de tokens, comme c’est l’usage pour les API de modèles de fondation.
La disponibilité d’un niveau gratuit est indiquée comme N/A dans les informations publiques fournies. En revanche, Moonshot ouvre un programme bêta pour les utilisateurs souhaitant accéder tôt aux futures mises à jour. Le point de pricing le plus important est le cache contextuel : avec un prix de cache hit à $0.19 par million de tokens, les workflows qui réutilisent de grands contextes, par exemple des dépôts indexés, des documents de spécification ou des historiques de conversation, peuvent réduire fortement le coût marginal des requêtes répétées.
Pour les équipes qui comparent les coûts, il faut raisonner en coût total d’agent plutôt qu’en prix par appel isolé. Un modèle moins cher en input peut devenir coûteux s’il génère beaucoup de tokens de sortie ou s’il relit sans cache de grands contextes. Inversement, un modèle avec cache efficace peut être très compétitif pour des IDE, des agents de maintenance ou des systèmes de RAG qui réutilisent souvent les mêmes bases de code.
Le cas d’usage principal est évidemment le développement logiciel assisté par IA. kimi-k2.7-code est adapté à la génération de code, au refactoring, à la correction de bugs, à l’écriture de tests et à la création de patches à partir de descriptions longues. La fenêtre 256k est particulièrement utile pour les tâches où le modèle doit comprendre plusieurs fichiers, une documentation produit, des conventions internes et des logs d’exécution dans une seule requête.
Le modèle est également pertinent pour les agents de code. Avec ToolCalls, JSON Mode et Partial Mode, une application peut orchestrer des étapes structurées : analyser une issue, récupérer des fichiers, proposer un plan, exécuter des tests, produire un diff, puis retourner une réponse JSON exploitable par un orchestrateur. Le cache contextuel automatique devient alors un levier économique pour les agents qui travaillent pendant des heures sur un même dépôt ou une même session de développement.
La multimodalité native élargit le périmètre au-delà du code pur. Une équipe peut soumettre une capture d’écran d’un bug UI, une vidéo de reproduction, un schéma d’architecture ou une trace visuelle d’erreur, puis demander une hypothèse de cause racine ou un plan de correction. Pour les plateformes de RAG, kimi-k2.7-code peut servir à interroger des bases mixtes composées de code, de tickets, de documentation, de captures et de vidéos de démo.
Pour commencer, les développeurs peuvent récupérer les poids open-source de kimi-k2.7-code sur HuggingFace, puis vérifier la licence exacte avant tout déploiement commercial ou interne sensible. Pour une utilisation managée, le modèle est disponible via l’API Moonshot AI et dans Kimi Code IDE. Le programme bêta est ouvert pour les équipes qui veulent tester les futures mises à jour, notamment le mode séparé 6x High-Speed annoncé.
Côté API, l’endpoint exact doit être confirmé depuis la console Moonshot AI, car il peut varier selon la région, le type de compte et le programme d’accès. Le modèle à utiliser est kimi-k2.7-code. Si la plateforme expose une interface compatible OpenAI, les wrappers OpenAI ou AsyncOpenAI peuvent être adaptés avec une base URL personnalisée, mais il faut éviter de copier des endpoints tiers sans validation officielle. Pour les SDK, utilisez ceux proposés par Moonshot ou les bibliothèques compatibles documentées dans votre espace développeur.
Pour une intégration sérieuse, commencez par mesurer trois dimensions : qualité des patches, coût total par tâche et latence perçue. Activez JSON Mode lorsque votre application attend un schéma stable, utilisez ToolCalls pour les actions externes, puis testez le cache contextuel sur des sessions répétitives. Gardez Partial Mode pour les expériences où l’utilisateur doit voir une progression avant la réponse finale, par exemple dans un IDE, un terminal agentique ou un outil de revue de pull request.
API Pricing — Input: $0.95 / Output: $4.00 / Context: 262,144 tokens