Kimi K3 en pratique : expérience et comparaison avec Claude Code

Sur quelle expérience repose la comparaison Kimi K3 et Claude Code ?#

Kimi K3 a été lancé le 16 juillet 2026. Il compte 2,8 billions de paramètres, dispose d’une fenêtre de contexte d’un million de tokens, a des poids ouverts et occupe la première place dans une comparaison frontend à l’aveugle. J’ai rassemblé tous les détails sur son architecture, ses benchmarks et ses prix dans la revue complète de Kimi K3 face à Claude Code, je ne vais donc pas les répéter ici.

À la fin de cette revue, j’ai écrit que le risque était de perdre une journée en configuration, et que le bénéfice était une facture qui baisse dès la deuxième semaine. J’ai mené l’expérience sur mes propres tâches.

Les premières heures sont vraiment enthousiasmantes. Le modèle se saisit volontiers d’une tâche, produit un travail frontend cohérent et n’hésite pas devant les fichiers volumineux. C’est pourquoi j’ai écrit dans le canal que j’étais agréablement surpris. Les problèmes sont apparus lors de longues sessions, avec plusieurs agents, après des séries de modifications répétées et, le soir, dans le terminal.

Finalement, j’ai fait marche arrière. Voici ce qui m’a conduit à cette décision, chiffres et liens vers les sources primaires à l’appui, pour que vous puissiez tout vérifier par vous-même.

Pourquoi les benchmarks montrent-ils que Kimi K3 dépasse Claude ?#

Voici les benchmarks où Kimi K3 dépasse Claude Fable 5 :

llm-stats a compilé ces benchmarks ; chaque ligne compare le modèle à Claude Fable 5.

Les chiffres sont réels. Sur les 35 benchmarks de la même compilation, Claude Fable 5 en remporte 22, Kimi K3 en remporte douze, et il y a une égalité.

Le plus intéressant, c’est là où Kimi K3 est en retrait. Son déficit sur les benchmarks de programmation est modeste, de 4 à 5 points. Il recule en connaissances et en raisonnement : sur HLE, Claude prend presque 10 points d’avance. C’est précisément là qu’une longue tâche bute : il faut d’abord comprendre, et seulement ensuite écrire.

Moonshot le formule ainsi dans la partie principale de son billet de lancement :

Pourquoi Kimi K3 semble-t-il deux fois plus lent en pratique ?#

Le modèle de comparaison est Claude Opus 4.8, la version de Claude pour laquelle une mesure complète de vitesse est disponible.

Kimi K3 répond plus tôt, ce qui le fait subjectivement paraître plus rapide dans une courte conversation. Au travail, c’est autre chose qui compte : la lenteur avec laquelle arrive la réponse complète. Sur ce point, il est presque deux fois plus lent, et l’écart atteint plusieurs minutes pour une longue réponse.

Kimi Code annonce 180–260 tokens par seconde, un chiffre qui paraît convaincant face à mes 34,7. Il s’agit de la version rapide de la génération précédente, K2.7 Code HighSpeed. Kimi K3 ne dispose pas du tout d’une telle version, et le benchmark indépendant mesure Kimi K3 lui-même.

Une session qui s’interrompt à la septième erreur et brûle des tokens avec des appels répétés révèle un échec de Context Engineering ; le choix du modèle est secondaire ici.

Où passent les tokens si l’on ne peut pas désactiver le raisonnement ?#

On peut réduire le niveau d’effort ; la documentation en indique trois : faible, élevé et maximal. Mais le raisonnement ne peut pas être entièrement désactivé : il est explicitement indiqué que le raisonnement et le stockage de son historique sont toujours activés pour Kimi K3. Lors des appels directs à l’API, le niveau maximal est défini par défaut, et la plupart des programmes wrapper ne le modifient pas.

Chaque tour ajoute des milliers de tokens de sortie, au tarif de $15 par million. De plus, Moonshot exige que vous renvoyiez l’intégralité du message de l’assistant, y compris son historique de raisonnement, et ces tokens de sortie deviennent à nouveau des tokens d’entrée au tour suivant.

Vous payez donc deux fois pour le même raisonnement : d’abord quand le modèle le rédige, puis quand vous le lui renvoyez.

Sur l’indice global, Kimi K3 utilise 21% moins de tokens de sortie que son prédécesseur, K2.6. Le modèle est devenu plus économe par rapport à sa propre version précédente. Claude en utilise toujours moins pour les mêmes tâches.

Le prompt « hi » est facturé 86 tokens. En coulisses, un prompt système caché d’environ 85 tokens est présent, et vous le payez à chaque requête.

J’ai publié un avis distinct sur le calcul de votre consommation et la vérification de votre solde restant : combien de tokens Claude Pro et Max vous donnent. La logique de calcul y est la même ; seuls les prix changent.

Que se passe-t-il quand le modèle reste bloqué dans son raisonnement ?#

Voilà à quoi cela ressemble. Le modèle se met à réfléchir, mais au lieu de développer son raisonnement, le texte se répète : le même mot, puis des fragments de syllabes, sans fin. La tâche piétine pendant que le compteur de tokens continue de tourner.

Un signalement du 28 juillet dans la liste des problèmes connus de Moonshot décrit Kimi K3 essayant de lire le même fichier six fois de suite, recevant sept fois le rejet « no-op call, file hasn’t changed since the previous read », puis terminant le tour comme si de rien n’était. Dans le suivi des problèmes de Kimi CLI, l’auteur décrit quatre variantes du même type de blocage — lecture, remplacement, test et analyse — et résume le tout en une phrase :

Moonshot indique directement la cause. Le modèle a été entraîné dans un mode qui préserve l’historique de raisonnement, et il doit recevoir l’intégralité de son raisonnement antérieur. Si l’historique arrive incomplet, le modèle tente de reconstruire la réponse, produit le même appel d’outil et repart dans une boucle.

L’auteur d’une analyse publiée dans un routeur de requêtes tiers pose le même diagnostic : Kimi est assez strict pour rejeter les requêtes dont l’historique de raisonnement est incomplet. Un wrapper externe ignore cette exigence et tronque l’historique.

Pourquoi une configuration multi-agents s’effondre-t-elle avec Kimi K3 ?#

La documentation officielle de Moonshot l’indique clairement : leur API ne prend pas encore en charge WebFetch. Autrement dit, Claude Code, qui va normalement en ligne récupérer une page, ne peut pas le faire avec Kimi K3. Pour contourner le problème, il faut coller le contenu manuellement ou connecter un outil tiers.

Claude Code peut charger des outils à la demande et place dans l’historique un bloc de service de type tool_reference. Kimi n’accepte pas ce type et renvoie une erreur 400. Il le fait sans explication, sans nommer le champ ni la raison :

{"error":{"type":"invalid_request_error","message":"Invalid request Error"},"type":"error"}

À titre de comparaison, voici à quoi ressemble la même erreur sur l’API native d’Anthropic, où le serveur nomme au moins le champ et énumère les types acceptés :

messages.166.content.0.tool_result.content.0: Input tag 'tool_reference' found
using 'type' does not match any of the expected tags: 'document', 'image',
'search_result', 'text'

La différence compte. Le premier message est impossible à diagnostiquer : ni le client ni la personne qui l’utilise ne peuvent savoir quel bloc a été rejeté. C’est précisément ce que reprochent les auteurs des signalements. Les développeurs de commutateurs de fournisseurs suggèrent déjà de désactiver par défaut le chargement différé des outils pour Kimi ou d’indiquer que l’API Moonshot n’accepte pas ces blocs.

La conséquence est décrite dans un signalement distinct, ouvert le 17 juillet et toujours sans réponse. L’auteur a rencontré cette erreur sept fois au cours d’une session. La session a résisté aux six premières ; la septième l’a définitivement tuée : ensuite, même saisir le texte brut « continue » provoquait son plantage. L’auteur précise par ailleurs qu’il était loin d’avoir atteint la limite de contexte ; l’explication selon laquelle « l’historique était trop long » ne tient donc pas.

Voici un récapitulatif des types de blocs que l’API Moonshot accepte et rejette :

Le mot « compatible » ne décrit ici que le format de la requête. Tout le reste diffère : les types de blocs acceptés, le contenu requis dans l’historique et les outils réellement disponibles.

Qu’est-ce qui ne se transpose pas avec Kimi K3 ?#

La section sur les limites du billet de lancement le dit mot pour mot :

Le développeur du modèle dit donc : utilisez notre client ; nous ne garantissons pas le comportement des autres.

Le deuxième point de cette même section explique une autre chose que j’avais attribuée à l’entêtement du modèle :

Mon fichier CLAUDE.md avait été écrit pour l’habitude inverse : poser des questions, présenter un plan et attendre une confirmation. Les instructions sont toujours là, mais elles sont désormais interprétées par un modèle au tempérament différent.

Si vous voulez conserver un seul fichier de règles pour plusieurs agents, j’ai décrit cette configuration séparément : un fichier d’instructions pour Claude Code, Codex et Cursor.

Combien Kimi K3 a-t-il réellement coûté ?#

D’abord, les prix, qui sont en faveur de Kimi K3 :

Les tarifs de Kimi proviennent de la documentation sur la mise en cache du contexte ; la colonne de droite indique les prix de Claude Opus 5 au 30 juillet 2026.

Le cache de Kimi est automatique, ne peut pas être désactivé et est identifié par le hachage au début de la requête. Toute modification du prompt système ou de la liste d’outils vide entièrement le cache des messages.

Voici ce que fait Claude Code au cours d’une journée de travail normale :

1. Connecter et déconnecter des outils externes à mesure que la tâche avance.
2. Charger des outils à la demande, lorsqu’ils sont nécessaires.
3. Lancer des sous-agents avec un ensemble d’outils différent.
4. Ajouter le fichier d’instructions au prompt système.
5. Reconstruire l’historique lors de la compression du contexte.

Chacune de ces actions réinitialise le début de la requête, et donc le cache. Les tokens d’entrée coûtent à nouveau $3 par million au lieu de 30 cents, soit dix fois plus. S’y ajoute un raisonnement constant à $15 par million de tokens de sortie, et ces mêmes tokens reviennent en entrée au tour suivant. Voilà comment un modèle affiché à bas prix peut produire une facture inattendue.

Selon les données agrégées d’OpenCode, sur près de 280 000 sessions en direct, une session Kimi K3 coûte en moyenne $1.86 et représente un volume moyen de 3,1 millions de tokens. Ce chiffre repose sur 93% des tokens d’entrée pris en charge par le cache. Modifiez le début de la requête, et il ne s’applique plus à votre cas.

Les forfaits Kimi coûtent $19, $39, $99 et $199. Le quota provient d’une réserve commune à l’ensemble de l’abonnement, se réinitialise chaque semaine sans report des quantités inutilisées et utilise une fenêtre glissante de cinq heures. La revue des forfaits le formule ainsi : quatre terminaux exécutant Kimi K3, qui raisonne en permanence, épuisent rapidement une fenêtre de cinq heures.

Le quota de programmation du forfait à $99 est comparable à celui du forfait à $200 d’Anthropic, ce qui va à l’encontre de ma propre position. Kimi coûte moins cher par token, mais cela ne se voit plus sur la facture du soir.

Dans quels domaines Kimi K3 est-il objectivement bon ?#

1. Frontend. Première place dans une comparaison à l’aveugle réalisée par des développeurs en activité. Il construit des mises en page soignées et plutôt élégantes.
2. Volume. Une fenêtre de contexte d’un million de tokens, et les longs fichiers ne l’impressionnent pas. Analyser un grand dépôt et en dresser la carte, c’est le genre de tâche qui lui convient.
3. Première réponse. Le temps avant le premier token est deux fois plus court que pour Claude. La différence est perceptible et agréable dans une courte conversation.
4. Prix par token. Environ 60% du prix de Claude Opus 5. Si le début de la requête ne change pas, cela permet de réelles économies sur les charges de travail volumineuses et répétitives.
5. Poids ouverts. Le modèle n’est pas lié à un seul fournisseur.

Le dernier point comporte une réserve. Faire tourner chez soi un modèle de ce type n’est pas réaliste : même compressés, ses poids se mesurent en téraoctets. Ici, l’ouverture signifie l’indépendance vis-à-vis d’un fournisseur unique.

Comment tester tout cela vous-même en une soirée#

1. Configurez l’accès en suivant les instructions. J’ai décrit les trois variables d’environnement et les substitutions de modèles selon le niveau d’abonnement dans la revue de Kimi K3 face à Claude Code. Vérifiez la configuration avec la commande /status : Kimi n’apparaîtra pas dans le menu de sélection des modèles, car il possède une liste d’alias intégrée, que vous n’avez pas besoin de modifier.
2. Supprimez l’ancienne clé. Si ANTHROPIC_API_KEY était précédemment défini, supprimez-le. Avec ANTHROPIC_AUTH_TOKEN, il provoque un conflit et vous obtiendrez une erreur d’autorisation sans raison valable.
3. Désactivez tout de suite le chargement différé des outils. Faites-le avant le premier lancement, pas après le plantage de la première session.
4. Ne changez pas de modèle au milieu d’une tâche. Si vous avez commencé avec Kimi K3, terminez avec Kimi K3. L’inverse est également vrai. C’est une exigence directe de Moonshot, que j’ai citée plus haut.
5. Utilisez une vraie tâche à vous. Une tâche sur laquelle vous avez travaillé hier, avec tout son désordre et ses fils inachevés. Un jeu de serpent ne montrera pas la différence : elle n’apparaît que dans la durée.
6. Notez deux chiffres. Le nombre de minutes nécessaires et la somme dépensée ce soir-là. Comparez-les à une soirée habituelle avec Claude.
7. Suivez séparément le temps d’inactivité. Quand l’agent se bloque, lit le même fichier en boucle ou répond par une erreur, cela fait aussi partie du coût.

Si la facture de la soirée est plus élevée que prévu, c’est presque toujours le cache : comptez combien de fois le début de la requête a été réinitialisé ce soir-là. Le prix par token y est pour peu.

Ce que j’ai finalement conservé#

Les lecteurs du canal qui ont testé le modèle avec moi sont arrivés indépendamment à la même configuration : ils demandent à Kimi K3 d’inspecter le dépôt et de donner un second avis, tout en laissant le travail principal à leur agent habituel. Cette configuration tient la route parce qu’elle ne nécessite ni de changer de wrapper ni de perturber ce qui fonctionne déjà.

On peut le dire ainsi : une tâche complète va à Kimi K3 ; une longue chaîne impliquant des outils et des sous-agents va à Claude Code. Plus une tâche exige de changements d’outil, plus elle coûte cher avec Kimi K3 et plus le risque d’interruption de session est élevé.

J’ai publié une revue distincte sur la manière d’attribuer des rôles à deux agents sans les confondre : trois façons de travailler avec deux agents.

Les benchmarks répondent à la question « Qui est le plus performant en laboratoire ? » La facture de votre soirée et votre liste de travaux accomplis répondent à la question « Qui est le plus performant pour vous ? » Si les réponses diffèrent, faites confiance à la seconde : c’est vous qui avez calculé, pas le service marketing.

Après avoir examiné tout cela, j’ai pris ma décision : quoi qu’on dise des nouveaux modèles, un leader reste un leader. Claude Code reste mon moteur principal.