Kimi K3 in OpenClaw im Vergleich zu dsh: 5/5 Aufgaben, 9× langsamer, 48× höhere Kosten

Ich habe meinen OpenClaw-Arbeitsagenten auf Kimi K3, das führende Reasoning-Modell von Moonshot, ausgerichtet und ihn dieselben fünf kleinen Programmieraufgaben ausführen lassen, die ich im August zur Bewertung von DeepSeek Harness (dsh) verwendet hatte. Kimi bestand alle fünf Tests. Am selben Tag führte ich dsh erneut auf DeepSeek V4-Flash aus – zweimal. Im Vergleich zur zweiten Ausführung (bei der der Cache bereits gefüllt war) benötigte Kimi etwa 9 Mal mehr Zeit (309,9 Sekunden gegenüber 35,7 Sekunden) und kostete etwa 48 Mal mehr ($0,531 gegenüber $0,011). Im Vergleich zur ersten Ausführung von dsh (44,8 Sekunden, $0,024) beträgt der Zeitunterschied etwa das 7-Fache und der Kostenunterschied etwa das 22-Fache.

Anschließend gab ich Kimi die Anweisungen zur Erstellung eines Pixel-Art-Logos – dieselben, die dsh zuvor verwendet hatte. Es waren drei Versuche nötig: Beim ersten Versuch entstand kein Widget. Beim zweiten schrieb Kimi ein komplettes Widget in den falschen Ordner; mein Zeitlimit wurde erreicht, bevor Kimi dies mitteilte – daher übersah ich es zunächst. Erst der dritte Versuch gelang, nachdem ich die Anweisungen gekürzt und Kimi befohlen hatte, auf Planung zu verzichten. Das untenstehende Widget ist das Ergebnis dieses dritten Versuchs; insbesondere die Konfiguration in Schritt 2 ist besonders nützlich und lohnt sich, übernommen zu werden.

Einrichtung: Auf welcher Umgebung habe ich es ausgeführt?

Dies sind die Befehle, die ich am 11.09.2026 auf meinem System ausgeführt habe – samt deren tatsächlichem Ausgabeergebnis:

$ 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

Zwei Dinge sollten Sie vor dem Ausführen irgendwelcher Befehle wissen:

• K3 führt immer eine Begründung durch. Das Plugin sendet standardmäßig reasoning_effort: "max" und akzeptiert außerdem low, high sowie max. Ich habe den Benchmark mit --thinking max ausgeführt. Zudem entfernt K3 alle Einstellungen zur Stichprobenauswahl (temperature, top_p usw.), da K3 diese festlegt; in meiner Modellkonfiguration steht ebenfalls supportsTemperature: false. Selbst bei der Anweisung „Antworten Sie genau mit: PONG.“ wurden 53 Begründungstokens verbraucht – rechnen Sie also damit ein.
• Der 1-Million-Context wird beworben; ich begrenze ihn jedoch. Im OpenClaw-Moonshot-Katalog wird für K3 ein Kontextumfang von 1.048.576 Tokens angegeben. In meiner Modellkonfiguration habe ich jedoch contextTokens: 262144 gesetzt, sodass die Sitzungen zu demselben Zeitpunkt abgeschnitten werden wie bei meinen anderen Modellen. In der Praxis sind es also ca. 256.000 Tokens statt 1 Million. Erhöhen Sie diesen Wert, steigen sowohl die Kosten für den Cache-Zugriff als auch die Verzögerung pro Abfrage.

Der Weg – von Grundlagen bis Fortgeschrittenes

Die Schritte 1 bis 3 führen zu einem funktionierenden Modell. Die Schritte 4 und 5 sind das, was ich anschließend gemacht habe.

Schritt 1: Plugin installieren und den Schlüssel eingeben

Dies sind die Schritte aus den offiziellen Moonshot-Dokumentationen von OpenClaw. Auf meinem System waren das Plugin sowie der Schlüssel bereits vorhanden; daher habe ich nur den Befehl in der letzten Zeile ausgeführt (sein Ausgabeergebnis findet sich im obigen Setup-Block).

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

Das Plugin liest den Schlüssel aus MOONSHOT_API_KEY. Ich speichere ihn in der Umgebungsdatei, die mein Gateway-Service lädt; meine Datei openclaw.json enthält hingegen keinen Schlüssel. Die Dokumentation bietet außerdem den Befehl openclaw onboard --auth-choice moonshot-api-key, falls Sie eine Schritt-für-Schritt-Anleitung bevorzugen. Der Standard-Endpunkt lautet https://api.moonshot.ai/v1; für die China-Region wird https://api.moonshot.cn/v1 verwendet (Authentifizierungsoption: moonshot-api-key-cn).

Das Plugin unterstützt die Modelle K3, K2.7 Code sowie K2.7 Code HighSpeed. Es übernimmt außerdem die Handhabung der speziellen Anforderungen von Kimi: Bei K2.7 müssen sowohl thinking als auch reasoning_effort aus der Anfrage entfernt werden – was das Plugin automatisch erledigt. Achten Sie auf die Bezeichnung der Umgebungsvariablen: MOONSHOT_API_KEY bezieht sich auf die Moonshot Open Platform; KIMI_API_KEY gehört hingegen zum separaten Abonnement-Service für Kimi Code (kimi/kimi-for-coding).

Schritt 2: Weisen Sie Ihren Worker-Agent auf K3 hin

Die relevanten Teile meiner Datei openclaw.json während des Benchmarks – wobei mein Worker-Agent in worker umbenannt wurde:

{
  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"],
            },
          },
        ],
      },
    },
  },
}

Ein kleiner Fehler führte zu einem Problem: In OpenClaw 2026.9.2 ersetzt ein compat-Block im Modell-Eintrag den eigenen compat-Objekt des Plugins – er fügt ihn nicht hinzu. In einer früheren Version meines Eintrags stand lediglich supportsTemperature: false; dadurch wurde die Unterstützung für Reasoning-Effort durch das Plugin stillschweigend deaktiviert. Falls Sie überhaupt ein compat-Objekt schreiben, schreiben Sie bitte das gesamte Objekt, wie oben gezeigt.

Schritt 3: Der Smoke Test sowie das von ihm zurückgegebene JSON

Jede Benchmark-Aufgabe bestand aus einem solchen Aufruf – jeweils mit einem neuen Sitzungsschlüssel:

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

Hier sind die wichtigen Felder, entnommen aus dem gespeicherten Ergebnis der PONG-Aufgabe:

$ 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" bedeutet, dass der Durchlauf in OpenClaws eigenem Loop erfolgte; ein Durchlauf über den Codex-App-Server würde "codex" anzeigen. winnerModel: "kimi-k3" zeigt an, dass der Durchlauf tatsächlich auf dem K3-Modell stattfand und nicht auf einem günstigeren Modell ausgeführt wurde. reasoningTokens werden innerhalb von output gezählt (die Gesamtzahl ergibt sich aus Eingabe plus Ausgabe); somit sind die 53 Reasoning-Tokens Teil der Gesamtzahl von 70.

Der Benchmark: dieselben 5 Aufgaben

Es handelt sich um dieselben fünf Aufgaben, die auch im dsh-Artikel getestet wurden – jeweils in einem neuen Arbeitsverzeichnis und mit einer neuen Sitzung pro Aufgabe. Am selben Tag führte ich dsh erneut auf V4-Flash aus; dabei wurde deepseek-v4-flash in einer Konfigurationsdatei festgelegt. Der erste Durchlauf dauerte 44,8 Sekunden und kostete 0,024 Dollar – bei noch leerem Cache. Die untenstehende Spalte zeigt den zweiten, „warmen“ Durchlauf: dies ist das schnellste und günstigste Ergebnis, das ich mit dsh erzielt habe; dieses Ergebnis wird in diesem Artikel verwendet, sofern nicht anders angegeben. Die genauen Prompt-Formulierungen waren nicht identisch: dsh arbeitet im Verzeichnis, aus dem es gestartet wird – daher enthielten dessen Prompts „das aktuelle Verzeichnis“. Kimis Prompts gaben hingegen den absoluten Pfad zu jedem Aufgabenverzeichnis an; zudem enthielt Kimis Bug-Fix-Prompt die Anweisung: „Falls pytest nicht verfügbar ist, installieren Sie es zuerst mit ‚pip install --user pytest‘“ (pytest war bereits installiert – Kimi führte die Installation jedoch nie aus). Die Spalten für V4-Pro und Gemma-4-26B stammen aus dem dsh-Artikel vom August; diese Tests wurden nicht erneut durchgeführt. Die angegebenen Zeiten umfassen den gesamten Prozess. Die Token-Zahlen sowie die Kosten für Kimi stammen aus dem JSON-Datenpaket von OpenClaw; bei dsh stammen sie aus dessen eigenem Sitzungsprotokoll.

Aufgabe	Kimi K3	dsh V4-Flash (am selben Tag)	dsh V4-Pro (August, historisch)	Gemma-4-26B (August, historisch)
„PONG“ zurücksenden (Start + ein Aufruf)	✅ 6,1 s · 0 Werkzeuge	✅ 1,7 s · 0 Werkzeuge	✅ 2,8 s	✅ 13,2 s*
FizzBuzz schreiben und ausführen	✅ 22,8 s · 2 Werkzeuge (schreiben, ausführen)	✅ 5,3 s · 3 Werkzeuge	✅ 8,4 s · 2 Werkzeuge	✅ 4,9 s · 2 Werkzeuge
Zwei Fehler beheben, sodass die Unit-Tests bestehen (Tests unverändert)	✅ 86,6 s · 6 Werkzeuge (ausführen, schreiben, bearbeiten)	✅ 11,3 s · 7 Werkzeuge	✅ 15,8 s · 7 Werkzeuge	✅ 10,4 s · 8 Werkzeuge
Einen 6-Module umfassenden Codebaustein zusammenfassen (<150 Wörter)	✅ 65,5 s · 10 Werkzeuge (lesen, ausführen, schreiben)	✅ 5,1 s · 7 Werkzeuge	✅ 10,9 s · 7 Werkzeuge	✅ 12,1 s · 7 Werkzeuge
Eine Funktion in 3 Dateien sowie den zugehörigen Tests umbenennen – anschließend Test erfolgreich	✅ 128,9 s · 9 Werkzeuge (ausführen, schreiben; ein sed-Aufruf über alle Dateien)	✅ 12,3 s · 11 Werkzeuge	✅ 18,2 s · 12 Werkzeuge	✅ 12,2 s · 11 Werkzeuge
Gesamtzeitdauer	309,9 s	35,7 s	56,1 s	52,8 s
Token: Eingabe (uncached) / Cache-Lesevorgänge / Ausgabe (Reasoning)	91.470 / 355.328 / 9.990 (4.053)	6.141 / 147.328 / 4.697 (1.984)	41,4k / 107k / 3,2k	40,5k / 237k / 5,6k
Kosten	≈ $0,531 ($3 / $15 / $0,30 pro Million)	≈ $0,011 ($0,44 / $1,32 / $0,014 pro Million)	≈ $0,072	$0 (nur Stromkosten)

Die Angaben zu den Werkzeugen beziehen sich auf die Anzahl der Tool-Aufrufe. Bei Kimi stammen diese Angaben aus toolSummary.calls im JSON-Datenpaket von OpenClaw; dabei werden die jeweiligen Werkzeugtypen in Klammern angegeben. Bei dsh stammen sie aus dessen Sitzungsprotokoll. *Erster Aufruf nachdem das Modell auf dem System geladen wurde. Die Kostenangaben für Kimi basieren auf den Werten in meinem OpenClaw-Katalogeintrag; OpenClaw verwendet diese Werte zur Berechnung der Kosten pro Aufgabe. Aktuelle Preise finden Sie auf der Preisseite von Moonshot. Für dsh V4-Flash gelten dieselben Höchstpreise wie im dsh-Artikel (DeepSeek-Preise); die Werte für V4-Pro und Gemma stammen aus diesem Artikel.

Was die Tabelle zeigt:

• In jeder Spalte „5/5“. Keine dieser Aufgaben bereitete Kimi Probleme: „PONG“ wurde wie gewünscht zurückgesendet; FizzBuzz gab die 15 korrekten Zeilen aus. Bei der Fehlerbehebung genügten zwei kleine Änderungen – ein fehlendes return sowie ein == 1, das eigentlich == 0 sein sollte – ohne dass die Tests verändert werden mussten; alle Tests bestanden. Die Zusammenfassung bestand aus einem einzigen Absatz mit 107 Wörtern, der sechs identische Module korrekt beschrieb. Beim Umbenennen reichte ein einziger sed-Aufruf über vier Dateien aus; auch die Testmethode wurde umbenannt – alle Tests bestanden ebenfalls. Mein Prompt verlangte außerdem nach einem leeren grep im gesamten Verzeichnis; da sich dort auch meine eigene Prompt-Datei befand, führte Kimi denselben sed-Aufruf auch auf dieser Datei aus und erwähnte dies in seiner Antwort. Es handelt sich dabei um kleine Aufgaben – ich habe keinen mehrdateigen Refactoring-Test durchgeführt.
• Kimi verbraucht mehr „Denkleistung“. K3 nutzte bei den fünf Aufgaben insgesamt 53.241, 315.158 und 1.858 Reasoning-Token (insgesamt 4.053). dsh auf V4-Flash rechnet ebenfalls nach – allerdings deutlich weniger: 0, 52, 834, 5 und 1.093 Token (insgesamt 1.984). Der Großteil der zusätzlichen Zeit bei Kimi entfällt auf Nachdenken sowie zusätzliche Arbeitsschritte.
• Der Cache spart Kosten. Jeder Kimi-Aufruf beginnt mit etwa 15.000 Tokens an System-Prompt und Tool-Definitionen. Insgesamt sendete Kimi 91.470 uncached-Eingabetoken; 355.328 Token wurden aus dem Cache gelesen – allein beim Umbenennen waren es 157.952 Token. Somit stammten 80 % der Prompt-Token aus dem Cache zu einem Preis von $0,30 pro Million statt $3. Ohne diesen Cache-Effekt hätte die Ausführung etwa $1,49 gekostet – statt $0,53; der Cache reduzierte die Kosten somit auf ein Drittel. Dennoch handelt es sich um einen Premium-Preis: $0,30 entsprechen etwa dem 21-fachen des Cache-Lese-Preises von dsh V4-Flash ($0,014 pro Million).
• Für kleine Aufgaben gewinnt V4-Flash. Im Vergleich zum „warmen“ Durchlauf war dsh etwa 9× schneller und 48× günstiger. Im Vergleich zum „kalten“ Durchlauf sogar etwa 7× schneller und 22× günstiger. In jedem Fall ist das Ergebnis identisch. Allein das Umbenennen kostete Kimi 128,9 Sekunden sowie $0,180; dsh benötigte dafür nur 12,3 Sekunden und $0,0043.

Kimi K3 in OpenClaw im Vergleich zu dsh – ein Überblick

Beide sind Agenten, die Dateien lesen, Shell-Befehle ausführen und nach Anzahl der verarbeiteten Tokens abrechnen. Sie unterscheiden sich darin, wer sie entwickelt hat sowie in der Art und Weise, wie man sie steuert.

	Kimi K3 in OpenClaw	dsh
Entwickler	Modell: Moonshot AI. Agentenloop: OpenClaw	DeepSeek (Modell sowie Steuerungswerkzeug), MIT
Aufruf aus einem Skript	openclaw agent --agent <id> --model moonshot/kimi-k3 -m "…" --json	dsh --profile headless "…"
Modellwechsel	Über den Parameter model.primary in der Datei openclaw.json	Über die Datei ~/.dsh/settings.yaml
Headless-Benchmark, 5 kleine Aufgaben	309,9 Sekunden, ca. $0,531, 5/5	35,7 Sekunden, ca. $0,011, 5/5 (V4-Flash; bei kallem Start 44,8 Sekunden, ca. $0,024)
Erstellung eines Pixel-Art-Widgets, gleiche Anweisung	3 Versuche – zwei davon führten zum gewünschten Ergebnis; der hier gezeigte Versuch dauerte 7,4 Minuten und kostete ca. $0,47	2 Versuche; der erfolgreiche Versuch benötigte 25 Minuten und kostete ca. 49 Cent
Geprüfte Version	OpenClaw 2026.9.2, Moonshot-Plugin 2026.9.2	0.1.1-rc.2 (Entwickler-Vorschau)

In früheren Vergleichen auf dieser Seite gab es noch eine Spalte für Reasonix. Am 2026-09-09 habe ich Reasonix von meinem System entfernt; daher ist es hier nicht mehr aufgeführt. Der dazu verfasste Artikel vom Juli bleibt jedoch als historisches Dokument erhalten. Ebenfalls habe ich MiniMax M3 durch dasselbe Testverfahren laufen lassen; MiniMax ist ein von Moonshot unabhängiges Unternehmen – zu diesem Test gibt es einen eigenen Bericht.

Der unterhaltsame Test: Derselbe Widget-Auftrag – Kimi vs. dsh

Der „Fun-Test“ im dsh-Artikel war ein Pixel-Art-Widget mit dem Logo dieser Seite – erstellt von dsh mithilfe von V4-Flash auf Basis einer schriftlichen Anweisung. Ich gab Kimi dieselbe, unveränderte Anweisung und maß dabei die Zeit. Kurz gesagt: Es wird Folgendes verlangt:

• Eine einzige Vanilla-JS-Datei, ll-pixel-logo.js, ohne Abhängigkeiten oder Netzwerkaufrufe. Sie fügt auf jedem .ll-pixel-logo-Element ein HiDPI-Canvas hinzu und stellt window.LLPixelLogo.mount(el) zur Verfügung. Außerdem gibt es eine Demo-Datei index.html sowie eine README.md.
• Prozedurale Kunst – kein handgezeichnetes Bitmap: Ein 40×40-Raster, bei dem die Beleuchtung durch die Funktion isLit(col, row) gesteuert wird. Es entsteht ein Ring (von 0,82R bis R) sowie zwei schräge „L“-Formen – jede aus zwei verschobenen Parallelogrammen bestehend.
• Interaktionen: Abstoßung des Zeigers mit Federrückkehr-Effekt, ein starker Klickeffekt, eine subtile Leerlauf-Animation, Unterstützung für „Reduzierte Bewegung“ sowie ein Selbsttest (node --check), bei dem die Anzahl der beleuchteten Zellen ohne DOM-Benutzung gezählt wird.

Im Pixel-Art-Widget-Showdown wird die vollständige Ausschreibung zitiert.

Wie Kimi vorgegangen ist:

• Versuch 1 (die ursprüngliche Aufgabenbeschreibung, unverändert): Nach 8,8 Minuten wurde der Prozess abgebrochen. Es wurde kein Widget-Code erstellt; Kosten: ca. $0,31. K3 betrachtete das Referenzlogo, überlegte sich die Geometrie sowie die Umsetzung – schrieb aber keine Ergebnisse. Auch dshs erster Versuch scheiterte auf ähnliche Weise (eine 10-minütige Schleife, in der lediglich ein Bitmap gezeichnet wurde); die Aufgabenbeschreibung erlaubte damals jedoch noch handgezeichnete Bitmaps.
• Versuch 2 (erneut die gleiche Aufgabenbeschreibung, neuer Sitzungsverlauf): Ein komplettes Widget wurde erstellt – allerdings am falschen Ort. Kosten: ca. $0,72. Nach etwa acht Minuten schrieb das System eine 323 Zeilen umfassende Datei namens ll-pixel-logo.js, außerdem eine Demo-Seite, eine README-Datei sowie zwei Testdateien. Anschließend führte es die Tests aus und passte sie so an, dass sie erfolgreich verliefen; danach verfasste es einen kurzen Bericht. Alles wurde im eigenen Arbeitsbereich des Worker-Agenten abgelegt – nicht in dem Ordner, den mein Skript überwachte. Die Sitzung erreichte nach 15 Minuten die von meinem Startskript festgelegte Zeitgrenze; zu diesem Zeitpunkt gab es laut meinen Beobachtungen noch keine Ergebnisse. Ich wartete nicht ab und startete nach etwa sieben Minuten Versuch 3.
• Versuch 3 (gekürzte Aufgabenbeschreibung sowie zusätzliche Anweisungen): Nach 7,4 Minuten waren alle drei Dateien erstellt; Kosten: ca. $0,47. Ich behielt die Ergebnisse bei, fügte obenhin TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. hinzu und ersetzte den Testabschnitt durch folgenden Text: Do NOT do a "node --check" or playwright test — just write the files and print a short report listing what you wrote. Das Widget verfügt über eine „Pointer-Repulsion“-Funktion mit Rückfederungseffekt, bei Klick zerbricht es in Teile, die sich anschließend wieder zusammensetzen; außerdem gibt es einen „Idle-Shimmer“-Effekt sowie einen Modus für reduzierte Bewegung. Meine eigenen Tests folgen weiter unten.

Die drei Versuche dauerten jeweils 8,8, 15 bzw. 7,4 Minuten und kosteten etwa 0,31 $, 0,72 $ bzw. 0,47 $. Insgesamt also rund 1,50 $ für zwei Widgets. Die Kosten des dritten Versuchs stammen aus dem zugehörigen JSON-Beleg. Bei den Versuchen 1 und 2 gab es keinen solchen Beleg; daher wurden die jeweiligen Kosten berechnet, indem man die von OpenClaw pro Nachricht berechneten Kosten pro Sitzung addierte. Diese Summe entspricht exakt dem Betrag im Beleg des dritten Versuchs.

Etwa eine Stunde später tauchte das Widget von „Versuch 2“ erneut auf – nachdem nämlich ein MiniMax M3, der auf demselben Worker lief, die Dateien gefunden, deren Tests durchgeführt und sie als eigene Arbeit gemeldet hatte. Diese Geschichte wird in dem Bericht über den MiniMax M3 beschrieben; beide Widgets von Kimi befinden sich neben dem Widget von dsh im Pixel-Art-Widget-Wettbewerb.

Was Kimi erstellt hat – die ersten ca. 30 Zeilen von 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 erstellt jedes „L“ aus zwei Parallelogrammen – einem verdrehten Stamm und einem „Fuß“ – mithilfe eines kleinen Hilfsprogramms namens makeL. Anschließend testet er Punkte mit einem weiteren Hilfsprogramm namens inPara innerhalb der Funktion isLit. Alle Einstellungen – darunter die Ringradien von 0,82R bis R, ein Winkel von 20° gemäß Math.tan, sowie Werte für Feder und Dämpfung – werden in einem Block am Anfang der Datei festgelegt. Die erstellten Dateien (die 397 Zeilen umfassende Datei ll-pixel-logo.js, die 40 Zeilen lange Datei index.html sowie die 79 Zeilen lange Datei README.md) werden unter /assets/uploads/2026/09/kimi-codex/ bereitgestellt.

Das Widget von dsh (sein Quellcode, zitiert im dsh-Artikel) wurde auf dieselbe Weise erstellt: Beide generieren aus geometrischen Formen einen Ring sowie zwei ineinandergreifende, kursiv geschriebene „Ls“; beide stellen window.LLPixelLogo.mount zur Verfügung und berücksichtigen zudem die Einstellung prefers-reduced-motion. Die verwendeten Konstanten unterscheiden sich jedoch. dsh verwendet einen äußeren Ringradius von 19,7, einen inneren Ring bei 0,80R sowie eine Neigung von 0,453 (etwa 24°); Kimi nutzt 19, 0,82R und 20°. Zudem sind die Striche bei Kimi dünner: Ihre Stämme und Enden haben eine Dicke von 3 Zellen – während die Stämme bei dsh 4,2 Zellen breit und die Enden 3,8 Zellen hoch sind. Aus diesem Grund aktiviert Kimis Logo 510 Zellen, während es bei dsh 656 Zellen sind. Keines der beiden Logos entspricht exakt dem Referenzlogo – doch auf den ersten Blick erkennt man in beiden das gleiche Zeichen. Bei seinem zweiten Versuch schrieb dsh außerdem einen Node-Unit-Test sowie – ohne dazu aufgefordert worden zu sein – ein Playwright-Skript. Kimis drittem Versuch wurde hingegen gesagt, auf Tests zu verzichten – und das tat er auch.

Überprüfungsbefehle, die ich auf Kimis Widget ausgeführt habe

Ich habe diese am 11.09.2026 erneut ausgeführt – und zwar anhand der Kopie, die diese Seite bereitstellt; sie befindet sich in /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

Zwei weitere Überprüfungen waren meine eigenen privaten Tests, durchgeführt mit zwei kleinen Hilfsskripten (jeweils unter 20 Zeilen), die ich nicht veröffentlicht habe. Daher gebe ich hier die Methode an – statt konkreter Befehle, die man einfach kopieren könnte:

• Zählung der beleuchteten Zellen. Ich lud die Widget-Datei in Node.js mit einem „stubbten“ DOM (leere Canvas-, Window- und Document-Objekte) ein, nutzte die darin enthaltene Funktion isLit(col, row) und rief sie für jede Zelle des 40×40-Rasters auf. Dabei zählte ich die beleuchteten Zellen nach Quadranten: 124 im oberen linken, 103 im oberen rechten, 160 im unteren linken sowie 123 im unteren rechten Quadranten. Insgesamt waren es 510 beleuchtete Zellen.
• Überprüfung des „Mount“-Vorgangs. Mit demselben „stubbten“ DOM vergewisserte ich mich, dass die Datei window.LLPixelLogo als Objekt definiert und dass der Aufruf von mount() auf einem Dummy-Element ein Objekt zurückgibt – anstatt einen Fehler auszulösen.

Allein der Ring (Zellen, deren Mittelpunkte zwischen 0,82R und R liegen; wobei R = 19 ist) umfasst 352 der insgesamt 510 Zellen. Damit bleiben noch 158 Zellen für die beiden „L“-Formen übrig. Die Hilfsskripte stammen von mir, nicht von Kimi; sie dienen lediglich als Test – es handelt sich dabei nicht um einen Browser-Test. Die Seite, die Sie gerade lesen, ist das Ergebnis eines solchen Browser-Tests.

Warum das nicht über Codex läuft

OpenClaw liefert außerdem ein Plugin namens „Codex Harness“, das den eigentlichen Codex App-Server ausführt (dieser verwendet @openai/codex in der Version 0.153.4). In diesem Artikel wird dieser Weg jedoch nicht genutzt – denn er kann dieses Modell nicht verarbeiten: Die Prüfung der Konfiguration, configuredModelRouteNeedsCodex, gibt für jeden Anbieter, dessen normalisierte ID nicht openai ist, den Wert false zurück. Die Provider-ID von Moonshot lautet moonshot; daher gelangt eine Route wie moonshot/kimi-k3 niemals an den Codex-Runtime. „OpenAI-kompatibel“ bedeutet also nicht automatisch „Codex-Harness-kompatibel“.

Kimi wird daher im eigenen Verarbeitungszyklus von OpenClaw ausgeführt – genauso wie jedes andere nativ unterstützte OpenClaw-Modell. Es stehen dabei weder die Funktionen zur Fortsetzung abgebrochener Prozesse noch die Kompaktionsfunktionen von Codex, die dynamische Tool-Bridge oder das spezielle Ausführungsmodell des App-Servers zur Verfügung. Falls Sie diese Funktionen für Kimi benötigen, gibt es einen bekannten Workaround: codex-router. Dabei handelt es sich um eine lokale Brücke, die Codex auf einen Endpunkt unter 127.0.0.1:4202 leitet und anschließend Anfragen an Kimi weiterleitet (siehe dazu die README-Datei). Damit das Plugin diese Konfiguration erkennt, muss der Wert von appServer.homeScope auf "user" gesetzt werden; dadurch wird Ihr lokales Verzeichnis ~/.codex (bzw. $CODEX_HOME) mit dem Plugin geteilt – anstatt den Codex-Zustand pro OpenClaw-Agent zu isolieren. Ich habe mich bisher noch nicht entschieden, ob mir das recht ist; daher habe ich diese Funktion bislang nicht implementiert.

Fallstricke (die mir tatsächlich untergekommen sind)

• Offene, unpräzise Aufgabenbeschreibungen können ein Reasoning-Modell zum Stillstand bringen – ein Timeout kann dabei als „Fehler“ interpretiert werden. Beim ersten Versuch dachte das Modell 8,8 Minuten lang nach, schrieb aber keinen Code für das Widget. Beim zweiten Versuch entstand zwar ein funktionierendes Widget, doch die Zeit lief ab, bevor der Code im richtigen Ordner gespeichert werden konnte – daher wirkte es wie ein weiterer Fehler. Die Lösung war eine kürzere, präzisere Aufgabenbeschreibung: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. Zudem wurde der Zielordner explizit angegeben. K3 arbeitet weiterhin mit dieser Beschreibung – allerdings plant es nicht endlos. Unabhängig vom Exit-Status sollte man sich ansehen, was die Sitzung geschrieben hat – auch im eigenen Arbeitsbereich des Agents.
• Ein Fehler-Exit bedeutet nicht zwangsläufig, dass die Aufgabe fehlgeschlagen ist. Überprüfen Sie die Dateien. Der erste Aufruf zur Erstellung des FizzBuzz-Programms lieferte den Exit-Code 1; es wurde kein „gewinnendes Modell“ gefunden, und als letzter Text erschien: „⚠️ API-Rate-Limit erreicht. Bitte versuchen Sie es später erneut.“ Dabei hatte das System bereits die Datei fizz.py erstellt – diese funktionierte einwandfrei. Beim erneuten Aufruf hieß es: „Bereits erstellt und ausgeführt.“ Nur dieses Ergebnis wurde als „abgeschlossen“ markiert. Mein Skript schrieb die JSON-Daten jedes Durchlaufs in dieselbe Datei – dadurch wurde das Ergebnis des fehlgeschlagenen Durchlaufs überschrieben; sein Exit-Code sowie der letzte Text blieben jedoch im Log der Sitzung erhalten. In der Tabelle wird daher ein späterer, erfolgreicher Durchlauf in einer neuen Sitzung verwendet.
• Kopieren Sie niemals einen „Scratch-Ordner“ aus einem abgeschlossenen Durchlauf eines anderen Testumfelds. Ich hatte den Ordner für Kimis Fehlerbehebungen dadurch erstellt, dass ich die Dateien aus dem fertigen Ordner von dsh kopierte – obwohl dsh diese bereits korrigiert hatte. Dadurch „fand“ Kimis erster Fehlerbehebungs-Durchlauf die bereits korrigierten Dateien und verifizierte sie lediglich. Kopieren Sie stattdessen Testdaten aus einer sauberen Quelle. Ich habe den Ordner zurückgesetzt und den Test in einer neuen Sitzung erneut durchgeführt; in der Tabelle ist dieser zweite Durchlauf aufgeführt.

Wo stehe ich nach all dem?

Bei diesen fünf Aufgaben war Kimi K3 zwar korrekt in seinen Antworten, aber langsam und teuer. Für kleinere Aufgaben erledigte dsh auf V4-Flash die gleiche Arbeit in etwa einem Neuntel der Zeit – und zu einem Preis, der nur etwa 1/48 des Preises von Kimi K3 betrug („Warm Pass“). Nach diesem Benchmark habe ich meinen Arbeits-Agenten von Kimi K3 auf MiniMax-M3 umgestellt; Kimi K3 blieb jedoch dort, wo es bereits war: hinter meinem Überprüfungs-Agenten. Dort ist eine langsamere, aber sorgfältigere Antwort es wert, dafür zu zahlen.

Verwandte Themen: DeepSeek Harness (dsh) (das System, mit dem ich verglichen habe; hier stammen der Benchmark sowie die Aufgabenbeschreibung her), Der Pixel-Art-Widget-Vergleich (alle drei Widgets nebeneinander), MiniMax M3 (dasselbe System, allerdings auf dem Modell, das mein Arbeits-Agent seit dem 11.09.2026 nutzt) sowie Was meine KI-Agenten tatsächlich kosten (ein umfassender Preisvergleich).