Ich habe dieselben Codierungsaufgaben an Kimi K2.7 Code und Claude Opus 4.8 über eine einzige API gesendet und gemessen, was zurückkam. Bei der Korrektheit lagen sie gleichauf: Beide meisterten eine SemVer-Präzedenzfalle und einen versteckten Fehler beim Zusammenführen von Intervallen. Opus antwortete jedoch 3–9× schneller mit nur einem Viertel der Ausgabe-Tokens, während Kimi pro Aufgabe zum Listenpreis etwa 46% weniger kostete. Die Wahl hängt also nicht davon ab, welches Modell „klüger“ ist. Wenn Sie kostensensitive oder batchbasierte Coding-Arbeiten ausführen, gewinnt Kimi K2.7 beim Preis. Wenn Sie geringe Latenz, einen 1M-Token-Kontext oder ein Final-Review-Modell brauchen, dem Sie vertrauen, ist Opus 4.8 den Aufpreis wert, und viele Teams routen am Ende zwischen beiden.
Hands-on: Ich habe die gleichen Programmieraufgaben durch beide ausgeführt
Wie ich getestet habe: Modell-IDs kimi-k2.7-code und claude-opus-4-8, aufgerufen über einen einzigen OpenAI-kompatiblen Gateway-Endpunkt am 2026-07-13, jeweils einmal pro Aufgabe mit Standardparametern und ohne Prompt-Caching. Die Latenz wird clientseitig als Wall-Clock-Zeit gemessen, daher umfasst sie Netzwerk- und Warteschlangenzeit, nicht nur die Generierung. Vor der Bewertung bat ich jedes Modell, sich zur Plausibilitätsprüfung selbst zu identifizieren (Kimi antwortete "made by Moonshot AI," Opus antwortete Anthropic); das ist ein Routing-Check, kein Versionsnachweis. Dies ist eine Stichprobe mit zwei Aufgaben, kein Benchmark. Sie zeigt ein Verhalten, das man wahrnehmen kann; sie kann die Performance eines mehrstufigen Agenten nicht messen.
Aufgabe 1 forderte jedes Modell auf, eine compare_semver()-Funktion gemäß der SemVer 2.0.0-Spezifikation zu implementieren, einschließlich des Teils, den die meisten Implementierungen falsch machen: die Priorität von Pre-Release-Versionen, bei der 1.0.0-alpha.1 < 1.0.0-alpha.beta gilt, numerische Bezeichner niedriger eingestuft werden als alphanumerische und beta.11 > beta.2 numerisch statt nach Zeichenfolgenreihenfolge verglichen wird. Ich bewertete jede Antwort anhand einer 72-Vergleichs-Matrix, die auf der kanonischen Reihenfolge der Spezifikation basiert. Aufgabe 2 übergab eine fehlerhafte merge_intervals()-Funktion, deren eigentlicher Defekt last[1] = cur[1] statt max(...) war, eine Zeile, die ein vollständig enthaltenes Intervall wie [1,10],[2,3] stillschweigend verschluckt; ich bewertete anhand von 5 Fällen, darunter dieses enthaltene Intervall.
Metrik | Kimi K2.7 Code | Claude Opus 4.8 |
|---|---|---|
Aufgabe 1 Korrektheit (72 Prioritätsregeln + Randfälle) | 72/72 | 72/72 |
Aufgabe 2 Korrektheit (5 Fälle inkl. enthaltenem Intervall) | 5/5 | 5/5 |
Aufgabe 1 Latenz (clientseitig) | 49.1s | 5.3s |
Aufgabe 2 Latenz (clientseitig) | 11.5s | 7.6s |
Aufgabe 1 Tokens (Eingabe / Ausgabe) | 172 / 1,907 | 774 / 418 |
Aufgabe 1 Kosten (nativer Listenpreis) | $0.0078 | $0.0143 |
Die Kosten werden aus den obigen Token-Zählungen zu den nativen Listenpreisen berechnet (Kimi $0.95/$4 pro Million in/out, Opus $5/$25): Kimi = 172×$0.95/M + 1,907×$4/M ≈ $0.0078; Opus = 774×$5/M + 418×$25/M ≈ $0.0143. Die Eingabe-Token-Zahlen unterscheiden sich (172 vs. 774), weil der Tokenizer jedes Modells und die Abrechnung des Gateways dieselbe Eingabe unterschiedlich zählen, nicht weil die Aufgaben unterschiedlich waren. Beide Modelle erzeugten auf beiden Aufgaben vollständig korrekten Code. Der Unterschied lag darin, wie sie dorthin gelangten. Opus war knapp und schnell und lieferte in Task 1 in 5,3 Sekunden 418 Tokens zurück. Kimi benötigte 49,1 Sekunden und gab 1,907 Tokens aus, vieles davon ein schrittweiser Begründungs-Trace, den es zusammen mit dem Code zurückgab. Da Kimis Tokens jedoch ungefähr 6× günstiger sind, kostete der ausführliche Lauf dennoch weniger.
Was das Duell beweist und was nicht
Es zeigt, dass Kimi K2.7 Code bei begrenzten, klar spezifizierten Programmierproblemen dieselbe korrekte Antwort wie ein Frontier-Modell erreicht. Es beweist nicht, dass Kimi Opus in langen, mehrstufigen agentischen Sitzungen erreicht, die zwei Single-Shot-Aufgaben nicht abbilden können. Kimis eigener stärkster Anspruch liegt genau in diesem agentischen Bereich, den die untenstehenden Benchmarks direkt adressieren.
Benchmarks: Was ist Drittanbieter und was ist die eigene Tabelle von Moonshot
Hier ist die Aufschlüsselung, wobei jede Zahl nach Quelle gekennzeichnet ist. Moonshots selbst gemeldete Tabelle ist der Bereich, in dem Kimi am stärksten aussieht; die unabhängige Bewertung ist dünner, weil das Modell noch relativ neu ist, und dort, wo noch kein Drittanbieterwert für K2.7 existiert, ist die nächstveröffentlichte Zahl für K2.6 (unten markiert).
Benchmark | Kimi K2.7 Code | Claude Opus 4.8 | Quelle |
|---|---|---|---|
MCPMark Verified (tool use) | 81.1 | 76.4 | Moonshot, selbst gemeldet |
SWE-bench Verified | 60.4% | nicht im selben Format veröffentlicht | Moonshot, selbst gemeldet |
Intelligence Index | 35 (K2.6 proxy) | 56 | Artificial Analysis, Drittanbieter |
Output speed | ~45 tok/s (K2.6 proxy) | 59 tok/s | Artificial Analysis, Drittanbieter |
Die eine Zahl, auf der der Vergleich beruht, MCPMark Verified 81.1 gegenüber 76.4, stammt aus der eigenen Tabelle von Moonshot, nicht aus einem unabhängigen Labor. Das ist kein Grund, sie abzutun, da die Nutzung von Tools im MCP-Stil genau der Bereich ist, auf den Kimi abgestimmt wurde. Aber lesen Sie die Überschrift „Kimi schlägt Opus“ als eine Herstellerbehauptung auf einem herstelleroptimierten Benchmark. Beim einen direkten Vergleich, der von einer externen Partei gemessen wurde, setzt Artificial Analysis Opus 4.8 beim Intelligence Index deutlich vor Kimi (56 gegenüber 35), obwohl diese Zeile K2.6 als Proxy verwendet, da K2.7 zum Zeitpunkt des Schreibens noch nicht unabhängig bewertet worden war.
Die Lücke im Kontextfenster verbirgt
Opus 4.8 bietet ein Kontextfenster von 1 Mio. Tokens; Kimi K2.7 erreicht maximal 256K. Benchmark-Ergebnisse zeigen das selten, aber in der Praxis ist es entscheidend. Ein 256K-Fenster fasst bequem ein mittelgroßes Repo und einen langen Agent-Trace und ist für die Mehrheit der Coding-Sessions völlig ausreichend. An die Grenze stößt man, wenn man ein komplettes großes Monorepo, umfangreiche Dokumentensammlungen oder mehrstündige Agent-Transkripte in einen einzigen Prompt einspeist. Dort ist das 4× größere Fenster von Opus der praktische Unterschied, nicht ein Punkt auf einem Diagramm.
Preisgestaltung: die 5–6×-Lücke und der Cache-Hebel
Zu den nativen API-Listenpreisen kostet Kimi K2.7 Code $0.95 pro Million Input-Tokens und $4.00 pro Million Output-Tokens; Claude Opus 4.8 kostet $5 und $25. Das ist ein 5–6×-Unterschied beim Output, und das ist der Hauptgrund, warum Teams Kimi überhaupt evaluieren.
Der Hebel, den die meisten Preistabellen übersehen, ist das Caching. Kimi berechnet bei einem Cache-Treffer 0,19 $ pro Million Tokens, ein Rabatt von 80 % auf Eingaben, die du bereits gesendet hast. In einer agentischen Schleife, die bei jedem Schritt denselben Codebestand erneut einliest, dominiert zwischengespeicherte Eingabe die Rechnung, sodass die effektiven Kosten weit unter der ausgewiesenen Preisspanne liegen. Philip Kiely von Baseten berichtete von rund 82 % Einsparungen bei einer Beispiel-Workload nach dem Wechsel von Opus 4.8 zu Kimi 2.7 Code, also genau der Art von Job mit hohem Cache- und Eingabeanteil, bei dem sich Kimis Preisgestaltung besonders auswirkt. Deine Zahl hängt von deinem Input-zu-Output-Verhältnis ab, aber die Richtung ist eindeutig: Je häufiger du Kontext erneut einliest im Verhältnis zu dem, was du erzeugst, desto stärker gewinnt Kimi bei den Kosten.
Opus verdient seinen Preis auf der Ausgabeseite wieder herein. Bei meiner Task 1 erzeugte es nur ein Viertel der Tokens von Kimi, sodass sich bei generationlastiger Arbeit wie dem Schreiben großer Dateien oder ausführlichen Refactorings die Kostenlücke pro Token in den tatsächlichen Ausgaben verringert, und Opus’ Geschwindigkeit die Wartezeit verkürzt, für die Sie einen Ingenieur bezahlen.
Das Versprechen von Open Weights vs. die 577-GB-Realität
Kimi K2.7 wird als Open Weights unter einer modifizierten MIT-Lizenz ausgeliefert, sodass Sie es selbst hosten und feinabstimmen können. Opus 4.8 ist nur per API verfügbar; Ihr Code und Ihre Reasoning-Traces gehen an Anthropic. Auf dem Papier ist das ein klarer Vorteil bei Datenschutz und Lock-in für Kimi. In der Praxis sollten Sie zuerst die Hardwarekosten prüfen.
Kimi K2.7 ist ein Mixture-of-Experts-Modell mit 1 Billion Parametern (32B aktiv pro Token, 384 Experten). Unabhängige Prüfer beziffern eine vollständige INT4-Bereitstellung auf etwa 577 GB VRAM, sobald Gewichte, KV-Cache und Laufzeit-Overhead mit eingerechnet werden; damit liegt die minimale praktische Konfiguration bei ungefähr 8× H100 80GB oder einer DGX-Spark-Klasse-Box. Eine einzelne RTX 4090 (24GB) kann das vollständige Modell nicht mit brauchbaren Einstellungen ausführen. Für alle außer einer Handvoll gut finanzierter Teams bedeutet „open weights“ die Freiheit, an einen Hosting-Anbieter weiterzuleiten oder auf gemieteten GPUs feinzujustieren, nicht ein Modell, das man intern selbst bereitstellt. Wenn Ihr Grund für die Wahl von Kimi die lokale Datenkontrolle ist, kalkulieren Sie den Cluster vor dem Commitment; für die meisten Teams bleibt Self-Hosting theoretisch.
Welche sollten Sie wählen
Passen Sie das Modell an die Arbeitslast an, statt einen Gewinner zu küren:
Wählen Sie Kimi K2.7 Code für kostensensitive, volumenstarke oder agentische Codierung, wenn Sie eine Codebasis wiederholt erneut lesen, Latenz nicht kritisch ist und ein 256K-Kontext ausreicht. Der Cache-Rabatt wirkt dabei zu Ihren Gunsten verstärkend.
Wählen Sie Claude Opus 4.8, wenn Sie geringe Latenz, einen 1M-Token-Kontext für große Repositories oder lange Sitzungen, knappere Ausgaben oder ein Endprüfungsmodell benötigen, dem Sie bei hochkritischen Änderungen vertrauen können, wobei sein Vorsprung bei unabhängigen Denk-Scores am wichtigsten ist.
Das hybride Vorgehen: günstiges Modell entwirft, Frontier-Modell vollendet
Das häufigste Muster bei Teams, die beide einsetzen, ist nicht, sich für eines zu entscheiden, sondern das Routing. Lassen Sie Kimi K2.7 den Großteil der Generierung und Iteration kostengünstig übernehmen und geben Sie das Ergebnis dann an Opus 4.8 für die abschließende Prüfung oder die Teile weiter, die ein Urteil auf Frontier-Niveau erfordern. Kimi spricht das OpenAI-Format nativ, während Opus die eigene API von Anthropic verwendet, daher ist der praktische Weg, zwischen beiden zu routen, ein Gateway, das beide hinter einem einzigen OpenAI-kompatiblen Endpoint bündelt; auf einer Plattform wie AIReiter zum Beispiel laufen beide unter einem einzigen Key, sodass ein Wechsel von Kimi zu Opus eher eine Änderung des Modell-Strings als eine erneute Integration ist. Die oben genannten 82% Einsparungen stammen genau aus dieser Art von Routing, nicht daraus, Opus vollständig wegzulassen.
FAQ
Ist Kimi K2.7 besser als Claude Opus 4.8 für Coding?
Bei begrenzten, klar spezifizierten Aufgaben sind sie gleichauf; in meinem Test lieferten beide vollständig korrekten Code. Kimi hat Vorteile bei agentischer Tool-Nutzung (MCPMark 81,1 gegenüber 76,4, laut Moonshot); Opus liegt bei allgemeinem Schlussfolgern, Geschwindigkeit und Long-Context-Arbeit vorn.
Wie viel günstiger ist Kimi K2.7 als Opus 4.8?
Etwa 5–6× günstiger beim Listenpreis ($0.95/$4 pro Million vs $5/$25). Mit Cache-Treffern ($0.19/M input) bei repetitiven Workloads können die Einsparungen in der Praxis 80 % oder mehr erreichen.
Was ist das Kontextfenster von Kimi K2.7 im Vergleich zu Opus 4.8?
Kimi K2.7 verarbeitet 256K Tokens; Opus 4.8 verarbeitet 1M, viermal größer.
Kann ich Kimi K2.7 lokal ausführen?
Nur mit ernsthafter Hardware. Eine vollständige INT4-Bereitstellung soll etwa 577 GB VRAM benötigen (ungefähr 8× H100 oder ein DGX Spark). Eine einzelne Consumer-GPU wie eine RTX 4090 kann das vollständige Modell nicht ausführen.
Ist Kimi K2.7 Open Source?
Es wird mit offenen Gewichten unter einer modifizierten MIT-Lizenz ausgeliefert, sodass Sie es selbst hosten und feinabstimmen können. Opus 4.8 ist geschlossen und nur per API verfügbar.
Das Fazit
Wenn dein Engpass das Budget ist, setze standardmäßig auf Kimi K2.7 Code und überlasse den Rest dem Caching. Wenn es um Latenz, Kontextlänge oder eine Änderung geht, bei der du dir keinen Fehler leisten kannst, bezahle für Opus 4.8. Betrachte die Open-Weights-Lizenz als Bonus, den du nur dann einlöst, wenn dir die GPUs gehören. Und wenn du dir nicht sicher bist, binde beide ein und leite nach Aufgabe weiter, statt den Workflow auf eine einzige Wette zu setzen, die du später wieder auflösen musst.