Claude Code mit Kimi K3 verbinden: Anleitung 2026

Claude Code kann mit Kimi K3 verbunden werden. Für eine funktionierende Einrichtung benötigen Sie den Anthropic-kompatiblen Kimi-Code-Endpunkt, einen dafür gültigen API-Schlüssel und eine freigeschaltete Modell-ID. Die allgemeine Kimi-API darf nicht einfach mit der Kimi-Code-Konfiguration vermischt werden. Vor dem produktiven Einsatz sollten Sie außerdem Authentifizierung, Dateizugriff, Tool-Aufrufe, Kontextkomprimierung und die Kosten- beziehungsweise Kontenzuordnung prüfen.

Dieser Leitfaden ist für Entwickler gedacht, die Kimi K3 in Claude Code testen möchten, für Administratoren eines Remote-Teams sowie für Anwender, die bei 401, „Model not found“ oder einem Wechsel auf langen Kontext festhängen.

Zuletzt aktualisiert am 01.08.2026; die Angaben wurden anhand der offiziellen Kimi-Code- und Claude-Code-Dokumentation überprüft.

Die Schnittstellen sauber trennen

Der wichtigste Schritt erfolgt vor der ersten Umgebungsvariable: Sie müssen unterscheiden, ob der verwendete Zugang zur allgemeinen Kimi-Open-Platform-API oder zu Kimi Code gehört.

Die allgemeine Kimi-API ist für eigene Anwendungen und klassische Modellaufrufe vorgesehen. Kimi Code stellt dagegen einen speziellen Zugang für Programmierwerkzeuge bereit und bietet eine Anthropic-kompatible Schnittstelle, die Claude Code erwartet. Für Claude Code muss daher der folgende Base-URL verwendet werden:

export ANTHROPIC_BASE_URL="https://api.kimi.com/coding/"

Die offizielle Kimi-Code-Anleitung für Claude Code unterscheidet diesen Anthropic-kompatiblen Pfad vom OpenAI-kompatiblen Endpunkt unter /coding/v1. Ein vollständiger Messages- oder Chat-Completions-Pfad gehört nicht in die Variable. Claude Code ergänzt die nachgelagerte Route selbst.

Ein typischer Fehlversuch sieht so aus: Ein Entwickler erzeugt einen Schlüssel in der allgemeinen API-Konsole, trägt anschließend einen OpenAI-kompatiblen Endpunkt in ANTHROPIC_BASE_URL ein und verwendet eine Modellbezeichnung wie k3, ohne deren Freischaltung zu prüfen. Claude Code startet zwar, aber der erste Agent-Aufruf endet mit 401, 403, 404 oder einer irreführenden Modellfehlermeldung.

Das bedeutet nicht automatisch, dass Claude Code und Kimi K3 inkompatibel sind. Häufig stimmen lediglich Zugang, Protokoll und Modellberechtigung nicht überein.

Vor dem Test sollten vier Voraussetzungen getrennt geprüft werden:

Claude Code ist installiert und lässt sich mit claude doctor prüfen.
Der Schlüssel stammt aus dem Kimi-Code-Zugang und ist für die gewünschte Modellfamilie freigeschaltet.
Das Geheimnis wird nicht in ein Repository, eine gemeinsam genutzte Shell-Konfiguration oder einen Chat kopiert.
Der erste Test erfolgt in einem leeren oder eigens dafür angelegten Verzeichnis.

Die offizielle Claude-Code-Einrichtung beschreibt Installation, Authentifizierung und Diagnosebefehle.

Achtung: Ein API-Schlüssel aus der allgemeinen Kimi-Plattform sollte nicht automatisch als Kimi-Code-Schlüssel betrachtet werden. Prüfen Sie zuerst die Herkunft des Schlüssels und den vorgesehenen Endpunkt, bevor Sie Claude Code debuggen.

Vorbereitung des isolierten Testprojekts

Ein unabhängiges Testverzeichnis verhindert, dass ein falsch konfigurierter Agent versehentlich Produktionsdateien verändert. Gleichzeitig lässt sich damit feststellen, ob Dateilesen und einfache Shell-Aufrufe grundsätzlich funktionieren.

claude doctor
mkdir -p ~/claude-kimi-test
cd ~/claude-kimi-test
printf '%s\n' 'Prüfdatei für Claude Code mit Kimi K3.' > test.txt

Das Verzeichnis sollte zunächst keine vertraulichen Quelltexte, privaten Schlüssel oder produktiven Konfigurationsdateien enthalten. Für eine reproduzierbare Prüfung können Sie anschließend ein lokales Git-Repository anlegen:

git init
git add test.txt
git commit -m "Initialer Kimi-Code-Test"

Damit ist später sichtbar, ob Claude Code tatsächlich nur die erwartete Datei verändert hat.

Die ersten Umgebungsvariablen

Für den ersten Versuch sollten die Variablen nur für die aktuelle Terminal-Sitzung gesetzt werden. Die Konfiguration bleibt dadurch leicht rücksetzbar und vermischt sich nicht dauerhaft mit anderen API-Projekten.

export ANTHROPIC_BASE_URL="https://api.kimi.com/coding/"
export ANTHROPIC_API_KEY="KIMI_API_KEY_HIER_EINSETZEN"
export ANTHROPIC_MODEL="k3"

Der Platzhalter muss durch den eigenen Kimi-Code-Schlüssel ersetzt werden. Ein echter Schlüssel darf weder im Artikel, in einem Commit noch in einem Support-Screenshot erscheinen.

Falls Ihre Claude-Code-Version eine Authentifizierung über ANTHROPIC_AUTH_TOKEN vorsieht, können Sie den dafür dokumentierten Mechanismus verwenden. Die Dokumentation zur Gateway-Konfiguration von Claude Code erklärt die relevanten Variablen und ihre Verwendung bei kompatiblen Zugängen.

Für eine dauerhafte lokale Konfiguration ist ein sicherer Schlüsselbund oder ein Secret-Manager vorzuziehen. Eine .env-Datei kann funktionieren, darf aber nicht in das Repository gelangen:

printf '%s\n' '.env' '.claude-local' >> .gitignore

Eine Eintragung in ~/.zshrc ist zwar bequem, wird aber bei Bildschirmfreigaben, Gerätewechseln oder gemeinsam genutzten Benutzerprofilen schnell zu einem Sicherheitsrisiko. Für Teams sind getrennte, widerrufbare und möglichst kurzlebige Schlüssel die bessere Grundlage.

Modell-ID und Standardprofile

Claude Code kann neben dem Hauptmodell weitere Modellpfade für Unteragenten oder unterschiedliche Aufgaben verwenden. Deshalb reicht es nicht immer aus, ausschließlich ANTHROPIC_MODEL zu setzen.

Wenn die aktuelle Kimi-Code-Modellübersicht die Modell-ID k3 für den eigenen Zugang bestätigt, kann eine einheitliche Testkonfiguration so aussehen:

export ANTHROPIC_MODEL="k3"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"

Die offizielle Kimi-Code-Dokumentation führt die verfügbaren Modelle und Zugangsvarianten. Modellnamen dürfen nicht geraten werden. Wenn ein Konto nur eine bestimmte Modell-ID oder ein bestimmtes Kontextprofil unterstützt, muss genau diese Schreibweise verwendet werden.

Nach dem Setzen der Variablen starten Sie Claude Code:

claude

Im interaktiven Modus können Sie anschließend den Status prüfen:

/status

Die Darstellung des Modells in Claude Code kann dabei von der tatsächlich verwendeten Modellbezeichnung abweichen. Für die Prüfung sind daher Base-URL, Antwortverhalten und Fehlertext wichtiger als ein sichtbarer Alias im Terminal.

Konfigurationsvergleich für Claude Code

Die folgende Übersicht trennt die wichtigsten Optionen und zeigt, welche Variante für Claude Code geeignet ist.

Option	Zweck	Eignung für Claude Code	Typisches Risiko	Bewertung
Allgemeiner Kimi-API-Endpunkt	Eigene API-Anwendungen	Nein, nicht als Standardweg	Falsches Protokoll oder falscher Schlüssel	Nicht verwenden
`https://api.kimi.com/coding/v1`	OpenAI-kompatible Werkzeuge	Nur für Clients mit OpenAI-Format	Claude Code erwartet Anthropic-Kompatibilität	Für Claude Code vermeiden
`https://api.kimi.com/coding/`	Anthropic-kompatible Werkzeuge	Ja	Zugang muss zu Kimi Code gehören	Empfohlen
`k3`	Kimi-K3-Standardprofil	Ja, sofern freigeschaltet	Modell-ID kann kontoabhängig sein	Gute Testwahl
`k3-256k`	Kimi K3 mit kleinerem Kontextprofil	Ja, sofern freigeschaltet	Alte Sitzung muss vor dem Wechsel bereinigt werden	Für Routineprojekte
`k3[1m]`	Erweitertes Kontextprofil in Claude Code	Nur nach Bestätigung	Hoher Kontextbedarf und mögliche Komprimierung	Für große Repositories

Die Tabelle ist eine Entscheidungshilfe, ersetzt aber keine Prüfung im eigenen Kimi-Code-Konto. Ein korrekter Base-URL kann mit einer nicht freigeschalteten Modell-ID kombiniert werden.

Der erste risikoarme Request

Der erste Request sollte drei Dinge prüfen: Authentifizierung, Antwortformat und Zugriff auf eine harmlose Datei. Verwenden Sie im Testverzeichnis folgende Anweisung:

Lesen Sie test.txt. Geben Sie den exakten Dateiinhalt aus und nennen Sie anschließend das verwendete Modell, sofern diese Information verfügbar ist. Ändern Sie keine Dateien und führen Sie keine Befehle aus.

Danach können Sie einen nicht-interaktiven Aufruf testen:

claude -p "Lesen Sie test.txt und fassen Sie den Inhalt in einem Satz zusammen. Ändern Sie keine Dateien."

Für die Diagnose ist ein ausführlicher Aufruf sinnvoll:

claude -p --verbose "Antworten Sie mit dem Wort OK und ändern Sie keine Dateien."

Die CLI-Referenz von Claude Code beschreibt unter anderem nicht-interaktive Aufrufe, ausführliche Logs und strukturierte Ausgabeformate.

Notieren Sie bei jedem fehlgeschlagenen Test den Statuscode, den vollständigen Fehlertext, die verwendete Modell-ID und den Zeitpunkt. Der API-Schlüssel selbst gehört nicht in das Protokoll.

Fehlerdiagnose nach Statuscode

Die Fehlerbehebung sollte nicht aus einer langen Liste zufälliger Shell-Befehle bestehen. Ordnen Sie das Problem zuerst einer Fehlerklasse zu.

Beobachtung	Wahrscheinliche Ursache	Sinnvolle Reihenfolge
`401 Unauthorized`	Schlüssel fehlt, ist falsch oder gehört zum falschen Zugang	Variable prüfen, Schlüsselstatus kontrollieren, bei Bedarf neuen Kimi-Code-Schlüssel erzeugen
`403 Forbidden`	Konto oder Modell besitzt keine Berechtigung	Kimi-Code-Zugang und Modellfreigabe prüfen
`404` oder „Model not found“	Modell-ID falsch geschrieben oder nicht verfügbar	Modellliste öffnen und Schreibweise exakt übernehmen
Fehler wegen Route oder URL	OpenAI-Pfad, vollständiger API-Pfad oder falscher Schrägstrich	Anthropic-Base-URL ohne zusätzlichen Unterpfad setzen
Antwort funktioniert, Dateizugriff scheitert	Projektfreigabe oder Berechtigungsmodus blockiert	Testordner autorisieren und ohne produktive Dateien wiederholen
Sitzung bricht bei langem Verlauf ab	Kontextlimit oder automatische Komprimierung	Sitzung zusammenfassen, komprimieren und neu starten

Die Kimi-Code-Fehlerreferenz ist bei der Einordnung hilfreich, weil Drittanbieter-Clients API-Fehler teilweise anders darstellen können.

Bei einem Fehler „Kimi K3 Modell nicht gefunden“ sollten Sie deshalb nicht sofort den Base-URL wechseln. Prüfen Sie zuerst:

Ist die Modell-ID exakt geschrieben?
Ist das Modell für den verwendeten Kimi-Code-Zugang freigeschaltet?
Wurde die Variable vor dem Start der Claude-Code-Sitzung gesetzt?
Gibt es eine zweite Variable, die das Modell für Unteragenten überschreibt?
Verwendet die aktuelle Claude-Code-Version die erwartete Konfigurationsmethode?

Der Agent-Test in der ersten Stunde

Eine erfolgreiche Textantwort beweist noch nicht, dass der Agent-Workflow funktioniert. Claude Code muss Dateien lesen, Änderungen vorschlagen, lokale Befehle ausführen und gegebenenfalls Werkzeuge aufrufen können.

Prüfen Sie diese Funktionen nacheinander:

Mehrere Dateien lesen: Erstellen Sie zwei Testdateien mit unterschiedlichem Inhalt und lassen Sie beide zusammenfassen.
Änderung planen: Fordern Sie einen Patch an, ohne die Änderung automatisch zu übernehmen.
Kleine Datei ändern: Erlauben Sie eine klar begrenzte Änderung.
Ungefährlichen Befehl ausführen: Verwenden Sie beispielsweise pwd oder eine reine Verzeichnisabfrage.
Diff kontrollieren: Prüfen Sie mit git diff, ob nur die erwartete Datei geändert wurde.
Werkzeugaufruf separat testen: Verwenden Sie zunächst keinen produktiven MCP-Server und keine echten Zugangsdaten.

Beispiel für die Vorbereitung:

printf '%s\n' 'alpha' > a.txt
printf '%s\n' 'beta' > b.txt
git add .
git commit -m "Dateitest"
claude

Verwenden Sie anschließend:

Lesen Sie a.txt und b.txt, erklären Sie den Unterschied und schlagen Sie eine Änderung an a.txt vor. Führen Sie die Änderung erst nach meiner Bestätigung aus.

Drei Grenzen werden in der Praxis besonders häufig übersehen:

Berechtigungen: Ein Modell kann korrekt antworten, während Claude Code den Datei- oder Shell-Zugriff blockiert.
Kontextkomprimierung: Bei langen Sitzungen werden frühere Inhalte möglicherweise zusammengefasst. Die wichtigsten Entscheidungen können erhalten bleiben, aber nicht jede ursprüngliche Tool-Ausgabe.
Werkzeugkompatibilität: Eine normale Textantwort kann funktionieren, obwohl ein bestimmter Tool-Aufruf oder Nachrichtenblock nicht unterstützt wird.

Erfahrung aus der Einrichtung: Wenn Dateilesen funktioniert, ein Shell- oder MCP-Aufruf aber scheitert, sollte zuerst die lokale Berechtigung geprüft werden. Ein Wechsel der Modell-ID behebt keinen gesperrten Dateizugriff.

Lange Kontexte und alte Sitzungen

Für große Repositories kann ein erweitertes Kontextprofil sinnvoll sein. Kimi Code dokumentiert für Claude Code die Schreibweise k3[1m], wenn das eigene Konto diesen Kontextmodus unterstützt. Diese Schreibweise darf nicht ungeprüft als allgemeine Modell-ID für jeden Client betrachtet werden.

Ein mögliches Muster lautet:

export ANTHROPIC_BASE_URL="https://api.kimi.com/coding/"
export ANTHROPIC_API_KEY="KIMI_API_KEY_HIER_EINSETZEN"
export ANTHROPIC_MODEL="k3[1m]"
export ANTHROPIC_DEFAULT_OPUS_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_SONNET_MODEL="$ANTHROPIC_MODEL"
export ANTHROPIC_DEFAULT_HAIKU_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"
export CLAUDE_CODE_EFFORT_LEVEL="high"

Wenn das Konto nur ein kleineres Kontextprofil unterstützt, kann stattdessen beispielsweise k3-256k verwendet werden:

export ANTHROPIC_MODEL="k3-256k"
export CLAUDE_CODE_SUBAGENT_MODEL="$ANTHROPIC_MODEL"

Vor dem Wechsel sollten Sie eine alte Sitzung nicht blind fortsetzen. Empfehlenswert ist diese Übergabe:

Offene Aufgaben, Annahmen und geänderte Dateien zusammenfassen lassen.
Die Zusammenfassung als handoff.md speichern.
Die Sitzung mit /compact komprimieren, sofern dieser Befehl in der installierten Version verfügbar ist.
Claude Code beenden.
Die neuen Modell- und Kontextvariablen setzen.
Eine neue Sitzung starten.
handoff.md ausdrücklich als Übergabedokument laden.

Ein Neustart ist besonders sinnvoll, wenn der alte Verlauf Eingabetypen, Tool-Aufrufe oder Nachrichtenblöcke enthält, die das neue Kontextprofil nicht sicher übernehmen kann. Ein vorhandener Verlauf kann technisch fortgesetzt werden, aber ein Modellwechsel ist dadurch nicht automatisch formatkompatibel.

Abnahme für eine Teamumgebung

Für einen einzelnen Entwickler genügt zunächst ein temporärer Testschlüssel. Vor der Freigabe für ein Remote-Team müssen jedoch Kosten, Zugriff und Rückfallverhalten dokumentiert werden.

Verwenden Sie diese Abnahmeliste:

Jeder Entwickler besitzt einen eigenen Schlüssel oder einen eindeutig zugeordneten Team-Schlüssel.
Schlüssel sind widerrufbar und werden nicht in Git, Chatprotokolle oder Screenshots übernommen.
Die Abrechnung des Kimi-Code-Zugangs ist von einer möglichen Anthropic-API-Abrechnung getrennt dokumentiert.
Die verwendete Modell-ID steht in einer versionierten, geheimnisfreien Konfigurationsvorlage.
Ein freigegebenes Rückfallmodell ist definiert.
Logs enthalten Statuscode, Projektkennung, Zeit und Modell-ID, aber keine Schlüssel oder vertraulichen Quelltexte.
Das Testprojekt ist von Produktionsprojekten getrennt.
Lange Sitzungen werden vor einem Modell- oder Kontextwechsel über ein Übergabedokument beendet.
Lokale Mac-Benutzer, Projektordner und Terminalrechte folgen dem Prinzip der geringsten Rechte.
Bei einem Remote-Arbeitsplatz sind Zugriff, Löschung und Schlüsselrotation dokumentiert.

Für die technische Umgebung sollten Sie neben der Claude-Code-Konfiguration auch Datenschutz und Zugriffsschutz auf dem Mac berücksichtigen. Wenn mehrere Personen dieselbe Entwicklungsumgebung verwenden, ist außerdem eine Cloud-Mac-Umgebung für Remote-Entwicklung zu prüfen.

Lokaler Rechner oder zentraler Mac

Die lokale Einrichtung ist für einen kurzen Kimi-K3-Test meist die schnellste Variante. Für längere Agent-Sitzungen und mehrere Teammitglieder entstehen jedoch konkrete Nachteile: persönliche Shell-Variablen werden leicht mit anderen Projekten vermischt, ein Laptop ist nicht immer erreichbar, und bei einem Gerätewechsel fehlen oft reproduzierbare Versions- und Schlüsselprotokolle.

Ein zentral vorbereiteter Mac kann diese Punkte besser trennen, wenn Benutzerrechte, Projektordner, Geheimnisse und Löschregeln sauber dokumentiert sind. Das ist keine pauschale Empfehlung für jede Nutzung. Wer nur gelegentlich kleine Dateien analysiert, benötigt gewöhnlich keine dauerhaft laufende Umgebung. Wer Claude Code dagegen über längere Sitzungen, in einem Remote-Team oder mit wiederkehrenden Agent-Aufgaben verwendet, profitiert eher von einer reproduzierbaren Mac-Konfiguration als von individuellen Terminal-Anpassungen.

Nach der lokalen Prüfung kann Mac-Support und Einrichtungshilfe als nächster Schritt dienen. Die Verbindung sollte jedoch erst dann in eine gemeinsam genutzte Umgebung übernommen werden, wenn Base-URL, API-Schlüssel, Modell-ID, Tool-Aufrufe und Kontextübergabe getrennt getestet wurden.