Il y a quatre jours, le plus grand modèle d'IA open-weight de l'histoire est discrètement entré en service.
Garde ça :)
Pas de keynote. Pas de live. Moonshot AI a simplement basculé kimi.com du jour au lendemain et a lancé Kimi K3 : 2,8 billions de paramètres, une fenêtre de contexte d'un million de tokens, et une capacité de codage qui vient de faire quelque chose qu'aucun modèle open n'a jamais fait.
Lors des tests humains en aveugle sur Arena, où les développeurs votent pour les résultats sans savoir quel modèle les a produits, K3 a pris la première place dans l'arène Frontend Code. Il a battu Claude Fable 5. Il a battu GPT-5.6 Sol. Première place, pour la création de choses, choisie par des développeurs qui ne savaient pas qu'ils sélectionnaient le modèle open.
La plupart des gens ont vu le titre et sont passés à autre chose. Presque personne ne l'a vraiment poussé à voir ce qu'il construit. Moi si. Voici 20 choses que K3 produit à partir d'un seul prompt, dont la plupart des gens qui discutent des benchmarks n'ont même jamais essayé. Copie les prompts. Teste-les toi-même. Mets ceci en favori avant que ça ne disparaisse.
Une petite note avant la liste, car l'honnêteté est le but principal : K3 est véritablement numéro un mondial pour le code frontend en test aveugle, mais globalement il se situe autour de la quatrième place, approximativement au niveau d'Opus 4.8, et il est derrière Fable 5 et GPT-5.6 Sol sur les benchmarks les plus larges. Là où il gagne, il gagne fort. Cette liste est ce territoire.
D'abord, 60 secondes sur ce qu'est réellement K3
Si tu es nouveau dans ce domaine, voici tout en termes simples avant que nous passions aux constructions.
Kimi K3 est un grand modèle de langage de Moonshot AI, un laboratoire de Pékin fondé par l'ancien chercheur de Google Yang Zhilin et soutenu par Alibaba. Il a été lancé le 16 juillet 2026 en deux versions : une version Max pour le chat et le travail d'agent, et une version Swarm conçue pour les tâches parallèles à grande échelle.
Le nombre de 2,8 billions de paramètres semble impossible à faire tourner, et ça le serait, sauf que K3 est un modèle Mixture-of-Experts. Imagine un bâtiment avec 896 spécialistes au lieu d'un seul énorme cerveau. Pour une tâche donnée, il ne réveille que les 16 spécialistes les plus adaptés, environ 1,8 % du total, et les autres restent endormis. Ainsi, il porte la connaissance d'un modèle de 2,8 billions de paramètres tout en coûtant bien moins cher à faire tourner. Énorme sur le papier, léger en pratique. C'est l'astuce qui rend tout ce qui suit abordable.
Ajoute trois choses à cela : une fenêtre de contexte d'un million de tokens, donc une base de code entière ou une pile de longs documents tient dans sa mémoire à la fois ; une entrée multimodale native, donc il lit les images et les vidéos directement plutôt que via un module complémentaire ; et un raisonnement toujours actif, que Moonshot appelle « mode de réflexion », donc il résout les problèmes par défaut. Cette dernière chose est une épée à double tranchant sur laquelle nous reviendrons.
Voilà la machine. Maintenant, voici ce qu'elle fait.
Partie 1 : Jeux et mondes 3D (Là où il bat tout)
C'est la catégorie qui a valu à K3 sa première place dans l'arène. Le mur entre « décrire un objet 3D » et « avoir un objet 3D fonctionnel » est désormais un seul prompt.
1. Jeux de navigateur jouables avec une vraie physique. Pas une démo ressemblant à un jeu. Des scènes jouables avec des réactions aux coups, des retours d'impact, et une physique qui se comporte réellement. Des gens ont sorti des arènes de combat avec effets visuels, des parcours de ville 3D dans le navigateur avec mécaniques de grappin, des courses en vue de dessus, et des jeux de zombies à partir d'un seul prompt. Le détail qui distingue K3 ici est qu'il gère les vingt petites choses qui cassent normalement : la réponse aux collisions, l'élan, le ressenti de la caméra.
1Crée un jeu de navigateur en un seul fichier : une arène en vue de dessus où le joueur esquive et tire sur des vagues d'ennemis. WebGL ou canvas, pas de ressources externes. Inclus : un véritable élan de mouvement, des réactions de l'ennemi aux coups, un tremblement d'écran lors de l'impact, un compteur de score, et un bouton de redémarrage. Cible 60 fps. Fais en sorte que ce soit réactif, pas flottant. Construis le tout.
2. Produits 3D interactifs qui ressemblent à des rendus, pas à des démos. Une montre avec une brillance et un comportement de lumière corrects. Un appareil photo que tu peux démonter. Un objet mécanique modélisé comme des dizaines de pièces individuelles qui s'assemblent et se désassemblent au clic. La différence avec toutes les tentatives précédentes de « l'IA construit un truc 3D » est la précision des matériaux : rugosité, métallisation, et de vraies ombres au lieu d'un plastique plat.
3. Simulations physiques qui sont calculées, pas animées. Un tissu qui tombe en drapé. Une structure qui s'effondre sous son propre poids. Deux véhicules entrant en collision en plein air avec un transfert d'élan qui semble correct plutôt que scripté. Des surfaces océaniques avec une véritable dynamique des vagues. Demande à K3 de calculer la physique et de commenter les maths pour que tu puisses vérifier, et il le fera.
1Crée trois scènes HTML5 canvas avec physique calculée, sans bibliothèques, un fichier chacune : (1) un pont qui s'effondre et laisse tomber un véhicule dans l'eau avec déplacement, (2) du tissu tombant sur un objet invisible, (3) une pile de blocs qui bascule suite à une poussée. Physique calculée, pas animée, 60 fps, bouton de réinitialisation, et commente les équations. Ne pose pas de questions d'abord.
4. Scènes visuelles Shader et WebGPU. Le truc graphique vraiment difficile. Un trou noir avec lentille gravitationnelle qui courbe le champ d'étoiles derrière lui. Des systèmes de particules avec des milliers de points. Un terrain procédural qui se génère pendant que tu te déplaces. C'est le travail qui nécessitait auparavant quelqu'un qui écrit du GLSL pour vivre, et K3 va le rédiger, puis l'affiner par rapport à une barre de qualité que tu définis. L'astuce est de nommer le standard à voix haute, « ça devrait ressembler à une entrée de demoscene, pas à un tutoriel », car K3 répond bien plus aux standards qu'aux instructions.
1Crée une scène WebGL en un seul fichier : un trou noir avec lentille gravitationnelle qui courbe visiblement un champ d'étoiles derrière lui, plus un disque d'accrétion avec une couleur basée sur la température. Ajoute des contrôles d'orbite. Barre de qualité : ça devrait ressembler à une visualisation scientifique, pas à un tutoriel shader. Construis le fichier.
Partie 2 : Produits et interfaces réels
Au-delà du plaisir visuel, la force frontend de K3 se transforme en travail de produit livrable.
5. Pages d'atterrissage qui ont l'air conçues, pas basées sur un template. Donne-lui un produit et une esthétique (« brutaliste », « éditorial chaleureux », « fintech propre ») et il produit une page avec une véritable hiérarchie typographique et une intention de mise en page, pas le look générique de l'IA. Définis le standard explicitement et il l'atteint.
6. Échafaudages d'applications full-stack à partir d'un cahier des charges. Décris le produit, la stack et les fonctionnalités, et K3 échafaude le frontend, le backend, le schéma de base de données et la couche d'authentification ensemble, câblés plutôt que des snippets déconnectés. Ce n'est pas un jouet ; c'est une base de code de départ que tu renforces, ce qui est exactement le but de sa conception à long horizon. Donne-lui tout le cahier des charges en un seul prompt et laisse-le construire par étapes.
1Construis l'échafaudage d'une application web de suivi d'habitudes. Stack : frontend React, API Node/Express, Postgres, authentification par email et mot de passe. Fonctionnalités : inscription utilisateur, créer/éditer/supprimer des habitudes, check-ins quotidiens, un compteur de séquences, et une vue de résumé hebdomadaire. Construis d'abord le schéma de base de données, puis l'API, puis l'UI. Câble-les ensemble et note tout ce que je devrais configurer pour l'exécuter.
7. Fonctionnalités collaboratives en temps réel qui restent réellement synchronisées. C'est là que les modèles plus faibles trichent discrètement. L'état en temps réel doit se synchroniser entre les clients, pas seulement être sauvegardé dans une base de données, et les bugs n'apparaissent qu'avec deux navigateurs ouverts. K3 gère la couche WebSocket, la reconnexion et la synchronisation multi-client, et tu peux le forcer à prouver le travail.
1Ajoute une couche collaborative en temps réel à une application : curseurs en direct plus épingles de commentaires cliquer-déposer, comme Figma. Utilise WebSocket (Socket.io ou ws natif). Exigences : curseurs des autres utilisateurs affichés en direct, commentaires apparaissent instantanément pour tout le monde, reconnexion gracieuse sans curseurs fantômes, mises à jour de curseurs debounced. Construis-le de bout en bout, puis prouve que la synchronisation fonctionne avec deux clients simulés avant de le déclarer terminé.
8. Tableaux de bord et visualisations de données à partir de données brutes. Donne-lui un CSV et une question, et il construit un tableau de bord interactif, des graphiques, des filtres, et tout le reste, en un seul passage. Son raisonnement sur les graphiques et figures est l'une de ses forces documentées, donc il ne se contente pas de tracer les données, il raisonne sur ce que les données montrent.
Partie 3 : Ingénierie sérieuse (Le superpouvoir à long horizon)
K3 a été conçu pour des sessions de codage soutenues à travers d'énormes bases de code. C'est la partie qui compte si tu écris du logiciel pour vivre.
9. Travail sur l'ensemble du dépôt avec un objectif mesurable. La manière la plus puissante d'utiliser K3. Ne lui donne pas une tâche, donne-lui un résultat et laisse-le travailler jusqu'à ce que le nombre bouge.
1Lis toute cette base de code avant de changer quoi que ce soit.2Objectif : réduire le temps de réponse p95 sur l'endpoint /search de 30 %.3Règles : profile d'abord et montre-moi où va le temps ; ne change pas les interfaces ou sorties publiques ; exécute les tests après chaque changement ; si un changement empire les choses, annule-le et dis pourquoi. Travaille jusqu'à ce que l'objectif soit atteint ou que tu puisses prouver qu'il ne peut pas l'être sans enfreindre une règle.4Termine par un journal : ce que tu as changé, ce que ça a apporté, ce que tu as essayé qui a échoué.
10. Mettre un véritable dépôt entier en contexte d'un seul coup. La fenêtre d'un million de tokens n'est pas un argument de fiche technique ici. Tu peux charger une véritable base de code et poser des questions au niveau de l'architecture, écrire de la documentation, ou tracer un bug à travers des dizaines de fichiers, car le modèle peut réellement voir l'ensemble plutôt que de deviner les parties que tu n'as pas collées. C'est la plus grande différence pratique entre K3 et un modèle avec une fenêtre plus petite : il raisonne sur ton système, pas sur des fragments. Une nuance à savoir cependant : un dossier serré de 200 000 tokens des fichiers importants bat généralement un monorepo gonflé de 900 000 tokens, car c'est la concentration, pas le volume, d'où vient sa force à long horizon.
11. Migrer du code entre frameworks ou langages. K3 est à la pointe de l'ingénierie logicielle multilingue, donc porter un service d'un langage à un autre, ou d'un framework à son successeur, est carrément dans son domaine de compétence, y compris les cas limites ennuyeux qui sont généralement oubliés. Parce qu'il garde tout le projet en contexte, il maintient un comportement cohérent tout au long de la migration au lieu de traduire fichier par fichier et de changer silencieusement ce que le code fait.
12. Sessions autonomes avec une condition de succès vérifiable. K3 peut fonctionner longtemps, largement sans surveillance, mais seulement bien quand l'objectif est vérifiable. « Améliore le code » le fait divaguer. « Fais passer ce test » ou « atteins ce benchmark » lui donne une cible vers laquelle il peut travailler sans dériver. Donne toujours une tâche à long horizon un nombre, pas une ambiance.
Partie 4 : Agents, outils et recherche
K3 est proche du sommet des benchmarks d'utilisation d'outils et de recherche web, ce qui en fait un opérateur, pas seulement un rédacteur.
13. Orchestration du terminal et du navigateur. Il pilote le shell, le navigateur et les appels API sans se désintégrer, ce qui est le tissu conjonctif dont chaque véritable tâche d'agent a besoin. Dirige-le vers un objectif qui nécessite de chercher des choses et d'agir dessus, et il enchaîne les étapes lui-même au lieu de s'arrêter pour te demander quoi faire à chaque embranchement.
1Objectif : trouver les trois fonctionnalités les plus demandées dans les issues GitHub de ce projet open-source, puis rédiger un court cahier des charges pour la première.2Étapes : cherche les issues du dépôt, classe par nombre de réactions et volume de commentaires, identifie les trois premières, choisis celle avec le plus d'impact, et écris un cahier des charges d'une page avec le périmètre, les cas limites et un plan d'implémentation approximatif. Montre ton travail.
14. Recherche web approfondie, augmentée par des outils. K3 est à la pointe sur les benchmarks de navigation. Donne-lui une question de recherche et il cherche, lit les sources primaires, fait des recoupements, et revient avec quelque chose de structuré et cité, dans le temps qu'il fallait auparavant pour parcourir dix onglets.
15. Travail parallèle massif via la variante Swarm. K3 a été lancé en deux versions, et la variante Swarm est conçue pour le traitement parallèle à grande échelle : répartir un gros travail par lots sur de nombreux sous-agents à la fois, puis fusionner les résultats, au lieu de le traiter un élément à la fois.
16. Transformer une pile de documents en un livrable unique. Pointe-le vers un dossier de PDFs ou un long corpus de recherche et demande une sortie synthétisée, une revue de littérature, un tableau comparatif, un briefing, et il traite l'ensemble et rend le résultat assemblé plutôt que quinze résumés séparés.
Partie 5 : Multimodal et mouvements puissants
K3 lit le texte, les images et les vidéos de manière native, et cela déverrouille une classe de travail différente.
17. Capture d'écran ou maquette directement en code fonctionnel. Montre-lui une maquette de design ou une capture d'écran d'une interface et il écrit le frontend qui la reproduit. La vision native combinée à sa couronne frontend en fait l'une des choses les plus immédiatement utiles de cette liste pour quiconque construit une UI.
18. Raisonnement sur les graphiques, figures et mathématiques visuelles. Donne-lui un graphique, un diagramme ou un problème de maths photographié et il ne se contente pas de décrire l'image, il raisonne dessus, extrait les nombres et travaille avec eux, soutenu par Python quand la tâche nécessite un vrai calcul. Documenté comme l'un de ses domaines de pointe.
19. Compréhension vidéo en entrée. Parce que l'entrée multimodale inclut la vidéo, tu peux lui donner une séquence vidéo comme contexte plutôt que de transcrire d'abord, et lui faire raisonner sur ce qui s'est réellement passé à l'écran.
20. Posséder le modèle totalement après le 27 juillet. Le plus grand mouvement puissant est celui que la plupart des gens comprennent mal. Le 27 juillet, les poids complets de K3 deviennent open sous une licence permissive. Pour une équipe sérieuse, cela signifie auto-hébergement sur votre propre matériel, fine-tuning sur vos propres données, inspection exacte de son comportement, et ne dépendre d'aucune API qui reste en ligne ou de conditions qui restent favorables. Cette indépendance, sur un modèle proche de la frontière, est la partie qui remodèle réellement le marché.
Deux avertissements honnêtes avant de plonger
Parce qu'une liste de superpouvoirs sans les petits caractères, c'est ainsi que les gens gaspillent de l'argent et se brûlent.
Ne fais pas de K3 ton modèle par défaut pour tout. Son raisonnement est toujours actif. Il réfléchit intensément à chaque requête, ce qui est magnifique pour les vingt choses ci-dessus et absurde pour formater une liste ou renommer des variables. Les premiers testeurs l'ont vu brûler des milliers de tokens de raisonnement sur des tâches qui devraient coûter une fraction de centime. Oriente le travail trivial vers un modèle plus petit et plus rapide, et réserve K3 pour les tâches qui justifient la puissance. C'est l'erreur la plus coûteuse que les nouveaux utilisateurs font.
Une nuance sur le coût qui va dans l'autre sens cependant : le prix de l'API de K3 est de 3 $ par million de tokens d'entrée et 15 $ par million de tokens de sortie, c'est milieu de gamme, pas bon marché, mais il a tendance à utiliser moins de tokens de sortie pour terminer un vrai travail que des modèles plus chers qui divaguent pour arriver à la même réponse. Donc la façon honnête de l'évaluer est le coût par tâche terminée, pas le coût par token. Sur le travail pour lequel il est conçu, la facture totale est souvent inférieure à ce que le prix affiché suggère. Sur un travail trivial, la réflexion toujours active efface complètement cet avantage, ce qui est exactement pourquoi l'orientation est importante.
« Poids ouverts » ne signifie pas « fonctionne sur ton portable ». Quand les poids seront disponibles le 27 juillet, tu ne télécharges pas K3 sur ton MacBook. Même fortement compressé, il fait bien plus d'un téraoctet et nécessite des dizaines de puces d'accélération pour fonctionner. Les poids ouverts sont un cadeau pour les organisations qui peuvent s'auto-héberger et pour les chercheurs qui peuvent faire du fine-tuning, pas un modèle privé pour ton PC de jeu. Pour presque tout le monde, « utiliser K3 » signifie l'application ou l'API, et c'est parfaitement bien.
Comment l'essayer aujourd'hui
→ Chat : kimi.com, en ligne maintenant, le moyen sans configuration d'exécuter chaque prompt ci-dessus.
→ API : compatible OpenAI-SDK, donc passer d'une configuration OpenAI ou Anthropic est une URL de base et une chaîne de modèle, pas une réécriture.
→ Dans ta base de code : installe le CLI Kimi Code à partir des instructions officielles sur kimi.com, ouvre ton projet, et laisse-le planifier, éditer et tester avec un accès direct aux fichiers.
→ Poids : sortie open complète prévue pour le 27 juillet, la date à laquelle cela cesse d'être un service que tu loues et devient quelque chose que quiconque avec le matériel peut posséder.
Pourquoi c'est plus grand qu'un benchmark
Recule des prompts un instant, car le contexte est la véritable histoire.
Moonshot a construit un modèle de classe frontière de 2,8 billions de paramètres sous trois ans de contrôles à l'exportation américains croissants sur les puces exactes dont tu aurais normalement besoin pour entraîner quelque chose de cette taille. Ils l'ont fait par ingéniosité architecturale plutôt que par puissance de calcul brute, et ensuite, au lieu de le verrouiller derrière une API pour toujours, ils ont annoncé qu'ils donneraient les poids. La sortie a été programmée pour arriver juste avant la Conférence mondiale sur l'intelligence artificielle à Shanghai, ce qui n'est pas une coïncidence.
La question intéressante n'a jamais été « la Chine a-t-elle rattrapé son retard ». C'est ce qui arrive à l'économie des modèles frontière fermés et coûteux quand un modèle libre et ouvert atterrit dans le même niveau. Quand la capacité de niveau frontière cesse d'être quelque chose que seulement trois entreprises peuvent vendre, et devient quelque chose que toute équipe bien dotée peut télécharger, le pouvoir de fixation des prix des laboratoires fermés change. Cette pression est l'événement réel ici, plus que n'importe quel nombre de benchmark unique.
Il y a aussi une véritable question ouverte qui plane. Les régulateurs chinois discutent de leurs propres règles d'exportation d'IA, donc savoir si K3 est la dernière grande sortie open-weight de ce côté ou la première de nombreuses est vraiment incertain. Quoi qu'il en soit, le modèle est sorti, et il ne rentrera pas.
Le vrai à retenir
Pendant trois ans, l'accord était simple : les laboratoires américains construisaient la frontière, et tous les autres obtenaient une copie moins chère six mois plus tard. Kimi K3 a brisé cela. C'est le plus grand modèle open jamais créé, c'est le modèle numéro un mondial pour le code frontend en test humain aveugle, et dans une semaine, il devient libre.
Ce n'est pas les tokens les moins chers, il ne domine pas tous les classements, et tu ne le feras pas tourner chez toi. Tout est vrai, et rien ne change le titre : un modèle de niveau frontière qui bat les vaisseaux amiraux fermés pour construire des choses est sur le point d'appartenir à tout le monde.
Les vingt prompts ci-dessus sont ton avance. Les personnes qui les exécutent réellement cette semaine sauront ce que ce modèle peut faire pendant que tout le monde discute encore d'un tableau de benchmark.
La plupart des gens liront le tweet de lancement et n'ouvriront jamais le modèle. Ceux qui passent une soirée à construire avec lui auront un mois d'avance sur toute la chronologie.
Je décortique chaque grande sortie d'IA sans le battage médiatique, et je te donne les prompts pour l'essayer toi-même. Suis-moi pour la prochaine, et mets ceci en favori tant que K3 est encore d'actualité.
Comment l'essayer :
→ Chat et application : kimi.com
→ API : compatible OpenAI-SDK
→ Poids ouverts : prévus pour le 27 juillet
Si tu as trouvé cela utile, suis-moi @eng_khairallah1 pour plus de contenu IA comme celui-ci. Je publie des analyses, des cours et des outils chaque semaine.
j'espère que cela t'a été utile, Khairallah ❤️**
