Die Moonshot API bezeichnet die Modellschnittstelle der Moonshot AI Open Platform, also die Entwicklerplattform hinter Kimi. Sie wird nach Tokenverbrauch abgerechnet und bietet keine Abonnementpakete. Bei der Budgetplanung unterlaufen vielen Teams zwei Fehler: Sie rufen noch das eingestellte Modell moonshot-v1 auf, und sie fassen Eingabe, Cache-Schreiben, Ausgabe und Retries zu einem Durchschnittspreis zusammen. Dieser Beitrag zerlegt die Abrechnungsstruktur anhand öffentlicher Dokumente mit Stand Oktober 2026; konkrete Preise richten sich nach den Modellpreisen auf dieser Website und der offiziellen Dokumentation.

Hinweis: Moonshot und Kimi sind Marken der jeweiligen Inhaber. Dieser Beitrag dient der technischen Erläuterung und begründet keine Zugehörigkeits- oder Vertretungsbeziehung zu den Rechteinhabern. Modellliste, Kontextlänge und Abrechnungsregeln können sich ändern; vor der Beschaffung die offiziellen Seiten erneut prüfen.

1. Zuerst „aktuelle Modelle“ und „eingestellte Modelle“ trennen

Stand Oktober 2026 nennt die Dokumentation der Open Platform als Hauptmodelle kimi-k3, kimi-k2.6, kimi-k2.7-code und kimi-k2.7-code-highspeed. Die alte moonshot-v1-Serie ist ausgelaufen: moonshot-v1-8k, -32k, -128k, -auto und die entsprechenden Vision-Preview-Versionen wurden am 31. August 2026 eingestellt, am selben Tag auch kimi-k2.5. Ältere kimi-k2-Previews und kimi-latest wurden ebenfalls beendet.

Modell Kontext Abrechnungsstruktur Status und Hinweis
kimi-k3 1.048.576 Eingabe, Cache-Treffer, Cache-Schreiben, Ausgabe Aktuelles Flaggschiff, offiziell als Migrationsziel empfohlen
kimi-k2.6 262.144 Eingabe, Cache-Treffer, Ausgabe Allzweck und multimodal, häufig in kostensensiblen Szenarien
kimi-k2.7-code 262.144 Eingabe, Cache-Treffer, Ausgabe Codegenerierung, Repository-Fragen, Agenten
kimi-k2.7-code-highspeed 262.144 Eingabe, Cache-Treffer, Ausgabe Codeaufgaben mit niedriger Latenz
moonshot-v1-8k/32k/128k Nach Modellname Alte Preisstufen nach Länge Am 31.08.2026 eingestellt

Modellnamen aus alten Anleitungen dürfen nicht einfach übernommen werden. Das „8k“ in moonshot-v1-8k bezeichnet selbst eine Kontextstufe; ein fehlgeschlagener Aufruf liegt nicht am Key, sondern daran, dass das Modell nicht mehr existiert. Bei der Migration zuerst den Modellnamen ändern, dann Kontext und Abrechnungsposten prüfen – keine reine Textersetzung.

2. Abrechnungseinheit: eine Anfrage in vier Posten

Eine aktuelle Rechnung besteht üblicherweise aus vier Token-Kategorien: Eingabe ohne Cache-Treffer, Eingabe mit Cache-Treffer, Cache-Schreiben und Ausgabe. Bei K3 wird das Cache-Schreiben nach zwei TTL-Stufen (5 Minuten und 1 Stunde) separat abgerechnet; die Preisseite der K2-Serie führt keinen separaten Posten für Cache-Schreiben. Eine Anfrage als Formel:

Kosten je Anfrage =
  Eingabe-Tokens ohne Treffer × Preis ohne Treffer
+ Eingabe-Tokens mit Cache-Treffer × Trefferpreis
+ Cache-Schreib-Tokens × Preis der jeweiligen TTL (nur K3)
+ Ausgabe-Tokens × Ausgabepreis

Die offizielle Dokumentation nennt eine nützliche Umrechnung: Standardchinesisch entspricht etwa 1,5 bis 2 Schriftzeichen einem Token. Wer die Zeichenzahl direkt mit dem Stückpreis multipliziert, unterschätzt die Eingabemenge. Für die formale Kalkulation die Schätz-Schnittstelle POST /v1/tokenizers/estimate-token-count oder direkt das usage-Feld der Antwort verwenden.

Bei Chat Completions heißen die Nutzungsfelder usage.prompt_tokens und usage.completion_tokens; Cache-Details stehen in usage.prompt_tokens_details.cached_tokens und cache_write_tokens. Bei der Messages API enthält input_tokens den Cache-Anteil nicht; die Gesamteingabe ist die Summe aus input_tokens, cache_read_input_tokens und cache_creation_input_tokens. Bei Streaming stream_options.include_usage=true setzen.

3. Wie Caching abgerechnet wird und warum Treffer ausbleiben

Der Kontext-Cache arbeitet mit Präfix-Matching, nicht mit Matching der gesamten Konversation. Ändert sich eine Stelle im Präfix, kann der Inhalt danach nicht wiederverwendet werden. Häufige Ursachen für ein gebrochenes Präfix: Zeitstempel oder zufällige IDs im System-Prompt, jedes Mal neu sortierte Tool-Definitionen, dynamisch zusammengesetzte Wissensdatenbank-Fragmente, Wechsel der TTL-Stufe. Der Cache ist zudem pro Organisation isoliert; verschiedene Organisationen teilen ihn nicht.

Bei K3 wird das Cache-Schreiben beim ersten Schreiben abgerechnet, die TTL ist fest auf 5 Minuten oder 1 Stunde gesetzt und kann nach dem Schreiben nicht gewechselt werden; ein Treffer verlängert die ursprüngliche TTL kostenlos, ohne erneut Schreibgebühr. Die beiden Cache-Stufen sind nicht miteinander verbunden. Reicht der Präfix-Rest am Ende nicht für einen vollständigen Cache-Block, wird dieser Teil üblicherweise als Fehltreffer behandelt.

Caching ist kein Schalter, der „eingeschaltet Geld spart“, sondern Präfix-Engineering. System-Prompt, Tool-Definitionen, feste Beispiele und gemeinsame Teile der Wissensdatenbank nach vorne, variable Teile nach hinten und die Trefferquote mit cached_tokens verifizieren.

4. Kosten des langen Kontexts: teuer wird die wiederholte Übertragung

K3 unterstützt 1.048.576 Tokens Kontext, die K2-Serie 262.144 Tokens. K3 nutzt eine einheitliche nutzungsbasierte Abrechnung und staffelt nicht mehr wie das alte moonshot-v1 nach 8k, 32k und 128k; die alte Stufenpreistabelle lässt sich daher nicht auf K3 übertragen.

Langer Kontext ist an sich kein Problem; problematisch ist, dass dasselbe Material in jeder Runde erneut übertragen wird. Bei einer Dokumentenfrage mit 200.000 Tokens und zehn Folgerunden mit jeweils vollständigem Text summieren sich die Eingabekosten schnell; auch Tool-Logs, Webseitentexte und Codeergebnisse bleiben im Verlauf und werden weiter abgerechnet. Üblicher ist: zuerst relevante Passagen per Retrieval auswählen und dann vom Modell lesen lassen; mehrstufige Dialoge mit rollierender Zusammenfassung; stabile Teile als Cache-Präfix; langen Kontext nur für Originaltexte reservieren, die zwingend erhalten bleiben müssen.

Langer Kontext erhöht zudem Latenz und Fehlerquote. Nicht gestreamte lange Anfragen laufen eher in Gateway-Timeouts, und Wiederholungen erzeugen neue Eingabekosten. Lange Aufgaben sollten bevorzugt gestreamt und mit einem angemessenen Lese-Timeout betrieben werden.

5. Wie Retries und fehlgeschlagene Anfragen zählen

Die offiziellen Fehlercodes teilen 429 in drei Klassen: rate_limit_reached_error bedeutet, dass Parallelität, RPM, TPM oder TPD auf Organisationsebene erreicht sind; exceeded_current_quota_error bedeutet unzureichendes Guthaben oder Kontingent; engine_overloaded_error bedeutet Überlast der Serverkapazität. Nur Guthabenprobleme lassen sich durch Aufladen lösen; Kapazitätsüberlast verschwindet dadurch nicht unmittelbar. Bei 500 und 503 ist ein späterer Retry üblich; bei Gateway-Timeouts langer Anfragen ist der Wechsel auf Streaming meist sinnvoller als das unveränderte erneute Senden.

Ob fehlgeschlagene Anfragen abgerechnet werden, sagt die offizielle Dokumentation nicht als „Fehler kostenlos“ zu. Sicher ist, keine kostenlosen Retries anzunehmen, Anfrage-Logs und usage abzugleichen und Retry-Zahlen separat zu erfassen. Eine Retry-Strategie lässt sich so umsetzen:

  1. Zuerst nach Fehlercode klassifizieren; Zahlungsrückstand, Parameterfehler und fehlgeschlagene Inhaltsprüfung nicht wiederholen.
  2. Nur 429-Drosselung, 500, 503 und Netzwerkabbrüche begrenzt wiederholen.
  3. Exponentielles Backoff mit zufälligem Jitter verwenden und Retry-After beachten.
  4. Obergrenze und Gesamtdauer für Retries setzen, damit Parallelität nicht dauerhaft belegt bleibt.
  5. Tool-Aufrufe mit Idempotenzschlüssel oder Deduplizierungstabelle absichern, um doppelte Bestellungen oder Nachrichten zu vermeiden.
  6. request_id, Modellname, Tokenverbrauch und Retry-Anzahl protokollieren, um die Abrechnung abzugleichen.

6. Budgetschätzung: von Tokens zur Monatsobergrenze

Das Budget nicht aus einem Stückpreis je Tokeneinheit rückwärts ableiten, sondern aus realen Aufgaben. 20 bis 50 repräsentative Aufgaben auswählen, die einfache, mittlere und komplexe Stufen abdecken, und Abnahmekriterien festlegen; dann die Eingabe mit der Schätz-Schnittstelle messen, das usage echter Aufrufe lesen und Modelle über „Gesamtkosten einer bestandenen Aufgabe“ vergleichen.

import os
import requests

resp = requests.post(
    "https://api.moonshot.cn/v1/tokenizers/estimate-token-count",
    headers={"Authorization": f"Bearer {os.environ['MOONSHOT_API_KEY']}"},
    json={
        "model": "kimi-k3",
        "messages": [{"role": "user", "content": "Extrahiere aus diesem Vertrag JSON: ..."}],
    },
    timeout=30,
)
print(resp.json()["data"]["total_tokens"])

Nach der Schätzung der Einzeleingabe sind vier Blöcke zu ergänzen: Verlauf, Tool-Rückgaben, Anteil der Cache-Fehltreffer und zusätzliche Aufrufe durch Retries. Für Offline-Batch-Verarbeitung lässt sich die Batch API prüfen; laut offizieller Dokumentation liegt sie rund 40 Prozent unter synchronen Aufrufen, unterstützt derzeit aber nur kimi-k2.7-code und kimi-k2.6, kimi-k3 noch nicht.

Für die Budgetkontrolle drei Ebenen empfehlen: Tages- und Monatsbudget pro Projekt, wobei die Konsole nach Erreichen der Obergrenze Anfragen des Projekts ablehnt, die Durchsetzung aber etwa zehn Minuten verzögert sein kann; Aufteilung nach Key oder Mitglied, damit ein Geschäftsbereich nicht das gesamte Organisationskontingent ausschöpft; wöchentlicher Abgleich nach Modell und Szenario, um die am schnellsten wachsenden Aufrufe zu finden. Guthabenwarnungen verhindern nur eine plötzliche Unterbrechung und ersetzen kein Budget.

7. Reihenfolge der Kostenoptimierung und Abgleichgewohnheiten

Die Reihenfolge nicht umkehren. Zuerst Caching und Eingabesteuerung, dann Ausgabebegrenzung, erst zuletzt der Modellwechsel; sonst werden nur falsche Antworten billiger.

  1. System-Prompt, Tool-Definitionen und Wissensdatenbank-Präfix fixieren und cached_tokens prüfen.
  2. Mit Retrieval und Zusammenfassungen den jeweils übertragenen Originaltext reduzieren; den Verlauf rollierend zusammenfassen.
  3. max_completion_tokens setzen, JSON oder feste Felder verlangen und offene lange Ausgaben reduzieren.
  4. Modelle nach Aufgabe routen: kimi-k2.6 für allgemeine Aufgaben, die K2.7-Code-Version für Code, K3 für sehr langes Material.
  5. Lange Anfragen auf Streaming umstellen, um Retries durch Timeouts und Verbindungsabbrüche zu verringern.
  6. Offline-Aufgaben über die Batch API, Echtzeitaufgaben über die synchrone Schnittstelle.
  7. Monatlich nach Projekt, Modell und Szenario abgleichen und Cache-Trefferquote, Retry-Anzahl und durchschnittliche Ausgabelänge separat erfassen.

Eine Abrechnungszeile enthält mindestens: Aufrufzeitpunkt, Projekt, Modell, Eingabe-Tokens, Cache-Treffer-Tokens, Cache-Schreib-Tokens, Ausgabe-Tokens, Retry-Anzahl und request_id. Fehlen diese Felder, lässt sich bei Abweichungen nur raten.

Häufig gestellte Fragen

Lässt sich moonshot-v1-8k weiterhin aufrufen?

Nein. Die gesamte moonshot-v1-Serie wurde am 31. August 2026 eingestellt; offiziell wird die Migration zu kimi-k3 empfohlen. Bei der Migration nicht nur den Modellnamen ändern, sondern auch Kontextlänge, Abrechnungsposten und Ausgabeparameter prüfen.

Warum greift der Cache-Treffer nicht?

Zuerst prüfen, ob Zeitstempel, zufällige IDs, dynamische Sortierung oder neu sortierte Tools das Präfix gebrochen haben; dann, ob der Abstand zwischen den Anfragen die TTL überschreitet; schließlich, ob Cache-Schreiben und -Lesen in derselben Organisation und derselben TTL-Stufe erfolgen. Mit cached_tokens urteilen, nicht nach Gefühl.

Ist langer Kontext immer teurer?

Nicht unbedingt, aber wiederholt übertragenes langes Material wird meist teuer. Die Kosten hängen davon ab, wie oft die Eingabe wiederholt wird, von der Cache-Trefferquote und der Ausgabelänge. Zuerst per Retrieval eingrenzen, dann über Millionenkontext entscheiden.

Werden fehlgeschlagene Anfragen abgerechnet?

Die offizielle Dokumentation sagt keine kostenlosen Fehler zu. Keine kostenlosen Retries annehmen, sondern über Anfrage-Logs und usage abgleichen und Retry-Zahlen in die Kosten je Aufgabe einrechnen.

Wo stehen die aktuellen Preise?

In den Modellpreisen auf dieser Website und in der offiziellen Moonshot/Kimi-Dokumentation. Preise, Modellliste und Cache-Regeln können sich ändern; keine alten Screenshots weiterverwenden.

Nächster Schritt

Erstellen Sie zunächst im ZSQH AI Gateway einen Test-Key, lassen Sie je eine Charge realer Aufgaben mit kimi-k2.6 und kimi-k3 laufen und erfassen Sie Eingabe, Ausgabe, Cache-Treffer und Retries, bevor Sie Hauptmodell und Monatsbudget festlegen. Konkrete Preise und verfügbare Modelle richten sich nach den Modellpreisen.

Weiterführende Beiträge