Mistral Vibe CLI

Ein [[providers]]-Block mit fünf Zeilen in .vibe/config.toml — api_base, api_key_env_var, api_style — richtet Vibe CLI auf Kunavo aus; der Schlüssel bleibt in einer Umgebungsvariablen statt in der Datei.

# ./.vibe/config.toml (project) or ~/.vibe/config.toml (user).
# "Project-level configuration takes precedence over user-level
# configuration", and the project file loads only in a trusted folder.
active_model = "sonnet-kunavo"

[[providers]]
name = "kunavo"
api_base = "https://api.kunavo.com/v1"
api_key_env_var = "KUNAVO_API_KEY"
api_style = "openai"
backend = "generic"

[[models]]
name = "claude-sonnet-5"
provider = "kunavo"
alias = "sonnet-kunavo"
# Optional, and documented on the api-keys-profiles page:
#   temperature   sampling temperature
#   input_price   indicative per-input cost, fed to --max-price
#   output_price  indicative per-output cost, fed to --max-price
# Take the two prices from the table further down this page if you want
# --max-price to mean anything.

# The key never goes in config.toml. api_key_env_var names the variable:
#   export KUNAVO_API_KEY="sk-kn-..."

Schritt für Schritt

1. Erstellen Sie unter /app/keys einen Schlüssel und kopieren Sie ihn — er wird nur einmal angezeigt.
2. Öffnen Sie ~/.vibe/config.toml (oder erstellen Sie ./.vibe/config.toml in dem Repository, auf das die Einstellung angewendet werden soll) und fügen Sie den obigen Block ein. Es gibt keinen Ablauf zum Hinzufügen eines Providers, den Sie per Klick durchlaufen müssen: Mistral beschreibt diese Datei als manuell zu bearbeiten, und /config sowie /model wechseln nur zwischen bereits vorhandenen Voreinstellungen.
3. Exportieren Sie die in api_key_env_var benannte Variable: export KUNAVO_API_KEY="sk-kn-...". Auf der Seite von Mistral zu Zugangsdaten wird ~/.vibe/.env als die Datei beschrieben, die die CLI beim Start für Zugangsdaten lädt. Im eigenen Beispiel für Drittanbieter wird für den Nicht-Mistral-Schlüssel ein Shell-export verwendet.
4. Fügen Sie für jede gewünschte ID eine Voreinstellung vom Typ [[models]] mit einem eigenen alias hinzu und setzen Sie active_model anschließend auf einen dieser Aliase. Der Alias gilt lokal: Er wird in /model aufgeführt; die tatsächlich an den Endpunkt übermittelte ID ist name.
5. Führen Sie vibe in einem vertrauenswürdigen Ordner aus und geben Sie dem Agenten eine Aufgabe, bei der eine Datei bearbeitet wird, keinen Gruß. Ein erster Durchlauf, der eine Datei liest und ändert, testet Tool-Aufrufe. Dort zeigen sich Fehlkonfigurationen des Providers üblicherweise zuerst.

Abgeglichen mit Konfigurationsseite für Mistral Vibe Code CLI am 21. September 2026. Einstellungen von Drittanbietern können sich ändern; wenn ein Feldname hier nicht mehr mit deiner Ansicht übereinstimmt, ist diese Seite maßgeblich, nicht diese hier.

Vor dem Debugging des Clients prüfen

Eine Anfrage klärt, ob der Fehler am Endpunkt, am Schlüssel oder an der Konfigurationsdatei liegt. Wenn diese Anfrage JSON zurückgibt, funktionieren dieselbe Basis-URL und derselbe Schlüssel in Mistral Vibe CLI.

# Settles whether a failure is the endpoint, the key, or the client.
curl -sS https://api.kunavo.com/v1/models \
  -H "Authorization: Bearer sk-kn-..."

Welche Modell-ID in das Feld gehört

Jedes Textmodell ist über eine Modell-ID erreichbar – die aktuelle Liste findest du unter GET /v1/models, den Katalog mit Preisen auf der Modellseite. Die Tarife sind USD pro 1 Mio. Token, Eingabe / Ausgabe.

Nicht der gesamte Datenverkehr läuft über diesen Provider

Das lässt sich aus einem Konfigurationsblock nicht erkennen und ist spezifisch für Vibe, nicht für Kunavo. In Version v2.25.5 leitet die CLI Hintergrund-„Utility“-Completions – kleine Aufrufe, die Konversationen und Worktrees benennen – an Mistrals eigenes mistral-vibe-cli-fast-Modell weiter, sobald ein Mistral-Provider verfügbar ist. In den ausgelieferten Standardeinstellungen ist immer einer konfiguriert, selbst wenn für die Sitzung Ihr Modell aktiv ist. Der Quellcode macht sowohl die Präferenz als auch die Rückfalloption deutlich: Ist kein Mistral-Provider verfügbar, wird für den Utility-Aufruf stattdessen das aktive Modell der Sitzung verwendet.

Wenn also jede Anfrage in der Sitzung über den von Ihnen konfigurierten Provider laufen soll, muss eine der folgenden Bedingungen erfüllt sein:

• MISTRAL_API_KEY ist nicht gesetzt, sodass die Zugangsdaten für das schnelle Modell nicht aufgelöst werden können und der Utility-Aufruf auf das Ausweichmodell zurückfällt; oder
• Der Alias des schnellen Modells wird über allowed_models ausgeschlossen. Das bewirkt dasselbe über die Zulassungsliste statt über den Schlüssel.

Der Smart Approve-Klassifikator geht noch weiter: Im Changelog-Eintrag zu 2.25.1 steht, dass er unabhängig vom aktiven Modell der Sitzung auf dem schnellen Mistral-Modell läuft. Daher verwendet eine Sitzung, die ausschließlich Kunavo nutzt, realistischerweise accept-edits oder plan statt Smart Approve. Nichts davon beeinträchtigt die obige Konfiguration. Es bedeutet lediglich, dass der Provider-Block Ihre Modellaufrufe abdeckt, nicht jedes Datenpaket, das die Binärdatei sendet.

Die anderen Werte für api_style

In der Dokumentation wird ein Beispielwert für api_style aufgeführt: "openai". Der Quellcode von v2.25.5 enthält vier weitere Werte – "anthropic", "openai-responses", "reasoning" und "vertex-anthropic" – in einem einfachen Dictionary ohne Validierung. Deshalb wird ein Tippfehler erst bei der Anfrage sichtbar und nicht beim Laden der Datei. Betrachten Sie diese Werte als im Quellcode bestätigt, aber undokumentiert. Beachten Sie bei einem Versuch mit dem Anthropic-Wert außerdem folgende Stolperfalle: Der Endpunkt des zugehörigen Adapters ist /v1/messages. api_base muss daher der reine Ursprung https://api.kunavo.com ohne /v1 sein – das Gegenteil des oben gezeigten Blocks. Kunavo beantwortet /v1/messages für IDs, die mit claude- beginnen. Auf dieser Seite wird der Stil openai gezeigt, da Mistral genau diesen dokumentiert.