AI-Modelle im IKEA-Test: GPT-6.1 Sol und Claude Opus 5.5 vorne
Bei der Aufgabe, eine 24-seitige IKEA-ALEX-Anleitung in ein 3D-Modell umzusetzen, erzielten GPT-6.1 Sol und Claude Opus 5.5 je 46 von 46 Punkten auf der Bewertungsskala. Kimi K3.1 Pro lieferte eine funktionierende gehostete Benutzeroberfläche.
Veröffentlicht am 25. Oktober • Zuerst erschienen auf kartit.net
Kimi K3.1 Pro, Claude Opus 5.5, GPT-6.1 Sol, GPT-6 Astra und Gemini 4 Argon haben am 25. Oktober 2026 dieselbe Aufgabe bearbeitet: eine 24-seitige IKEA-ALEX-Anleitung in ein 3D-Modell umzusetzen. Über sechs Builds und 23 nummerierte Schritte erreichten Sol bis Codex und Opus jeweils 46/46 Punkte auf der Bewertungslehre für die Anleitung. Kimi lieferte eine funktionierende gehostete Benutzeroberfläche, erzielte aber nur 12/46 Punkte für die Montagekorrektheit. Diese erweiterte Rezension bewahrt die URL des ursprünglichen Opus-Artikels und ergänzt die Ergebnisse der anderen Modelle, Live-Demos, die Einstellungen für den Rechenaufwand, aufgezeichnete Laufzeiten sowie die Kostenangaben.
Nutzen Sie das Modell-Dropdown im Live-Vergleich. Die ursprüngliche URL öffnet nun die Auswahl statt ausschließlich das Opus-Ergebnis anzuzeigen.
Kimi bleibt auf seiner ursprünglichen Kimi-Seite gehostet. Die anderen fünf Ergebnisse werden auf kartit.net ausgeliefert. Die Auswahl bietet einen Open-demo-Link an, falls ein eingebettetes Ergebnis nicht verfügbar ist.
Die Tabelle trennt die Korrektheit gegenüber der Anleitung, die Funktionsmerkmale der Benutzeroberfläche und die visuelle Bewertung, weil diese drei Aspekte unterschiedliche Dinge messen.
Die Reihenfolge richtet sich zuerst nach der Korrektheit gegenüber der Anleitung, dann nach den Funktionsmerkmalen und schließlich nach dem blinden visuellen Gesamtergebnis pro Build. Sol bis Codex und Opus liegen bei den ersten beiden Prüfungen daher gleichauf; beim visuellen Tie-Break liegt Sol vorn. Ein separater visueller Sechswege-Vergleich zog Opus vor. Dies sind verschiedene Bewertungsdurchgänge und damit nicht austauschbare Messgrößen.
Die Durchläufe teilten lediglich dieselbe Ausgangsaufgabe, nicht aber identische kontrollierte Bedingungen. Werkzeuge, Zugriffspläne und Nachfass-Prompts unterschieden sich. Diese Einschränkungen sind bei der Interpretation der Tabelle wichtig.
Kimis größter Schwachpunkt ist die Lücke zwischen einer funktionierenden Benutzeroberfläche und den Montageaktionen, die sie darstellt.
Kimi zeigt durchaus die finale Anordnung von zwei flachen Schubladen über drei tiefen Schubladen. Seine Steuerung und Bildausschnitte sind brauchbar. Die Schlussfolgerung bezieht sich auf diesen Build: Es handelt sich um einen interaktiven Prototyp, der erhebliche Korrekturen an der Quelle benötigt, und nicht um den Nachweis, dass jeder künftige Kimi-Durchlauf scheitern wird.
Beide Builds erfüllten alle getesteten nummerierten Anweisungen gemäß der Bewertungslehre für die Anleitung, einschließlich der Ausrichtung des Schranks, des wiederholten Schubladenbaus und der finalen Anordnung der Schubladen.
Opus macht die Bewegung besonders leicht mit der Quellseite nachvollziehbar. Sol bis Codex bildet die gedruckten Stückzahlen der Beschläge in seinen Szeneninstanzen korrekt ab und war im aufgezeichneten Durchlauf schneller. Beide haben weiterhin Darstellungsschwächen: winzige Beschläge in Totalaufnahmen, geringer Kontrast zwischen weißen Teilen und wiederholte Aktionen, die klare Zählungen erfordern.
Sols eigener zeitgesteuerter Durchlauf konnte den Browsertest wegen einer Freigabesperre nicht ausführen. Spätere externe Vergleichsprüfungen bestanden. Opus erhielt nach dem zeitgesteuerten Durchlauf Änderungen an Darstellung und Demo, und der vorliegende Score beschreibt die ausgelieferte Version. Ein Score von 46/46 auf der Bewertungslehre ist keine Behauptung, dass jedes geometrische Detail physisch validiert wurde.
Jedes Modell weist einen anderen Fehler auf, den ein einzelner finaler Screenshot übersehen könnte.
Diese Beispiele zeigen, warum das Prüfen von JSON, das Prüfen von Schaltflächen und das Prüfen des gerenderten Montageverhaltens getrennte Aufgaben sind.
Die tatsächliche Zahlungsgrundlage ist hier verlässlicher als ein einzelnes hypothetisches Dollar-Ranking.
Abonnements sind nicht gratis, nur weil ein Durchlauf keine inkrementelle API-Zahlung verursacht. Eine frühere Kalkulation zu Argon nutzte ein kleineres Zeitfenster und ergab 2,53 Dollar; dieser Artikel verwendet den späteren Datensatz von 2,5562 Dollar. API-äquivalente Berechnungen für Abonnement-Durchläufe hängen von Preis- und Cache-Annahmen ab. Es sind weder Rechnungen noch aktuelle Herstellerangebote. Kimis aufgezeichnete Dauer lässt keinen Rückschluss auf die Dauer des Builds zu.
„High“ und „Medium“ sind die Einstellungen im jeweiligen Werkzeug. Sie stellen keinen standardisierten Rechenaufwand über die Anbieter hinweg dar.
Jeder der 23 Schritte wurde an mehreren Stellen seiner Animation mit der Anleitung verglichen und mit 0 für falsch, 1 für teilweise oder 2 für übereinstimmend mit der getesteten Anweisung bewertet. Die gesonderte Checkliste mit elf Punkten umfasste Wiedergabe, Scrubbing, Explosionsansicht, Bauteilinspektion, Orbit/Zoom, Vergleich mit der Anleitung, Bildausschnitt, Flips, Schubladeneinsetzen und Konsolenfehler.
Der blinde visuelle Bewerter war Gemini 4 Argon, das zugleich einer der Teilnehmer war. Es stufte seinen eigenen Build am niedrigsten ein, was einen einzelnen Bewertungsdurchlauf jedoch nicht zu einem unabhängigen wiederholten Benchmark macht. Astra und der zweite Sol-Durchlauf wurden in einer späteren Sitzung bewertet. Kurze aufgezeichnete Zeitfenster führten zudem dazu, dass der Bewerter bereits erfolgte Schubladenbewegungen übersah. Manuelle Prüfungen korrigierten mehrere Behauptungen des Bewerters zu den Positionen von Opus-Cam-Locks und Füßen.
Nehmen Sie die originale Anleitung als primäre Quelle, prüfen Sie die tatsächliche Animation und behandeln Sie einen visuellen Bewerter nur als zusätzliches Indiz.
Der Ausgangs-Prompt verlangte Belege vor dem Code und beobachtbare Bewegung, bevor der Erfolg erklärt werden durfte:
Lies zuerst jede Seite der Montageanleitung. Schreibe eine guide.json mit jedem Bauteil, jeder Beschlagsnummer, jeder Stückzahl, jedem nummerierten Schritt, jeder Quellseite, jeder Bewegungsrichtung, Rotation und Warnung. Markiere geschätzte Maße. Schreibe ein seitenweises READING_LOG.md. Baue aus diesen Daten einen Offline-Three.js-Guide mit passender Anleitungsseite, Wiedergabesteuerung, Scrubbing, Explosionsansicht, anklickbaren Bauteilen, Orbit/Zoom und Vergleichsmodus. Animiere die Pfeile, Schrauben, Panel-Flips und das finale Schubladeneinsetzen der Anleitung. Teste jeden Schritt in einem Browser und prüfe die Konsole.
Für einen stabileren Wiederholungslauf sollten Sie explizite Assertions hinzufügen, welche Bauteile vor, während und nach jedem Schritt sichtbar sind, und die Beschlagscodes getrennt von der Geometrie verifizieren.
Der ursprüngliche Artikel dokumentierte Opus' erstes funktionierendes Ergebnis mit 28 Min 44 Sekunden, gerundet auf 29 Minuten. Dieses Update ergänzt die finale Zeitmessung und die fünf anderen Builds, ohne die Artikel-URL zu ändern.
Die gehostete Opus-Seite schlug zunächst fehl, weil eine globale Git-Ignore-Regel die mitgelieferte Three.js-Laufzeitumgebung von der Bereitstellung ausschloss. Die Laufzeitumgebung wird nun mitgeliefert. Die öffentliche Demo korrigiert zudem die gegenläufigen Biegungen und geschlossenen sechseckigen Enden des Inbusschlüssels sowie die Spitze des Kreuzschlitzschraubendrehers. Diese sind als Nachrezensions-Korrekturen der öffentlichen Demo gekennzeichnet. Sie wurden nicht stillschweigend in die Scores des ursprünglichen zeitgesteuerten Durchlaufs eingerechnet. Die anderen öffentlichen Builds behalten das geprüfte Verhalten, einschließlich ihrer dokumentierten Fehler.
Das stärkste Ergebnis ist nicht einfach ein Schrank, der fertig aussieht. Es ist ein Guide, dessen Bauteile, Bewegungen und Bezeichnungen sich bis zur Anleitung zurückverfolgen lassen. Dieses Experiment macht einen nützlichen Unterschied sichtbar: Eine polierte Benutzeroberfläche kann funktionale Prüfungen bestehen und dabei die falsche Montage vermitteln. Bitten Sie eine KI, ihre Arbeit anhand der Quelle nachzuweisen, und spielen Sie dann jeden Schritt ab.
Unabhängige Rezension von Anass Kartit. Keine Verbindung zu IKEA oder den Modellanbietern. Demo-Montageanleitungen sollten gegen die originale Anleitung geprüft werden.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 25 • Originally published at kartit.net
Kimi K3.1 Pro, Claude Opus 5.5, GPT-6.1 Sol, GPT-6 Astra and Gemini 4 Argon attempted the same 24-page IKEA ALEX manual-to-3D task on 25 October 2026. Across six builds and 23 numbered steps, Sol through Codex and Opus tied at 46/46 on the manual rubric. Kimi delivered a working hosted interface but scored 12/46 for assembly correctness. This expanded review preserves the original Opus article's URL and adds the other results, live demos, effort settings, recorded durations and cost qualifications.
Use the Model dropdown in the live comparison. The original URL now opens the selector instead of presenting Opus as the only result.
Kimi remains hosted on its original Kimi page. The other five results are served on kartit.net. The selector provides an Open demo link if an embedded result is unavailable.
The table keeps manual correctness, interface features and visual judging separate because they measure different things.
The ordering uses manual correctness, then features, then the per-build blind visual total. Sol through Codex and Opus therefore tie on the first two checks; the visual tie-break places Sol first. A separate six-way visual comparison preferred Opus. These are different judging passes, not interchangeable measurements.
The runs shared a starting task, not identical controlled conditions. Tools, access plans and follow-up prompts differed. Those limitations matter when interpreting the table.
Kimi's biggest failure is the gap between a working interface and the assembly actions it depicts.
Kimi does show the final arrangement of two shallow drawers above three deep drawers. Its controls and framing are useful. The conclusion is about this build: it is an interactive prototype that needs substantial source correction, not evidence that every future Kimi run will fail.
Both builds matched every tested numbered instruction under the manual rubric, including the cabinet orientation, repeated drawer construction and final drawer arrangement.
Opus makes the movement particularly easy to connect to the source page. Sol through Codex matches the printed hardware totals in its scene instances and completed faster in the recorded run. Both still have presentation limitations: tiny hardware in wide shots, low contrast between white parts, and repeated actions that need clear counts.
Sol's own timed run could not perform the browser test because of an approval gate. Later external comparison checks passed. Opus received presentation and demo changes after the timed run, and the available score describes the served version. A 46/46 rubric score is not a claim that every geometric detail has been physically validated.
Each has a different failure that a final screenshot could miss.
These examples explain why checking JSON, checking buttons and checking rendered assembly behavior are separate tasks.
Actual payment basis is more reliable here than a single hypothetical dollar ranking.
Subscriptions are not free just because a run has no incremental API payment. Earlier Argon accounting used a smaller window and showed $2.53; this article uses the later $2.5562 record. API-equivalent calculations for subscription runs depend on pricing and cache assumptions. They are not invoices or current vendor quotes. Kimi's recording duration does not establish its build duration.
“High” and “Medium” are the settings in each tool. They do not represent a standardized amount of computation across vendors.
Each of the 23 steps was compared with the manual at multiple points in its animation and scored 0 for wrong, 1 for partial, or 2 for matching the tested instruction. The separate eleven-item checklist covered playback, scrubbing, exploded view, part inspection, orbit/zoom, manual comparison, framing, flips, drawer insertion and console errors.
The blind visual judge was Gemini 4 Argon, also one of the contestants. It ranked its own build lowest, but that does not turn a single judging pass into an independent repeated benchmark. Astra and the second Sol run were judged in a later session. Short recorded windows also caused the judge to miss drawer movements that had already happened. Manual checks corrected several judge claims about Opus's cam-lock and foot locations.
Use the original manual as the primary source, inspect the actual animation, and treat a visual judge as additional evidence.
The starting prompt required evidence before code and observable motion before declaring success:
Read every page of the assembly manual first. Write guide.json with every part, hardware number, count, numbered step, source page, movement direction, rotation and warning. Mark estimated dimensions. Write a page-by-page READING_LOG.md. Build an offline Three.js guide from that data, with the matching manual page, playback controls, scrubbing, exploded view, clickable parts, orbit/zoom and compare mode. Animate the manual's arrows, screws, panel flips and final drawer insertion. Test every step in a browser and check the console.
For a stronger repeat, add explicit assertions for which parts are visible before, during and after every step, and verify hardware codes separately from geometry.
The original article documented Opus's first working result at 28 min 44 s, rounded to 29 minutes. This update adds the final timing and the five other builds without changing the article URL.
The hosted Opus page initially failed because a global Git ignore rule excluded its vendored Three.js runtime from deployment. The runtime now ships. The public demo also corrects the Allen key's opposing bends and closed hexagonal ends, plus the Phillips screwdriver tip. These are labeled post-review public-demo fixes. They are not silently added to the original timed-run scores. The other public builds retain the reviewed behavior, including their documented mistakes.
The strongest result is not simply a cabinet that looks finished. It is a guide whose parts, movements and identifiers can be traced back to the manual. This experiment makes a useful distinction visible: a polished interface can pass functional checks while teaching the wrong assembly. Ask AI to show its work against the source, then play every step.
Independent review by Anass Kartit. Not affiliated with IKEA or the model vendors. Demo assembly instructions should be checked against the original manual.