Moonshot ouvre Kimi à Codex et Claude Code, redéfinissant le conflit entre Anthropic et Moonshot

Moonshot AI a ouvert Kimi à deux environnements de codage rivaux le 2 septembre, malgré un différend non résolu entre Anthropic et Moonshot concernant l’entraînement et l’accès aux modèles. L’API Kimi accepte désormais les requêtes OpenAI Responses API de Codex et les requêtes Anthropic Messages API de Claude Code. Moonshot affirme que les développeurs peuvent se connecter sans convertisseur de format ni proxy local.

Cette évolution peut sembler être une simple mise à jour de compatibilité. Elle est plus importante, car les agents de codage dépendent d’un comportement de protocole détaillé, et non de la seule complétion de texte ordinaire. Le client envoie des définitions d’outils, reçoit des appels structurés, renvoie les résultats d’exécution et répète ce cycle jusqu’à la fin de la tâche.

Moonshot tente donc de dissocier l’interface de codage de l’entreprise qui l’a créée. Codex peut rester le client du développeur tandis qu’un modèle Kimi remplace un modèle OpenAI. Claude Code peut conserver son flux de travail familier tandis que les requêtes sont acheminées vers Moonshot plutôt que vers Anthropic.

Cette stratégie place OpenAI et Anthropic sous un autre type de pression. Aucune des deux entreprises ne perd la propriété de son client ou de son protocole. Elles font toutefois désormais face à un autre fournisseur qui utilise la compatibilité pour concurrencer au sein de flux de travail qu’elles ont contribué à établir.

La prise en charge de Codex par l’API Kimi supprime un obstacle pratique

Le changement important de Moonshot est la prise en charge native des protocoles, et non une nouvelle interface de codage.

L’annonce de Moonshot du 2 septembre indique que Kimi prend en charge le format Responses API utilisé par Codex. Il prend également en charge le format Messages API associé à Anthropic et Claude Code. L’entreprise a publié des guides de configuration distincts pour chaque voie.

Pour Codex, Moonshot documente un fournisseur personnalisé utilisant son URL de base d’API et un format de communication Responses. Un fournisseur personnalisé indique au client où les requêtes de modèle doivent être envoyées et quel protocole il doit utiliser. Le développeur peut ensuite sélectionner un modèle Kimi tout en continuant à travailler dans Codex.

Moonshot identifie kimi-k3, kimi-k2.7-code-highspeed, kimi-k2.7-code et kimi-k2.6 comme des choix compatibles. La disponibilité peut toujours dépendre du compte, du point de terminaison, de la version du client et de la configuration actuelle de la plateforme.

La configuration Codex est notable, car elle supprime une couche de traduction que les intégrations précédentes exigeaient souvent. Un adaptateur local recevait un format de requête, le réécrivait pour une autre API, puis traduisait en retour la réponse en streaming.

Chaque adaptateur devient un élément mobile supplémentaire. Il peut mal gérer les appels d’outils, omettre un type d’événement, exposer un identifiant d’accès ou cesser de correspondre au client après une mise à jour. Il complique également le débogage, car une défaillance peut provenir du client, de l’adaptateur, du réseau ou du modèle en amont.

La prise en charge native de Responses réduit cette surface d’intégration. Elle ne garantit pas un comportement identique à celui d’un modèle hébergé par OpenAI. Elle signifie que le serveur de Moonshot accepte le contrat de communication attendu par le client.

Cette distinction compte, car Codex ne se contente pas d’envoyer une instruction et d’afficher une réponse. L’explication d’OpenAI sur la boucle d’agent Codex décrit des échanges répétés entre l’inférence du modèle et l’exécution d’outils. Le client transporte des messages, des instructions, des définitions d’outils, des éléments liés au raisonnement et des résultats d’outils au fil de ces échanges.

Un serveur compatible doit préserver une part suffisante de cette structure pour que la boucle puisse continuer. La génération de texte seule ne suffit pas. Les événements en streaming, les identifiants d’appels d’outils, les éléments d’entrée et le comportement de terminaison influencent tous la fiabilité du client.

La voie Codex de l’API Kimi vise donc les développeurs qui apprécient déjà l’interface Codex mais souhaitent un autre backend de modèle. Elle donne également aux équipes un moyen de comparer des modèles sans remplacer leur flux de travail dans le terminal ni reconstruire les scripts environnants.

La même logique s’applique à l’expérience sur ordinateur lorsque les fournisseurs personnalisés sont disponibles. Un sélecteur de modèles peut afficher un libellé personnalisé générique, selon la documentation de Moonshot, même lorsque le backend configuré est Kimi. Cette limite de l’interface peut rendre la vérification importante.

Les développeurs doivent confirmer le fournisseur actif au moyen de la configuration, des journaux de requêtes et de tests contrôlés. Une réponse réussie ne permet pas à elle seule d’établir quel backend a traité la requête.

Moonshot indique également que son implémentation de Responses accepte les entrées texte et image, mais ne prend pas actuellement en charge les entrées vidéo. Cette limite restreint la portée de la prise en charge native. La compatibilité de protocole peut être suffisamment large pour le travail de codage sans couvrir toutes les entrées possibles ou fonctionnalités de plateforme.

Le bénéfice immédiat reste clair. Les développeurs n’ont plus besoin de maintenir un pont de protocole local pour le parcours documenté. Cela réduit le travail de configuration et donne à Moonshot une voie plus directe vers un flux de travail d’agent établi.

La prise en charge de Claude Code par Kimi transforme un client en canal de distribution

La voie API configurable de Claude Code permet à Moonshot de concurrencer pour l’inférence sans créer un client aussi familier.

La configuration de Kimi avec Claude Code utilise le point de terminaison compatible avec Anthropic de Moonshot. Claude Code envoie des requêtes Messages API, tandis que le modèle Kimi sélectionné produit l’inférence. Le client continue de gérer les fichiers, les outils, les autorisations et son flux de travail interactif.

Le guide Claude Code de Moonshot décrit le point de terminaison et les identifiants requis. Cela remplace le schéma précédent consistant à installer un relais local uniquement pour convertir le format de requête.

La Messages API d’Anthropic est une interface structurée pour les conversations, les blocs de contenu et l’utilisation d’outils. Prendre en charge sa structure permet à un autre fournisseur de recevoir des requêtes provenant de logiciels conçus autour de ce contrat. Cela ne transforme pas un modèle Kimi en Claude et ne transfère pas le comportement des modèles d’Anthropic.

Cette distinction doit rester visible. Claude Code est le client agent. Claude est la famille de modèles d’Anthropic. Un utilisateur peut exécuter le client contre un point de terminaison externe compatible, mais le résultat produit provient du fournisseur configuré.

La propre documentation sur les passerelles d’Anthropic reconnaît que les formats d’API pris en charge peuvent connecter Claude Code à des passerelles. Elle précise également qu’Anthropic ne cautionne pas, n’assure pas la maintenance ni n’audite les produits de passerelle tiers. Plus directement, Anthropic indique qu’elle ne prend pas en charge le routage de Claude Code vers des modèles non-Claude par l’intermédiaire d’une passerelle.

Moonshot ne prétend pas qu’Anthropic prend en charge Kimi. L’entreprise implémente le format de requête attendu par le client. Cette différence sépare l’interopérabilité technique d’un partenariat commercial.

La configuration offre aux développeurs un cas d’usage réel. Une équipe peut conserver un client de codage, orienter un environnement de test vers Kimi et exécuter la même tâche de dépôt contre un autre backend. Elle peut comparer la qualité des correctifs, la fiabilité des outils, la latence et la récupération après échec à l’aide de commandes familières.

Le flux de travail réduit aussi les coûts de changement. Auparavant, l’évaluation d’un autre modèle pouvait nécessiter l’adoption de son client dédié ou la maintenance d’un proxy. La compatibilité native rapproche cette décision d’un simple changement de configuration.

Cela crée une pression sur les fournisseurs de modèles, car la fidélité des utilisateurs peut s’attacher à l’enveloppe de l’agent plutôt qu’au modèle sous-jacent. Un développeur peut préférer une interface tout en choisissant différents modèles pour la revue de code, l’exploration de dépôts, le débogage assisté par image ou les modifications de longue durée.

Les protocoles deviennent par conséquent des canaux de distribution. Dès lors qu’un client accepte des points de terminaison personnalisés, tout fournisseur suffisamment compatible peut chercher à accéder à ses utilisateurs. Le fournisseur d’origine contrôle toujours l’évolution du client, mais ne contrôle plus chaque requête d’inférence.

Il existe des limites. Claude Code ajoute des fonctionnalités au fil du temps, et les implémentations externes doivent suivre le rythme des champs de requête et de réponse exigés par ces fonctionnalités. Anthropic avertit que les passerelles peuvent casser des capacités lorsqu’elles ne transmettent pas les nouveaux comportements.

Un point de terminaison tiers direct fait face à la même charge de compatibilité. Si Claude Code introduit un autre schéma d’outil, en-tête, bloc de contenu ou événement de streaming, Moonshot doit l’implémenter correctement. « Native » décrit le parcours d’intégration actuel, et non une parité fonctionnelle permanente.

L’authentification modifie aussi la frontière de confiance. Les requêtes envoyées à Moonshot sont régies par le service, la gestion des données, les règles de conservation et la disponibilité régionale de Moonshot. Elles ne sont pas traitées sous un compte Anthropic simplement parce que Claude Code reste affiché à l’écran.

Les équipes devraient traiter le choix du fournisseur comme une décision d’infrastructure. Le code source, les instructions, les sorties d’outils et le contexte du dépôt peuvent transiter par le point de terminaison configuré. Les examens de sécurité doivent suivre le backend qui reçoit ces éléments.

La voie Kimi pour Claude Code est donc à la fois plus simple et plus conséquente qu’un plugin ordinaire. Elle permet à Moonshot d’entrer dans un flux de travail associé à un concurrent tout en assumant la responsabilité du service de modèle sous-jacent.

Le conflit entre Anthropic et Moonshot porte sur le contrôle, pas sur la compatibilité

La tension centrale est que l’ouverture technique peut coexister avec la méfiance commerciale.

Le mot-clé principal, anthropic moonshot, renvoie à une relation antagoniste plutôt que coopérative. La compatibilité de Moonshot avec Messages ne doit pas être confondue avec un accord avec Anthropic.

Le 23 février 2026, Anthropic a publiquement accusé Moonshot, DeepSeek et MiniMax de mener ce qu’elle a qualifié de campagnes de distillation à l’échelle industrielle. La distillation entraîne un modèle à l’aide de résultats générés par un autre modèle, bien que cette méthode puisse être légitime lorsque l’accès et les autorisations le permettent.

Anthropic a affirmé que les trois entreprises avaient collectivement généré plus de 16 millions d’échanges avec Claude par l’intermédiaire d’environ 24 000 comptes frauduleux. L’entreprise a attribué plus de 3,4 millions d’échanges à Moonshot et a indiqué que l’activité visait le codage, l’utilisation d’outils, le raisonnement, l’analyse de données, l’utilisation d’ordinateurs et la vision.

Il s’agit d’allégations d’Anthropic, et non de conclusions établies de manière indépendante dans les éléments examinés pour cet article. La compatibilité API nouvellement annoncée par Moonshot ne les confirme ni ne les résout. Aucune conclusion sur l’entraînement de Kimi ne doit être tirée de sa seule prise en charge du format de messages d’Anthropic.

Cette histoire modifie néanmoins la lecture de ce lancement. Anthropic soutient que les sorties des modèles et les restrictions d’accès exigent une protection plus stricte. Moonshot facilite parallèlement l’utilisation de l’interface associée à Anthropic avec un modèle concurrent.

Le conflit entre Anthropic et Moonshot se joue donc sur deux niveaux. L’un concerne les personnes autorisées à accéder aux capacités des modèles et selon quelles conditions. L’autre porte sur la possibilité pour un protocole client de fonctionner comme une interface largement implémentée.

Les allégations de distillation d’Anthropic mettent l’accent sur le premier niveau. La publication de compatibilité de Moonshot met l’accent sur le second. Les deux parties contestent le contrôle, mais sur des parties différentes de la pile technologique.

Le protocole lui-même ne contient pas l’ensemble du comportement du modèle. Il définit la manière dont les requêtes, les contenus, les outils et les réponses circulent entre le client et le serveur. Plusieurs fournisseurs peuvent implémenter des interfaces similaires tout en produisant des résultats différents.

Cette séparation est familière sur d’autres marchés informatiques. Des applications peuvent communiquer via un protocole de base de données partagé sans utiliser le même moteur de base de données. Des services cloud peuvent exposer des interfaces de stockage d’objets compatibles sans correspondre à chaque détail opérationnel.

Les agents d’IA compliquent davantage la séparation, car le comportement du modèle influence la boucle côté client. Un agent de programmation attend du modèle qu’il sélectionne les outils, interprète les résultats, produise des modifications valides et se rétablisse après des erreurs. La compatibilité formelle des API est nécessaire, mais c’est la compatibilité comportementale qui détermine si l’expérience reste utile.

Moonshot en bénéficie si les développeurs considèrent Codex et Claude Code comme des interfaces neutres. OpenAI et Anthropic en bénéficient si les utilisateurs associent leurs clients à des modèles optimisés spécifiquement pour ces clients. La question concurrentielle est de savoir quelle vision s’imposera.

Si l’interface devient indépendante, le routage des modèles devient plus simple. Les entreprises peuvent négocier l’accès aux fournisseurs, appliquer des politiques régionales différentes ou attribuer des modèles à des charges de travail précises. Les développeurs peuvent conserver leurs automatismes tout en changeant de fournisseur d’inférence.

Si l’optimisation approfondie entre modèle et client l’emporte, les concurrents compatibles pourraient rester secondaires. De subtiles différences dans l’appel d’outils, la gestion du contexte, la mise en cache, les contrôles de raisonnement et la récupération après erreur peuvent l’emporter sur la commodité d’un endpoint partagé.

C’est pourquoi le changement du 2 septembre n’est pas simplement une case API supplémentaire à cocher. Il teste la possibilité de dissocier la distribution des agents de programmation de la propriété des modèles.

Les formats natifs ne garantissent toujours pas des performances natives

Une connexion qui démarre avec succès peut tout de même échouer durant les phases exigeantes de l’exécution d’un agent.

L’annonce de Moonshot établit une voie documentée. Elle ne fournit pas de preuve indépendante que chaque fonctionnalité de Codex ou Claude Code se comporte de manière identique sur les modèles Kimi mentionnés.

La première incertitude concerne la couverture du protocole. Responses et Messages ne se limitent pas à de simples champs de texte. Ils couvrent le streaming, le contenu multimodal, les schémas d’outils, les résultats d’outils, les métadonnées, les rapports d’utilisation et les structures d’erreur.

Un fournisseur peut accepter la requête principale tout en traitant différemment les cas limites. Les appels d’outils parallèles peuvent arriver dans un autre ordre. Un flux peut omettre un événement attendu par le client. L’annulation peut se comporter différemment pendant une commande longue.

La deuxième incertitude concerne l’adéquation comportementale. Les clients de programmation comptent sur les modèles pour suivre des instructions spécialisées et utiliser les outils avec soin. Un modèle qui obtient de bons résultats à un benchmark de programmation peut néanmoins peiner avec les prompts d’un client spécifique ou le flux de travail d’un dépôt.

L’évaluation utile doit donc mesurer l’exécution des tâches plutôt que le succès de la connexion. Les équipes doivent vérifier si le modèle modifie les bons fichiers, respecte les instructions du projet, interprète la sortie des commandes et s’arrête lorsqu’une approbation est requise.

La troisième incertitude est l’évolution du client. OpenAI et Anthropic peuvent modifier leurs clients à mesure que de nouvelles capacités arrivent. Les fournisseurs externes doivent suivre ces changements sans en contrôler le calendrier.

La description de Codex par OpenAI montre à quel point la boucle de l’agent est devenue détaillée. Les sorties des appels d’outils sont ajoutées aux requêtes suivantes, et le contexte de la conversation s’étend sur des tours répétés. Des changements dans ces objets peuvent affecter la compatibilité même lorsque l’endpoint reste /responses.

Anthropic formule un avertissement similaire pour les opérateurs de passerelles. Sa documentation indique que de nouvelles capacités de Claude Code peuvent échouer lorsqu’une passerelle ne les transmet pas. Un fournisseur qui implémente directement le format assume un risque de maintenance comparable.

La quatrième incertitude concerne la gouvernance des données. Remplacer le backend modifie les endroits où transitent le code et le contexte. Les organisations ne peuvent pas supposer que les contrôles associés à un compte OpenAI ou Anthropic suivront la requête vers Moonshot.

Un examen de sécurité doit couvrir le stockage des identifiants, la conservation, la journalisation, le traitement géographique, la réponse aux incidents et le contrôle des accès. Les équipes doivent également identifier les fichiers du dépôt que l’agent peut lire avant d’envoyer une véritable tâche de production.

La cinquième incertitude est l’observabilité. Une étiquette de modèle générique peut rendre le backend actif moins évident. Les organisations ont besoin de journaux reliant chaque requête à un fournisseur, un identifiant de modèle, un développeur, un dépôt et une politique.

C’est là qu’une base de connaissances d’ingénierie interne peut aider. Les équipes peuvent y consigner les configurations approuvées, les résultats d’évaluation, les incompatibilités connues et les étapes de retour arrière sans dépendre de la mémoire individuelle.

Aucune de ces préoccupations n’invalide la sortie. Elles définissent ce que devrait signifier, en pratique, le « support natif ». Cela signifie que le fournisseur a supprimé un composant de traduction requis, non que chaque fonctionnalité client a atteint une parité permanente.

Un essai responsable commence avec un dépôt représentatif et des permissions limitées. Il comprend des tâches impliquant la recherche de fichiers, des modifications sur plusieurs fichiers, l’exécution de tests, l’échec de commandes, l’entrée d’images et de longues séquences d’outils.

Les équipes doivent comparer le correctif final et le processus qui l’a produit. Un résultat correct obtenu au prix d’un accès inutile aux fichiers ou de commandes répétées qui échouent reste un signal de risque opérationnel.

Les meilleures preuves viendront d’un usage soutenu au fil des mises à jour des clients. Moonshot a facilité l’adoption. Il doit désormais démontrer que la compatibilité reste fiable après le premier prompt réussi.

Ce que les développeurs devraient surveiller après le 2 septembre

Trois signaux détermineront si cette sortie transforme la concurrence entre modèles ou reste une option d’intégration pratique.

Le premier signal est la parité fonctionnelle au fil des mises à jour des clients. Les développeurs doivent surveiller si les nouvelles capacités de Codex et Claude Code fonctionnent rapidement via les endpoints de Moonshot.

Cela inclut les nouveaux types de contenu, les définitions d’outils, les événements de streaming, les contrôles de raisonnement et le comportement d’authentification. Une prise en charge rapide renforcerait l’affirmation de Moonshot selon laquelle il peut agir comme fournisseur de premier rang. Des défaillances récurrentes l’affaibliraient.

La documentation publique fournira un premier indicateur. Des matrices de compatibilité claires, des exigences de version, des limitations connues et des mises à jour datées comptent davantage qu’une affirmation générale de prise en charge.

Le deuxième signal est la performance vérifiée sur les charges de travail. Des tests indépendants devraient examiner des tâches complètes sur des dépôts plutôt que des questions de programmation isolées. Parmi les mesures utiles figurent les correctifs réussis, les taux de réussite des tests, les appels d’outils inutiles, la latence, la récupération après des erreurs de commande et le temps de correction humaine.

La comparaison pertinente n’est pas simplement Kimi face à Claude ou à un modèle OpenAI dans une fenêtre de chat. C’est Kimi au sein de la boucle client exacte que les développeurs envisagent d’utiliser.

Différents modèles peuvent exceller sur différentes charges de travail. Un modèle rapide peut convenir à la recherche dans un dépôt et aux transformations routinières. Un modèle plus réfléchi peut mieux réussir les changements d’architecture ou le débogage difficile. La compatibilité native facilite ces comparaisons, mais ne les tranche pas.

Le troisième signal est la manière dont OpenAI et Anthropic réagissent à la portabilité entre fournisseurs. Ils peuvent approfondir l’optimisation modèle-client, resserrer les politiques relatives aux fournisseurs pris en charge, améliorer le routage en entreprise ou rendre les choix de cloud officiels plus attractifs.

Anthropic trace déjà une frontière entre les passerelles qu’il documente et les modèles non-Claude qu’il ne prend pas en charge. Le différend non résolu entre anthropic et moonshot ajoute une raison supplémentaire de surveiller si cette frontière devient plus stricte.

OpenAI a explicitement décrit l’endpoint Responses de Codex comme configurable. Ce choix architectural favorise la portabilité, même si les détails d’implémentation et les configurations prises en charge peuvent changer. La sortie de Moonshot teste jusqu’où les développeurs utiliseront cette flexibilité.

Pour les développeurs individuels, l’action immédiate est simple. Considérez Kimi comme un autre backend à évaluer, et non comme un remplacement direct d’identité. Commencez avec une branche jetable, confirmez le modèle actif, limitez les identifiants et examinez chaque correctif.

Pour les responsables d’ingénierie, la question plus vaste porte sur la dépendance. L’organisation souhaite-t-elle un fournisseur intégré unique, ou une couche client capable de router entre plusieurs fournisseurs ? La compatibilité rend la deuxième approche plus pratique, mais elle transfère également le travail de test et de gouvernance au client.

Conservez un bref dossier d’évaluation dans une base de connaissances personnelle. Consignez la version du client, le modèle sélectionné, le type de dépôt, la tâche, les échecs observés et l’examen humain final. Répéter le même test après les mises à jour révélera si la compatibilité s’améliore.

Moonshot a supprimé un obstacle visible entre Kimi, Codex et Claude Code. Le suivant est la confiance acquise au fil d’exécutions répétées d’agents. La prise en charge native du protocole restera-t-elle fiable lorsque les clients changent, que les tâches s’allongent et que le conflit entre anthropic et moonshot maintient au premier plan les questions d’accès et de contrôle ?