Kimi-K3-API-Preise im Praxistest: So lässt sich das standardmäßige Reasoning abschalten

Laut Dokumentation von Kimi K3 lässt sich Thinking nicht abschalten und reasoning_effort akzeptiert ausschließlich "max". In unseren Messungen nahm die API trotzdem "none" an und setzte den Wert auch um: Dieselbe triviale Frage kostete mit standardmäßigem Reasoning $0.00179, ohne Reasoning nur $0.000285. Das ist ein Unterschied um den Faktor 6.3. K3 startete am 2026-07-16 mit Preisen von $3 pro Million Input-Token und $15 pro Million Output-Token. Damit hat das Modell den höchsten Listenpreis, den ein chinesisches Lab bislang aufgerufen hat, und liegt auf demselben Preisniveau wie Claude Sonnet 5. Bei diesem Output-Preis bestimmen die standardmäßig erzeugten Reasoning-Token den Großteil der Rechnung. Deshalb lohnt es sich, den undokumentierten Schalter genau zu verstehen.

TL;DR

• Kimi K3 verwendet mit den Standardeinstellungen 69-93% seiner Output-Token für Reasoning. Ein Absatz mit 120 Wörtern wurde mit 2,289 Output-Token und $0.0346 abgerechnet.
• reasoning_effort: "none" wird entgegen der Dokumentation akzeptiert und senkte die Kosten unserer einfachen Abfragen um den Faktor 6.3. Bei mehrstufigen Rechenaufgaben fiel die Erfolgsquote jedoch von 3/3 auf 0/6.
• Der Prompt Cache von Kimi K3 greift ab ungefähr 256 Token gemeinsamem Präfix, arbeitet in Blöcken von 256 Token und berechnet Cache Reads mit $0.30/M.
• Unter den CJK-Sprachen ist Chinesisch bei K3 am günstigsten: netto 52 Token pro 100 Zeichen, gegenüber 58 bei GLM-5.2 und DeepSeek.

Alle folgenden Messungen wurden am 2026-07-20 mit kimi-k3 durchgeführt. Das Modell ist im Synthorai-Gateway zu Moonshots Listenpreisen verfügbar. Wiederholte Prompts wurden mit unterschiedlichen Zusätzen versehen, um Response Caches auszuschließen. Die Verhaltensbeobachtungen haben wir über einen zweiten, unabhängigen Request-Pfad gegengeprüft. Sämtliche Zahlen sind durch die Rohdaten der Usage Records belegt.

Wie viel kostet eine Antwort von Kimi K3 standardmäßig?

Bei allen getesteten Aufgabentypen dominiert das Reasoning die Rechnung, selbst wenn die Aufgabe überhaupt kein Reasoning erfordert. Pro Antwort ergaben sich mit den Standardeinstellungen folgende Werte:

Entscheidend ist der Vergleich zwischen den Modellen: GPT-5.6 setzt Reasoning adaptiv ein. Bei den trivialen Fragen und Wissensfragen erzeugt es keine Thinking-Token, bei Mathematik- und Schreibaufgaben liegt deren Anteil bei 65-70%. Claude Sonnet 5 wird standardmäßig mit deaktiviertem Thinking ausgeliefert. GLM-5.2 verwendet relativ gesehen sogar mehr Reasoning als K3. Der Output-Preis von GLM beträgt jedoch $4.40/M, der von K3 $15/M. Dieselbe Antwort auf 17×23 kostete deshalb bei GLM-5.2 $0.00078, bei GPT-5.6 $0.00027, bei Sonnet 5 $0.0001 und bei K3 $0.0018. Mit der Länge des Outputs wächst der Abstand: Derselbe Absatz mit 120 Wörtern kostete bei K3 $0.0346, bei GLM-5.2 $0.0186, bei GPT-5.6 $0.0072 und bei Sonnet 5 $0.0024. Bei der gewöhnlichsten Aufgabe im Testfeld ergibt sich damit eine Spanne um den Faktor 15. Der prozentuale Reasoning-Aufschlag ist mit anderen chinesischen Reasoning-Modellen vergleichbar. Der absolute Betrag ist es nicht.

Für die Budgetplanung sind zwei weitere Eigenschaften des Standardmodus relevant. Erstens fügt der Thinking-Modus jedem Request ein verborgenes Präfix von ungefähr 67 Token hinzu. Eine identische Nachricht mit nur einem Wort wurde mit aktiviertem Reasoning als 86 Prompt-Token abgerechnet, ohne Reasoning als 19. Das ist der „verborgene System-Prompt“, der frühen Testern aufgefallen war. Wird Reasoning deaktiviert, verschwindet er ebenfalls. Zweitens ist K3 derzeit langsam: Unsere Requests mit trivialen Fragen dauerten bei aktiviertem Reasoning insgesamt ungefähr 19-24 Sekunden, ohne Reasoning 3-8 Sekunden. Darin ist die Serving-Situation der Launch-Woche bereits enthalten. Neben den Kosten muss also auch die Latenz eingeplant werden.

Lässt sich Reasoning bei Kimi K3 abschalten?

Ja, entgegen der Dokumentation. Laut offizieller API-Referenz ist Thinking bei K3 „immer aktiviert“ und reasoning_effort akzeptiert nur "max". Tatsächlich nahm der Endpoint "none", "low", "medium" und "high" fehlerfrei an und setzte die Werte auch um. Dasselbe Verhalten konnten wir über einen unabhängigen Request-Pfad bestätigen. Bei der mehrstufigen Textaufgabe funktionierte die Einstellung, allerdings nur in groben Abstufungen:

Zwei Punkte fallen auf. Die mittleren Einstellungen liegen dicht beieinander: Von low bis max waren Token-Zahl und Erfolgsquote bei dieser Aufgabe nahezu identisch. Der relevante Schalter ist daher praktisch binär. Bei none fällt die Qualität deutlich ab. K3 sollte eine mehrstufige Rechenaufgabe knapp beantworten und lag in sechs von sechs Versuchen falsch. Die falschen Ergebnisse streuten, statt auf einen einzelnen systematischen Fehler zurückzugehen. Ohne erzwungenes Kurzformat ignorierte das Modell die Vorgabe zur Kürze teilweise und rechnete die Zwischenschritte sichtbar in der Antwort aus. Das Ergebnis war dann korrekt, aber die Token wechselten lediglich aus dem Reasoning-Feld ins Textfeld, statt wegzufallen.

Die Latenz verändert sich weniger, als die Token-Zahlen vermuten lassen. Beim Streaming derselben Aufgabe über alle Effort-Stufen hinweg lag die Time to First Byte zwischen 6-24 Sekunden, wobei sich die Wertebereiche stark überschnitten. Selbst none wartete ohne Reasoning 12-13 Sekunden. Bei Aufgaben dieser Größe bestimmt das Serving also die Zeit bis zum ersten Token. Tatsächlich beeinflusst die Einstellung vor allem den Abstand zwischen dem ersten Byte und dem ersten Antwort-Token. Das ist die Thinking-Phase, auf die der Nutzer wartet.

Für Retrieval-, Formatierungs- und einstufige Aufgaben ist none ein echter Kostenhebel. Bei Aufgaben mit Zwischenschritten ist die Einstellung dagegen riskant. Es gibt keine dokumentierte Garantie, dass dieser Parameter dauerhaft funktioniert. Behandelt ihn als gemessenes Verhalten, kontrolliert die eigenen usage-Felder und rechnet damit, dass er mit einer Aktualisierung der Dokumentation entweder offiziell unterstützt oder entfernt wird.

Wann sollte Reasoning bei Agent-Workloads aktiviert bleiben?

Wir haben K3 in fünf Agent-typischen Szenarien jeweils zweimal getestet: einmal mit den Standardeinstellungen und einmal mit reasoning_effort: "none". Die einfachen Aufgaben waren in beiden Konfigurationen identisch und wurden jeweils vollständig bestanden:

Überraschend ist die erste Zeile: In Tool-Call-Schleifen denkt K3 selbst mit den Standardeinstellungen kaum nach. Der Anteil beträgt nur 8%, entsprechend gering ist das Einsparpotenzial. Das Modell behandelt die Tool-Auswahl eher als Reflex denn als Abwägung. Die größten Einsparungen entstehen bei mechanischen Aufgaben mit hohem Thinking-Anteil, etwa bei RAG-Lookups und Batch-Extraktion. Genau dort ist ein fester, dauerhaft anfallender Aufschlag am wenigsten sinnvoll. Für tatsächlich mehrstufige Agent-Pläne gilt der im vorigen Abschnitt gemessene Qualitätseinbruch. Hier sollte Reasoning aktiviert bleiben.

Über viele Requests hinweg ist der Latenzeffekt trotz der Schwankungen einzelner Calls messbar. In diesen Szenarien trafen die ersten Token mit den Standardeinstellungen nach 10-19 Sekunden ein, mit none nach 8-13 Sekunden. Bei substanziellen Outputs lag die Generierungsrate im Median bei 35 Token pro Sekunde. Einschließlich der Serving-Situation in der Launch-Woche eignen sich diese Werte derzeit eher für asynchrone und Batch-Workloads als für dialogorientierte Anwendungen.

Wird zurückgesendetes Reasoning erneut als Input abgerechnet?

Ja, Token für Token. Laut Kimi-Dokumentation soll reasoning_content aus jedem Assistant-Turn unverändert im Message-Verlauf bleiben. Wir haben die daraus entstehenden Kosten gemessen: Ein zweiter Turn mit der Chain of Thought des ersten Turns wurde mit 599 Prompt-Token abgerechnet. Derselbe Request ohne diese Daten kam auf 198. Die Differenz von 401 Token entspricht nahezu exakt den 402 Reasoning-Token des ersten Turns. Beibehaltenes Thinking fließt bei jedem weiteren Request also erneut zum vollen Input-Preis von $3/M ein. Eine lange Unterhaltung bezahlt damit in jedem Turn das bis dahin angesammelte Reasoning erneut.

Das Weglassen ist dennoch nicht automatisch günstiger. Ohne die vorherige Chain of Thought führte K3 das Reasoning für die Folgefrage erneut von Grund auf durch. Die Reasoning-Token des zweiten Turns stiegen um 31% von 343 auf 449. Bei $3/M für Input gegenüber $15/M für Output war es in unserem Test insgesamt günstiger, die CoT beizubehalten. Die Empfehlung aus der Dokumentation ist damit nicht nur aus Qualitäts-, sondern auch aus Kostensicht sinnvoll. Der entscheidende Hebel ist hier der Prompt Cache aus dem nächsten Abschnitt: Der beibehaltene Verlauf bildet ein stabiles Präfix, und stabile Präfixe werden nach dem Cache-Treffer nicht mehr zum vollen Preis abgerechnet.

Cacht Kimi K3 Prompts, und ab wie vielen Token?

Der Prompt Cache von K3 arbeitet automatisch und greift bereits bei kurzen Präfixen. Treffer begannen bei ungefähr 256 Token gemeinsamem Präfix und wurden in Blöcken von 256 Token angerechnet. Bei einem Prompt mit 303 Token wurden 256 gecacht. Ein Prompt mit 153 Token erzielte auch nach mehreren Versuchen keinen Treffer. Gecachter Input kostet $0.30/M, also pauschal 90% weniger als der reguläre Preis von $3/M. Bei keinem unserer Calls fiel ein Aufpreis für Cache Writes an. Bis zum ersten Treffer waren zwei bis fünf identische Calls nötig. Ein einzelner Wiederholungsversuch belegt daher weder das Vorhandensein noch das Fehlen eines Cache-Eintrags. Dafür sind mehrere Messungen nötig.

Zum Vergleich: Diese Untergrenze entspricht einem Viertel des von OpenAI dokumentierten Minimums von 1,024 Token. Die Blockgröße ist jedoch gröber als die andernorts von uns gemessene Granularität von 64 Token. Die Lebensdauer folgt keinem festen TTL, sondern ist best effort. In unserem Test überstanden Cache-Einträge Leerlaufzeiten von 4 und 15 Minuten, während nach 8 Minuten ein Miss auftrat. Die Ablaufzeit sollte daher als lastabhängige Verdrängung betrachtet werden. Prüft bei jedem Call die Aufteilung der gecachten und nicht gecachten Token. Eine weitere relevante Preiseigenschaft: Für das Context Window von 1M Token gilt laut Preisliste ein einheitlicher Preis ohne zusätzlichen Long-Context-Tarif. Ein vollständig belegtes Fenster kostet pro Call $3.00 für frischen Input und nach Aufwärmen des Präfixes $0.30. Bei Workloads mit großem Kontext ist der Cache deshalb weit wichtiger als der Listenpreis. Verwendet euer Traffic einen System-Prompt von nur wenigen Hundert Token mehrfach, greift der Cache von K3 bereits an einer Stelle, an der er bei den meisten Anbietern noch nicht einmal starten würde. Die Funktionsweise und die Prüfung von Treffern über usage erklären unser Leitfaden zum Prompt Caching und die Studie zu den gemessenen Mindestgrößen für Prompt Caches.

Ist Chinesisch bei Kimi K3 tatsächlich teurer?

Nein. Im Vergleich zur Konkurrenz arbeitet der Tokenizer von K3 bei Chinesisch besonders effizient. Damit lässt sich eine Frage beantworten, die in den Diskussionen der Launch-Woche häufig aufkam. Die folgenden Werte zeigen Netto-Token pro 100 Zeichen für semantisch vergleichbare Passagen, abzüglich des Envelope-Overheads:

Bei K3 werden für 100 chinesische Zeichen 52 Token abgerechnet. Das sind 11% weniger als bei GLM-5.2 und DeepSeek und weniger als die Hälfte des Werts von Sonnet 5. Schwächer ist K3 bei Japanisch. Hier benötigt es 16-24% mehr Token als die anderen Open-Weight-Modelle. Außerdem konnten wir bestätigen, dass der Tokenizer innerhalb der Modellfamilie unverändert ist: K3, K2.7-code und K2.5 lieferten bei allen 23 vergleichbaren Samples identische Token-Zahlen. Sprachspezifische Budgets für K2 lassen sich daher übernehmen. Wie Tokenizer-Dichte und Token-Preis in neun Sprachen zusammenspielen, untersucht unsere Studie zum günstigsten LLM nach Sprache.

FAQ

Wann werden die Open Weights von Kimi K3 veröffentlicht?

Moonshot hat die vollständigen Weights unter einer Modified-MIT-Lizenz bis zum July 27, 2026 angekündigt. Zum Zeitpunkt dieses Beitrags ist K3 ausschließlich per API verfügbar. Die Bezeichnung als „größtes Open-Weight-Modell aller Zeiten“ ist derzeit eine Zusage, noch kein Download-Link. Wie Caching im Open-Weight-Ökosystem funktioniert, zu dem das Modell künftig gehören soll, zeigt unser Überblick zum Prompt Caching für Open-Weight-LLMs.

Was ist bei K3 im Vergleich zur K2-Familie tatsächlich neu?

Bei der Abrechnung haben wir drei Unterschiede gemessen: den Preis, always-on Thinking und sonst nichts. K3 kostet $3/$15, K2.7-code dagegen $0.95/$4. Das entspricht einem Anstieg um den Faktor 3.2-3.75. K2.5 verwendet überhaupt kein Reasoning, K2.7-code bietet einen Schalter dafür. Der Tokenizer ist bei K3, K2.7-code und K2.5 in allen 23 vergleichbaren Samples byte-identisch. Token-Budgets aus der K2-Generation lassen sich daher übernehmen. Laut Moonshots Spezifikation gibt es außerdem eine neue MoE-Architektur mit 2.8T Parametern, 896 Experts und 16 aktiven Experts pro Token sowie Kimi Delta Attention. Hinzu kommen ein Context Window von 1M Token gegenüber 256K bei K2.7-code und nativer Bild-Input. Gemessen haben wir die Angaben zur Abrechnung, nicht die zur Architektur.

Unterstützt Kimi K3 strukturierte Ausgaben?

Ja. Ein response_format mit json_schema lieferte in unserem Test ein gültiges Objekt, das dem Schema entsprach. Im Hintergrund läuft trotzdem Reasoning: 66 der 97 Output-Token dieses Extraktions-Calls waren Reasoning-Token. Schema-beschränkte Calls zahlen daher denselben Thinking-Aufschlag wie alle anderen, sofern nicht zusätzlich reasoning_effort: "none" gesetzt wird.

Ändert das Abschalten von Reasoning die sichtbaren Daten?

Ja. Mit den Standardeinstellungen gibt K3 seine vollständige Chain of Thought in reasoning_content zurück. Die Dokumentation empfiehlt, sie in mehrstufigen Verläufen unverändert wieder mitzusenden. Mit reasoning_effort: "none" fehlt das Feld vollständig. Gleichzeitig verschwindet das Thinking-Präfix von ungefähr 67 Token aus der Prompt-Abrechnung.

Gemessen am 2026-07-20 mit kimi-k3 zu den Listenpreisen der Launch-Woche ($3/M Input, $0.30/M gecacht, $15/M Output). Wiederholte Prompts wurden mit unterschiedlichen Zusätzen versehen, um Caches auf Response-Ebene zu umgehen. Für die Erfolgsquoten wurden Aufgaben mit eindeutig prüfbaren Antworten verwendet. Verhaltensbeobachtungen wurden über einen zweiten, unabhängigen Request-Pfad reproduziert. Preise und Verhalten können sich mit zunehmender Reife des Releases ändern. Prüft die Angaben anhand eurer eigenen usage-Records, bevor ihr euch auf die hier genannten Werte verlasst.

← Zurück zum Blog