Kimi K3 auf Moonshot als Coding-Agent: Es in OpenClaw integrieren, es im Vergleich zu dsh bewerten sowie es um ein Pixel-Art-Logo-Widget bitten.

Ich richtete meinen OpenClaw-Arbeitsagenten auf Kimi K3 aus – das Spitzenmodell von Moonshot für logisches Schließen – und ließ es die gleichen fünf kleinen Programmieraufgaben ausführen, die ich im August verwendet hatte, um DeepSeek Harness (dsh) zu bewerten. Kimi bestand alle fünf Aufgaben. Im Vergleich zu dsh unter Verwendung von DeepSeek V4-Flash – bei erneuter Ausführung am selben Tag auf denselben fünf Aufgaben – benötigte Kimi etwa 9 Mal länger (309,9 Sekunden gegenüber 35,7 Sekunden) und kostete etwa 48 Mal mehr ($0,531 gegenüber $0,011). Anschließend gab ich Kimi die Beschreibung für ein Pixel-Art-Logo vor, anhand derer dsh zuvor ein Widget erstellt hatte. Kimi benötigte drei Versuche: Beim ersten Versuch ohne Änderungen an der Beschreibung entstand kein Widget. Beim zweiten Versuch schrieb Kimi zwar ein komplettes Widget samt Tests, speicherte es jedoch im falschen Verzeichnis; außerdem wurde die Ausführung nach Ablauf des Zeitlimits abgebrochen – daher bemerkte ich es zunächst nicht. Der dritte Versuch gelang schließlich, nachdem ich die Beschreibung gekürzt und Kimi angewiesen hatte, auf Planung zu verzichten.

Pfad A vs. Pfad B – ehrlich gesagt

Alles hier entspricht Pfad A: Kimi K3 steuert die eigentliche Agenten-Logik von OpenClaw über den Moonshot-Provider. Auf meinem System war der Provider bereits konfiguriert; daher genügte ein einziger Modellwechsel, um den Worker auf Kimi umzustellen.

Pfad B würde Kimi hingegen hinter dem eigentlichen Codex App-Server platzieren – diesen steuert das Codex-Harness-Plugin von OpenClaw (das Plugin verwaltet @openai/codex 0.153.4). Ich habe dieses Plugin nicht selbst entwickelt, und in diesem Artikel wird nichts über Codex abgewickelt. Der Grund dafür liegt im Plugin-Code: Die Funktion configuredModelRouteNeedsCodex gibt für jeden Provider, dessen normalisierte ID nicht openai ist, den Wert false zurück. Die ID des Moonshot-Providers lautet moonshot; daher gelangt eine Route vom Typ moonshot/kimi-k3 niemals an die Codex-Laufzeitumgebung.

Eine bekannte Umgehungslösung ist codex-router: Ein lokaler „Brücken“-Dienst, der Codex auf einen Endpunkt unter 127.0.0.1:4202 umleitet und anschließend Anfragen an Kimi weiterleitet (siehe dazu die README-Datei). Damit das Harness diese Konfiguration erkennt, muss der Wert von appServer.homeScope im Plugin auf "user" gesetzt werden. Dadurch wird Ihr lokales Verzeichnis ~/.codex (bzw. $CODEX_HOME) mit dem Harness geteilt – anstatt den Codex-Zustand pro OpenClaw-Agent zu isolieren. Ich habe mich noch nicht entschieden, ob mir das recht ist; daher bleibt Pfad B vorerst nur theoretisch bestehen.

Pfad A hat jedoch gewisse Einschränkungen, die Sie kennen sollten: In den Antwortberichten steht agentHarnessId: "openclaw" – also dieselbe Bezeichnung wie bei allen anderen OpenClaw-eigenen Modellen. Sie erhalten weder die Möglichkeit zum Fortsetzen unterbrochener Codex-Threads noch Codex’ eigene Komprimierungsfunktionen, den dynamischen Tool-Bridge-Mechanismus oder das spezielle Ausführungsmodell des App-Servers. Falls Sie diese Funktionen benötigen, ist Pfad B die einzige Alternative.

Einrichtung: Auf welcher Umgebung ich es ausgeführt habe

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

Drei Dinge, die man wissen sollte, bevor man irgendetwas ausführt:

• 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 die Anweisung „Antworte exakt mit: PONG.“ erforderte 53 Begründungstokens.
• Der 1-Million-Context wird beworben – ich begrenze ihn jedoch. Im OpenClaw-Moonshot-Katalog wird K3 mit einem Kontext von 1.048.576 Tokens angegeben. In der 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 somit ca. 256.000 Tokens – nicht 1 Million.
• Der Cache sorgt für Kosteneinsparungen. Jeder Task beginnt mit etwa 15.000 Tokens an System-Prompts und Tool-Definitionen. Nach dem ersten Schritt werden die meisten davon aus dem Cache gelesen – zu einem Preis von 0,30 $ pro Million Tokens statt 3 $. Beim „Umbenennungs-Task“ entfielen allein auf das Lesen aus dem Cache 157.952 Tokens.

Der Weg – von Grundlagen bis zur Fortgeschrittenenstufe

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 Schlüssel zuweisen

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 lediglich die Überprüfung in der letzten Zeile ausgeführt (das Ergebnis ist im obigen Setup-Block zu sehen):

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 openclaw onboard --auth-choice moonshot-api-key an, 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).

Der Katalog des Plugins umfasst K3, K2.7 Code sowie K2.7 Code HighSpeed. Es kümmert sich außerdem um die Besonderheiten 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 Namen der Umgebungsvariablen: MOONSHOT_API_KEY bezieht sich auf die Moonshot Open Platform; KIMI_API_KEY gehört hingegen zum separaten Kimi Code-Abonnement (kimi/kimi-for-coding).

Schritt 2: Richten Sie Ihren Worker-Agenten auf K3 aus

Hier sind 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 Fehler hat mir eine unerwünschte Regression eingebracht: In OpenClaw 2026.9.2 ersetzt ein compat-Block im Modell-Eintrag den eigenen compat-Objekt des Plugins – er führt keine Zusammenführung durch. In einer früheren Version meines Eintrags war lediglich supportsTemperature: false angegeben; dadurch wurde die Unterstützung für Reasoning-Effort seitens des Plugins stillschweigend deaktiviert. Falls Sie überhaupt einen compat-Block verwenden, geben Sie bitte das gesamte Objekt an, wie oben gezeigt.

Die Zeile contextTokens: 262144 entspricht der Obergrenze aus den Einrichtungsanweisungen. Falls Sie diesen Wert erhöhen, sollten Sie damit rechnen, dass sowohl die Kosten für Cache-Lesevorgänge als auch die Latenz pro Turn mit der Sitzungsdauer zunehmen.

Schritt 3: Der Smoke Test sowie das von ihm gelieferte 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" ist das Kennzeichen für Pfad A. Ein Durchlauf über den Codex-App-Server würde "codex" angeben. winnerModel: "kimi-k3" zeigt an, dass der Durchlauf tatsächlich auf dem K3-Prozessor stattfand und nicht auf einem günstigeren Modell ausgeführt wurde. reasoningTokens werden innerhalb von output gezählt (die Gesamtzahl setzt sich aus Eingabe- und Ausgabe-Tokens zusammen); somit sind die 53 Reasoning-Tokens Teil der Gesamtzahl von 70.

Vergleich: Kimi K3 in OpenClaw vs. dsh

Beide sind Agenten, die Dateien lesen, Shell-Befehle ausführen und nach Anzahl der verarbeiteten Tokens abrechnen. Unterschiede bestehen darin, wer was entwickelt hat sowie in der Bedienung.

	Kimi K3 in OpenClaw (Pfad A)	dsh
Entwickler	Modell: Moonshot AI; Agentenlogik: OpenClaw	DeepSeek (Modell sowie Steuerung), 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	In der Datei ~/.dsh/settings.yaml
Headless-Benchmark, 5 kleine Aufgaben	309,9 Sekunden, ca. $0,531; alle 5 Aufgaben erfolgreich erledigt	35,7 Sekunden, ca. $0,011; alle 5 Aufgaben erfolgreich erledigt (V4-Flash, zweiter Durchlauf war schneller)
Erstellung eines Pixel-Art-Widgets, gleiche Anweisung	3 Versuche – bei zwei davon entstand ein Widget; das hier gezeigte benötigte 7,4 Minuten und kostete ca. $0,47	2 Versuche; der erfolgreiche Versuch dauerte 25 Minuten und kostete ca. 49 Cent
Geprüfte Versionen	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 Artikel dazu vom Juli bleibt jedoch als historisches Dokument erhalten. Ebenfalls habe ich MiniMax M3 mit demselben Testverfahren geprüft; MiniMax ist ein von Moonshot unabhängiges Unternehmen – dazu gibt es einen eigenen Bericht.

Der Benchmark: die gleichen 5 Aufgaben

Es handelt sich um dieselben fünf Aufgaben, die auch im dsh-Artikel verwendet wurden – jeweils in einem neuen Arbeitsverzeichnis und mit einer neuen Sitzung pro Aufgabe. Am selben Tag führte ich dsh erneut auf V4-Flash mit denselben fünf Aufgaben aus; dabei wurde deepseek-v4-flash in einer Konfigurationsdatei festgelegt. Die Wortwahl der Prompts war nicht identisch: dsh verwendete den Begriff „aktuelles Verzeichnis“, während Kimi die absoluten Pfade zu den jeweiligen Aufgabenverzeichnissen angab. Zudem enthielt Kimis Fix-Prompt die Anweisung: „Falls pytest nicht verfügbar ist, installieren Sie es zunächst mit ‚pip install --user pytest‘“ – obwohl pytest bereits installiert war und Kimi die Installation gar nicht ausführte. Die Spalte „Kimi“ zeigt das zweite Durchlaufen der Aufgaben an: Der erste Durchlauf dauerte 44,8 Sekunden und kostete 0,024 Dollar bei ungenutztem Cache; der zweite Durchlauf ist es, den ich in diesem Artikel als Vergleichswert heranziehe. Die Spalten V4-Pro sowie Gemma-4-26B stammen aus dem dsh-Artikel vom August und wurden nicht erneut ausgeführt. Die Gesamtzeit umfasst den gesamten Prozess. Die Token-Zahlen sowie die Kosten für Kimi stammen aus dem JSON-Output von OpenClaw; bei dsh stammen sie aus dessen eigenem Sitzungsprotokoll.

Aufgabe	Kimi K3 (Pfad A)	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 & 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 erfolgreich laufen (Tests bleiben 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 Codebestand aus 6 Modulen 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
Funktion in 3 Dateien + Tests umbenennen; anschließend Test erfolgreich ausführen	✅ 128,9 s · 9 Werkzeuge (Ausführen, Schreiben; ein sed-Befehl in mehreren Dateien)	✅ 12,3 s · 11 Werkzeuge	✅ 18,2 s · 12 Werkzeuge	✅ 12,2 s · 11 Werkzeuge
Gesamtzeit	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 Token)	≈ $0,011 ($0,44/$1,32/$0,014 pro Million Token)	≈ $0,072	$0 (nur Stromkosten)

Die Angaben zu den Werkzeugen beziehen sich auf die Anzahl der Tool-Aufrufe. Bei Kimi stammen sie aus toolSummary.calls im JSON-Output 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 Preise für Kimi entstammen meinem OpenClaw-Katalogeintrag; OpenClaw nutzt diese Werte zur Berechnung der Kosten pro Aufgabe. Aktuelle Preise finden Sie auf Moonshots Preisseite. Für dsh V4-Flash werden dieselben Spitzenpreise wie im dsh-Artikel verwendet (DeepSeek-Preise); die Werte für V4-Pro sowie Gemma stammen aus jenem Artikel.

Was die Tabelle zeigt:

• In jeder Spalte: 5/5 Punkte. Keine der Aufgaben bereitete Kimi Probleme. Bei der Fehlerbehebung blieben die Tests unverändert; das Umbenennen erforderte lediglich einen sed-Befehl in vier Dateien, gefolgt von einem erfolgreichen Testlauf sowie einem leeren grep-Aufruf nach dem alten Funktionsnamen.
• Kimi benötigt mehr „Nachdenkzeit“. K3 verbrauchte bei den fünf Aufgaben insgesamt 53.241 Reasoning-Token (insgesamt 4.053). dsh auf V4-Flash überlegt ebenfalls, allerdings 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 beeinflusst die Kosten erheblich. Bei den fünf Aufgaben sendete Kimi 91.470 uncached-Eingabetoken; zudem wurden 355.328 Token aus dem Cache gelesen – somit stammten 80 % der eingegebenen Tokens aus dem Cache. Wären alle Token als „uncached“ abgerechnet worden, hätte die Ausführung etwa $1,49 statt $0,53 gekostet.
• Für kleine Aufgaben gewinnt V4-Flash. Für das gesamte Aufgabenpaket benötigte V4-Flash 35,7 Sekunden und verursachte Kosten von ca. $0,011 – das ist etwa 9× schneller sowie 48× günstiger als Kimi bei denselben Aufgaben, wobei das Ergebnis identisch blieb. Allein das Umbenennen dauerte bei Kimi 128,9 Sekunden und kostete $0,180; dsh benötigte dafür lediglich 12,3 Sekunden sowie $0,0043.

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

Der „Fun-Test“ im dsh-Artikel war ein Pixel-Art-Widget des Logos dieser Website – erstellt von dsh auf V4-Flash anhand einer schriftlichen Anweisung. Ich gab Kimi dieselbe, unveränderte Anweisung und maß dabei die Zeit. Die Anweisung lautete:

Auftrag: interaktives Pixel-Art-Widget für das LaserLloyd-Logo

Erstellen Sie eine eigenständige, einbettbare Pixel-Art-Version des LaserLloyd-Logos (siehe reference-logo.png: ein dicker blauer Ring in der Farbe #1f3f8f auf weißem Hintergrund; darin zwei ineinander verschränkte, kursiv/schräge Großbuchstaben „L“ – das untere Ende des oberen „L“ verläuft unter dem Stamm des unteren „L“, als wären die Buchstaben diagonal übereinander gestapelt).

Lieferumfang (alles in diesem Ordner)

1. ll-pixel-logo.js – eine reine Vanilla-JS-Datei, ohne Abhängigkeiten, ohne Build-Schritt und ohne Netzwerkanfragen. Jede Seite kann sie einbinden via: <div class="ll-pixel-logo" data-size="320"></div> + <script src="ll-pixel-logo.js"></script>. Das Skript sucht nach allen Elementen mit der Klasse .ll-pixel-logo und fügt dort ein <canvas>-Element ein. Responsiv: Das Canvas füllt die Breite des Containers aus (quadratisch); auf HiDPI-Displays bleibt es scharf (devicePixelRatio). Es stellt außerdem window.LLPixelLogo.mount(el) bereit.
2. index.html – eine Demo-Seite, die das Widget in drei Größen zeigt sowie kurze Erklärungen zu den Interaktionen.
3. README.md – Anleitung zur Einbindung, Beschreibung der Interaktionen sowie aller verfügbaren Parameter (data-Attribute).

Die Pixel-Art

• Ein Pixel-Raster von 40×40 Zellen. Zeichnen Sie das Bild nicht manuell – keine Zeilen mit „#“/„.“-Zeichen, da dies langsam und fehleranfällig ist. Stattdessen erzeugen Sie das Raster prozedural aus geometrischen Formen: Eine Funktion isLit(col,row), die true zurückgibt, wenn (a) der Abstand vom Zentrum zwischen 0,82R und R liegt – also für den Ring – sowie (b) für die beiden schrägen „L“-Buchstaben. Letztere bestehen jeweils aus zwei Parallelogrammen; das untere Ende des oberen „L“ verläuft unter dem Stamm des unteren „L“, wie im Referenz-Logo. Passen Sie die wenigen Konstanten so an, dass das Ergebnis bei einer Größe von 200px exakt dem Referenz-Logo entspricht. Berechnen Sie die beleuchteten Zellen einmalig beim Einbinden des Widgets.
• Farbpalette: Logo-Blau #1f3f8f; Leuchtfarbe Blau #2ea8ff; Bernstein #ffb64a; Cyan #00e6cf; Hintergrund transparent.

Interaktionen (der Kern des Auftrags – sie sollen Spaß machen)

• Mausbewegung / Touch-Bewegung: Die Pixel in der Nähe des Cursors reagieren physikalisch – sie werden wie von einer Flüssigkeit oder magnetischer Abstoßung weggeschoben und kehren anschließend gedämpft zurück; währenddessen leuchten sie in Richtung #2ea8ff/#00e6cf. Die Animation läuft flüssig mit 60 Bildern pro Sekunde via requestAnimationFrame – ohne Ruckeln.
• Klick / Antippen: Ein tolles, befriedigendes Effekt-Event. Wählen Sie einen starken Effekt aus und realisieren Sie ihn gut – z. B. das gesamte Logo zerfällt in einzelne Pixel, die sich unter Einfluss von Schwerkraft und Reibung nach außen bewegen, um anschließend wieder zu einem Logo zusammenzufügen (ca. 1,5–2 Sekunden); oder ein „Laser“ zeichnet das Logo pixelweise nach, wobei leuchtende Funken entstehen. Mehrfache Klicks sollen sich gut anfühlen – unterbrechen Sie dabei keine laufende Animation.
• Im Ruhezustand: Ein subtiles, atmosphärisches Element (langsames Flimmern oder gelegentliches Aufleuchten einzelner Pixel), damit das Widget niemals „tot“ wirkt – ohne dabei ablenkend zu sein.
• Berücksichtigen Sie prefers-reduced-motion: reduce: In diesem Fall wird nur das statische Logo gerendert; der Hover-Glow bleibt erhalten.
• Funktioniert sowohl mit Maus als auch Touch. Es erfolgt kein „Scroll-Hijacking“.

Qualitätsanforderungen

• Klar strukturierter, kommentierter Code; keine globalen Variablen außer LLPixelLogo. Einrückung mit 2 Leerzeichen. Maximal ca. 400 Zeilen.
• Das Skript läuft ohne Fehler unter file://-URLs. Testen Sie es selbst: Schreiben Sie ein kleines Node-Skript oder öffnen Sie die Datei mit einem beliebigen Tool, um sie syntaktisch zu prüfen sowie die Funktionalität zu testen (jsdom steht NICHT zur Verfügung – nutzen Sie node --check sowie einen DOM-freien Unit-Test, z. B. um die Anzahl der beleuchteten Pixel zu zählen und zu prüfen, ob Ring sowie die beiden „L“-Buchstaben in den richtigen Quadranten vorhanden sind).
• Abschließend geben Sie einen kurzen Bericht aus: Was Sie erstellt haben, wie das Widget eingebunden wird sowie welche Tests erfolgreich waren.

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 Referenz-Logo, überlegte sich die Geometrie sowie die Umsetzungspläne – schrieb aber keine Ergebnisse nieder. Auch dshs erster Versuch scheiterte auf ähnliche Weise (eine 10-minütige Schleife, in der ein Bitmap gezeichnet wurde); die Aufgabenbeschreibung erlaubte damals jedoch noch handgezeichnete Bitmaps.
• Versuch 2 (erneut die gleiche Aufgabenbeschreibung, neuer Sitzungsstart): Ein vollständiges 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; schließlich verfasste es noch einen kurzen Bericht. Alles wurde im eigenen Arbeitsbereich des Worker-Agenten abgelegt – nicht in dem Ordner, den mein Skript überwachte. Die Sitzung lief nach 15 Minuten ab; ich sah von außen, dass Versuch 2 zu keinem Ergebnis geführt hatte. Daher startete ich etwa sieben Minuten später Versuch 3.
• Versuch 3 (gekürzte Aufgabenbeschreibung samt Anweisungen): Nach 7,4 Minuten waren alle drei Dateien erstellt; Kosten: ca. $0,47. Ich behielt die erforderlichen Ergebnisse bei und fügte an den Anfang der Datei folgende Anweisung ein: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. Den Testabschnitt ersetzte ich durch folgende Anweisung: 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 mehrere Teile, die sich anschließend wieder zusammensetzen; außerdem gibt es einen „Idle-Shimmer“-Effekt sowie einen Modus für reduzierte Bewegung. Meine Überprüfungen finden Sie im nächsten Abschnitt.

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 basieren die dortigen Werte auf den von OpenClaw berechneten Kosten pro Nachricht pro Sitzung – diese Summen stimmen mit den Werten des dritten Versuchs überein.

Etwa eine Stunde später tauchte das Widget von Versuch 2 erneut auf – nachdem ein MiniMax M3, der auf demselben Worker lief, die Dateien gefunden, deren Tests ausgeführt und sie als eigene Arbeit gemeldet hatte. Diese Geschichte wird im 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 ~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

Und hier läuft es – die unveränderte Version des Kimi K3-Builds:

Kimi erstellt jedes „L“ aus zwei Parallelogrammen – einem verdrehten Stamm und einem „Fuß“ – mithilfe des kleinen Hilfsprogramms makeL. Anschließend prüft er Punkte mit dem Hilfsprogramm inPara innerhalb von isLit. Alle Einstellungswerte – wie die Ringradien von 0,82R bis R, der 20°-Winkel, der mittels Math.tan berechnet wird, sowie Feder- und Dämpfungseinstellungen – werden in einem Block ganz oben in der Datei gespeichert.

Die Dateien, die Kimi geschrieben hat (die 397 Zeilen umfassende Datei ll-pixel-logo.js, eine 40 Zeilen lange Datei index.html sowie eine 79 Zeilen lange Datei README.md), werden unter /assets/uploads/2026/09/kimi-codex/ bereitgestellt – neben der Aufgabenbeschreibung in der Datei BRIEF.md.

Zur Vergleichung: Die ersten ca. 30 Zeilen des Widgets von dsh, wie sie von /assets/uploads/2026/08/deepseek-harness/ll-pixel-logo.js ausgeliefert werden:

/*!
 * ll-pixel-logo.js — interactive pixel-art LaserLloyd logo widget.
 * Vanilla JS, zero dependencies, no network requests, works from file://.
 *   <div class="ll-pixel-logo" data-size="320"></div>
 *   <script src="ll-pixel-logo.js"></script>
 * Auto-mounts on .ll-pixel-logo elements; window.LLPixelLogo.mount(el) too.
 * Knobs: data-size, data-speed, data-static.
 */
(function (global) {
  'use strict';
  // ---- 0. palette -----------------------------------------------------
  var BLUE = [31, 63, 143];      // #1f3f8f — logo blue
  var HI = [46, 168, 255];       // #2ea8ff — hover / repulsion glow
  var AMBER = [255, 182, 74];    // #ffb64a — twinkle spark
  var CYAN = [0, 230, 207];      // #00e6cf — deep glow
  // ---- 1. art: procedural 40x40 raster (no hand-drawn bitmap) ----------
  // A cell is lit when it belongs to the ring or to one of the two slanted
  // interlocking Ls. Each L is two parallelograms (stem + foot), described by
  // top-left (ax,ay), width w, height h, sheared by SLANT (bottom edge shifts
  // left): TL=(ax,ay) TR=(ax+w,ay) BL=(ax-SLANT*h,ay+h). The upper-left L's
  // foot runs right and tucks under the lower-right L's stem, like the ref.
  var GRID = 40;                 // cells per side
  var RING_R = 19.7;             // outer ring radius (cells)
  var RING_IN = 0.80 * RING_R;   // inner ring radius (reference ~0.808R)
  var SLANT = 0.453;             // shear of stems/feet (~24deg)
  var LETTERS = [
    { ax: 15.0, ay: 5.2, w: 4.2, h: 10.6 },   // upper-left L: stem
    { ax: 10.2, ay: 15.8, w: 15.0, h: 3.8 },  // upper-left L: foot
    { ax: 24.7, ay: 13.8, w: 4.2, h: 14.7 },  // lower-right L: stem
    { ax: 18.0, ay: 28.5, w: 15.0, h: 3.8 }   // lower-right L: foot
  ];

Die beiden Widgets sind auf dieselbe Weise erstellt: Beide wandeln aus geometrischen Formen einen Ring sowie zwei ineinandergreifende, kursiv geschriebene „L“-Buchstaben in Rasterdaten um; beide stellen window.LLPixelLogo.mount zur Verfügung und berücksichtigen außerdem prefers-reduced-motion. Die Konstanten unterscheiden sich jedoch. Dsh verwendet einen äußeren Ringradius von 19,7, einen inneren Ring bei 0,80R sowie einen Neigungswinkel 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; bei dsh beträgt die Breite der Stämme 4,2 Zellen und die Höhe der Enden 3,8 Zellen. Aus diesem Grund werden bei Kimis Logo 510 Zellen beleuchtet, bei dsh hingegen 656. Keines der beiden Logos entspricht exakt dem Referenzlogo – doch auf den ersten Blick erkennt man sie beide als Logo. Beim zweiten Versuch schrieb dsh außerdem einen Node-Unit-Test sowie – ohne dazu aufgefordert worden zu sein – ein Playwright-Skript. Kimi wurde im dritten Versuch angewiesen, auf Tests zu verzichten – und das tat sie auch.

Überprüfungsbefehle, die ich am Widget von Kimi ausgeführt habe

Ich habe diese am 11.09.2026 erneut an der Kopie des Widgets ausgeführt – die sich in /assets/uploads/2026/09/kimi-codex/ befindet:

$ 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. Dabei verwendete ich zwei kleine Hilfsskripte (jeweils unter 20 Zeilen), die ich nicht veröffentlicht habe. Deshalb beschreibe ich hier die Methode anstatt der eigentlichen Befehle, die man kopieren könnte:

• Zählung der beleuchteten Zellen. Ich lud die Widget-Datei in Node.js mit einem „stubbed-out“-DOM (Canvas-, Window- und Document-Objekte wurden simuliert). Anschließend nutzte ich die Funktion isLit(col, row) aus der Datei, um jede Zelle des 40×40-Rasters zu überprüfen. Dabei zählte ich die beleuchteten Zellen nach Quadranten: 124 im oberen linken, 103 im oberen rechten, 160 im unteren linken und 123 im unteren rechten Bereich – insgesamt also 510 Zellen.
• Überprüfung des „Mount“-Mechanismus. Mit demselben simulierten 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 – und 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.

Fallstricke (die, auf die ich tatsächlich gestoßen bin)

• „OpenAI-kompatibel“ bedeutet nicht „kompatibel mit dem Codex-Harness“. Moonshots /v1/chat/completions-Endpunkt funktioniert einwandfrei als OpenClaw-Provider – doch das Codex-Harness-Plugin akzeptiert nur Routen, deren Provider-ID openai lautet. Falls Sie insbesondere die Funktion zum Fortsetzen von Codex-Threads sowie die dynamische Tool-Bridge benötigen, ist Pfad B (der Codex-Router-Bridge) die einzige Option. Siehe dazu oben „Pfad A vs. Pfad B“.
• K3 führt stets eine Begründung durch – selbst bei trivialen Antworten. Die Anweisung „Antworte exakt mit: PONG.“ verbrauchte 53 Reasoning-Tokens. Das ist beabsichtigt und vorhersehbar; planen Sie entsprechend Budget ein.
• Ein compat-Block ersetzt bestehende Einstellungen – er führt keine Fusion durch. Wenn Sie compat zur Modellkonfiguration hinzufügen, um z. B. temperature zu deaktivieren, müssen Sie auch die entsprechenden Felder zum Reasoning-Effort kopieren – andernfalls gehen diese stillschweigend verloren.
• Der angegebene 1-Million-Kontext ist nur eine Werbeangabe – er gilt nicht für meine Grenzen. Im Katalog steht „1.048.576 Tokens“; bei mir beträgt contextTokens: 262144, sodass Sitzungen auf ca. 256k begrenzt sind. Erhöhen Sie diesen Wert absichtlich – nicht versehentlich.
• Der Rabatt für Cache-Nutzung ist real, doch die Preise entsprechen den Premium-Sätzen. 0,30 $ pro Million gelesener Cache-Tokens entspricht etwa dem 21-fachen von dsh V4-Flashs Preis von 0,014 $. Dennoch reduziert der Cache die Kosten um rund ein Drittel im Vergleich zu einer Nutzung ohne Cache.
• Offene, kreative Aufgabenstellungen können ein Reasoning-Modell zum Stillstand bringen; ein Timeout kann jedoch auch einen Erfolg verbergen. Versuch 1 dachte 8,8 Minuten lang nach – ohne dabei Code zu schreiben. Versuch 2 erstellte zwar ein funktionierendes Widget, lief aber ab, bevor die Dateien im richtigen Ordner gespeichert wurden; es wirkte daher wie ein Fehler. Erfolgreich war hingegen eine kürzere Aufgabenstellung: TARGETED — write the widget file in one tool call, no exploration, no planning, no verification loop. K3 führt auch bei solchen Anweisungen noch eine Begründung durch – allerdings nicht endlos. Unabhängig vom Exit-Status sollten Sie stets prüfen, was die Sitzung tatsächlich erstellt hat.
• Ein Fehler-Exit bedeutet nicht zwangsläufig, dass die Aufgabe gescheitert ist – überprüfen Sie die Dateien. Der erste FizzBuzz-Aufruf endete mit Code 1 sowie der Meldung „⚠️ API rate limit reached. Please try again later.“ Tatsächlich hatte er bereits fizz.py geschrieben; die Datei funktionierte einwandfrei. Ein erneuter Versuch meldete lediglich „Already created and ran.“ – das Protokoll des zweiten Durchlaufs überschrieb jedoch das Ergebnis des ersten. Letzteres findet sich im Log der Sitzung, die den Benchmark ausgeführt hat. In der Tabelle ist der zweite, erfolgreiche Durchlauf aufgeführt.
• Kopieren Sie niemals einen Scratch-Ordner von einem abgeschlossenen Lauf eines anderen Harnesses. Ich kopierte zunächst die Dateien aus dshs fertiggestelltem Ordner in Kimis Bug-Fix-Ordner – obwohl dsh die Fehler bereits behoben hatte. Daher fand Kimis erster Testlauf die bereits korrigierten Dateien vor und verifizierte sie lediglich. Erst nach einem Neustart der Sitzung entstand der in der Tabelle dokumentierte zweite Lauf. Zudem arbeitet dsh stets im Verzeichnis, aus dem es gestartet wird: Mein erstes Skript änderte den Pfad nicht per cd, wodurch die Dateien am falschen Ort entstanden; ich musste alle fünf Aufgaben erneut ausführen.
• Keines der Widgets entspricht exakt dem Referenz-Logo. Die Vorgabe lautet, die Konstanten so einzustellen, dass das Ergebnis bei 200px Größe wie das Original aussieht. Ich würde mindestens zehn Minuten an der Anpassung von Strichbreiten und Neigung verbringen, bevor ich eines davon veröffentliche.

Wohin das mich führt

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. Nach diesem Benchmark habe ich meinen Arbeits-Agenten von Kimi auf MiniMax-M3 umgestellt; Kimi K3 blieb jedoch dort, wo es bereits war: hinter meinem Überprüfungs-Agenten – schließlich lohnt es sich bei langsameren, aber sorgfältigeren Antworten, mehr zu zahlen.

Der Weg B, also die Verbindung des Codex-Routers zum eigentlichen Codex-App-Server, bleibt vorerst nur auf dem Papier – bis ich mir sicher bin, was homeScope: "user" im Detail bewirkt. Bis dahin bedeutet „Kimi als Coding-Agent“ auf meinem System, dass Kimi die native Schleife von OpenClaw steuert – genauso wie jedes andere OpenClaw-native Modell auch.

Verwandte Themen: DeepSeek Harness (dsh) (das Tool, mit dem ich verglichen habe; hier stammen Benchmark und Aufgabenstellung her), MiniMax M3 (dasselbe Tool, allerdings auf dem Modell, das mein Arbeits-Agent seit dem 11.09.2026 nutzt), Reasonix (veraltet; am 09.09.2026 von meinem System entfernt) sowie Was meine KI-Agenten tatsächlich kosten (ein umfassender Preisvergleich).