Documentation

Mistral Vibe CLI

Vibe CLI se connecte à un point de terminaison tiers au moyen d’un bloc TOML à modifier manuellement, et la documentation de Mistral utilise une passerelle comme exemple détaillé. Cinq lignes sous [[providers]], et l’agent utilise Claude ou GPT avec votre clé.

Un bloc [[providers]] de cinq lignes dans .vibe/config.toml — api_base, api_key_env_var, api_style — dirige Vibe CLI vers Kunavo, la clé restant dans une variable d’environnement plutôt que dans le fichier.

.vibe/config.toml

# ./.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-..."

api_baseConservez le /v1. La documentation de référence de Mistral décrit ce champ uniquement comme « URL de base de l’API du fournisseur » et n’énonce aucune règle sur le suffixe. Pour trancher, il faut regarder la valeur utilisée dans son propre exemple détaillé, sur les deux pages de documentation : api_base = "https://openrouter.ai/api/v1", puis la raison sous-jacente dans le code source de la v2.25.5 : l’adaptateur openai ajoute /chat/completions à api_base et rien d’autre, et le fournisseur Mistral intégré à l’interface CLI utilise une URL de base /v1 pour la même raison. Supprimez le suffixe et vous interrogerez /chat/completions à la racine, ce qui donnera une erreur 404, et non une erreur d’authentification.

Cette configuration a été relevée dans la documentation de Mistral et le code source de Vibe à la date indiquée ci-dessous. Kunavo n’a pas exécuté Vibe CLI sur son point de terminaison — ni session, ni échange en flux continu, ni aller-retour d’appel d’outil. Une page de configuration publiée n’est pas un test en conditions réelles, et rien ici ne doit être interprété comme tel. Le curl ci-dessous est le point que vous pouvez vérifier en dix secondes ; pour tout ce que le client fait ensuite, vous devrez faire un premier essai avec Vibe.

Kunavo ne sert aucun modèle d’embeddings, de synthèse vocale ou de transcription vocale. Ce point de terminaison répond donc uniquement aux requêtes de complétion de chat : le bloc fournisseur configuré ici prend en charge les échanges avec le modèle, et rien d’autre.

Voici un comportement qui joue en votre faveur, et dont il est utile de comprendre la raison. La route OpenAI de Vibe construit chaque charge utile avec un champ temperature, alors que plusieurs identifiants Claude — notamment claude-sonnet-5 et claude-opus-5 — répondent en amont à l’ensemble des trois paramètres 400. Kunavo supprime ces paramètres avant la transmission, précisément pour les identifiants qui les rejettent. Le champ systématique du client ne provoque donc pas de rejet. La clé temperature d’un préréglage [[models]] est donc sans risque ici, mais elle n’a également aucun effet sur ces identifiants.

Pas encore de clé ? Créez un compte Kunavo, créez une clé (elle commence par sk-kn-) et ajoutez un crédit à partir de 10 $ — les appels sont payés sur ce solde et les appels échoués ne sont pas facturés. Le tableau de bord s’ouvre ensuite sur la configuration Mistral Vibe CLI.

Étape par étape

Créez une clé sur /app/keys et copiez-la — elle n’est affichée qu’une seule fois.
Ouvrez ~/.vibe/config.toml (ou créez ./.vibe/config.toml dans le dépôt auquel vous souhaitez appliquer cette configuration) et collez le bloc ci-dessus. Aucune procédure d’ajout de fournisseur n’est à sélectionner : Mistral indique que ce fichier doit être modifié manuellement, et /config et /model permettent uniquement de basculer entre des préréglages déjà existants.
Exportez la variable indiquée dans api_key_env_var — export KUNAVO_API_KEY="sk-kn-...". La page de Mistral sur les identifiants précise que le fichier ~/.vibe/.env est chargé au démarrage de l’interface CLI, et son exemple tiers utilise une commande shell export pour la clé qui n’est pas celle de Mistral.
Ajoutez un préréglage [[models]] pour chaque identifiant souhaité, chacun avec son propre alias, puis définissez active_model sur l’un de ces alias. L’alias est local : c’est le nom affiché par /model, tandis que name est l’identifiant effectivement transmis au point de terminaison.
Exécutez vibe dans un dossier de confiance et donnez-lui une tâche qui modifie un fichier, pas une salutation. Un premier échange qui lit et modifie un fichier met à l’épreuve l’appel d’outils, là où une configuration incorrecte du fournisseur se manifeste généralement.

Vérifié avec Page de configuration de Mistral Vibe Code CLI le 21 septembre 2026. Les paramètres tiers évoluent ; si le nom d’un champ ne correspond plus à ce que vous voyez ici, cette page fait autorité, pas celle-ci.

Voici la version courte. Le guide complet — choix du modèle, coût d’une session réelle et modes d’échec — se trouve dans la comparaison entre Vibe CLI et Claude Code.

Vérifiez avant de déboguer le client

Une requête suffit à déterminer si l’échec vient de l’endpoint, de la clé ou du fichier de configuration. Si cette requête renvoie du JSON, la même URL de base et la même clé fonctionnent dans 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-..."

Quel identifiant de modèle saisir dans le champ

Tous les modèles textuels sont accessibles sous forme d’identifiant de modèle — la liste à jour se trouve sur GET /v1/models, et le catalogue avec les prix sur la page des modèles. Les tarifs sont en USD par million de tokens, entrée / sortie.

Identifiant du modèle	Entrée / sortie sur Kunavo	Où cela s’intègre dans Mistral Vibe CLI
`claude-sonnet-5`	$1.40 / $7.00	l’alias de travail — celui auquel active_model fait référence la plupart du temps
`claude-opus-5`	$3.50 / $17.50	un second préréglage pour le mode planification, où un plan erroné coûte cher
`claude-haiku-4-5`	$0.70 / $3.50	des échanges à bas coût et un tri rapide des fichiers, avec un alias distinct à sélectionner
`gpt-5-6-sol`	$2.00 / $12.00	une autre famille derrière le même bloc fournisseur, avec la même clé

La facturation se fait au token à partir d’un solde prépayé, sans frais mensuels — consultez la facturation. Avec un contexte répété — ce qu’envoient la plupart des éditeurs et clients de chat — la mise en cache des prompts influe davantage sur la facture que le choix du modèle.

Tout votre trafic ne passe pas par ce fournisseur

C’est un point qu’un bloc de configuration ne peut pas vous révéler, et qui concerne Vibe plutôt que Kunavo. Dans la v2.25.5, l’interface CLI achemine les complétions d’« utilité » en arrière-plan — les petits appels qui nomment les conversations et les espaces de travail Git — vers le modèle mistral-vibe-cli-fast de Mistral dès qu’un fournisseur Mistral est utilisable. Les valeurs par défaut fournies en configurent toujours un, même lorsque le modèle actif de la session est le vôtre. Le code source est explicite sur la préférence et le mécanisme de repli : lorsqu’aucun fournisseur Mistral n’est utilisable, l’appel utilitaire est envoyé au modèle actif de la session.

Ainsi, si vous voulez que chaque requête de la session passe par le fournisseur que vous avez configuré, l’une de ces conditions doit être remplie :

MISTRAL_API_KEY n’est pas défini, de sorte que l’identifiant du modèle rapide ne résout pas ses identifiants d’accès et que l’appel utilitaire utilise le fournisseur de repli ; ou
l’alias du modèle rapide est exclu par allowed_models, ce qui produit le même effet au moyen de la liste d’autorisation plutôt que de la clé.

Le classificateur Smart Approve va plus loin : son entrée dans le journal des modifications de la version 2.25.1 indique qu’il utilise le modèle Mistral rapide, quel que soit le modèle actif de la session. Une session limitée à Kunavo fonctionne donc plus réalistement en mode accept-edits ou plan qu’en mode Smart Approve. Cela ne remet pas en cause la configuration ci-dessus : le bloc fournisseur concerne les échanges avec votre modèle, et non tous les paquets envoyés par le binaire.

Les autres valeurs de api_style

La documentation indique une valeur pour api_style et la présente comme exemple : "openai". Le code source de la v2.25.5 en contient quatre autres — "anthropic", "openai-responses", "reasoning" et "vertex-anthropic" — dans un simple dictionnaire sans validation. C’est pourquoi une faute de frappe ne se manifeste qu’au moment de la requête, et non au chargement du fichier. Considérez ces valeurs comme vérifiées dans le code source, mais non documentées. Attention à un piège si vous essayez la valeur Anthropic : son adaptateur utilise le point de terminaison /v1/messages. Il faut donc définir api_base sur l’origine seule, https://api.kunavo.com, sans /v1 — c’est l’inverse du bloc ci-dessus. Kunavo répond bien à /v1/messages pour les identifiants commençant par claude-. Cette page montre le style openai, car c’est celui que Mistral documente.

Questions fréquentes

Comment ajouter un fournisseur personnalisé à Mistral Vibe CLI ?

Manuellement, dans config.toml : il n’existe pas d’interface pour ajouter un fournisseur. La page de configuration de Mistral documente ./.vibe/config.toml dans le répertoire de travail et ~/.vibe/config.toml dans le répertoire personnel ; le fichier du projet est prioritaire. Son exemple détaillé comprend une table [[providers]] avec les champs name, api_base, api_key_env_var, api_style et backend, ainsi qu’une table [[models]] avec les champs name, provider et alias, et un active_model qui pointe vers cet alias. La clé elle-même ne figure jamais dans le fichier : api_key_env_var désigne la variable d’environnement qui la contient.

Faut-il terminer api_base par /v1 dans Vibe CLI ?

Pour api_style « openai », oui. La référence de configuration de Mistral décrit api_base uniquement comme l’URL de base de l’API du fournisseur et ne précise aucune règle concernant le suffixe. Cependant, l’exemple détaillé de ses deux pages utilise une valeur qui se termine par /v1, et le code source de v2.25.5 l’explique : l’adaptateur de style OpenAI ajoute /chat/completions à api_base, sans rien ajouter d’autre, et le fournisseur Mistral intégré à la CLI utilise par défaut une URL de base en /v1. Pour Kunavo, la valeur est donc https://api.kunavo.com/v1. Si vous omettez le suffixe, vous obtenez une erreur 404, pas un échec d’authentification. Le style « anthropic », qui n’est pas documenté, est le cas inverse : son point de terminaison est /v1/messages ; api_base ne doit donc pas inclure /v1.

Mistral Vibe CLI peut-il exécuter des modèles Claude ?

Oui, au moyen d’un préréglage de fournisseur, plutôt qu’en activant une option. api_style désigne le protocole de communication, pas le fournisseur, et le champ name du préréglage de modèle est transmis au point de terminaison tel quel. Un identifiant Claude est donc résolu au point de terminaison que vous avez configuré, et non dans la CLI. Mistral illustre cette méthode dans sa propre documentation à l’aide d’une passerelle tierce ; il s’agit donc d’une méthode documentée, et non d’un contournement.

Pourquoi Vibe CLI continue-t-il d’appeler Mistral après la configuration de mon propre fournisseur ?

Parce que les complétions utilitaires en arrière-plan sont acheminées séparément. Dans la version v2.25.5, la CLI privilégie le modèle mistral-vibe-cli-fast de Mistral pour les petits appels en arrière-plan — nommer les conversations et les worktrees — dès qu’un fournisseur Mistral est utilisable. Les paramètres par défaut livrés avec la CLI en configurent toujours un, même si la session utilise un autre modèle actif. La CLI revient au modèle actif lorsqu’aucun fournisseur Mistral n’est utilisable, ce qui signifie en pratique que MISTRAL_API_KEY n’est pas définie ou que cet alias est exclu par allowed_models. Le classificateur Smart Approve est encore plus strict : son journal des modifications indique qu’il utilise le modèle Mistral rapide, quel que soit le modèle actif de la session.

Kunavo a-t-il testé Mistral Vibe CLI ?

Non. Les vérifications effectuées le 21 septembre 2026 portaient sur la documentation de Mistral : les noms et l’ordre des champs, ainsi que la question de /v1, en sont tirés. Le raisonnement sur l’URL de base a été confirmé à partir du code source de v2.25.5 du paquet mistral-vibe. Kunavo n’a pas exécuté de session Vibe sur son point de terminaison et ne prétend rien quant au streaming, aux échanges avec les outils ou au comportement du client pendant une tâche longue. Vous pouvez vérifier le point de terminaison et la clé séparément à l’aide de la commande curl présentée sur cette page ; le reste dépend du client.

Où Vibe CLI récupère-t-il la clé API ?

Dans la variable d’environnement indiquée par api_key_env_var — pour un bloc de fournisseur Kunavo, vous pouvez lui donner le nom de votre choix, par exemple KUNAVO_API_KEY. La page de Mistral sur les identifiants documente, dans l’ordre de priorité, trois sources pour sa propre clé : l’assistant de configuration interactif, qui écrit dans ~/.vibe/.env ; une variable d’environnement exportée, prioritaire sur ce fichier ; et la modification directe de ~/.vibe/.env, que la CLI charge au démarrage. L’exemple de fournisseur tiers utilise une commande export dans le shell. La même page précise que .env ne contient que les identifiants et que la configuration générale se trouve dans config.toml.