Kimi K3 API-Preise gemessen: 'Always-On'-Reasoning abschalten

Die Dokumentation von Kimi K3 sagt, dass sich Thinking nicht abschalten lässt und dass reasoning_effort nur "max" akzeptiert. In unseren Messungen akzeptiert die API trotzdem "none", und es funktioniert: Dieselbe triviale Frage kostet mit Standard-Reasoning $0,00179 und ohne $0,000285 — ein Faktor von 6,3. K3 ist am 16.07.2026 erschienen, zu $3 pro Million Input-Tokens und $15 pro Million Output. Das ist der höchste Listenpreis, den je ein chinesisches Lab veröffentlicht hat, und derselbe Preis wie bei Claude Sonnet 5. Bei diesem Output-Preis machen die Reasoning-Tokens, die das Modell standardmäßig verbraucht, die Rechnung aus — deshalb lohnt es sich, den undokumentierten Ausschalter genau zu verstehen.

TL;DR

• Kimi K3 verbraucht bei Standardeinstellungen 69–93 % seiner Output-Tokens für Reasoning; ein Absatz mit 120 Wörtern wurde mit 2.289 Output-Tokens abgerechnet, $0,0346.
• reasoning_effort: "none" wird akzeptiert, obwohl die Doku etwas anderes sagt, und hat unsere Kosten bei einfachen Anfragen um den Faktor 6,3 gesenkt — aber bei mehrstufiger Arithmetik ging es von 3/3 richtig auf 0/6.
• Der Prompt-Cache von Kimi K3 greift ab etwa 256 Tokens Präfix, in 256-Token-Blöcken, zu einer Leserate von $0,30/M.
• Chinesisch ist die günstigste CJK-Spur von K3: 52 Netto-Tokens pro 100 Zeichen, unter GLM-5.2 und DeepSeek mit 58.

Alles Folgende wurde am 20.07.2026 gegen kimi-k3 gemessen, das über das Synthorai-Gateway zu Moonshots Listenpreisen live ist. Die Prompts wurden bei Wiederholung mit Salt versehen, um Response-Caches auszuhebeln, und die Aussagen zum Verhalten wurden über einen zweiten, unabhängigen Request-Pfad gegengeprüft. Jede Zahl ist durch die rohen Usage-Records belegt.

Was kostet Kimi K3 pro Antwort in der Standardkonfiguration?

Bei jeder Aufgabenform, die wir geschickt haben, dominiert Reasoning die Rechnung – auch bei Aufgaben, die überhaupt kein Reasoning brauchen. Pro Antwort, mit Standardeinstellungen:

Worauf die Grafik hinaus will, ist der Vergleich zwischen den Modellen: GPT-5.6 nutzt Reasoning adaptiv (null Thinking-Tokens bei den trivialen und faktischen Fragen, 65-70% bei Mathe und Textaufgaben), Claude Sonnet 5 liefert mit ausgeschaltetem Thinking aus, und GLM-5.2 denkt relativ gesehen noch stärker als K3. Aber der Output-Preis von GLM liegt bei $4.40/M und der von K3 bei $15/M. Dieselbe 17×23-Antwort kostete deshalb $0.00078 bei GLM-5.2, $0.00027 bei GPT-5.6, $0.0001 bei Sonnet 5 und $0.0018 bei K3. Mit der Output-Länge wird der Abstand größer: Der identische 120-Wörter-Absatz kostete $0.0346 bei K3 gegenüber $0.0186 bei GLM-5.2, $0.0072 bei GPT-5.6 und $0.0024 bei Sonnet 5 – ein Faktor 15 bei der gewöhnlichsten Aufgabe im ganzen Set. Der Steuersatz ist mit anderen chinesischen Reasoning-Modellen vergleichbar; die Steuerrechnung nicht.

Zwei weitere Fakten zum Standardmodus, die man einplanen sollte. Erstens fügt der Thinking-Modus jedem Request eine versteckte Präambel von etwa 67 Tokens hinzu: Eine identische Ein-Wort-Nachricht wurde mit aktiviertem Reasoning mit 86 Prompt-Tokens abgerechnet und ohne mit 19. Das ist der „versteckte System-Prompt“, den frühe Tester bemerkt haben, und er verschwindet zusammen mit dem Reasoning. Zweitens ist K3 aktuell langsam: Unsere Aufrufe mit trivialen Fragen brauchten mit Reasoning ende-zu-ende rund 19-24 Sekunden und ohne 3-8 Sekunden, Launch-Woche-Serving eingerechnet. Plane die Latenz mit ein, nicht nur die Dollar.

Kann man das Reasoning von Kimi K3 abschalten?

Ja – trotz Dokumentation. Die offizielle API-Referenz behauptet, K3 habe „thinking immer aktiviert” und reasoning_effort akzeptiere ausschließlich "max". In der Praxis nahm der Endpoint "none", "low", "medium" und "high" ohne Fehler an, respektierte sie und wir haben dasselbe Verhalten über einen unabhängigen Request-Pfad bestätigt. Beim mehrstufigen Textaufgaben-Test funktioniert der Regler tatsächlich, ist aber grob:

Zwei Dinge fallen auf. Die Zwischenstufen liegen dicht beieinander: low bis max brachten ähnliche Token-Zahlen und identische Genauigkeit bei dieser Aufgabe – der entscheidende Schalter ist also binär. Und none hat eine echte Klippe: Zwingt man K3, eine mehrstufige Rechenaufgabe knapp zu beantworten, lag es sechsmal von sechs falsch, dabei verstreut falsche Antworten statt eines systematischen Fehlers. Ohne erzwungenes knappes Format ignorierte das Modell die Kürze manchmal und arbeitete die Schritte in der sichtbaren Antwort ab: korrekt, aber die Tokens wanderten aus dem Reasoning-Feld ins Text-Feld, statt zu verschwinden.

Die Latenz bewegt sich weniger, als die Token-Zahlen vermuten lassen. Streamt man dieselbe Aufgabe über alle Effort-Stufen, lagen die First-Byte-Zeiten bei 6-24 Sekunden, wobei sich die Bereiche der Stufen stark überlappen. Selbst none, ohne irgendetwas zum Nachdenken, wartete 12-13 Sekunden – das Serving dominiert also die Zeit bis zum ersten Token bei dieser Aufgabengröße. Was der Regler wirklich verändert, ist der Abstand zwischen erstem Byte und erstem Antwort-Token, also die Denkphase, die der Nutzer aussitzt.

Praktisch gelesen: none ist ein echter Kostenhebel für Aufgaben aus Retrieval, Formatierung oder Einzelschritten – und ein Selbstschuss für alles, was Zwischenschritte braucht. Es gibt keine dokumentierte Garantie, dass dieser Parameter weiter funktioniert; behandle ihn als gemessenes Verhalten, prüfe ihn in deinen eigenen usage-Feldern und rechne damit, dass er formalisiert oder entfernt wird, sobald die Docs nachziehen.

Wann sollte Reasoning bei Agent-Workloads anbleiben?

Wir haben K3 durch fünf agentenartige Szenarien geschickt, jeweils zweimal: Standard gegen reasoning_effort: "none", mit identischen einfachen Aufgaben, die beide Konfigurationen vollständig bestanden:

Die Überraschung steckt in der ersten Zeile: In Tool-Call-Loops denkt K3 selbst mit Standardeinstellungen kaum (8% Anteil), da gibt es also wenig zu sparen. Das Modell behandelt die Tool-Auswahl als Reflex, nicht als Abwägung. Die Einsparungen konzentrieren sich dort, wo der Thinking-Anteil hoch und die Aufgabe mechanisch ist (RAG-Lookups und Batch-Extraktion) – genau dort, wo eine feste Dauerabgabe am wenigsten hingehört. Für echte mehrstufige Agent-Pläne gilt die Genauigkeitsklippe aus dem vorigen Abschnitt: Reasoning anlassen und die Tokens ausgeben.

Im großen Maßstab ist der Latenzeffekt real, auch wenn einzelne Calls verrauscht sind: Über diese Szenarien trafen die ersten Tokens bei Standardeinstellungen nach 10-19 Sekunden ein und mit none nach 8-13 Sekunden, die Generierung lief bei substanziellen Outputs mit einem Median von 35 Tokens pro Sekunde. Diese Zahlen – inklusive Launch-Week-Serving – passen besser zu asynchronen und Batch-Formen als zu allem, was heute konversationell ist.

Wird das zurückgegebene Reasoning erneut als Input abgerechnet?

Ja, Token für Token. Die Doku von Kimi weist dich an, reasoning_content aus jedem Assistant-Turn unverändert im Message-Verlauf zu behalten. Wir haben gemessen, was das kostet: Ein zweiter Turn, der mit der Chain of Thought des ersten Turns gesendet wurde, hat 599 Prompt-Tokens abgerechnet; dieselbe Anfrage ohne diese Chain kam auf 198. Die Differenz von 401 Tokens deckt sich fast exakt mit den 402 Reasoning-Tokens des ersten Turns. Behaltenes Thinking fließt also bei jeder folgenden Anfrage zum vollen Input-Tarif von 3 $/M wieder ein, und ein langes Gespräch zahlt sein angesammeltes Reasoning bei jedem Turn erneut.

Es wegzulassen ist aber nicht automatisch billiger. Ohne die vorherige Chain of Thought hat K3 den Folge-Turn von Grund auf neu durchdacht: Die Reasoning-Tokens im zweiten Turn stiegen um 31 % (von 343 auf 449). Bei 3 $/M Input gegen 15 $/M Output war das Behalten der CoT in unserem Test unterm Strich die günstigere Variante. Der Ratschlag der Doku hält also nicht nur aus Qualitätsgründen, sondern auch bei den Kosten. Der Hebel, der sich hier wirklich auszahlt, ist der Prompt-Cache aus dem nächsten Abschnitt: Behaltener Verlauf ist ein stabiler Präfix, und stabile Präfixe werden nicht mehr zum vollen Preis abgerechnet.

Cacht Kimi K3 Prompts, und ab wie vielen Tokens?

Der Prompt-Cache von K3 läuft automatisch, und die Untergrenze ist niedrig: Treffer setzten bei rund 256 Tokens gemeinsamem Präfix ein und stiegen in 256-Token-Blöcken (ein Prompt mit 303 Tokens cachte 256; ein Prompt mit 153 Tokens cachte über wiederholte Versuche hinweg nie). Gecachter Input wird mit 0,30 $/M abgerechnet, ein glatter Rabatt von 90 % gegenüber dem Frischtarif von 3 $/M, ohne Cache-Write-Aufschlag bei irgendeinem unserer Calls. Das Warmlaufen brauchte zwei bis fünf identische Calls bis zum ersten Treffer, ein einzelner Retry beweist also so oder so nichts; miss über mehrere hinweg.

Zur Einordnung: Diese Untergrenze ist ein Viertel des von OpenAI dokumentierten Minimums von 1.024 Tokens, und die Blockgröße ist gröber als die 64-Token-Granularität, die wir anderswo gemessen haben. Die Lebensdauer ist Best-Effort statt einer festen TTL: Gecachte Einträge überlebten in unserem Test Leerlaufpausen von 4 und 15 Minuten, während eine 8-Minuten-Pause verfehlt wurde. Behandle den Ablauf also als lastabhängige Eviction und überprüfe den Cache-Split bei jedem Call. Noch ein Preisfaktor, der eine Rechnung wert ist: Das Kontextfenster von 1M Tokens hat einen einheitlichen Preis, ohne Long-Context-Stufe auf der Preisliste. Ein voll ausgereiztes Fenster kostet 3,00 $ frischen Input pro Call und 0,30 $, sobald der Präfix warm ist. Large-Context-Workloads stehen und fallen also weit mehr mit dem Cache als mit dem Listenpreis. Wenn dein Traffic einen System-Prompt von auch nur ein paar hundert Tokens wiederverwendet, greift der Cache von K3 dort, wo der der meisten Anbieter noch gar nicht angesprungen wäre. Die Mechanik und wie du Treffer aus usage verifizierst, behandeln unser Leitfaden zum Prompt-Caching und die Studie zu den gemessenen Cache-Minima.

Ist Chinesisch bei Kimi K3 tatsächlich teurer?

Nein. Chinesisch ist die Sprache, in der K3s Tokenizer im Vergleich zur Konkurrenz am effizientesten arbeitet – das beantwortet eine Frage, die in den Diskussionen der Launch-Woche immer wieder aufkam. Netto-Tokens pro 100 Zeichen bei semantisch abgeglichenen Textpassagen, abzüglich des Envelope-Overheads:

K3 berechnet für Chinesisch 52 Tokens pro 100 Zeichen – 11 % unter GLM-5.2 und DeepSeek und weniger als die Hälfte von Sonnet 5. Schwach ist es bei Japanisch: Hier zahlt man 16–24 % mehr als bei den anderen Open-Weight-Modellen. Wir haben außerdem bestätigt, dass der Tokenizer innerhalb der Familie unverändert ist: K3, K2.7-code und K2.5 lieferten bei allen 23 abgeglichenen Samples identische Werte. Damit gelten die für K2 erstellten Budgets pro Sprache weiter. Wie sich Tokenizer-Dichte und Preis pro Token über neun Sprachen hinweg aufaddieren, behandelt unsere Studie günstigstes LLM nach Sprache.

FAQ

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

Moonshot hat volle Gewichte unter einer Modified MIT-Lizenz bis zum 27. Juli 2026 versprochen; zum Zeitpunkt dieses Beitrags ist K3 nur über die API verfügbar. Die Formulierung „größtes Open-Weight-Modell aller Zeiten“ ist eine Zusage, noch kein Download-Link. Wie sich Caching im Open-Weight-Ökosystem verhält, dem die Gewichte beitreten werden, ist in Prompt-Caching für Open-Weight-LLMs dargestellt.

Was ist an K3 gegenüber der K2-Familie tatsächlich neu?

Bei der Abrechnung sind es drei Dinge, die wir gemessen haben: der Preis (K3 mit 3/15 $ gegenüber K2.7-code mit 0,95/4 $, also ein Sprung um das 3,2- bis 3,75-Fache), das durchgängig aktive Thinking (K2.5 reasoniert überhaupt nicht, K2.7-code hat einen Schalter) und sonst nichts: Der Tokenizer ist bei K3, K2.7-code und K2.5 über alle 23 abgeglichenen Samples byte-identisch, sodass die Token-Budgets aus der K2-Ära weitergelten. Auf dem Spezifikationsblatt steht laut Moonshot: ein neues MoE mit 2,8 Billionen Parametern (896 Experten, 16 pro Token aktiv) mit Kimi Delta Attention, ein Kontextfenster von 1 Mio. Tokens gegenüber 256K bei K2.7-code und native Bildeingabe. Wir haben die Angaben zur Abrechnung gemessen, nicht die zur Architektur.

Unterstützt Kimi K3 strukturierte Ausgaben?

Ja. Ein response_format mit json_schema lieferte in unserem Test ein gültiges, schema-konformes Objekt. Zu beachten: Das Reasoning läuft trotzdem darunter weiter – 66 der 97 Output-Tokens bei diesem Extraktions-Call waren Reasoning. Schema-gebundene Calls zahlen also wie alles andere den Thinking-Aufschlag, sofern man nicht zusätzlich reasoning_effort: "none" setzt.

Ändert das Abschalten des Reasonings, was man zu sehen bekommt?

Ja. In der Standardeinstellung gibt K3 seine komplette Gedankenkette in reasoning_content zurück, und die Doku empfiehlt, sie in der Multi-Turn-History unverändert zurückzureichen. Mit reasoning_effort: "none" fehlt das Feld vollständig, und der rund 67 Tokens lange Thinking-Vorspann verschwindet damit von der Prompt-Rechnung.

Gemessen am 20.07.2026 mit kimi-k3 zu den Listenpreisen der Launch-Woche (3 $/M Input, 0,30 $/M cached, 15 $/M Output). Wiederholte Prompts wurden gesalzen, um Caches auf Antwortebene zu umgehen; Genauigkeitszählungen beruhen auf Aufgaben mit einer einzigen überprüfbaren Antwort; Verhaltensaussagen wurden über einen zweiten, unabhängigen Request-Pfad reproduziert. Preise und Verhalten können sich mit der Reifung des Release ändern; prüfe die Werte gegen deine eigenen usage-Records, bevor du dich auf eine Zahl hier verlässt.

← Zurück zum Blog