Kimi K3 erreicht GPT-5.6, braucht aber 4,6-mal so lange

Im Coding Agent Index von Artificial Analysis erreicht Kimi K3 denselben Wert wie GPT-5.6 medium, braucht mit 23,8 statt 5,2 Minuten aber 4,6-mal so lange [1]. GLM-5.2 schneidet schlechter ab: Aus 1,40 $ pro Million Input-Tokens werden 6,51 $ pro Aufgabenversuch [2]. Mein Fazit ist, dass beide Modelle mithalten können, aber keines so günstig ist, wie der Tokenpreis vermuten lässt.

Der Vergleich auf einen Blick: Kimi hält mit, GLM-5.2 fällt zurück

Kimi K3 ist konkurrenzfähig, aber nicht dominant: Im Gesamtindex erreicht es denselben Wert wie GPT-5.6 Sol medium, führt beim Terminal-Test, fällt beim Repository-Verständnis zurück und läuft deutlich langsamer. GLM-5.2 liegt bei diesen Einstellungen hinter allen drei Vergleichsmodellen und führt bei keinem Messwert [1] [2].

Messwert	Kimi K3	GLM-5.2	Sol medium	Opus 5 medium
Coding Agent Index	61	43	61	62 (Bester Wert der Zeile)
DeepSWE, %	64	29	64	63
Terminal-Bench v2, %	84 (Bester Wert der Zeile)	72	78	79
SWE-Atlas Q&A, %	37	29	40	44 (Bester Wert der Zeile)
Kosten pro Aufgabe, $	3,18	6,51	2,99 (Bester Wert der Zeile)	3,14
Aktive Zeit, min	23,8	25,1	5,2 (Bester Wert der Zeile)	12,2

Kimis Gleichstand mit Sol medium ist der nützlichste direkte Vergleich: Beide erreichen 61 Punkte, und ihre gemessenen Aufgabenkosten liegen mit 3,18 $ beziehungsweise 2,99 $ nah beieinander [1]. Der Unterschied liegt im Weg dorthin. Kimi verbraucht pro Aufgabe 23,8 aktive Minuten und 10,6 Millionen Tokens, Sol dagegen 5,2 Minuten und 5,8 Millionen Tokens. Opus 5 medium ergibt ein ähnliches Bild: Es liegt einen Indexpunkt vor Kimi, kostet vier Cent weniger und ist in ungefähr der halben Zeit fertig [2].

Die höchsten Indexwerte erreichen weiterhin westliche Modelle. Sol max und Opus 5 xhigh kommen beide auf 67 Punkte und kosten 7,08 $ beziehungsweise 8,23 $ pro Aufgabe. Opus führt außerdem das Repository-Verständnis mit 55 % bei SWE-Atlas Q&A an [1] [2]. Fable 5 max folgt mit 66 Punkten, kostet aber 11,71 $ pro Aufgabe [2]. Bei Terminal-Arbeit bleibt Kimi stark: Seine 84 % bei Terminal-Bench v2 übertreffen Sol high mit 83 % und liegen nur wenige Punkte hinter den Modellen mit maximaler Effort-Stufe [1] [2].

Das Repository-Verständnis ist die klare Schwäche. Kimi erreicht beim Codebase-Q&A-Teil 37 %, weniger als Sol medium mit 40 % und deutlich weniger als die Claude-Konfigurationen [1] [2]. Bei einem neuen Projekt fällt das womöglich kaum ins Gewicht. In einer bestehenden Codebasis mit 300.000 Zeilen ist das Verständnis des vorhandenen Codes dagegen ein großer Teil der Arbeit.

Warum gibt es so viel Hype um Kimi K3? Die Browser-Ergebnisse

Kimis Platzierungen in den Arenas haben einen großen Teil der Aufmerksamkeit ausgelöst. Sie zeigen, dass Menschen seine Arbeit im Browser bevorzugen, auch wenn breitere Agent-Tests Schwächen aufdecken. Kimi führt Arenas Fullstack-Leaderboard [3] und liegt in der WebDev Arena vor Claude Fable 5 und GPT-5.6 auf Platz zwei [4]. Open Weights und scheinbar niedrige Tokenpreise verstärken den Reiz.

Die Arena-Ergebnisse sind relevant, weil sie messen, welche Ausgabe Menschen bevorzugen, nicht ob eine Testsuite erfolgreich durchläuft. Auf dem Fullstack-Board vom 24. Juli 2026 lag Kimi K3 max mit 1.664 Punkten vor GPT-5.6 Sol mit 1.633 und Fable 5 mit 1.623 [3]. Vier Tage später führte Opus 5 max die WebDev Arena mit 1.712 Punkten an. Kimi erreichte bei insgesamt 3.777 Stimmen mit 1.682 Punkten Platz zwei, vor Fable 5, Sol und GLM-5.2 [4]. Kimis Ergebnisse im Browser kommen bei Nutzern also gut an.

Die Angaben der Anbieter belegen auch das Open-Weight-Angebot. Moonshot beschreibt Kimi K3 als erstes Open-Weight-Modell mit 2,8 Billionen Parametern, einem Kontextfenster von einer Million Tokens und eingebauter Vision. Die API kostet 3 $ pro Million Input-Tokens und 15 $ pro Million Output-Tokens [5]. Z.ai veröffentlicht GLM-5.2 mit 753 Milliarden Parametern unter einer MIT-Lizenz [6] und verlangt 1,40 $ für Input sowie 4,40 $ für Output [7]. Nach den Listenpreisen wirken beide deutlich billiger als ihre westlichen Konkurrenten.

Moonshots eigener Launch-Post ist zurückhaltender, als dieser Vergleich vermuten lässt. Darin heißt es, K3 liege weiterhin hinter Fable 5 und GPT-5.6 Sol, mit „einer spürbaren Lücke in der Nutzererfahrung“ gegenüber beiden [5]. Die unabhängigen Agent-Messungen machen diese Lücke vor allem beim Tempo und beim Repository-Verständnis sichtbar. Moonshots eigene Zurückhaltung ist es wert, im Kopf zu behalten, wenn ein chinesisches Labor als Erklärung für etwas genannt wird, und genau das vertrete ich in Claudes Text-Wasserzeichen ist eine Antwort auf die EU und nicht auf die chinesischen Labore.

Was misst der Coding Agent Index? Komplette Agent-Systeme

Der Coding Agent Index misst vollständige Kombinationen aus Modell und Agent bei Softwareentwicklung, Terminal-Arbeit und Fragen zu Repositories. Artificial Analysis gewichtet in Version 1.3 drei Tests gleich: 113 DeepSWE-Aufgaben, 84 Aufgaben aus Terminal-Bench v2 und 124 Fragen aus SWE-Atlas Q&A [8].

Diese Grenze ist wichtig, weil Kimi in Kimi Code CLI lief, GLM-5.2 in Claude Code, Sol in Codex und die Claude-Modelle ebenfalls in Claude Code [1] [2]. Jeder Wert beschreibt daher das Modell zusammen mit seinem Agenten und der gewählten Effort-Stufe. Die Tabelle kann diese tatsächlich getesteten Konfigurationen vergleichen, aber nicht zeigen, wie dieselben Modellgewichte in einem neutralen Harness abschneiden würden.

Sind Kimi K3 und GLM-5.2 billiger? Nicht pro gelöster Aufgabe

Nein. Die Kosten einer gelösten Aufgabe hängen davon ab, wie viele Tokens der Agent braucht und wie oft er erfolgreich ist, nicht nur vom Preis eines einzelnen Tokens. GLM-5.2 zeigt das am deutlichsten: Es hat hier den niedrigsten Listenpreis, kostet pro Aufgabenversuch aber mehr als jede westliche Konfiguration mit medium als Effort-Stufe [2] [7].

Anthropic hat den Einführungspreis von Claude Sonnet 5 dauerhaft gemacht: 2 $ für Input und 10 $ für Output pro Million Tokens [9]. Kimi K3 kostet 3 $ und 15 $ [5], womit sowohl Input als auch Output 50 % teurer sind als bei Sonnet. Gegen dieses Modell hat Kimi keinen Vorteil beim Listenpreis.

Weiter oben in der Preisliste verlangt Anthropic 5 $ für Opus-5-Input und 25 $ für Output, bei Fable 5 sind es 10 $ und 50 $ [9]. OpenAI setzt GPT-5.6 mit 5 $ und 30 $ an, in der Langkontext-Stufe mit 10 $ und 45 $ [10]. Z.ai unterbietet alle mit GLM-5.2 für 1,40 $ und 4,40 $, hinzu kommen 0,26 $ für Cache-Lesezugriffe [7]. Alle Preise gelten pro Million Tokens.

Auch diese Einheiten sind nicht vollständig vergleichbar. Die Anbieter verwenden unterschiedliche Tokenizer, und laut Anthropic erzeugt der aktuelle Tokenizer für denselben Text ungefähr 30 % mehr Tokens als sein Vorgänger [9]. Eine Million Tokens kann je nach Modellfamilie also unterschiedlich viel Text enthalten. Moonshots Kurzanleitung sagt außerdem, dass Kimi K3 immer im Reasoning-Modus arbeitet, dieser Modus nicht abgeschaltet werden kann und standardmäßig max als Effort-Stufe nutzt [11]. Die nicht sichtbaren Reasoning-Tokens stehen trotzdem auf der Rechnung.

Listenpreis pro Million Input-Tokens

1,40 $

das billigste Modell in diesem Vergleich

gemessen pro Aufgabenversuch

6,51 $

in Claude Code bei 25,1 aktiven Minuten

abgeleitet pro gelöster Aufgabe

15,14 $

Kosten pro Versuch geteilt durch die Erfolgsquote von 43 %

Wenn ich gelöste statt versuchte Aufgaben vergleiche, liegen Sol medium, Opus 5 medium und Kimi K3 mit ungefähr 4,90 $, 5,06 $ und 5,21 $ weiterhin nah beieinander. GLM-5.2 springt auf 15,14 $, also ungefähr das Dreifache. Der niedrigste Tokenpreis in dieser Gruppe führt damit zu den höchsten geschätzten Kosten für ein erfolgreiches Ergebnis.

Die Schätzung unterschätzt die Kosten von Fehlversuchen zusätzlich, weil sie keine Arbeitszeit enthält. Zehn Minuten für die Prüfung eines Fehlschlags kosten mehr als jede Modellgebühr in der Abbildung. Sobald jemand die Ausgabe kontrollieren muss, zählt die Erfolgsquote daher deutlich mehr als der Tokenpreis. Damit ist die Kostenfrage geklärt, und es bleibt zu prüfen, welche Aufgaben gut genug zu Kimis langsameren Läufen passen.

Worin ist Kimi K3 gut? Terminal und Fullstack

Kimi K3 überzeugt am ehesten bei Terminal-lastigen Aufgaben, Fullstack-Webentwicklung und langen Agent-Läufen, besonders wenn ein Team Open Weights und lokales Hosting braucht. Unabhängige Messungen, Arena-Stimmen und Moonshots eigene Ergebnisse stützen diese Einsätze [1] [3] [5]. Sie stützen nicht die Vorstellung, Kimi sei ein günstiger Ersatz für Arbeiten an großen bestehenden Repositories.

Das Terminal-Ergebnis zeigt sich in unabhängigen Tests und in den Messungen des Anbieters: Artificial Analysis ermittelte 84 % in Kimis eigener CLI, Moonshot 88,3 % in seiner bevorzugten Konfiguration [1] [12]. K3 führt auch Moonshots SWE-Marathon-Tabelle mit 42 Punkten an, allerdings sind die Fußnoten wichtig. Fable 5 nutzte bei 35 % seiner Aufgaben Fallback-Modelle, und einige Kimi-Zeilen liefen auf einem Vorab-Branch, der für H20-Hardware kalibriert war [12]. Zusammen mit Kimis eigenem Vision-Encoder und dem Kontextfenster von einer Million Tokens hat Moonshots vorgeschlagener Workflow zwischen Code und Live-Screenshots eine nachvollziehbare technische Grundlage [5] [12].

Diese Stärken haben praktische Grenzen. Mit 37 % bei den Fragen zur Codebasis ist Kimi eine fragwürdige Wahl, wenn eine Aufgabe vor allem Repository-Verständnis verlangt [1]. Die 23,8 aktiven Minuten pro Lauf bedeuten außerdem, dass du mehrere Agenten parallel betreiben oder warten musst. Auch beim Selbsthosting ist der Hardwarebedarf hoch: Allein die Gewichte mit 2,8 Billionen Parametern brauchen bei 4-Bit-Quantisierung ungefähr 1,4 TB. KV-Cache und Serving-Overhead kommen noch hinzu, weshalb ein praktischer Betrieb einen Server-Cluster statt einer Workstation erfordert.

Vor der Einführung kommt eine rechtliche Prüfung hinzu. Ein Model-as-a-Service-Unternehmen mit mehr als 20 Millionen Dollar Gesamtumsatz braucht eine separate Vereinbarung mit Moonshot. Produkte mit mehr als 100 Millionen monatlich aktiven Nutzern oder 20 Millionen Dollar Monatsumsatz müssen „Kimi K3“ gut sichtbar anzeigen, während die interne Nutzung ausgenommen ist [13]. Moonshots Standardbedingungen für die API erlauben außerdem, Kundeninhalte für Bereitstellung, Wartung, Entwicklung, Support und Verbesserung der Dienste zu verwenden. Einschränkungen für Modelltraining werden über separate Enterprise-Vereinbarungen geregelt [14]. Bevor ich ein proprietäres Repository an die öffentliche API sende, würde ich mir diese Einschränkungen schriftlich bestätigen lassen.

Warum schwächelt GLM-5.2 in Claude Code? Das Agent-Setup zählt

Der Rückgang von GLM-5.2 um neun Terminal-Bench-Punkte warnt vor allem vor dem Agent-Setup und beweist nicht, dass die Modellgewichte schwach sind. Das Modell erreicht in Z.ais Terminus-Harness 81 % und in Claude Code 72 % [6] [2]. Niemand außerhalb von Z.ai kennt die genaue Ursache. Tool-Aufrufe, Fehlerbehandlung, Caching oder die Konventionen des Agents könnten den Unterschied erklären.

Unabhängig von der Ursache schneidet diese Konfiguration schlecht ab. GLM-5.2 erreicht im Index 43 Punkte und sowohl bei DeepSWE als auch beim Codebase-Q&A 29 %. Mit 6,51 $ und 25,1 aktiven Minuten pro Versuch ist es außerdem die langsamste Konfiguration im Vergleich [2]. Die Preise von 1,40 $ für Input und 4,40 $ für Output führen bei diesem Verbrauch nicht zu niedrigen Aufgabenkosten.

Die Model Card von Z.ai zeigt, wie wichtig das umgebende System ist. Der Wert von 62,1 bei SWE-Bench Pro stammt aus OpenHands mit einem angepassten Prompt. DeepSWE läuft in isolierten Containern mit zwei Stunden Timeout, Terminal-Bench in Terminus mit vier Stunden Budget [6]. Das sind gültige Messungen von GLM-5.2 in einem eigens dafür gewählten Setup, aber sie sagen sein Verhalten in einem anderen Agenten nicht zuverlässig voraus.

GLM-5.2 kann sich trotzdem für selbst gehostete und automatisch geprüfte Aufgaben eignen. Mit 753 Milliarden Parametern und einer MIT-Lizenz lässt es sich leichter selbst betreiben als Kimi K3 [6]. Der Inputpreis von 1,40 $ macht es für Codemods oder Migrationen in großer Zahl interessant, wenn deterministische Prüfungen die 57 % Fehlversuche ohne manuelle Kontrolle ablehnen können. Muss jemand diese Versuche prüfen, spart der niedrige Tokenpreis kein Geld mehr. Das Hosten ist ein eigener Kostenfaktor, wie ich bei DeepSeek V4.1 Flash mit günstiger API und riesigen Open Weights gesehen habe.

So liest du ein Coding-Leaderboard: Vergleiche zuerst den Harness

Beginne mit dem Harness, der Benchmarkversion und der gemessenen Aufgabe, denn ein Leaderboard-Wert gehört immer zu diesem Setup. Der Abstand zwischen Kimis Erfolgen in den Arenas und den vom Harness abhängigen GLM-Ergebnissen zeigt, warum Modellname und Endwert allein nicht ausreichen.

Signal	Was es belohnt	Was es dir nicht sagen kann
DeepSWE, 113 Aufgaben	Engineering-Aufgaben von Anfang bis Ende abschließen	die Passung zu den Konventionen deiner Codebasis
Terminal-Bench v2, 84 Aufgaben	eine Shell bis zu einem geprüften Endzustand steuern	das Verständnis eines großen bestehenden Repositorys
SWE-Atlas Q&A, 124 Aufgaben	technische Fragen zu Code beantworten	ob das Modell die beschriebene Änderung umsetzen kann
WebDev und Fullstack Arena	was Menschen im direkten Vergleich bevorzugen	Korrektheit, Tests, Sicherheit und Wartbarkeit
Model Cards der Anbieter	das Modell in Bestform und im eigenen Setup	ob sich die Zeilen miteinander vergleichen lassen

Die Infrastruktur ist die erste Unsicherheit. Das Engineering-Team von Anthropic veränderte einen Wert bei Terminal-Bench 2.0 allein durch andere Ressourcenlimits um sechs Prozentpunkte. Als das Team die Limits erhöhte, sank die Fehlerrate der Infrastruktur von 5,8 % auf 0,5 % [15]. Es kam zu dem Schluss, dass Unterschiede von weniger als ungefähr drei Punkten mit Vorsicht behandelt werden sollten, bis die Konfigurationen dokumentiert und angeglichen sind. Kimi und Sol medium liegen innerhalb dieses Bereichs, weshalb ihr gemeinsamer Wert für einen Gleichstand und nicht für einen Sieg eines Modells spricht.

Die zweite Unsicherheit ist das uneinheitliche Test-Setup. Moonshot führt jeden Konkurrenten in einem anderen Harness aus, setzt in manchen Zeilen Fallback-Modelle ein und verwendet einen eigenen Benchmark. Fable 5 griff in diesem Test bei 80 Aufgaben 13-mal auf Fallbacks zurück und verweigerte eine Aufgabe [12]. Moonshot legt diese Details offen, doch ein Vergleich verliert viel von seinem Wert, wenn sie in einer Zusammenfassung fehlen.

Zuletzt muss auch die Benchmarkversion übereinstimmen. Artificial Analysis versieht den Index mit Versionsnummern, weil sich die Aufgaben ändern. Hier ist v1.3 aktuell [8]. Werte aus verschiedenen Versionen lassen sich daher nicht direkt vergleichen, selbst wenn der Name des Benchmarks gleich bleibt. Ein brauchbarer Vergleich nennt Harness, Effort-Stufe, Aufgabenbudget und Version. Die Neubewertung von Muse Spark 1.3 im Index von Artificial Analysis zeigt, wie stark ein Versionswechsel einen Rang verschieben kann.

Meine Auswahl: Kimi für UI, GLM nur mit automatischen Checks

Ich würde Kimi K3 zuerst bei neuen Fullstack-Projekten und UI-lastiger Arbeit testen. GLM-5.2 würde ich nur in seinem nativen Harness und hinter automatischen Prüfungen einsetzen. Für die übrigen Aufgaben würde ich mich je nach Arbeit weiterhin zwischen Claude und GPT-5.6 entscheiden:

Die Arbeit	Meine Wahl heute
Routineänderungen mit soliden Tests	Sonnet 5 zum dauerhaften Preis von 2 $/10 $
Schnelle Agent-Schleifen und Terminal-Arbeit	GPT-5.6 mit medium oder high als Effort-Stufe
Arbeit in einem großen bestehenden Repository	Opus 5 mit medium oder high als Effort-Stufe
Neue Fullstack-Projekte und UI-lastige Builds	Kimi K3, gestützt durch die Ergebnisse der Arenas
Viele Aufgaben mit automatischer Prüfung	GLM-5.2 im nativen Harness, zunächst als Pilotprojekt
Eskalation, wenn alle anderen Modelle scheitern	Fable 5, sparsam eingesetzt

Die Tabelle folgt derselben Regel, die ich während der Launch-Woche von Opus 5 verwendet habe: Vergleiche die Kosten angenommener Änderungen, nicht nur die Tokenpreise. Damit landet Kimi dort, wo seine Terminal- und Arena-Ergebnisse am stärksten sind, während GLM hinter automatischen Prüfungen bleibt.

Zwei weitere Messungen könnten meine Auswahl verändern. Kimi K3 müsste seine 61 Punkte in einem neutralen Harness wie Claude Code oder Codex halten. So ließe sich die Leistung des Modells vom möglichen Vorteil der Kimi Code CLI trennen. GLM-5.2 braucht den umgekehrten Test: einen unabhängigen Lauf in seinem nativen Agenten durch jemanden, der das Modell nicht verkauft. Bis dahin zeigen beide Modelle nützliche Fähigkeiten bei bestimmten Aufgaben, aber nicht den breiten Kostenvorteil, den ihre Tokenpreise vermuten lassen.