Kimi K3 égale GPT-5.6, mais prend 4,6 fois plus de temps

Artificial Analysis classe Kimi K3 à égalité avec GPT-5.6 medium, mais Kimi reste actif 23,8 minutes contre 5,2, soit 4,6 fois plus longtemps [1]. GLM-5.2 fait moins bien : son prix d’entrée de 1,40 $ devient 6,51 $ par tentative [2]. À mes yeux, aucun n’offre l’économie que son prix par token laisse espérer.

Le comparatif en un tableau : Kimi rivalise, GLM-5.2 décroche

Kimi K3 rivalise avec les meilleurs sans les dominer : il égale GPT-5.6 Sol medium sur l’indice global, mène le test de terminal, comprend moins bien les dépôts et s’exécute beaucoup plus lentement. À ces réglages, GLM-5.2 finit derrière les trois autres modèles et ne mène aucune mesure [1] [2].

Mesure	Kimi K3	GLM-5.2	Sol medium	Opus 5 medium
Coding Agent Index	61	43	61	62 (Meilleure valeur de la ligne)
DeepSWE, %	64	29	64	63
Terminal-Bench v2, %	84 (Meilleure valeur de la ligne)	72	78	79
SWE-Atlas Q&A, %	37	29	40	44 (Meilleure valeur de la ligne)
Coût par tâche, $	3,18	6,51	2,99 (Meilleure valeur de la ligne)	3,14
Temps actif, min	23,8	25,1	5,2 (Meilleure valeur de la ligne)	12,2

L’égalité entre Kimi et Sol medium est la comparaison directe la plus utile : tous deux obtiennent 61, et leurs coûts mesurés par tâche sont proches, à 3,18 $ et 2,99 $ [1]. La différence tient à la manière d’y parvenir. Kimi consomme 23,8 minutes actives et 10,6 millions de tokens par tâche, contre 5,2 minutes et 5,8 millions pour Sol. Opus 5 medium montre le même écart : il devance Kimi d’un point, coûte quatre cents de moins et termine en deux fois moins de temps environ [2].

Les modèles occidentaux conservent les meilleurs scores de l’indice. Sol max et Opus 5 xhigh atteignent tous deux 67, pour 7,08 $ et 8,23 $ par tâche, tandis qu’Opus domine aussi la compréhension des dépôts avec 55 % sur SWE-Atlas Q&A [1] [2]. Fable 5 max suit à 66, mais coûte 11,71 $ par tâche [2]. Kimi reste compétitif là où il est le plus fort : ses 84 % sur Terminal-Bench v2 dépassent les 83 % de Sol high et approchent les modèles à effort maximal [1] [2].

La compréhension des dépôts est sa faiblesse la plus nette. Kimi obtient 37 % sur la partie consacrée aux questions sur le code, contre 40 % pour Sol medium et bien davantage pour les configurations Claude [1] [2]. Cet écart compte moins au démarrage d’un nouveau projet, mais dans un dépôt existant de 300 000 lignes, comprendre le code déjà présent constitue l’essentiel du travail.

Pourquoi Kimi K3 suscite-t-il autant d’engouement ? Ses résultats web

Les classements d’Arena ont largement alimenté l’engouement pour Kimi, car ils montrent que les utilisateurs préfèrent son travail dans le navigateur même lorsque des tests d’agents plus larges révèlent ses faiblesses. Il mène le classement de code fullstack d’Arena [3] et arrive deuxième de la WebDev Arena, devant Claude Fable 5 et GPT-5.6 [4]. Ses poids ouverts et ses prix par token, qui paraissent bas, renforcent encore son attrait.

Ces résultats comptent parce que les arènes mesurent ce que les utilisateurs préfèrent, pas la réussite d’une batterie de tests. Dans le classement fullstack du 24 juillet 2026, Kimi K3 max arrivait premier avec 1 664 points, devant GPT-5.6 Sol à 1 633 et Fable 5 à 1 623 [3]. Quatre jours plus tard, Opus 5 max menait la WebDev Arena avec 1 712 points. Kimi arrivait deuxième avec 1 682 points sur 3 777 votes, devant Fable 5, Sol et GLM-5.2 [4]. Les utilisateurs apprécient clairement ce que Kimi produit dans un navigateur.

Les annonces des deux modèles confirment qu’ils ont bien des poids ouverts. Moonshot présente Kimi K3 comme le premier modèle à poids ouverts doté de 2 800 milliards de paramètres. Il possède aussi une fenêtre de contexte d’un million de tokens, une fonction de vision intégrée et une API facturée 3 $ par million de tokens en entrée et 15 $ en sortie [5]. Z.ai publie GLM-5.2, plus petit avec ses 753 milliards de paramètres, sous licence MIT [6]. Son prix catalogue est de 1,40 $ en entrée et 4,40 $ en sortie [7]. D’après ces seuls tarifs, les deux modèles paraissent bien moins chers que leurs concurrents occidentaux.

Le billet de lancement de Moonshot est plus mesuré que cette comparaison ne le laisse penser. Il indique que K3 reste derrière Fable 5 et GPT-5.6 Sol, avec « un écart sensible d’expérience utilisateur » face aux deux [5]. Les mesures indépendantes rendent cet écart concret, notamment sur la vitesse et la compréhension des dépôts. La prudence de Moonshot elle-même mérite d’être gardée en tête chaque fois qu’un laboratoire chinois est désigné comme la cause de quelque chose, et c’est ce que je défends dans le filigrane des textes de Claude répond à l’UE et non aux laboratoires chinois.

Que mesure le Coding Agent Index ? Des systèmes d’agents complets

Le Coding Agent Index mesure des systèmes complets associant un modèle et un agent dans trois domaines : le génie logiciel, le travail en terminal et les questions sur le code d’un dépôt. Dans sa version 1.3, Artificial Analysis combine à parts égales 113 tâches DeepSWE, 84 tâches Terminal-Bench v2 et 124 questions SWE-Atlas Q&A [8].

Cette limite compte parce que Kimi tournait dans Kimi Code CLI, GLM-5.2 dans Claude Code, Sol dans Codex et les modèles Claude dans Claude Code [1] [2]. Chaque score reflète donc à la fois le modèle, son agent et le niveau d’effort choisi. Le tableau permet de comparer ces configurations réelles, mais pas de déterminer comment les mêmes poids se classeraient dans un harness neutre.

Kimi K3 et GLM-5.2 sont-ils moins chers ? Pas par tâche réussie

Non. Le coût d’une tâche réussie dépend du nombre de tokens dont l’agent a besoin et de son taux de réussite, pas seulement du prix de chaque token. GLM-5.2 l’illustre le mieux : son tarif catalogue est le plus bas du comparatif, mais chaque tentative coûte plus cher que pour toutes les configurations occidentales à effort medium [2] [7].

Anthropic a rendu permanent le tarif de lancement de Claude Sonnet 5, soit 2 $ en entrée et 10 $ en sortie par million de tokens [9]. Kimi K3 coûte 3 $ et 15 $ [5]. Ses prix d’entrée et de sortie sont donc tous deux 50 % plus élevés que ceux de Sonnet. Kimi n’a aucun avantage tarifaire face à ce modèle.

Plus haut dans la grille, Anthropic facture Opus 5 à 5 $ en entrée et 25 $ en sortie, contre 10 $ et 50 $ pour Fable 5 [9]. OpenAI facture GPT-5.6 à 5 $ et 30 $, ou 10 $ et 45 $ dans le palier long contexte [10]. Z.ai reste moins cher que tous avec GLM-5.2 à 1,40 $ et 4,40 $, plus 0,26 $ pour les lectures en cache [7]. Tous ces tarifs s’entendent par million de tokens.

Ces unités ne sont pas parfaitement comparables. Les fournisseurs emploient des tokenizers différents, et Anthropic indique que son système actuel produit environ 30 % de tokens de plus que le précédent pour un même texte [9]. Le guide de démarrage de Moonshot précise aussi que Kimi K3 raisonne toujours, ne permet pas de désactiver ce mode et utilise max par défaut [11]. Les tokens de raisonnement cachés restent facturés.

prix catalogue, par million de tokens en entrée

1,40 $

le modèle le moins cher de ce comparatif

mesuré, par tentative

6,51 $

dans Claude Code, 25,1 minutes actives

calculé, par tâche réussie

15,14 $

coût par tentative divisé par le taux de réussite de 43 %

Quand je compare les tâches réussies plutôt que les tentatives, Sol medium, Opus 5 medium et Kimi K3 restent proches, autour de 4,90 $, 5,06 $ et 5,21 $. GLM-5.2 passe à 15,14 $, soit environ trois fois plus. Le modèle au prix par token le plus bas produit donc le coût estimé le plus élevé pour obtenir un résultat correct.

Cette estimation reste favorable aux échecs, puisqu’elle exclut le temps de l’ingénieur. Dix minutes consacrées à examiner une tentative ratée coûtent plus que tous les frais de modèle indiqués dans la figure. Le taux de réussite compte donc bien davantage que le prix par token dès qu’une personne doit contrôler le résultat. Reste à savoir quelles tâches conviennent assez bien à Kimi pour justifier ses exécutions plus lentes.

Dans quels domaines Kimi K3 est-il bon ? Terminal et fullstack

Kimi K3 est surtout convaincant pour les tâches qui reposent sur le terminal, le développement web fullstack et les longues sessions d’agent, en particulier si une équipe a besoin de poids ouverts et d’un hébergement local. Les mesures indépendantes, les votes d’arène et les résultats de Moonshot convergent vers ces usages [1] [3] [5]. Ils ne justifient pas de considérer Kimi comme un remplaçant moins cher pour travailler dans de grands dépôts existants.

Le résultat de terminal apparaît dans les tests indépendants comme dans ceux du fournisseur : Artificial Analysis mesure 84 % avec la propre CLI de Kimi, tandis que Moonshot mesure 88,3 % dans sa configuration préférée [1] [12]. K3 mène aussi le tableau SWE-Marathon de Moonshot avec un score de 42, mais les notes comptent. Fable 5 a utilisé des modèles de secours sur 35 % de ses tâches, et certaines lignes Kimi reposaient sur une branche préliminaire réglée pour du matériel H20 [12]. Ajoutez l’encodeur visuel dédié de Kimi et sa fenêtre de contexte d’un million de tokens, et la méthode de travail proposée par Moonshot entre code et captures d’écran repose sur des fonctions concrètes [5] [12].

Ces atouts s’accompagnent de limites pratiques. Le score de 37 % aux questions sur le code fait de Kimi un choix discutable lorsque la compréhension du dépôt détermine la réussite [1]. Ses 23,8 minutes actives par exécution obligent aussi à lancer plusieurs agents en parallèle ou à attendre. Quant à l’auto-hébergement, il ne s’improvise pas : avec 2 800 milliards de paramètres, les poids occupent environ 1,4 To en quantification 4 bits, avant le cache KV et les coûts du serveur. Il faut donc un cluster, pas une station de travail.

Les conditions juridiques imposent une autre vérification avant toute adoption. Une entreprise qui fournit un modèle en tant que service et dépasse 20 millions de dollars de chiffre d’affaires total doit conclure un accord séparé avec Moonshot. Un produit qui dépasse 100 millions d’utilisateurs actifs mensuels ou 20 millions de dollars de chiffre d’affaires mensuel doit afficher « Kimi K3 » de manière visible. L’usage interne est exempté [13]. Les conditions standard de l’API permettent aussi d’utiliser le contenu des clients afin de fournir, maintenir, développer, assister les utilisateurs et améliorer les services. Les restrictions sur l’entraînement passent par des accords d’entreprise distincts [14]. J’obtiendrais ces restrictions par écrit avant d’envoyer un dépôt propriétaire à l’API publique.

Pourquoi GLM-5.2 peine-t-il dans Claude Code ? L’agent compte

La baisse de neuf points de GLM-5.2 sur Terminal-Bench met surtout en garde contre les effets de la configuration d’agent. Elle ne prouve pas que les poids du modèle sont faibles. Le modèle obtient 81 % dans le harness Terminus de Z.ai, contre 72 % dans Claude Code [6] [2]. Personne en dehors de Z.ai ne peut en déterminer la cause exacte, mais les appels d’outils, la récupération après erreur, le cache ou les conventions de l’agent peuvent expliquer l’écart.

Quelle qu’en soit la cause, cette configuration fonctionne mal. GLM-5.2 obtient 43 sur l’indice et 29 % à la fois sur DeepSWE et sur les questions de code. À 6,51 $ et 25,1 minutes actives par tentative, c’est aussi la configuration la plus lente du comparatif [2]. Ses prix de 1,40 $ en entrée et 4,40 $ en sortie ne se traduisent jamais par une tâche bon marché.

La fiche de Z.ai montre pourquoi le système qui entoure le modèle compte. Son résultat de 62,1 sur SWE-Bench Pro utilise OpenHands avec un prompt d’instructions adapté. DeepSWE tourne dans des conteneurs isolés avec une limite de deux heures, tandis que Terminal-Bench utilise Terminus avec un budget de quatre heures [6]. Ces mesures décrivent valablement GLM-5.2 dans une configuration choisie pour lui, mais elles ne prédisent pas son comportement dans un autre agent.

GLM-5.2 conserve malgré tout un usage plausible pour du travail auto-hébergé et vérifié automatiquement. Ses 753 milliards de paramètres et sa licence MIT le rendent plus facile à héberger que Kimi K3 [6]. Son tarif d’entrée de 1,40 $ convient à des codemods en volume ou à des migrations couvertes par des contrôles déterministes. Ces contrôles peuvent rejeter les 57 % de tentatives ratées sans relecture manuelle. Si un ingénieur doit les examiner, la réduction sur les tokens ne fait plus économiser d’argent. L’hébergement a son propre coût, comme je l’ai constaté avec DeepSeek V4.1 Flash, dont l’API bon marché s’accompagne de poids ouverts massifs.

Comment lire un classement de code ? Comparez d’abord le harness

Commencez par le harness, la version du benchmark et le type de tâche mesuré, car un score appartient toujours à cette configuration. L’écart entre le succès de Kimi dans les arènes et la dépendance de GLM au harness montre pourquoi le nom du modèle et le score final ne suffisent pas.

Signal	Ce qu’il récompense	Ce qu’il ne peut pas vous dire
DeepSWE, 113 tâches	terminer des tâches d’ingénierie de bout en bout	l’adéquation aux conventions de votre code
Terminal-Bench v2, 84 tâches	utiliser un shell jusqu’à un état final vérifié	la compréhension d’un grand dépôt existant
SWE-Atlas Q&A, 124 tâches	répondre à des questions techniques sur le code	la capacité à livrer le changement décrit
WebDev et Fullstack Arena	ce que les utilisateurs préfèrent lors d’un duel	exactitude, tests, sécurité et maintenabilité
Fiches des fournisseurs	le modèle dans la configuration choisie pour lui	la possibilité de comparer directement les lignes

L’infrastructure est la première source d’incertitude. L’équipe d’ingénierie d’Anthropic a fait varier un score Terminal-Bench 2.0 de six points uniquement en changeant les limites de ressources. Les erreurs d’infrastructure sont passées de 5,8 % à 0,5 % à mesure que ces limites augmentaient [15]. L’équipe conclut qu’un écart inférieur à environ trois points mérite d’être traité avec prudence tant que les configurations ne sont pas documentées et alignées. Kimi et Sol medium se situent dans cette marge. Leur score commun indique donc une égalité, pas une victoire de l’un sur l’autre.

Le deuxième problème vient du manque d’uniformité des tests. Moonshot exécute chaque concurrent dans un harness différent, utilise des modèles de secours sur certaines lignes et inclut son propre benchmark interne. Fable 5 a eu recours à des modèles de secours 13 fois et refusé une tâche sur 80 dans ce test [12]. Moonshot donne ces détails, mais une comparaison perd une grande partie de sa valeur lorsque les résumés les font disparaître.

Enfin, la version du benchmark doit être la même. Artificial Analysis numérote les versions de son indice parce que la sélection des tâches change, et la v1.3 est celle utilisée ici [8]. Deux scores issus de versions différentes ne sont pas directement comparables, même si le nom du benchmark reste identique. Une comparaison utile précise donc le harness, le niveau d’effort, le budget alloué aux tâches et la version. Le recalcul de Muse Spark 1.3 sur l’indice d’Artificial Analysis montre à quel point un changement de version peut déplacer un classement.

Ma répartition : Kimi pour l’UI, GLM sous contrôle automatique

Je testerais Kimi K3 sur les nouveaux projets fullstack et les tâches riches en UI, tandis que GLM-5.2 resterait derrière des contrôles automatiques dans son harness natif. Pour le reste, je confierais encore le travail à Claude ou à GPT-5.6 selon la tâche :

Le travail	Mon choix aujourd’hui
Changements ordinaires avec des tests solides	Sonnet 5, à son tarif permanent de 2 $/10 $
Boucles d’agents rapides et travail de terminal	GPT-5.6 à effort medium ou high
Travail dans un grand dépôt existant	Opus 5 à effort medium ou high
Nouveau projet fullstack riche en UI	Kimi K3, soutenu par les résultats des arènes
Travail en volume avec vérification automatique	GLM-5.2 dans son harness natif, sous forme de test pilote
Dernier recours lorsque les autres échouent	Fable 5, avec parcimonie

Le tableau suit la règle que j’ai appliquée pendant la semaine de lancement d’Opus 5 : comparez le coût des changements approuvés, pas seulement le prix des tokens. Kimi reste ainsi sur les tâches où ses résultats de terminal et d’arène sont les plus solides, tandis que GLM demeure derrière des contrôles automatiques.

Deux mesures pourraient modifier ces choix. Kimi K3 doit conserver son score de 61 dans un harness neutre comme Claude Code ou Codex, ce qui permettrait de séparer les capacités du modèle de l’avantage offert par Kimi Code CLI. GLM-5.2 a besoin du test inverse : une exécution indépendante dans son agent natif par une équipe qui ne le commercialise pas. En attendant, les deux modèles montrent des capacités utiles pour des tâches précises, mais aucun n’offre l’avantage économique général suggéré par son prix par token.