Kimi K3 dans OpenClaw comparé à dsh : 5 tâches sur 5, 9 fois plus lent, 48 fois le coût

J’ai orienté mon agent de travail OpenClaw vers Kimi K3, le modèle de raisonnement phare de Moonshot, et je l’ai soumis aux mêmes cinq petites tâches de programmation que j’avais utilisées en août pour évaluer DeepSeek Harness (dsh). Kimi a réussi les cinq tests. Le même jour, j’ai de nouveau exécuté dsh sur DeepSeek V4-Flash, à deux reprises. Comparé à la deuxième exécution (cache déjà chaud), Kimi a mis environ 9 fois plus de temps pour terminer (309,9 s contre 35,7 s) et coûté environ 48 fois plus cher (0,531 $ contre 0,011 $). Comparé à la première exécution de dsh avec un cache froid (44,8 s, 0,024 $), l’écart est d’environ 7× en temps et de 22× en coût.

Ensuite, j’ai confié à Kimi le cahier des charges concernant la création d’un logo en pixel art, celui même sur lequel dsh s’était basé pour générer son widget. Il a fallu trois tentatives. La première n’a produit aucun widget. La deuxième a généré un widget complet mais dans le mauvais dossier ; mon délai d’attente ayant été atteint, la réponse s’est interrompue, si bien que je ne l’ai pas remarquée tout de suite. La troisième tentative a enfin abouti, après que j’aie raccourci le cahier des charges et demandé à Kimi de sauter la phase de planification. Le widget ci-dessous provient de cette troisième tentative ; le piège lié à la configuration dans l’Étape 2 est d’ailleurs le point le plus intéressant à retenir.

Configuration : sur quoi j’ai exécuté le test

Voici les commandes que j’ai lancées sur ma machine le 11/09/2026, ainsi que leurs sorties réelles :

$ node -v
v24.18.0
$ openclaw --version
OpenClaw 2026.9.2 (3928bad)
$ dsh --version
0.1.1-rc.2
$ openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'
{"id":"moonshot","enabled":true,"version":"2026.9.2"}
$ openclaw config get models.providers.moonshot.models.0.compat
{
  "supportsReasoningEffort": true,
  "supportsTemperature": false,
  "supportedReasoningEfforts": [
    "low",
    "high",
    "max"
  ]
}
$ openclaw config get models.providers.moonshot.models.0.contextTokens
262144

Deux points importants à savoir avant d’exécuter quoi que ce soit :

• K3 effectue toujours un raisonnement. Le plugin envoie par défaut reasoning_effort: "max" et accepte les valeurs low, high et max ; j’ai exécuté le benchmark avec --thinking max. K3 supprime également les paramètres de sampling (temperature, top_p, etc.) car il les fixe lui-même ; ma configuration du modèle indique d’ailleurs la même chose via supportsTemperature: false. Même pour une demande du type « Répondez exactement : PONG. », 53 tokens de raisonnement ont été nécessaires ; prévoyez donc un budget suffisant à cet effet.
• Le contexte de 1 million de tokens est annoncé, mais je le limite. Le catalogue Moonshot d’OpenClaw indique que K3 gère jusqu’à 1 048 576 tokens de contexte. J’ai toutefois défini contextTokens: 262144 dans la configuration du modèle, afin que les sessions se compactent au même moment que celles de mes autres modèles. Dans la pratique, on peut donc s’attendre à 256 000 tokens, et non 1 million. Si vous augmentez cette limite, les coûts liés à la lecture du cache ainsi que la latence par tour augmenteront proportionnellement à la taille de la session.

La procédure, du niveau de base à l’avancé

Les étapes 1 à 3 vous permettent d’obtenir un modèle fonctionnel. Les étapes 4 et 5 correspondent à ce que j’ai fait ensuite.

Étape 1 : installer le plugin et lui fournir la clé

Il s’agit des étapes décrites dans la documentation Moonshot d’OpenClaw. Sur ma machine, le plugin et la clé étaient déjà configurés ; j’ai donc simplement exécuté la vérification indiquée à la dernière ligne (son résultat figure dans le bloc de configuration ci-dessus).

openclaw plugins install @openclaw/moonshot-provider
openclaw gateway restart
openclaw plugins list --json | jq -c '.plugins[] | select(.id=="moonshot") | {id, enabled, version}'

Le plugin lit la clé depuis MOONSHOT_API_KEY. Je la conserve dans le fichier d’environnement chargé par mon service de passerelle ; mon fichier openclaw.json ne contient quant à lui aucune clé. La documentation propose également openclaw onboard --auth-choice moonshot-api-key si vous préférez suivre une procédure guidée. Le point de terminaison par défaut est https://api.moonshot.ai/v1, tandis que la région Chine utilise https://api.moonshot.cn/v1 (option d’authentification : moonshot-api-key-cn).

Le catalogue du plugin inclut K3, K2.7 Code et K2.7 Code HighSpeed. Il gère automatiquement les particularités liées à Kimi : pour K2.7, il faut omettre à la fois thinking et reasoning_effort dans la requête, ce que le plugin fait lui-même. Faites attention au nom de la variable d’environnement : MOONSHOT_API_KEY concerne la plateforme Open d’Moonshot, tandis que KIMI_API_KEY est destinée à l’abonnement Kimi Code (kimi/kimi-for-coding).

Étape 2 : indiquez à votre agent de travail de se connecter à K3

Les parties pertinentes de mon fichier openclaw.json lors du benchmark, avec mon agent de travail renommé en worker :

{
  agents: {
    entries: {
      worker: {
        model: {
          primary: "moonshot/kimi-k3",
          fallbacks: ["deepseek/deepseek-v4-flash", "deepseek/deepseek-v4-pro"],
        },
      },
    },
  },
  models: {
    providers: {
      moonshot: {
        baseUrl: "https://api.moonshot.ai/v1",
        api: "openai-completions",
        timeoutSeconds: 1200,
        models: [
          {
            id: "kimi-k3",
            name: "Kimi K3",
            reasoning: true,
            input: ["text", "image"],
            cost: { input: 3, output: 15, cacheRead: 0.3, cacheWrite: 0 },
            contextWindow: 1048576,
            maxTokens: 131072,
            contextTokens: 262144,
            compat: {
              supportsTemperature: false,
              supportsReasoningEffort: true,
              supportedReasoningEfforts: ["low", "high", "max"],
            },
          },
        ],
      },
    },
  },
}

Un piège m’a coûté une régression silencieuse : dans OpenClaw 2026.9.2, un bloc compat dans votre entrée de modèle remplace l’objet compat propre au plugin. Il ne se fait pas de fusion. Une version antérieure de mon entrée ne spécifiait que supportsTemperature: false, ce qui a eu pour effet de désactiver silencieusement la prise en charge du paramètre reasoning-effort par le plugin. Si vous écrivez quoi que ce soit dans compat, veillez à écrire l’objet complet, comme ci-dessus.

Étape 3 : le test de validation, et le JSON qu’il génère

Chaque tâche de benchmark correspondait à un appel de ce type, avec à chaque fois une clé de session nouvelle :

openclaw agent --agent <your-agent-id> --model moonshot/kimi-k3 --thinking max \
  --session-key "<fresh-key>" --message-file prompt.txt --json > out.json

Voici les champs importants, extraits de l’enveloppe enregistrée pour la tâche PONG :

$ jq '.result | {harness: .meta.agentMeta.agentHarnessId, model: .meta.executionTrace.winnerModel, usage: .meta.agentMeta.usage}' out.json
{
  "harness": "openclaw",
  "model": "kimi-k3",
  "usage": {
    "input": 15068,
    "output": 70,
    "reasoningTokens": 53,
    "total": 15138,
    "cost": {
      "total": 0.046254
    }
  }
}

harness: "openclaw" indique que le tour s’est exécuté dans la boucle propre à OpenClaw ; un tour exécuté via le serveur d’applications Codex afficherait "codex". winnerModel: "kimi-k3" signifie que le tour a bel et bien été traité par K3, sans recours à un modèle moins coûteux. reasoningTokens est compté dans output (le total correspond à l’input plus l’output) ; ainsi, les 53 tokens de raisonnement font partie des 70 au total.

Le benchmark : les mêmes 5 tâches

Il s’agit des cinq mêmes tâches testées dans l’article sur dsh ; chaque tâche a été exécutée dans un dossier temporaire distinct, avec une nouvelle session pour chaque tâche sous Kimi. J’ai de nouveau lancé dsh sur V4-Flash le même jour, en spécifiant deepseek-v4-flash dans un fichier de configuration. Le premier passage a nécessité 44,8 secondes et coûté 0,024 $ avec un cache froid ; la colonne ci-dessous indique le deuxième passage, avec cache chaud, qui représente le résultat le plus rapide et le moins cher obtenu avec dsh – c’est celui utilisé pour tous les calculs dans cet article, sauf indication contraire. Le libellé des invites n’était pas identique : dsh s’exécute depuis le dossier où on le lance, donc ses invites mentionnaient « le répertoire courant » ; celles de Kimi indiquaient le chemin absolu de chaque dossier de tâche. De plus, l’invite de correction de bug de Kimi ajoutait : « si pytest n’est pas disponible, installez-le d’abord avec ‘pip install --user pytest’ » (or pytest était déjà installé, et Kimi ne l’a jamais installé). Les colonnes V4-Pro et Gemma-4-26B proviennent de l’article sur dsh publié en août ; elles n’ont pas été recalculées. Le temps total indiqué correspond à l’ensemble du processus. Les données relatives aux tokens et au coût pour Kimi proviennent de l’enveloppe JSON fournie par OpenClaw, tandis que celles concernant dsh viennent de ses propres journaux de session.

Tâche	Kimi K3	dsh V4-Flash (même jour)	dsh V4-Pro (août, données historiques)	Gemma-4-26B (août, données historiques)
Répondre « PONG » (démarrage + un appel)	✅ 6,1 s · 0 outils	✅ 1,7 s · 0 outils	✅ 2,8 s	✅ 13,2 s*
Écrire et exécuter FizzBuzz	✅ 22,8 s · 2 outils (écriture, exécution)	✅ 5,3 s · 3 outils	✅ 8,4 s · 2 outils	✅ 4,9 s · 2 outils
Corriger 2 bugs afin que les tests unitaires passent (tests inchangés)	✅ 86,6 s · 6 outils (exécution, écriture, modification)	✅ 11,3 s · 7 outils	✅ 15,8 s · 7 outils	✅ 10,4 s · 8 outils
Résumer un code source de 6 modules (<150 mots)	✅ 65,5 s · 10 outils (lecture, exécution, écriture)	✅ 5,1 s · 7 outils	✅ 10,9 s · 7 outils	✅ 12,1 s · 7 outils
Renommer une fonction dans 3 fichiers + tests, et vérifier que tout passe	✅ 128,9 s · 9 outils (exécution, écriture ; un seul sed sur tous les fichiers)	✅ 12,3 s · 11 outils	✅ 18,2 s · 12 outils	✅ 12,2 s · 11 outils
Temps total	309,9 s	35,7 s	56,1 s	52,8 s
Tokens : entrée non mise en cache / lecture du cache / sortie (raisonnement)	91 470 / 355 328 / 9 990 (4 053)	6 141 / 147 328 / 4 697 (1 984)	41,4 k / 107 k / 3,2 k	40,5 k / 237 k / 5,6 k
Coût	≈ 0,531 $ (3 $ / 15 $ / 0,30 $ par million)	≈ 0,011 $ (0,44 $ / 1,32 $ / 0,014 $ par million)	≈ 0,072 $	0 $ (seulement consommation électrique)

Le nombre d’outils indiqué correspond au nombre d’appels d’outils. Pour Kimi, ces chiffres proviennent de toolSummary.calls dans l’enveloppe JSON d’OpenClaw ; les types d’outils sont indiqués entre parenthèses. Pour dsh, ils viennent de ses journaux de session. *Premier appel après que le modèle a été chargé sur la machine. Les tarifs appliqués pour Kimi correspondent à ceux figurant dans ma fiche de catalogage OpenClaw, utilisée pour calculer le coût de chaque tâche ; consultez la page tarifaire de Moonshot pour les chiffres actuels. Le coût associé à dsh V4-Flash repose sur les mêmes tarifs maximums indiqués dans l’article sur dsh (tarifs DeepSeek) ; les données pour V4-Pro et Gemma proviennent de cet article.

Ce que le tableau montre :

• 5/5 dans chaque colonne. Aucune des tâches n’a posé problème à Kimi. Le mot « PONG » est bien revenu comme demandé. FizzBuzz a affiché les 15 lignes attendues. La correction des bugs consistait en deux modifications d’une seule ligne chacune (un return manquant et un == 1 qui aurait dû être == 0) ; les tests, inchangés, ont tous été validés. Le résumé se limitait à un paragraphe de 107 mots décrivant correctement six modules identiques chargés de récupérer, transformer et valider des données. Pour le renommage, il suffisait d’un seul sed sur quatre fichiers, ce qui a également modifié le nom de la fonction dans les tests ; tous ces tests ont ensuite réussi. Ma demande exigeait un grep vide sur l’ensemble du dossier, où se trouvait aussi mon propre fichier d’invite : Kimi a donc appliqué le même sed sur ce fichier et l’a mentionné dans sa réponse. Il s’agit de tâches simples ; je n’ai pas testé de refactorisation impliquant plusieurs fichiers.
• Kimi consacre plus de ressources au raisonnement. K3 a utilisé respectivement 53, 241, 315, 1 586 et 1 858 tokens de raisonnement pour les cinq tâches (soit 4 053 au total). dsh sur V4-Flash effectue aussi du raisonnement, mais en moindre quantité : 0, 52, 834, 5 et 1 093 tokens (1 984 au total). La majeure partie du temps supplémentaire consommé par Kimi est due à ce processus de réflexion ainsi qu’à des étapes supplémentaires.
• Le cache joue un rôle décisif sur le coût. Chaque tâche sous Kimi commence avec environ 15 000 tokens correspondant au prompt système et aux définitions d’outils. Au total, Kimi a envoyé 91 470 tokens d’entrée non mis en cache et en a lu 355 328 depuis le cache (dont 157 952 pour la seule tâche de renommage) ; ainsi, 80 % des tokens utilisés provenaient du cache, facturés à 0,30 $ par million au lieu de 3 $. Sans le cache, le coût total aurait été d’environ 1,49 $ au lieu de 0,53 $, soit une réduction d’un tiers. Ce tarif reste cependant élevé : 0,30 $ représente environ 21 fois le prix du cache pour dsh V4-Flash, fixé à 0,014 $ par million.
• Pour de petites tâches, V4-Flash est imbattable. Comparé au passage avec cache chaud, dsh s’est avéré environ 9 fois plus rapide et 48 fois moins cher pour obtenir le même résultat. Comparé au cas avec cache froid, ces ratios étaient respectivement de 7 et 22. Dans tous les cas, le verdict est identique. La tâche de renommage a demandé à Kimi 128,9 secondes et 0,180 $, tandis que dsh n’a eu besoin que de 12,3 secondes et de 0,0043 $.

Aperçu comparatif : Kimi K3 dans OpenClaw vs dsh

Il s’agit tous deux de boucles d’agents capables de lire des fichiers, d’exécuter des commandes shell et de facturer au nombre de tokens utilisés. Ils diffèrent toutefois par leurs créateurs ainsi que par la manière de les utiliser.

	Kimi K3 dans OpenClaw	dsh
Qui en est le créateur	Modèle : Moonshot AI. Boucle d’agent : OpenClaw	DeepSeek (modèle et outil), MIT
Appel depuis un script	openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json	dsh --profile headless "…"
Changer de modèle	Paramètre model.primary dans le fichier openclaw.json	~/.dsh/settings.yaml
Benchmark en mode headless, 5 petites tâches	309,9 s, ≈ 0,531 $ ; 5/5 réussies	35,7 s, ≈ 0,011 $ ; 5/5 réussies (V4-Flash, passage en mode « warm ») ; passage en mode « cold » : 44,8 s, ≈ 0,024 $
Génération d’un widget pixel-art, même consigne	3 tentatives ; deux ont donné un résultat valable ; celle présentée ici a nécessité 7,4 min et coûté ≈ 0,47 $	2 tentatives ; la réussie a pris 25 min et coûté ≈ 49¢
Version testée	OpenClaw 2026.9.2, plugin Moonshot 2026.9.2	0.1.1-rc.2 (version préliminaire pour développeurs)

Dans les comparaisons antérieures publiées sur ce site, il y avait une colonne dédiée à Reasonix. J’ai désactivé Reasonix sur ma machine le 2026-09-09 ; il n’apparaît donc pas ici. Son article de juillet reste disponible en tant que document historique. J’ai également testé MiniMax M3 avec le même ensemble de tests ; MiniMax est une entreprise distincte de Moonshot, et ce test fait l’objet d’un article séparé.

Le test amusant : même cahier des charges pour les widgets, Kimi vs dsh

Dans l’article de dsh, le « test amusant » consistait à créer un widget en pixel art représentant le logo de ce site, réalisé par dsh sur V4-Flash à partir d’un cahier des charges écrit. J’ai donné à Kimi ce même cahier des charges, sans modification, et j’ai chronométré ses actions. En bref, il s’agissait de :

• Un seul fichier en JavaScript pur, ll-pixel-logo.js, sans dépendances ni appels réseau, qui instancie un canvas HiDPI dans chaque élément .ll-pixel-logo et expose window.LLPixelLogo.mount(el), ainsi qu’un fichier de démonstration index.html et un README.md.
• Un art procédural, pas un bitmap dessiné à la main : un quadrillage 40×40 dont les points allumés sont déterminés par la fonction isLit(col, row) ; il s’agit d’un anneau (de rayon 0,82R à R) ainsi que de deux L inclinés, chacun formé de deux parallélogrammes déformés.
• Des interactions : répulsion du pointeur avec effet de ressort, un effet de clic marqué, une animation discrète en état d’inactivité, prise en charge du mode « réduction des animations », ainsi qu’un auto-test (node --check et comptage des cellules allumées sans recours au DOM).

L’épreuve des widgets en pixel art reprend intégralement ce cahier des charges.

Comment Kimi s’en est sorti :

• Première tentative (cahier des charges identique, sans modification) : interrompue après 8,8 minutes, aucun code de widget produit, coût d’environ 0,31 $. K3 a analysé le logo de référence, a réfléchi à la géométrie et aux outils à utiliser, mais n’a jamais écrit quoi que ce soit. La première tentative de dsh s’est soldée de manière similaire (une boucle de 10 minutes pour « dessiner » mentalement un bitmap), même si le cahier des charges autorisait alors les bitmaps dessinés à la main.
• Deuxième tentative (même cahier des charges, nouvelle session) : un widget complet a été généré, mais au mauvais endroit ; coût d’environ 0,72 $. Au bout de huit minutes environ, Kimi a écrit un fichier ll-pixel-logo.js de 323 lignes, puis une page de démonstration, un README et deux fichiers de test ; il a exécuté les tests et les a ajustés jusqu’à ce qu’ils soient conformes, avant de rédiger un bref rapport. Tout cela s’est retrouvé dans l’espace de travail propre à l’agent, et non dans le dossier surveillé par mon script ; la session a atteint la limite de 15 minutes imposée par mon lanceur avant que Kimi ne réponde. De mon point de vue, la deuxième tentative n’avait rien produit ; je n’ai pas attendu davantage et j’ai lancé une troisième tentative sept minutes plus tard.
• Troisième tentative (cahier des charges raccourci et instructions spécifiques) : 7,4 minutes de travail, les trois fichiers créés ; coût d’environ 0,47 $. J’ai conservé les exigences relatives aux livrables, à l’art graphique et aux interactions, j’ai ajouté en tête du cahier des charges TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop., puis j’ai remplacé la section test par une instruction se terminant par Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. Le widget ainsi créé présente une répulsion du pointeur avec effet de ressort, se fragmente puis se reconstitue au clic, comporte une lueur et des scintillements en état d’inactivité, ainsi qu’un mode « réduction des animations ». Mes propres vérifications figurent plus bas.

En somme, les trois tentatives ont duré 8,8, 15 et 7,4 minutes, pour un coût respectif d’environ 0,31 $, 0,72 $ et 0,47 $ : soit environ 1,50 $ pour deux widgets. Le montant lié à la troisième tentative provient de son reçu JSON propre ; les tentatives 1 et 2 n’ayant pas généré de reçu, leurs coûts correspondent aux tarifs par message appliqués par OpenClaw pour chaque session ; cette somme correspond d’ailleurs au montant indiqué sur le reçu de la troisième tentative.

Environ une heure plus tard, le widget créé lors de la deuxième tentative est réapparu : un MiniMax M3 exécuté sur le même worker a détecté les fichiers, les a testés et les a présentés comme son propre travail. Ce récit figure dans l’article consacré au MiniMax M3 ; les deux widgets produits par Kimi se retrouvent aux côtés de celui de dsh dans l’épreuve des widgets en pixel art.

Voici ce que Kimi a produit, à commencer par les 30 premières lignes du fichier ll-pixel-logo.js :

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 *
 * Self-contained vanilla JS: no dependencies, no build step, no network.
 * Embed on any page with:
 *
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 *
 * Every .ll-pixel-logo element gets a <canvas> mounted inside it at load.
 * Programmatic API: window.LLPixelLogo.mount(el) -> instance.
 *
 * Art: 40x40 pixel grid, rasterised procedurally from geometry (ring + two
 * interlocking italic Ls). Interactions: pointer repulsion with spring-back,
 * click/tap shatter-and-reassemble, idle shimmer/twinkle, reduced-motion
 * support. Mouse and touch. No scroll hijacking (all listeners passive).
 */
(function () {
  'use strict';

  // -- constants ------------------------------------------------------------
  var VERSION = '1.0.0';
  var GRID = 40;                                // logical grid: GRID x GRID cells
  var BLUE   = [31, 63, 143];                   // #1f3f8f logo blue
  var HILITE = [46, 168, 255];                  // #2ea8ff highlight blue
  var AMBER  = [255, 182, 74];                  // #ffb64a twinkle amber
  var CYAN   = [0, 230, 207];                   // #00e6cf max-displacement glow

  var CENTER = GRID / 2;                        // grid centre coordinate (20)
  var R_OUT = 19;                               // ring outer radius (cells)
  var R_IN = 0.82 * R_OUT;                      // ring inner radius
  var SLANT = Math.tan(20 * Math.PI / 180);     // ~20 deg italic shear

Kimi construit chaque L à partir de deux parallélogrammes (une tige et un pied déformés) grâce à une petite fonction utilitaire makeL ; il teste les points via l’aide inPara intégrée dans isLit. Toutes les constantes de réglage (rayons de l’anneau allant de 0,82R à R, angle d’inclinaison de 20° calculé via Math.tan, paramètres de ressort et de amortissement) sont regroupées en un seul bloc au début du fichier. Les fichiers générés (le ll-pixel-logo.js de 397 lignes, le index.html de 40 lignes et le README.md de 79 lignes) sont disponibles à l’adresse /assets/uploads/2026/09/kimi-codex/.

Le widget de dsh (son code source, cité dans l’article consacré à dsh) est construit de la même manière : il rasterise un anneau et deux L inclinés à partir de données géométriques, expose window.LLPixelLogo.mount et respecte également prefers-reduced-motion. Les constantes diffèrent toutefois : dsh utilise un rayon extérieur de 19,7, un rayon intérieur de 0,80R et un angle de 0,453 radian (soit environ 24°) ; Kimi, quant à lui, emploie 19, 0,82R et 20°. Les traits dessinés par Kimi sont en outre plus fins : ses tiges et pieds mesurent 3 cellules d’épaisseur, contre 4,2 cellules de large pour les tiges et 3,8 cellules de hauteur pour les pieds chez dsh. C’est pourquoi le logo de Kimi allume 510 cellules, tandis que celui de dsh en active 656. Aucun des deux ne reproduit exactement le logo de référence, mais tous deux sont reconnaissables au premier coup d’œil. La seconde tentative de dsh a également généré un test unitaire Node et, sans qu’on le lui demande, un script Playwright ; la troisième tentative de Kimi, en revanche, a reçu l’instruction de ne pas effectuer de tests, et s’y est conformée.

Commandes de vérification que j’ai exécutées sur le widget de Kimi

Je les ai relancées le 11/09/2026 sur la copie fournie par cette page, depuis le répertoire /assets/uploads/2026/09/kimi-codex/ :

$ wc -l ll-pixel-logo.js
397 ll-pixel-logo.js
$ node --check ll-pixel-logo.js && echo "node --check passed"
node --check passed

Deux autres vérifications ont été effectuées de mon propre chef, à l’aide de deux petits scripts auxiliaires (de moins de 20 lignes chacun) que je n’ai pas publiés. Voici donc la méthode utilisée plutôt que des commandes que vous pourriez copier-coller :

• Décompte des cellules allumées. J’ai chargé le fichier du widget dans Node en utilisant un DOM simulé (objets canvas, window et document sans effet réel). J’ai ensuite capturé la fonction isLit(col, row) définie dans le fichier, et l’ai appelée pour chaque cellule d’une grille 40×40, en comptant les cellules allumées par quadrant. Résultat : 510 cellules allumées : 124 en haut à gauche, 103 en haut à droite, 160 en bas à gauche et 123 en bas à droite.
• Vérification du montage. Toujours avec ce même DOM simulé, j’ai vérifié que le fichier définit window.LLPixelLogo en tant qu’objet, et qu’appeler mount() sur un élément simulé renvoie un objet sans provoquer d’erreur.

Rien que l’anneau (cellules dont le centre se situe entre 0,82R et R, avec R = 19) représente 352 des 510 cellules allumées ; il reste donc 158 cellules pour former les deux lettres « L ». Ces scripts auxiliaires sont de ma création, pas de Kimi ; il s’agit simplement d’un test préliminaire, et non d’une exécution dans un navigateur : la page que vous lisez ici est le résultat de cette exécution dans le navigateur.

Pourquoi cela ne fonctionne pas avec Codex ?

OpenClaw propose également un plugin d’interface Codex qui exécute le vrai app-server Codex (il gère @openai/codex 0.153.4). Rien dans cet article ne passe par ce plugin, car il ne peut pas prendre en charge ce modèle : sa vérification de route, configuredModelRouteNeedsCodex, renvoie false pour tout fournisseur dont l’identifiant normalisé n’est pas openai. L’identifiant du fournisseur Moonshot est moonshot, donc une route de type moonshot/kimi-k3 n’atteint jamais le moteur d’exécution Codex. Être « compatible OpenAI » ne signifie pas nécessairement « compatible avec l’interface Codex ».

Ainsi, Kimi s’exécute ici dans la boucle propre à OpenClaw, de la même manière que tout autre modèle natif d’OpenClaw. Vous ne bénéficiez donc pas de la reprise de threads Codex, du mécanisme de compactage propre à Codex, du pont outil dynamique, ni du modèle d’exécution de l’app-server. Si vous avez besoin de ces fonctionnalités avec Kimi, la solution de contournement connue est codex-router, un pont local qui redirige Codex vers un point de terminaison sur 127.0.0.1:4202 afin de le faire communiquer avec Kimi (selon son README). Pour que le plugin détecte cette configuration, il faut que la valeur de appServer.homeScope soit "user" ; cela partage alors votre répertoire natif ~/.codex (ou $CODEX_HOME) avec l’interface Codex, au lieu d’isoler l’état de Codex par agent OpenClaw. Je n’ai pas encore décidé si cela me convenait, donc je ne l’ai pas mis en œuvre.

Pièges courants (ceux que j’ai réellement rencontrés)

• Des consignes créatives trop ouvertes peuvent bloquer un modèle de raisonnement ; un délai d’exécution peut également masquer un succès. Lors de la première tentative, le modèle a réfléchi pendant 8,8 minutes sans écrire le moindre code pour le widget ; lors de la deuxième tentative, il a bien produit un widget fonctionnel, mais a dépassé le temps imparti, et ses fichiers se trouvaient dans le mauvais dossier, ce qui donnait l’impression d’un nouvel échec. La solution consiste à fournir des consignes plus courtes, indiquant par exemple TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop., et à préciser le dossier cible. K3 continue de raisonner selon ces consignes, mais ne planifie plus indéfiniment. Quel que soit le code de sortie affiché, vérifiez ce que la session a produit, ainsi que le contenu du espace de travail de l’agent.
• Un code de sortie d’erreur ne signifie pas nécessairement qu’une tâche a échoué. Vérifiez les fichiers. Lors du premier appel pour exécuter FizzBuzz, le code de sortie était 1 ; aucun modèle gagnant n’avait été identifié, et le message final indiquait : « ⚠️ Limite de requêtes API atteinte. Veuillez réessayer plus tard. » Pourtant, le fichier fizz.py avait déjà été créé et fonctionnait correctement. Lors d’une nouvelle tentative, le système a répondu « Déjà créé et exécuté. », et seul cet en-tête indiquait que l’opération était terminée. Mon script écrivait les données JSON de chaque exécution dans le même fichier, si bien que les informations relatives à l’exécution ayant échoué ont été écrasées ; cependant, son code de sortie et son message final sont toujours présents dans les logs de la session ayant lancé le benchmark. Le tableau ci-dessous reprend les résultats d’une exécution ultérieure, effectuée dans une nouvelle session.
• Ne copiez pas un dossier temporaire issu d’une exécution terminée d’un autre outil. J’ai configuré le dossier de correction des bugs pour Kimi en copiant les fichiers depuis le dossier terminé de dsh, alors que ce dernier les avait déjà corrigés ; par conséquent, la première exécution de Kimi a simplement vérifié que les fichiers étaient bien corrigés. Il convient donc de copier les éléments de test depuis une source vierge. J’ai réinitialisé le dossier et relancé l’opération dans une nouvelle session ; le tableau indique les résultats de cette deuxième exécution.

Où cela me mène

Pour ces cinq tâches, Kimi K3 a donné les bonnes réponses, mais de manière lente et à un coût élevé. Pour des tâches mineures, dsh sur V4-Flash a effectué le même travail en environ un neuvième du temps et pour environ 1/48e du prix (essai préliminaire). Après ce test de référence, j’ai déplacé mon agent exécutant depuis Kimi vers MiniMax-M3 ; quant à Kimi K3, il est resté là où il était déjà : derrière mon agent de relecture, car une réponse plus lente mais plus soignée justifie le coût supplémentaire.

Voir aussi : DeepSeek Harness (dsh) (l’outil que j’ai utilisé pour la comparaison ; c’est de là que proviennent le test et les consignes), Le comparatif des widgets d’art pixel (les trois widgets côte à côte), MiniMax M3 (la même suite logicielle sur le modèle utilisé par mon agent exécutant depuis le 11/09/2026), ainsi que Le coût réel de mes agents IA (une comparaison plus large des prix).