Kimi K3.1 Pro: Kontingent-Reset, 25%-Regel und API-Kosten

Der angekündigte Kontingent-Reset für Kimi K3.1 Pro stellt bis zu 25 Prozentpunkte deines monatlichen Abokontingents wieder her; er verspricht nicht, sämtliche Anfragelimits aufzuheben. Prüfe zuerst die monatliche Verbrauchsanzeige und anschließend das separate Nutzungsfenster von Kimi Code, falls Programmieranfragen weiter fehlschlagen. Wenn die Arbeit nicht warten kann, bietet ein nutzungsabhängig bezahlter API-Zugang eine separate Abrechnung mit eigenem Schlüssel, Endpunkt, Guthaben und eigenen Limits.

In seiner Ankündigung vom 25. Oktober übernahm Moonshot die Verantwortung für Probleme mit Anfragelimits und unnötigen Kontingentverbrauch beim K3.1-Pro-Abo. Das Unternehmen kündigte einen Ausgleich für Abonnenten aller Tarife an. Zugleich sollen Änderungen unnötige Subagent-Aufrufe und die Ausgabelänge reduzieren.

Die folgenden Regeln beruhen auf der Ankündigung und der offiziellen Dokumentation mit Stand 2026-10-26.

Wie viel Kontingent stellt der Reset um 25% wieder her?

Die Ankündigung bedeutet, dass vom monatlichen Verbrauch 25 Prozentpunkte abgezogen werden, wobei der Verbrauch nicht unter null fällt. Bei unverändertem Monatskontingent und ohne zwischenzeitliche Nutzung oder reguläre Erneuerung zum Abrechnungszyklus gilt:

used_after = max(0, used_before - 25)

Gleichwertig lässt sich das verbleibende Kontingent so berechnen:

remaining_after = min(100, remaining_before + 25)

Jeder Wert bezeichnet einen Prozentsatz des gesamten Monatskontingents.

Vorher verbrauchtes Monatskontingent	Erwarteter Verbrauch nach der Anpassung	Erwartetes Restkontingent
18%	0%	100%
25%	0%	100%
60%	35%	65%
100%	75%	25%

Das sind berechnete Beispiele, keine beobachteten Kontowerte. Wer weniger als 25% verbraucht hatte, erhält genau diesen verbrauchten Anteil zurück; die Formel erzeugt kein verfügbares Kontingent über 100%.

Der Unterschied zwischen Prozent und Prozentpunkten ist entscheidend. Würde man einen Verbrauch von 60% um 25% dieses Verbrauchs senken, blieben 45% verbraucht. Nach der angekündigten Anpassung bleiben dagegen 35% verbraucht.

Moonshot bezeichnete die wiederhergestellte Menge als Gegenwert einer Nutzungswoche. Das beschreibt den Umfang des Ausgleichs. Es garantiert weder eine Woche Programmierzeit noch einen neuen wöchentlichen Reset oder zusätzliche Abotage. Maßgeblich für deinen normalen Abrechnungszyklus ist der nächste Erneuerungszeitpunkt auf der Aboseite.

Als Frist für die Aktualisierung der Verbrauchsanzeige nannte die Ankündigung vom 25. Oktober „end of day PST“, also das Ende dieses Tages nach PST. Kontrolliere die Anzeige nach dieser Frist. Die Ankündigung allein belegt noch nicht, dass die Anpassung auf deinem Konto bereits erfolgt ist.

Teilen sich Kimi-Abo, Kimi Code und API-Schlüssel dasselbe Kontingent?

Das Kimi-Abo und Kimi Code teilen sich das monatliche Abokontingent; die öffentliche Kimi API Platform rechnet separat nach Verbrauch ab. Ein API-Schlüssel kann zu einem der beiden Systeme gehören. Dass du einen Schlüssel verwendest, sagt daher noch nicht, welches Kontingent du verbrauchst.

Die Nutzungsregeln für Abos erklären, dass die enthaltenen Funktionen auf einen gemeinsamen, anhand von Tokens gemessenen Kreditpool zugreifen. Kimi Code legt zusätzlich zum Monatskontingent kürzere Nutzungsfenster fest.

Der aktuelle Leitfaden zu Abos von Kimi Code unterscheidet neue und ältere Tarife:

Tarifgruppe mit Zugriff auf Kimi Code	Gleitendes Fünf-Stunden-Limit	Wochenlimit	Gemeinsames Monatskontingent
Neue Tarife Plus, Pro, Max und Ultra	Gilt	Gilt nicht	Gilt
Ältere Tarife Andante, Moderato, Allegretto und Allegro	Gilt	Gilt	Gilt

Das Wochenkontingent älterer Tarife erneuert sich alle sieben Tage ab dem Abodatum. Bei beiden Gruppen kann außerdem das ausgeschöpfte Monatskontingent die Nutzung blockieren. Go enthält keinen Zugriff auf Kimi Code; K3.1 Pro selbst erfordert einen neuen Tarif ab Plus oder einen älteren Tarif ab Moderato.

Die pauschale Aussage, Kimi habe keine Wochenlimits, ist deshalb unvollständig. Sie trifft auf die neuen Tarife mit Programmierzugriff zu, nicht auf jedes bestehende Abo. Die Wiederherstellung des Monatskontingents belegt auch nicht, dass ein ausgeschöpftes Fünf-Stunden-Fenster oder das Wochenfenster eines älteren Tarifs zurückgesetzt wurde.

Anfragen an Kimi Code aus CLI, Desktop, VS Code und unterstützten Drittanbieter-Clients nutzen dieselben Leistungen des Kontos. Ein weiterer Code-API-Schlüssel oder der Wechsel von Claude Code zu OpenCode schafft kein neues Abokontingent. Aktiviertes Extra Usage kann die kostenpflichtige Fortsetzung über die Abrechnung des Abos ermöglichen.

Moonshots API-Preisdokumentation beschreibt die öffentliche API Platform dagegen ausdrücklich als nutzungsabhängig bezahlten Dienst, getrennt vom Abo und von Kimi Code. Die Reset-Ankündigung bestätigt weder eine Erstattung noch eine Guthabengutschrift oder das Zurücksetzen von Anfragelimits für dieses separate API-Konto.

Eine ausführlichere Erklärung der Zeitfenster findest du im Artikel Kimi Code: Fünf-Stunden-Limits, Wochenlimits älterer Tarife, Monatskontingent und 429-Fehler. Die dort genannten Statuscodes für Kontingentfehler weichen von der aktuellen offiziellen Referenz ab. Verwende zur Diagnose die aktuellen Zuordnungen weiter unten.

Was verbraucht nach der Änderung weiterhin Kontingent?

Nützliche Modellarbeit verbraucht weiterhin Tokens, auch wenn Subagents sie ausführen. Moonshot kündigt weniger unnötige Aufrufe und kürzere Ausgaben an; delegierte Arbeit und lange Antworten werden dadurch nicht kostenlos.

Laut Kimis Dokumentation zu Subagents arbeitet jeder Subagent in einem eigenen Kontext und verbraucht separat Modelltokens. Delegation kann daher zusätzliche Eingabe- und Ausgabearbeit verursachen, besonders wenn mehrere Agenten überlappende Inhalte untersuchen. Bei einer kleinen Aufgabe kann der Hauptagent dasselbe Ergebnis mit weniger Aufrufen erreichen.

Beginne für eine Verbrauchsmessung mit einer klar begrenzten Aufgabe. Füge beispielsweise diesen Prompt in einen Coding-Client ein, in dem ein Repository geöffnet ist:

Read this repository's README and test configuration.
Identify the command for running its existing tests.
Work in the main agent without spawning subagents.
Do not modify files or run tests.
Answer in at most 100 words, citing the files that establish the command.
If no test command is documented, say so.

Das Ergebnis lässt sich überprüfen: Du erhältst den Testbefehl des Repositorys und die Dateien, die ihn belegen. Unnötige Delegation fällt bei einer solchen Aufgabe auch leichter auf als bei einer umfassenden Aufforderung, das gesamte Projekt zu prüfen.

Der Prompt gibt eine Arbeitsanweisung, setzt aber keine harte Ausgabengrenze. Prüfe in der Aktivitätsansicht des Clients, ob er Arbeit delegiert hat, und bewerte das Ergebnis anhand des protokollierten Verbrauchs. Eine kürzere sichtbare Antwort allein belegt keinen geringeren Gesamtverbrauch.

Halte Modell und Reasoning-Einstellungen beim Vergleich konstant. Laut Leitfaden zur Modellkonfiguration kann ein Wechsel des Modells oder des Reasoning-Aufwands den Kontext-Cache ungültig machen und den Verbrauch erhöhen. Die Dokumentation nennt außerdem ungefähr den doppelten Kontingentverbrauch für k3.1-pro-highspeed gegenüber dem Standardmodell k3.1-pro. Verwende für einen Effizienzvergleich deshalb das Standardmodell, sofern Geschwindigkeit nicht die entscheidende Anforderung ist.

Lass den Denkmodus aktiviert: K3.1 Pro lehnt Anfragen ab, die ihn deaktivieren. Die Länge der endgültigen Antwort zu begrenzen ist eine andere Einstellung als das Abschalten des Reasonings.

Wie prüfst du den Reset und einen geringeren Verbrauch?

Prüfe die Wiederherstellung des Kontingents getrennt vom Verbrauch einer neuen Aufgabe. Eine gemeinsame Messung kann beide Effekte verdecken: Die Gutschrift senkt den angezeigten Verbrauch, während ein anderer laufender Agent ihn erhöht.

1. Erfasse die richtigen Anzeigen. Öffne in Kimis Weboberfläche dein Profilbild → Settings → Subscription. Notiere den Tarif, ob die Prozentzahl den verbrauchten oder verbleibenden Anteil zeigt, den nächsten Erneuerungszeitpunkt sowie Datum und Uhrzeit mit Zeitzone. Führe in Kimi Code außerdem /usage aus und prüfe in der Console den Status der kürzeren Nutzungsfenster.

2. Vergleiche die Anpassung ohne andere laufende Nutzung. Pausiere während der Prüfung weitere Sitzungen, die Abokontingent verbrauchen. Wenn du einen Wert vor der Anpassung erfasst hast, vergleiche ihn nach dem Update anhand der Formel oben. Berücksichtige zwischenzeitliche Aufgaben und eine mögliche reguläre Monatserneuerung. Ohne vorherige Messung lässt sich die genaue Gutschrift nicht allein aus der aktuellen Anzeige rekonstruieren.

3. Miss nach abgeschlossener Anpassung eine kleine Aufgabe. Notiere den Verbrauch unmittelbar vor dem begrenzten Repository-Prompt und prüfe nach Abschluss den Nutzungseintrag dieser Aufgabe. Kimis FAQ zum Verbrauch beschreibt diese Aufzeichnungen und weist auf eine mögliche kurze Verzögerung der Anzeige hin.

4. Vergleiche gleichwertige Arbeit. Verwende dasselbe Repository, Modell, Reasoning, dieselben verfügbaren Werkzeuge und dasselbe Aufgabenziel. Halte vorhandene Cache-Informationen fest, statt identische Cache-Bedingungen für zwei Durchläufe anzunehmen. Vergleiche sowohl den Kontingentverbrauch als auch die Frage, ob die Antwort die Aufgabe tatsächlich erfüllt hat.

Ohne einen vergleichbaren früheren Durchlauf entsteht damit ein Ausgangswert für künftige Aufgaben. Die Messung beweist nicht, wie viel eine Backend-Änderung eingespart hat. Wenn die Prozentanzeige zu grob ist, um eine kleine Anfrage zu erkennen, prüfe zuerst den detaillierten Eintrag, bevor du für wiederholte Versuche weiteres Kontingent verbrauchst.

Falls Anfragen weiterhin fehlschlagen, nutze die vollständige Fehlermeldung. Mit Stand 2026-10-26 führt die offizielle Fehlerreferenz von Kimi Code diese Kontingentfälle unter HTTP 429 auf:

Fehlermeldung von Kimi Code	Was du prüfen solltest
You've reached your 5-hour usage limit	Prüfe in der Console den Reset-Zeitpunkt des Fünf-Stunden-Fensters.
You've reached your weekly (7-day) usage limit	Prüfe das Wochenfenster des älteren Tarifs.
You've reached your monthly usage limit for this billing cycle	Prüfe die gemeinsame Monatsanzeige und die Anpassung.

Wiederholte Versuche füllen ein ausgeschöpftes Kontingent nicht auf. Serverüberlastung ist eine separate Ursache. Deshalb kann eine Anfrage trotz wiederhergestellten Monatskontingents fehlschlagen.

Wenn die zugesagte Anpassung nach Ablauf der Frist und nach Aktualisierung der Anzeige weiterhin fehlt, kontaktiere den Kimi-Abosupport. Gib Tarif und Zeitstempel an und füge Verbrauchsnachweise von vorher und nachher bei, in denen sensible Daten unkenntlich gemacht sind.

Wann lohnt sich der Wechsel zu einer separat abgerechneten API?

Nutze einen nach Verbrauch bezahlten Zugang, wenn die Aufgabe eine separate Zahlung rechtfertigt und das Warten auf ein neues Abofenster die Arbeit blockieren würde. Wenn es wichtiger ist, die bestehende Kimi-Sitzung fortzusetzen, prüfe zuerst, ob dein Konto Extra Usage anbietet. Dieses bezahlte Guthaben teilen sich Kimi und Kimi Code. Aktiviere dessen monatliche Ausgabengrenze, bevor du dich für weitere Arbeit darauf verlässt.

Wähle den Abrechnungsweg und kalkuliere die Kosten

Endpunkt, Modell-ID und Herkunft des Schlüssels müssen zusammenpassen. Die Tabelle zeigt die internationalen OpenAI-kompatiblen Basis-URLs; werkzeugspezifische Anthropic-Konfigurationen verwenden andere Basispfade.

Zugang	Basis-URL	Modell-ID für K3.1 Pro Standard	Abrechnung
Kimi Code	https://api.kimi.ai/coding/v1	k3.1-pro	Aboleistungen; bei berechtigten Konten kann Extra Usage übernehmen
Kimi API Platform	https://api.moonshot.ai/v1	kimi-k3.1-pro	Separates API-Konto mit nutzungsabhängiger Abrechnung
BetterToken	https://www.bettertoken.ai/v1	kimi-k3.1-pro	Separates API-Guthaben bei BetterToken

BetterTokens aktueller Modellkatalog führte kimi-k3.1-pro am 2026-10-26 mit Zugängen über Chat Completions und Anthropic Messages. Der Modellleitfaden erklärt, dass Responses für dieses Modell nicht aktiviert ist. Es handelt sich um unabhängigen API-Zugriff, nicht um Kontingent aus einem Kimi-Abo.

Zur Einordnung: Moonshots aktuelle globale API-Preise nennen für kimi-k3.1-pro Standard $2 pro Million regulärer Eingabetokens und $10 pro Million Ausgabetokens, jeweils vor anfallenden Steuern. Eine hypothetische Anfrage mit 100,000 Eingabetokens zum Preis von $2 und insgesamt 10,000 abgerechneten Ausgabetokens kostet:

(100,000 / 1,000,000 × $2) + (10,000 / 1,000,000 × $10) = $0.30

Diese Schätzung setzt voraus, dass keine kostenpflichtigen Werkzeugaufrufe, Cache-Treffer oder Cache-Schreibvorgänge mit einer Stunde Gültigkeit anfallen. Reguläre Cache-Schreibvorgänge mit fünf Minuten Gültigkeit kosten ebenfalls $2 pro Million Tokens. Ein Token wird nicht zusätzlich als reguläre Eingabe berechnet, wenn es bereits zur Kategorie Cache-Schreibvorgang gehört. Rechne mit den tatsächlich abgerechneten Tokens, nicht mit der Länge der sichtbaren Antwort.

BetterToken hat eigene aktuelle Preise. Aus einem prozentualen Aboverbrauch lässt sich nicht ableiten, welcher Zugang günstiger ist. Eine Agentenaufgabe kann außerdem viele Anfragen umfassen, die über ihre sichtbare Abschlussantwort hinausgehen.

Prüfe eine Anfrage, bevor du eine Agentensitzung umstellst

Wähle für BetterToken deinen eigenen API-Schlüssel in der Konsole, bestätige Modellzugriff und verfügbares Guthaben und sende eine kleine Anfrage. Das folgende Beispiel entspricht dem dokumentierten Anfrageformat; für diesen Artikel wurde es nicht mit einem kostenpflichtigen Inferenzkonto ausgeführt.

Verwende Bash mit installiertem curl und jq. Sobald read auf Eingabe wartet, füge deinen Schlüssel ein und drücke Enter. Die Eingabe bleibt verborgen.

set -o pipefail
read -rs BETTERTOKEN_API_KEY && export BETTERTOKEN_API_KEY

curl --silent --show-error --fail-with-body \
  https://www.bettertoken.ai/v1/chat/completions \
  --header "Authorization: Bearer ${BETTERTOKEN_API_KEY:?API key is required}" \
  --header "Content-Type: application/json" \
  --data '{
    "model": "kimi-k3.1-pro",
    "stream": false,
    "messages": [
      {"role": "user", "content": "Reply with exactly: API_OK"}
    ]
  }' |
jq '{
  model,
  answer: .choices[0].message.content,
  finish_reason: .choices[0].finish_reason,
  usage,
  error
}'

Der Antwortkörper enthält das Ergebnis; diese Anfrage ohne Streaming benötigt keine regelmäßige Abfrage eines Jobstatus. Prüfe die angeforderte Antwort API_OK, den vollständigen Abschluss der Antwort und die Nutzungsinformationen. Gleiche die Anfrage im BetterToken-Dashboard mit Modell, Status, Tokenverbrauch und berechnetem Betrag ab, bevor du eine größere Aufgabe umstellst.

Um in Cline weiterzuarbeiten, öffne Use your own API key, wähle OpenAI Compatible und trage die BetterToken-Basis-URL aus der Tabelle, deinen BetterToken-Schlüssel und kimi-k3.1-pro ein. Speichere, lade die Erweiterung neu und beginne mit derselben kleinen Repository-Aufgabe. Für OpenCode folgst du der Konfiguration des benutzerdefinierten Anbieters für Chat Completions.

Die BetterToken-Konfiguration für Claude Code verwendet die Anthropic-kompatible Basis https://bettertoken.ai, ohne /v1. Folge den Authentifizierungsanweisungen dieses Werkzeugs, statt die Basis-URL für Chat Completions in seine Konfiguration zu übernehmen.

Falls der erste Verbindungstest 401 zurückgibt, prüfe den BetterToken-Schlüssel erneut. Bei 404 oder einem Fehler bei der Modellsuche kontrolliere den exakten Endpunkt und die Modell-ID. Bei einem Anfragelimit- oder Guthabenfehler prüfe vor einem weiteren Versuch die Antwort und das Dashboard dieses API-Kontos. Der Abo-Reset belegt nicht den Zustand eines separat abgerechneten Zugangs.