Kimi K2 API wird eingestellt: K2.7 Code auf K3.1 Pro umstellen

Stellen Sie Anwendungen mit kimi-k2.6 und kimi-k2.7-code vor der geplanten Abschaltung Ende Dezember 2026 auf kimi-k3.1-pro um. Legen Sie die Reasoning-Stufe für das Schlussfolgern und eine Ausgabegrenze ausdrücklich fest. Prüfen Sie Tool-Verlauf und Cache-Kosten, bevor Sie Produktionstraffic umstellen. Stand 2026-11-05 gelten die Einschränkungen für neue Konten bereits.

Wann funktioniert Kimi K2 nicht mehr?

Bestehende Konten behalten vorerst Zugriff, sofern sie die Voraussetzungen erfüllen. Einen genauen Abschalttag oder eine Uhrzeit nennt Kimi in diesen Mitteilungen nicht.

Laut dem Hinweis auf der Preisseite sind K2-Modelle seit dem 31. Oktober 2026 für neu registrierte Nutzer nicht mehr verfügbar. Bis Ende Dezember 2026 sollen alle K2-Modelle eingestellt werden.

Die aktuelle Modellliste formuliert die Grenze etwas anders. Danach können Nutzer, die sich vor dem 1. November registriert haben, kimi-k2.6, kimi-k2.7-code und kimi-k2.7-code-highspeed weiter verwenden. Deren Abschaltung wird für Ende Dezember 2026 erwartet.

Wenn Ihre Registrierung in diesen Zeitraum fällt, prüfen Sie den tatsächlichen Zugriff Ihres Kontos. Die Formulierungen nennen keinen eindeutigen Zeitpunkt, ab dem neue Konten ausgeschlossen sind. Beginnen Sie neue Integrationen direkt mit K3.1 Pro.

Gehen Sie nicht davon aus, dass jeder fehlgeschlagene K2-Zugriff denselben Fehler liefert. Das Änderungsprotokoll vom August bestätigt 404 „model not found“ für die bereits eingestellten Modelle kimi-k2.5 und moonshot-v1. Dieser Hinweis legt nicht fest, welche Antwort K2.6 oder K2.7 Code nach ihrer Abschaltung liefern werden.

Passen Sie Anfragen vor dem Wechsel an

Ändern Sie den Anfrageinhalt und die Speicherung des Gesprächsverlaufs gemeinsam. Der aktuelle Parametervergleich von Kimi beschreibt Unterschiede, die bei einem bloßen Austausch des Modellnamens leicht übersehen werden.

Einstellung	`kimi-k2.6`	`kimi-k2.7-code`	`kimi-k3.1-pro`
Denkmodus (Thinking)	Standardmäßig aktiv; abschaltbar	Immer aktiv	Immer aktiv; das K2-Objekt `thinking` entfernen
`reasoning_effort`	Nicht unterstützt	Nicht unterstützt	Auf oberster Ebene: `low`, `high` oder `max`; Standard: `max`
`temperature`	Mit Denkmodus fest auf `1.0`, ohne auf `0.6`	Fest auf `1.0`	Fest auf `1.0`; das Feld weglassen
Dokumentierte Standardgrenze für die Generierung	`max_tokens`: `32768`	`max_tokens`: `32768`	`max_completion_tokens`: `131072`

K2.7 Code arbeitete bereits immer im Denkmodus und bewahrte die Reasoning-Inhalte im Verlauf auf. Für Anwendungen, die K2.6 ohne Denkmodus nutzen, bedeuten diese Vorgaben eine größere Änderung.

Der Schnellstart für K3.1 Pro legt außerdem top_p=0.95, n=1, presence_penalty=0 und frequency_penalty=0 fest. Lassen Sie diese Felder und temperature weg. Prüfen Sie auch die Standardwerte Ihrer Client-Bibliothek: Sie kann Sampling-Werte ergänzen, die Ihre Anwendung nie selbst gesetzt hat.

Verwenden Sie für neue Chat-Completions-Anfragen max_completion_tokens. Die API-Referenz kennzeichnet max_tokens als veraltet, erklärt das Feld aber nicht für entfernt. K3.1 Pro akzeptiert einen konfigurierten Höchstwert von 1048576. Die tatsächliche Generierung ist durch den verbleibenden Platz im Kontextfenster begrenzt.

Eine Ausgabegrenze ist ein Maximum. Sie bedeutet nicht, dass jede Anfrage so viele Tokens verbraucht. Wählen Sie eine passende Grenze für Ihre Aufgabe, statt den größeren Standardwert zu übernehmen.

Beginnen Sie bei der Reasoning-Stufe mit low für Verbindungstests und klar begrenzte Abfragen. Probieren Sie high für übliche Programmieraufgaben. Setzen Sie max ein, wenn Ihre Regressionstests den zusätzlichen Reasoning-Aufwand rechtfertigen. low reduziert den Aufwand, schaltet den Denkmodus aber nicht aus.

Prüfen Sie API und Tool-Aufrufe mit begrenzter Generierung

Prüfen Sie die API direkt, bevor Sie nach Fehlern in der Agentenkonfiguration suchen.

Erstellen Sie einen API-Schlüssel auf der Global Kimi Open Platform. Stand 2026-11-05 setzen die Zugangsbedingungen eine erfolgreiche Aufladung von mindestens $1 voraus. Verwenden Sie einen Schlüssel der Plattform, die zu https://api.moonshot.ai gehört. Bei Kontofehlern in Kimi Code beginnen Sie mit dem separaten Leitfaden zu Kimi-Code-Limits.

Lesen Sie den Schlüssel in Bash ein, ohne ihn anzuzeigen:

read -rs MOONSHOT_API_KEY && export MOONSHOT_API_KEY

Der folgende Bash-Befehl verwendet die Standardbibliothek von Python 3. Er sendet zwei kostenpflichtige Anfragen und führt die Multiplikation lokal aus. Die Generierungsgrenze 4096 gilt für diesen Rechentest und ist kein allgemeines Budget für Programmieraufgaben.

python3 - <<'PY'
import json
import os
import urllib.error
import urllib.request

tools = [{
    "type": "function",
    "function": {
        "name": "multiply",
        "description": "Multiply two integers.",
        "parameters": {
            "type": "object",
            "properties": {
                "a": {"type": "integer"},
                "b": {"type": "integer"}
            },
            "required": ["a", "b"],
            "additionalProperties": False
        }
    }
}]

def chat(messages, choice):
    payload = {
        "model": "kimi-k3.1-pro",
        "messages": messages,
        "reasoning_effort": "low",
        "max_completion_tokens": 4096,
        "tools": tools,
        "tool_choice": choice
    }
    request = urllib.request.Request(
        "https://api.moonshot.ai/v1/chat/completions",
        data=json.dumps(payload).encode("utf-8"),
        headers={
            "Authorization": "Bearer " + os.environ["MOONSHOT_API_KEY"],
            "Content-Type": "application/json"
        },
        method="POST"
    )
    try:
        with urllib.request.urlopen(request, timeout=120) as response:
            data = json.load(response)
    except urllib.error.HTTPError as error:
        raise SystemExit(f"HTTP {error.code}: check access and request parameters.")
    if data.get("model") != "kimi-k3.1-pro":
        raise RuntimeError("Unexpected response model.")
    if data["choices"][0]["finish_reason"] == "length":
        raise RuntimeError("Generation limit reached; do not accept this result.")
    return data

messages = [{
    "role": "user",
    "content": "Use multiply to calculate 6 times 7, then report the result."
}]
first = chat(messages, "required")
assistant = first["choices"][0]["message"]
calls = assistant.get("tool_calls") or []
if not calls:
    raise RuntimeError("Expected a tool call.")
messages.append(assistant)

for call in calls:
    function = call["function"]
    arguments = json.loads(function["arguments"])
    if function["name"] != "multiply":
        raise RuntimeError("Unexpected tool.")
    if not isinstance(arguments, dict) or set(arguments) != {"a", "b"}:
        raise RuntimeError("Unexpected arguments.")
    if any(type(arguments[key]) is not int for key in ("a", "b")):
        raise RuntimeError("Expected integer arguments.")
    result = arguments["a"] * arguments["b"]
    messages.append({
        "role": "tool",
        "tool_call_id": call["id"],
        "content": json.dumps({"result": result})
    })

final = chat(messages, "none")
choice = final["choices"][0]
answer = choice["message"].get("content") or ""
if choice["finish_reason"] != "stop" or not answer.strip():
    raise RuntimeError("Expected a completed final answer.")
print(answer)
print(json.dumps({"first": first["usage"], "final": final["usage"]}))
PY

Erwartet wird eine abschließende Antwort mit 42. Danach folgen die Objekte mit den Verbrauchsdaten beider Anfragen. Der Test bricht bei fehlenden Tool-Aufrufen, einem unerwarteten Modell, ungültigen Argumenten, abgeschnittener Generierung oder einer unvollständigen Abschlussantwort ab.

messages.append(assistant) übernimmt die vollständige Antwortnachricht unverändert, einschließlich reasoning_content und tool_calls. Jedes Tool-Ergebnis erhält anschließend die dazugehörige tool_call_id. Wenden Sie diese Regel zum Erhalten des Verlaufs auch auf den gespeicherten Gesprächsverlauf Ihrer Produktionsanwendung an.

Der Test verwendet bewusst erforderliche und verbotene Tool-Aufrufe, um beide Phasen zu prüfen. Im normalen Agentenablauf können Sie auto verwenden, wenn das Modell über den nächsten Tool-Aufruf entscheiden soll.

Wenn die Anfrage fehlschlägt, wählen Sie anhand der Fehlerreferenz die nächste Prüfung:

Bei 401 prüfen Sie, auf welcher Plattform der Schlüssel erstellt wurde und ob der Endpunkt dazu passt. Wiederholen Sie anschließend denselben Test.
Bei 400 in einer vorhandenen Anwendung prüfen Sie das gesendete JSON auf alte K2-Einstellungen für thinking oder abweichende feste Sampling-Werte.
Bei 404 prüfen Sie sowohl die Modellkennung als auch die Zugriffsrechte des Kontos. Der Statuscode allein belegt keinen Tippfehler.
Bei finish_reason="length" behandeln Sie die Antwort als unvollständig. Passen Sie Aufgabe, Reasoning-Stufe oder Generierungsgrenze an, bevor Sie das Ergebnis übernehmen.

Stand 2026-11-05 führt auch BetterToken kimi-k3.1-pro im Katalog. Seine OpenAI-kompatible API verwendet https://www.bettertoken.ai/v1 mit Ihrem eigenen BetterToken-API-Schlüssel. Prüfen Sie die aktuellen Preise und die API-Vorgaben separat. Aus Moonshots Cache-Regeln lässt sich das Verhalten dieses Gateways nicht ableiten.

Aktualisieren Sie OpenCode und Claude Code

Ändern Sie alle Routen, über die K2 ausgewählt werden kann. Dazu gehören Hintergrundaufgaben und Subagenten. Ein erfolgreicher Hauptdialog bestätigt nicht, dass diese Routen ebenfalls funktionieren.

OpenCode: Moonshot als Anbieter auswählen

Verwenden Sie den integrierten Anbieter Moonshot AI, und aktualisieren Sie dessen Modellkatalog. Seine Anbieterkennung lautet moonshotai; den Schlüssel liest er aus MOONSHOT_API_KEY.

Für die Kommandozeilenschnittstelle (CLI) von OpenCode v1.19.5 führen Sie diese Befehle in derselben Bash-Sitzung aus:

opencode models moonshotai --refresh
opencode run --model moonshotai/kimi-k3.1-pro --variant high \
  "Inspect the current project and identify the test command. Do not edit files."

Die aktualisierte Liste sollte moonshotai/kimi-k3.1-pro enthalten. Der zweite Befehl sollte mit diesem Anbieter und Modell eine Antwort zu Ihrem Projekt liefern. Fehlt das Modell, prüfen Sie die installierte Client-Version und die Aktualisierung des Katalogs, bevor Sie fortfahren.

Die CLI-Referenz beschreibt beide Optionen. Um die Modellauswahl zu speichern, setzen Sie "model": "moonshotai/kimi-k3.1-pro" in der Projektdatei opencode.json oder global in ~/.config/opencode/opencode.json. Beachten Sie die Rangfolge der Konfigurationen, wenn beide Dateien vorhanden sind.

Der Befehl legt high für diesen Aufruf fest. Wählen Sie in einer interaktiven Sitzung die Reasoning-Stufe mit /variants, bevor Sie den ersten Prompt senden. Wenn Sie zugleich den Client aktualisieren, prüfen Sie die geänderten Berechtigungen in OpenCode 2, bevor Sie Änderungen am Repository erlauben.

Claude Code: Alle Modellzuordnungen aktualisieren

Moonshot beschreibt einen Kompatibilitätsweg für Claude Code. Anthropic erklärt in seiner Gateway-Dokumentation, dass es die Weiterleitung von Claude Code an Modelle außerhalb der Claude-Familie nicht unterstützt. Behandeln Sie diese Konfiguration als Adapterlösung von Moonshot, und prüfen Sie sie mit Ihrer installierten Client-Version.

Prüfen Sie zuerst ~/.claude/settings.json und die Projekteinstellungen. Korrigieren Sie veraltete Endpunkte, Zugangsdaten, Modelle und Reasoning-Stufen in deren env-Blöcken. Moonshot warnt, dass Umgebungsvariablen aus Einstellungsdateien die im Terminal exportierten Werte überschreiben können.

Im aktuellen Beispiel von Moonshot verweist Haiku noch auf kimi-k2.7-code. Die folgende Bash-Konfiguration stellt als Migrationsvorschlag alle aufgeführten Modellstufen auf das Zielmodell um:

unset ANTHROPIC_API_KEY
export ANTHROPIC_BASE_URL="https://api.moonshot.ai/anthropic"
export ANTHROPIC_AUTH_TOKEN="$MOONSHOT_API_KEY"
export ANTHROPIC_MODEL="kimi-k3.1-pro"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_FABLE_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_EFFORT_LEVEL="high"

claude --model kimi-k3.1-pro

Sie verwendet den bereits für den API-Test exportierten Schlüssel. Prüfen Sie, ob alte K2-Einstellungen wie ANTHROPIC_SMALL_FAST_MODEL übrig geblieben sind.

Führen Sie /status aus, und prüfen Sie Basis-URL und Modell. Stellen Sie danach eine einfache Frage. Geben Sie außerdem eine Aufgabe, für die der Client eine lokale Datei lesen muss. Prüfen Sie die tatsächlich aktive Reasoning-Stufe über die Einstellungen für Modelle.

Claude Code verwendet das Messages-Protokoll. Unterscheiden Sie die folgenden Kimi-Messages-Felder von den Feldern in Chat Completions:

Zweck	Chat Completions	Kimi Messages
Reasoning-Stufe	`reasoning_effort`	`output_config.effort`
Generierungsgrenze	`max_completion_tokens`	Pflichtfeld `max_tokens`
Cache-Lebensdauer	`prompt_cache_options.ttl`	`cache_control.ttl` im Objekt auf oberster Ebene

Benennen Sie max_tokens im Messages-Protokoll nicht um, nur weil das gleichnamige Feld in Chat Completions veraltet ist.

Prüfen Sie Cache-Kosten, ohne Tokens doppelt zu zählen

Teilen Sie die Eingabetokens in aus dem Cache gelesene, in den Cache geschriebene und ungecachte Tokens auf. K3.1 Pro berechnet Cache-Schreibvorgänge separat. Beziehen Sie diese Kosten in Ihre Kalkulation ein.

Lesen Sie für Chat Completions diese Felder aus:

Gesamte Eingabe: usage.prompt_tokens.
Aus dem Cache gelesene Tokens: usage.prompt_tokens_details.cached_tokens.
In den Cache geschriebene Tokens: usage.prompt_tokens_details.cache_write_tokens.
Gesamte Ausgabe: usage.completion_tokens.

Nach den Abrechnungsregeln der API überschneiden sich die drei Eingabekategorien nicht. Die Ausgabe enthält bereits sowohl Reasoning- als auch Antworttokens.

Verwenden Sie Preise in derselben Währung je 1,000,000 Tokens:

uncached = prompt_tokens - cached_tokens - cache_write_tokens

token_cost = (
    uncached * miss_rate
    + cached_tokens * hit_rate
    + write_5m * write_5m_rate
    + write_1h * write_1h_rate
    + completion_tokens * output_rate
) / 1_000_000

write_5m + write_1h muss dabei cache_write_tokens ergeben. Entnehmen Sie die Preise den aktuellen Tarifen des Anbieters. Die Formel schätzt Token-Kosten; gleichen Sie das Ergebnis mit der Rechnung ab.

Wenn Sie keine Cache-Optionen angeben, nutzt Kimi automatisch 5m. Prüfen Sie bei längeren Pausen zwischen Anfragen die Einstellung "prompt_cache_options": {"mode": "implicit", "ttl": "1h"}.

Nach dem Cache-Leitfaden behält ein bestehender Eintrag seine ursprüngliche Lebensdauer. Das Senden von 1h verlängert einen aktiven 5m-Eintrag nicht. Erfassen Sie die Antwortheader Msh-Usage-Cache-Write-Tokens-5m und Msh-Usage-Cache-Write-Tokens-1h, um die tatsächlich geschriebenen Tokenmengen zu ermitteln.

Testen Sie wiederholte Anfragen mit demselben repräsentativen Präfix, also einem unveränderten Anfangsteil. Das Rechenbeispiel kann zu klein sein, um Caching sinnvoll zu prüfen. Unvollständige Blöcke werden nicht im Cache gespeichert. Halten Sie während des Tests die Reasoning-Stufe konstant: Ein Wechsel macht Treffer im Präfix-Cache ungültig.

Setzen Sie bei Streaming-Anwendungen außerdem stream_options.include_usage=true. Setzen Sie nach dem Streaming-Leitfaden die Fragmente für Reasoning, Antwort und Tool-Aufrufe zusammen. Verarbeiten Sie auch den letzten Block mit Verbrauchsdaten, selbst wenn sein choices-Array leer ist.

Legen Sie Regressionstests vor dem Wechsel fest

Stellen Sie einen kleinen Teil des Traffics erst um, wenn die neue Route Ihre vorhandenen Abnahmetests bestanden hat.

Verwenden Sie für jeden Vergleich dieselbe Repository-Revision, dieselben Prompts, Tool-Definitionen und Testbefehle. Prüfen Sie low, high und max in getrennten Sitzungen. Erfassen Sie die Qualität abgeschlossener Aufgaben, die Zeit bis zur vollständigen Antwort, Eingabetokens nach Kategorie, gesamte Ausgabetokens, Wiederholungsversuche und abgerechnete Kosten.

Nehmen Sie folgende Fälle in die Regressionstests auf:

Eine Aufgabe über mehrere Dialogschritte, die eine frühere Antwort des Assistenten benötigt.
Einen Tool-Aufruf, auf den eine weitere Modellantwort folgt.
Einen gestreamten Tool-Aufruf mit JSON-Argumenten, die in Fragmenten eintreffen.
Eine Aufgabe nahe der konfigurierten Generierungsgrenze.
Hintergrundaufgaben oder Subagenten, deren Konfiguration noch einen K2-Alias enthalten könnte.

Nutzen Sie die niedrigste Reasoning-Stufe, die Ihre Anforderungen an Qualität und Antwortzeit erfüllt. Wenn high bei einer wichtigen Aufgabe scheitert und max sie in Ihren Tests zuverlässig löst, behalten Sie für diese Aufgabenklasse max bei.

Behalten Sie eine Rückkehr zu K2 nur als Option, solange Ihr Konto noch Zugriff hat. Testen Sie vor dem angekündigten Abschaltzeitraum einen Ersatzweg, der nicht von K2 abhängt. Entfernen Sie alte K2-Kennungen aus geplanten Aufgaben, Routen für Wiederholungsversuche und Agentenkonfigurationen.