Kimi K3.1 Pro: Was das Modell der 3T-Klasse von Moonshot AI bietet

Moonshot AI veröffentlichte Kimi K3.1 Pro am 23. Oktober 2026 als erstes Modell der K3.1-Serie. Es ist bereits über Kimi, Kimi Work, Kimi Code und die API nutzbar. Das Angebot verbindet ein Kontextfenster von bis zu einer Million Tokens mit Verbesserungen bei Programmierung, 3D-Erstellung, Finanzrecherche und Aufgaben, die mehrere aufeinanderfolgende Aktionen erfordern. Hinzu kommt K3.1 Pro Highspeed, eine Variante für kürzere Wartezeiten bei solchen Interaktionen.

Für ein Entwicklungsteam stellt sich vor allem eine praktische Frage: Kann das Modell einen Auftrag von der ersten Anfrage bis zu einem überprüfbaren Ergebnis bearbeiten? Dazu gehören das Verstehen eines Repositorys, Dateiänderungen, Werkzeugaufrufe und die Auswertung von Fehlern. Eine überzeugende Chatantwort deckt nur einen Teil dieses Ablaufs ab. Interessant ist die Fähigkeit, eine Aufgabe weiterzuverfolgen und den Kurs zu korrigieren. Das muss am jeweiligen Projekt geprüft werden.

Die offizielle Beschreibung bezeichnet K3.1 Pro als Modell der 3T-Klasse. T steht dabei für eine Billion Parameter. Das ist eine Größenklasse und keine Veröffentlichung einer exakten Zahl von 3.000.000.000.000 Parametern. Kimis Modelltabelle unterscheidet diese Bezeichnung von den ausdrücklich Kimi K3 zugeordneten 2,8T. K3 ist das Spitzenmodell der vorherigen Generation.

K3.1 Pro ist eine Version von K3 mit erweitertem Nachtraining und höherem Rechenaufwand in dieser Phase. Daraus folgt nicht automatisch, dass sämtliche für den Vorgänger dokumentierten internen Zahlen auch für Pro gelten. Die Pro-Vorstellung nennt weder eine neue exakte Gesamtzahl und Anzahl aktiver Parameter noch bestätigt sie dort eine bestimmte Zahl ausgewählter Experten pro Token. Aus der Gesamtgröße lassen sich auch die Betriebskosten nicht allein ableiten.

In den von Moonshot veröffentlichten Ergebnissen erreicht K3.1 Pro bei Terminal-Bench 4.0 einen Wert von 65,7 %. Der Test bewertet Agenten bei Terminalaufgaben mit begrenzten Ressourcen und aufgabenspezifischen Prüfungen. Derselbe Vergleich nennt 66,4 % für Claude Opus 5.5 und 58,2 % für GPT-6 Astra. Diese Werte helfen bei der Einordnung, bestimmen aber keinen allgemeinen Sieger für jedes Repository und jede Umgebung.

Das Unternehmen berichtet außerdem 61,2 % im internen Kimi Code Bench 3.0 Long-horizon gegenüber 55,95 % für K3. Für OfficeQA Pro v2 nennt es 64,4 Punkte; diese Evaluation behandelt komplexe Fragen zu Finanzdokumenten. Die Messungen betreffen unterschiedliche Aufgaben. Ihre Zahlen lassen sich weder addieren noch als allgemeiner Prozentsatz für Intelligenz oder Genauigkeit verstehen.

Es handelt sich um vom Entwickler vorgestellte Evaluationen, nicht um eine unabhängige Wiederholung durch Inferama. Beim Vergleich von Arbeitswerkzeugen zählen auch Anweisungen, Berechtigungen, vorhandene Tests, verfügbare Zeit und Kosten je abgeschlossener Aufgabe. Eine hilfreiche Prüfung hält diese Bedingungen vergleichbar und untersucht das fertige Ergebnis statt nur die Erklärung des Modells.

Das größere Fenster ermöglicht mehr Dokumentation oder Code in einer Sitzung. Bei einer Änderung an einer Programmierschnittstelle kann es beispielsweise sinnvoll sein, Spezifikation, aufrufende Komponenten und Integrationstests gemeinsam bereitzustellen. Eine große Eingabemenge garantiert jedoch weder, dass jedes Detail gefunden wird, noch, dass alle Abhängigkeiten richtig zugeordnet werden.

Es bleibt sinnvoll, das Ziel abzugrenzen, relevante Dateien zu nennen und überprüfbare Ergebnisse zu verlangen. Bei einer Softwaremigration wäre eine konkrete Kontrolle, die Tests vorher und nachher auszuführen, Verhaltensänderungen zu prüfen und verbleibende Fehler zu erfassen. Ein vollständiges Repository ohne präzise Fragestellung kann Latenz und Kosten erhöhen, ohne die Entscheidung zu verbessern. In Kimi Code hängt der verfügbare Kontext außerdem vom Tarif ab: Der beworbene Höchstwert gilt nicht für jede Stufe.

Die Anleitung der API-Plattform verwendet die Modellkennungen kimi-k3.1-pro und kimi-k3.1-pro-highspeed. Kimi Code nutzt in seiner eigenen Konfiguration k3.1-pro und k3.1-pro-highspeed. Die richtige Kennung beim richtigen Dienst verhindert, dass ein Programmierabonnement mit der API-Abrechnung verwechselt wird. Kontingente und Bedingungen sind getrennt zu prüfen.

Für Highspeed bewirbt der Anbieter eine ungefähr zwei- bis dreifache Geschwindigkeit. Das kann in interaktiven Sitzungen nützlich sein, bedeutet aber für sich genommen keinen niedrigeren Preis. Die tatsächlichen Kosten hängen von Eingabe- und Ausgabetokens, Cache, Denkaufwand und Werkzeugaufrufen ab. Ein aussagekräftiger Versuch misst Zeit und Ausgaben bis zu einer Lösung, die alle vorgesehenen Prüfungen besteht, einschließlich erfolgloser Versuche.

In Kimi Code muss bei Pro der Denkmodus aktiviert bleiben; das Abschalten führt zu einem Fehler. Die Dokumentation empfiehlt außerdem eine neue Sitzung beim Wechsel der Modellgeneration. Solche Integrationsdetails wirken sich direkt aus: Eine ungeeignete Einstellung kann wie eine Schwäche des Modells erscheinen, obwohl sie die vorgesehene Nutzung verhindert.

Mit Stand vom 27. Oktober sind die vollständigen Gewichte laut Ankündigung bis spätestens 4. November 2026 vorgesehen. Der API-Zugang besteht bereits. Daraus lässt sich nicht schließen, dass die Modelldateien schon zum Herunterladen und Betrieb auf eigener Infrastruktur veröffentlicht wurden. Angekündigte Offenheit und tatsächlich mögliche lokale Ausführung müssen getrennt beurteilt werden.

Ein eigener Betrieb setzt die Prüfung der tatsächlich bereitgestellten Dateien, ihrer Lizenz und Formate, der Kompatibilität zur Inferenzsoftware sowie des Speicherbedarfs voraus. Auch eine dünn besetzte Aktivierung macht eine große Architektur nicht automatisch für eine handelsübliche Grafikkarte geeignet. Wer heute entscheidet, kann den verfügbaren Dienst erproben und konkrete Berechnungen zur lokalen Infrastruktur auf tatsächlich veröffentlichte Distributionsangaben stützen, sobald diese vorliegen.

K3.1 Pro erweitert die Auswahl für Teams, die Programmieragenten und viel Kontext benötigen. Entscheidend sind Ergebnisqualität bei der konkreten Arbeit, Integrationsaufwand und Betriebskosten. Ein Versuch mit realen Aufgaben, Abnahmekriterien und Kontrolle der Änderungen bietet eine verlässlichere Grundlage als die Auswahl allein nach Parameterzahl.