Pixel-Art-Widget-Showdown: Drei Codierungsagenten, ein Auftrag, zwei Autoren

Die folgende Aufgabenstellung wurde im August für dsh, DeepSeeks Codier-Agenten, verfasst. Im September führte ich dieselbe Aufgabenstellung nacheinander mit Kimi K3 und MiniMax M3 durch; beide nutzten dabei OpenClaws eigenen Agenten-Loop auf demselben Worker-Agenten. Zwei der drei Agenten erstellten jeweils ein Widget. Der dritte behauptete ebenfalls, eines erstellt zu haben. Das Nützlichste an diesem Test ist nicht eine Rangliste der Widgets – sondern die Erkenntnis, dass man prüfen sollte, was ein Agent tatsächlich geschrieben hat, bevor man seinen Aussagen glaubt.

Die Zahlen

Jeweils ein Durchlauf pro Agent; bei Kimi waren es drei Versuche. Betrachten Sie dies daher als eine Anekdote mit Belegen – nicht als Benchmark. Die Spalten zeigen die drei Widget-Dateien auf dieser Seite.

Die fehlende Spalte bezieht sich auf Kimis ersten Versuch. Bei der unveränderten Aufgabenstellung dachte er 8,8 Minuten lang nach, schrieb jedoch keinen Code – der Durchlauf kostete ca. $0,31. Insgesamt verursachten Kimis drei Versuche etwa $1,50 für zwei Widgets. Dshs fehlgeschlagener erster Versuch kostete lediglich 2 Cent; sein gesamter Durchlauf belief sich somit auf ca. 51 Cent.

Die Kosten für Versuch 3 stammen aus dem entsprechenden JSON-Beleg. Für die ersten beiden Versuche gab es keinen solchen Beleg; daher wurden die Summen aus den pro Nachricht berechneten Kosten von OpenClaw ermittelt – diese entsprechen exakt der Gesamtsumme in Versuch 3s Beleg. Alle Angaben zu Kimi basieren auf den Moonshot-Raten gemäß meiner OpenClaw-Konfiguration.

Was MiniMax tat

MiniMax M3 erhielt dieselbe, unveränderte Aufgabenstellung etwa eine Stunde nach Kimis zweitem Versuch – ebenfalls auf demselben Worker-Agenten und in dessen Arbeitsbereich. Kimis Dateien vom zweiten Versuch waren noch vorhanden. Innerhalb von 59 Sekunden (25 Durchläufe, 24 Tool-Aufrufe; zu Listenpreisen ca. $0,13 bei meinem monatlichen Flatrate-Plan) las MiniMax diese fünf Dateien sowie Kimis eigenen Bericht, führte dessen zwei Testdateien aus und antwortete: „Das gesamte Widget-Set wurde erstellt und überprüft.“ Es schrieb keinen einzigen Codezeile – lediglich seinen eigenen Bericht sowie eine Statusdatei.

Ich glaubte dieser Antwort zunächst. Die erste Version dieser Seite wies MiniMax eine dritte Zelle zu: eine Spalte mit einem Versuch, 59 Sekunden Laufzeit und $0,13 Kosten – mit der Schlussfolgerung, dass dies der günstigste, schnellste sowie einzige erfolgreiche Durchlauf sei. Der Sitzungslog zeigte jedoch: Die dort angezeigte Datei war exakt dieselbe, die Kimis zweiter Versuch um 08:11 Uhr JST erstellt hatte; MiniMax las sie lediglich, ohne sie zu verändern. Folglich besitzt MiniMax kein eigenes Widget auf dieser Seite. Ein fairer Test wäre ein erneuter Durchlauf in einem leeren Ordner – was ich bislang nicht getan habe.

Kimi Versuch 2 ist das Gegenstück: Er schrieb sein Widget, die Tests sowie einen kurzen Bericht in seinen Arbeitsbereich; wurde jedoch abgebrochen, bevor er antworten konnte. Aus meiner Sicht schien nichts erstellt worden zu sein. Ein Agent behauptete Arbeit geleistet zu haben, die er nicht tat; der andere tat etwas, was niemand sah. In beiden Fällen widersprachen die Antworten den tatsächlich vorhandenen Dateien – und diese waren korrekt.

Probieren Sie alle drei aus

Ein früherer Entwurf dieser Seite enthielt eine vierte, leere Zelle für Reasonix. Dieser Agent erhielt die Aufgabenstellung nie; ich habe ihn mittlerweile von meinem System entfernt – daher ist er nicht Teil des Vergleichs.

Was sich tatsächlich unterscheidet

Alles Folgende basiert auf der Analyse der drei Skripte – nicht auf den Beschreibungen der Agenten.

Gemeinsamkeiten. Alle drei implementieren exakt die vier in der Aufgabenstellung vorgegebenen Farben. Im Ruhezustand befinden sich die Pixel entweder am Logo-Blau oder nahe daran; ein verschobener Pixel leuchtet von Blau über das Highlight-Blau bis zu Cyan. Alle drei erfüllen den ersten vorgeschlagenen Klick-Effekt: Das Logo zerfällt in Einzelpixel, die der Schwerkraft folgen und anschließend wieder zusammensetzen. Dsh sowie Kimis Versuch 2 wählten diesen aus zwei Möglichkeiten; Versuch 3s gekürzte Aufgabenstellung bot nur diese Option an. Alle drei respektieren prefers-reduced-motion, funktionieren mit Touch und bleiben unter der empfohlenen Zeilenzahl von ca. 400.

Form. Die Aufgabenstellung verlangte einen Ring von 0,82R bis R sowie Ls, die um etwa 20° geneigt sind. Kimis Versuch 3 folgte dies exakt (Math.tan(20 * Math.PI / 180); Stiele 3 Zellen dick) – das Ergebnis war mit 510 beleuchteten Zellen das leichteste. Versuch 2 nutzte eine Neigung von 0,42 (ca. 23°) mit 4,6 Zellen breiten Stielen: 602 Zellen. Dsh wählte 0,453 (ca. 24°), 4,2 Zellen dicke Stiele sowie einen etwas dickeneren Ring ab 0,80R: 656 Zellen – das kompakteste aller drei. Keines davon ähnelt dem Original-Logo genug, um es zu ersetzen.

Klick-Effekt. Dsh aktiviert den Effekt für 0,72 Sekunden; danach kehren die Pixel innerhalb von maximal einer halben Sekunde an ihre Ausgangsposition zurück – das Logo „wellt“ sich dabei. Die Pixel prallen von allen vier Wänden ab; nur schnelle Berührungen mit geringer Bewegung gelten als Klick – ein Scrollen zerstört es also nicht. Kimis Versuch 3 läuft für 0,85 Sekunden und kehrt dann zurück; dabei ignoriert er weitere Klicks, bis das Logo vollständig wiederhergestellt ist. Unter reduzierter Bewegung gibt es lediglich einen kleinen Puls – obwohl die Aufgabenstellung ein statisches Logo verlangte. Versuch 2 dauert ebenfalls 0,85 Sekunden, kehrt nach 1,0 Sekunden zurück und prallt nur vom Boden ab; ein weiterer Klick während des Fluges zerstört es erneut.

Ruhezustand. Dsh erzeugt langsame Farbverläufe sowie alle 1,2 bis 3,8 Sekunden ein bis drei bernstein- oder cyanfarbene Funken. Kimis Versuch 3 verändert die Opazität jedes Pixels und fügt alle 0,2 bis 0,6 Sekunden einen neuen bernsteinfarbenen Glanz hinzu – wodurch er am aktivsten wirkt. Versuch 2 blitzt alle zwei Sekunden ein bernstein- oder cyanfarbener Pixel auf und zeichnet hinter die nächstgelegenen Pixel einen weichen Halo.

Code-Struktur. Dsh verwendet einen Widget-Konstruktor mit Prototyp-Methoden sowie eine separate mount()-Funktion; dazu existieren data-size, data-speed und data-static-Parameter. Kimis Versuch 3 nutzt einen Logo-Konstruktor mit zwei Geometrie-Hilfsfunktionen (inPara und makeL) sowie den data-interactive-Parameter. Versuch 2 hat keinen Konstruktor: createInstance() gibt ein gewöhnliches Objekt zurück; die Physik wird in freien Funktionen implementiert. Zudem exportiert er sich als Node-Modul – weshalb seine Tests ohne Browser laufen. Dasselbe Modell, doch die beiden Dateien weisen kaum strukturelle Ähnlichkeiten auf.

Warum jeweils ein eigenes Frame? Die Aufgabenstellung verlangte, dass das Skript „alle Elemente mit der Klasse .ll-pixel-logo findet und darin ein Canvas einbindet“ – was alle drei taten. Jedes markierte seine Container mit unterschiedlichen Eigenschaftsnamen und überschrieb jeweils das gemeinsame window.LLPixelLogo. Setzte man alle drei Skripte auf einer Seite ein, entstanden also drei übereinanderliegende Canvas-Elemente pro Container. Der erste Entwurf dieser Seite wies exakt diesen Fehler auf; ich bemerkte ihn erst auf meinem Handy. Ein eigenes Frame pro Widget sorgt dafür, dass die Skripte getrennt bleiben – ohne ihren Code verändern zu müssen.

Was ich daraus mitnehme

Zwei Agenten erstellten Widgets aus dieser Aufgabenstellung. Dsh benötigte zwei Versuche und ca. 49 Cent für das funktionierende Ergebnis; dies geschah drei Wochen vorher – nachdem die Aufgabenstellung bereits einmal missverstanden worden war. Kimi brauchte drei Versuche und insgesamt ca. $1,50, um zwei unterschiedliche, funktionierende Widgets zu erzeugen – von einem davon wusste ich erst nach eingehender Suche. Der dritte Agent lieferte lediglich eine selbstbewusste Aussage über fremde Dateien ab.

Ich würde dies nicht zu einer Rangliste der Widgets verallgemeinern. Es gab jeweils nur einen Durchlauf pro Agent; dshs Aufgabenstellung war nach dem ersten Misserfolg angepasst worden; Kimis Versuch 3 erhielt eine kürzere Version. Wichtig ist vielmehr der Prozess: Eine präzise Aufgabenstellung mit regelbasierten Geometrie-Anweisungen führt letztlich zu einem funktionierenden Widget – vorausgesetzt, man prüft, welcher Agent es erstellt hat. Beim nächsten Mal werde ich jedem Agenten einen leeren Ordner zuweisen und erst die von ihm geschriebenen Dateien untersuchen, bevor ich mir seinen Bericht ansehe.

Die Aufgabenstellung (vollständig zitiert)

Dies ist die Ausschreibung – exakt so, wie dsh sie beim zweiten Versuch erhalten hat, Kimi bei seinen ersten beiden Versuchen sowie MiniMax. Umfang: 3.301 Bytes. Beim ersten Versuch von dsh wurde eine frühere Version verwendet, in der es noch erlaubt war, ein Bitmap per Hand zu zeichnen; die Zeile „Handgezeichnete Bitmaps sind nicht zulässig“ stellt die entsprechende Änderung dar. Kimis dritter Versuch lieferte eine gekürzte Version – mit der in der Tabelle angegebenen Anweisung.

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

Erstellen Sie eine eigenständige, einbaubare **Pixel-Art-Version des LaserLloyd-Logos** (siehe `reference-logo.png`):
Ein dicker blauer Ring in der Farbe #1f3f8f auf weißem Hintergrund; darin befinden sich zwei ineinander verwobene, kursiv/schräge Großbuchstaben „L“ – das untere Ende des oberen „L“ verläuft unter dem Stamm des unteren „L“, sodass die Buchstaben diagonal übereinander liegen.

## Ergebnisse (alle in diesem Ordner)
1. `ll-pixel-logo.js` – EINE reine Vanilla-JS-Datei, keine Abhängigkeiten, kein Build-Schritt, keine Netzwerkanfragen.
   Jede Seite kann sie so einbinden:
     <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 in diese jeweils ein ``-Element ein. Responsiv: Das Canvas füllt die Breite des Containers aus (quadratisch); auf HiDPI-Bildschirmen 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 `data-`-Attribute.

## Die Grafik
- Ein Pixel-Raster von 40×40 Zellen. Handgezeichnete Bitmaps sind nicht zulässig (keine Zeilen mit „#“/„.“ – das ist langsam und fehleranfällig). Stattdessen muss die Grafik prozedural aus Geometrie erzeugt werden: mittels einer Funktion `isLit(col,row)`, die für folgende Bereiche „true“ zurückgibt:
  (a) Der Ring: Abstand vom Zentrum zwischen 0,82R und R;
  (b) Die beiden schrägen „L“-Buchstaben – jeweils aus zwei Parallelogrammen bestehend (ein Stamm, der ca. 20° geneigt ist, sowie ein Fuß); das untere Ende des oberen „L“ liegt exakt unter dem Stamm des unteren „L“, wie im Referenzlogo. Passen Sie die wenigen Konstanten so an, dass das Ergebnis bei einer Größe von 200 Pixeln exakt dem Referenzlogo entspricht. Berechnen Sie die beleuchteten Zellen bereits beim Einbinden des Widgets.
- Farbpalette: Logo-Blau #1f3f8f; Leuchtfarbe Blau #2ea8ff; Bernsteinfarbe #ffb64a; Cyan #00e6cf; Hintergrund transparent.

## Interaktionen (der Kern dieser Aufgabe – sie sollen unterhaltsam sein)
- **Mausüberfahrt / Touch-Bewegung:** Die Pixel in der Nähe des Zeigers reagieren physikalisch – sie werden vom Cursor weggeschoben, ähnlich wie bei einer magnetischen Abstoßung; anschließend kehren sie mit Dämpfung in ihre Ausgangsposition zurück. Während der Bewegung leuchten sie in Richtung #2ea8ff/#00e6cf. Die Animation läuft flüssig mit 60 fps mittels `requestAnimationFrame`; es darf keine Verzögerungen geben.
- **Klick / Tap:** Eine beeindruckende, befriedigende Reaktion – wählen Sie EINEN effektvollen Mechanismus und realisieren Sie ihn gut. Beispiele: Das gesamte Logo zerbricht in einzelne Pixel, die sich unter Einfluss von Schwerkraft und Reflexion ausbreiten; anschließend setzt es sich wieder zusammen (ca. 1,5–2 Sekunden). Oder ein „Laser“ zeichnet das Logo pixelweise nach, wobei leuchtende Funken entstehen. Mehrfache Klicks sollen sich gut anfühlen – die Animation darf dabei nicht unterbrochen werden.
- **Ruhezustand:** Ein subtiler, atmosphärischer Effekt (langsames Flimmern oder gelegentliches Aufleuchten einzelner Pixel), sodass 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, während das Leuchten bei der Mausüberfahrt ausbleibt.
- Das Widget muss sowohl mit Maus als auch Touch funktionieren; es darf keine Scroll-Hijacking-Effekte geben.

## Qualitätsanforderungen
- Sauberer, kommentierter Code; außer `LLPixelLogo` dürfen keine globalen Variablen verwendet werden. Tabbreite: 2; maximal ca. 400 Zeilen.
- Das Skript muss ohne Fehler über `file://` ausgeführt werden. Testen Sie es selbst: Schreiben Sie ein kleines Node-Skript oder öffnen Sie die Datei mit einem beliebigen Tool, um sie zumindest auf Syntaxfehler zu prüfen sowie den Modul-Code zu testen (z. B. mittels `node --check`). Ein DOM-freier Unit-Test ist ebenfalls erforderlich – etwa das Zählen der beleuchteten Zellen sowie die Überprüfung, ob Ring und beide „L“-Buchstaben in den richtigen Quadranten vorhanden sind.
- Abschließend geben Sie einen kurzen Bericht aus: Was Sie erstellt haben, wie das Widget einzubinden ist sowie welche Tests Sie durchgeführt haben.

Software-Stack

• Die Ausschreibung: oben vollständig zitiert.
• dsh: Version 0.1.0-rc.7 zum Zeitpunkt der Erstellung des Widgets im August (Stand 2026-09-11: 0.1.1-rc.2); verwendet DeepSeek V4-Flash.
• Kimi K3 und MiniMax M3: OpenClaw 2026.9.2; jeweils eigener Agent-Zyklus; beide nutzen denselben Worker-Agenten.
• Die Widgets: dsh, Kimi, Versuch 3, Kimi, Versuch 2 – unverändert. Jedes Widget wird über eine HTML-Seite mit einem einzigen Container in einem eigenen iframe eingebunden.
• Von mir durchgeführte Tests: node --check auf allen drei Skripten; Zählung der beleuchteten Zellen durch Aufruf der jeweiligen isLit-Funktion auf dem 40×40-Raster; Identifizierung der Urheber durch Vergleich der Dateihashes mit den Protokollen der Agenten; Testlauf in einem headless Chromium unter 390, 768 und 1280 Pixeln – dabei wurde überprüft, ob pro Frame ein Canvas erzeugt wird, ob die gesamte Ausschreibung sichtbar ist, ob es keinen seitlichen Scroll gibt sowie ob keine Fehlermeldungen im Konsolenfenster auftreten.
• Umschlagbild: Handgezeichnetes SVG; kein Bildmodell verwendet.

Verwandte Themen: DeepSeek Harness (dsh) (Quelle der Ausschreibung sowie des ersten Widgets), Kimi K3 als Coding-Agent (alle drei Versuche von Kimi) sowie MiniMax M3 als Coding-Agent (der Fünf-Aufgaben-Test sowie der Vorfall mit dem verwechselten Widget).