Ajouter des providers personnalisés

Mise à jour du 2 novembre 2026 — Devstral. Devstral 2 (devstral-2512) a atteint sa date de retrait le 31 juillet 2026, et Devstral Small 2 le 31 mars 2026 : un appel à ces modèles n’est plus garanti. La table officielle les renvoie vers Mistral Medium 3.5, lui-même déprécié au profit de Mistral Large 4. Codestral (codestral-2508) reste en disponibilité générale pour la complétion de code. Vérifiez dans la table des modèles vers quoi pointent les alias en -latest avant de reprendre ces exemples.

Pourquoi utiliser des providers tiers ?

Par défaut, Vibe communique avec l’API Mistral. Mais l’architecture de l’outil est conçue pour être agnostique : vous pouvez ajouter n’importe quel provider compatible avec le format d’API OpenAI. Cela répond à quatre besoins bien réels. Vous pouvez accéder à des modèles d’autres fournisseurs — Claude, GPT, Llama —, passer par un relais comme OpenRouter pour comparer plusieurs modèles sur la même tâche, pointer vers une instance locale (Ollama, vLLM) quand le code ne doit pas sortir de la machine, ou encore basculer d’un provider à l’autre selon la nature du travail.

Le cas typique est celui d’une équipe qui travaille au quotidien avec Devstral 2 sur l’API Mistral, mais qui bascule sur une instance locale dès qu’il s’agit du dépôt d’un client soumis à des contraintes de confidentialité.

Anatomie d’un provider

Un provider se déclare dans config.toml avec la directive [[providers]] :

[[providers]]
name = "openrouter"
api_base = "https://openrouter.ai/api/v1"
api_key_env_var = "OPENROUTER_API_KEY"
api_style = "openai"
backend = "generic"

Chaque champ a un rôle précis :

• name — Identifiant unique du provider (utilisé pour référencer les modèles)
• api_base — URL de base de l’API (le endpoint /chat/completions sera ajouté automatiquement)
• api_key_env_var — Nom de la variable d’environnement contenant la clé API
• api_style — Format de l’API. Utilisez "openai" pour tout provider compatible OpenAI
• backend — Type de backend. "generic" fonctionne pour la plupart des cas

Le piège classique concerne api_base : comme Vibe ajoute lui-même /chat/completions, une URL qui inclut déjà ce suffixe produira une adresse invalide et une erreur réseau difficile à interpréter.

Exemples de providers courants

Les valeurs à renseigner pour les services les plus répandus sont les suivantes. Les deux providers locaux n’ont pas de variable de clé, puisqu’ils n’exigent aucune authentification.

Déclarer un modèle sur un provider

Déclarer le provider ne suffit pas : il faut ensuite lui rattacher les modèles que vous comptez utiliser.

[[models]]
name = "mistralai/devstral-2512:free"
provider = "openrouter"
alias = "devstral-openrouter"
temperature = 0.2

Le champ name reprend l’identifiant du modèle tel que le provider le connaît, au caractère près. provider doit correspondre au name d’un provider déclaré plus haut, sans quoi Vibe ne saura pas où envoyer la requête. alias définit un nom raccourci pour l’utiliser dans Vibe, et temperature règle la créativité, de 0.0 pour un comportement déterministe à 1.0 pour un modèle plus inventif. Pour du code, une valeur basse comme celle de l’exemple donne des résultats bien plus stables.

Pour activer ce modèle par défaut, il suffit de reprendre son alias :

active_model = "devstral-openrouter"

Exemple complet : OpenRouter

Voici une configuration complète, avec un provider et deux modèles rattachés :

# ~/.vibe/config.toml

# Provider OpenRouter
[[providers]]
name = "openrouter"
api_base = "https://openrouter.ai/api/v1"
api_key_env_var = "OPENROUTER_API_KEY"
api_style = "openai"
backend = "generic"

# Modèle Devstral gratuit via OpenRouter
[[models]]
name = "mistralai/devstral-2512:free"
provider = "openrouter"
alias = "devstral-free"
temperature = 0.2

# Modèle Llama via OpenRouter
[[models]]
name = "meta-llama/llama-3.3-70b-instruct"
provider = "openrouter"
alias = "llama-70b"
temperature = 0.3

La configuration seule ne suffit pas : il reste à définir la variable d’environnement que le provider attend, faute de quoi les appels partiront sans authentification.

export OPENROUTER_API_KEY="sk-or-votre-cle-ici"

Une fois les deux modèles déclarés, vous disposez de deux alias interchangeables. En cours de session, /model devstral-free bascule de l’un à l’autre sans perdre la conversation, ce qui permet de comparer deux réponses sur le même problème. Au lancement, l’option --model fait la même chose : vibe --model llama-70b.

Provider local avec Ollama

Le cas d’un modèle servi localement mérite un exemple à part, car il ne demande aucune clé API : le champ api_key_env_var reste simplement vide.

[[providers]]
name = "ollama"
api_base = "http://localhost:11434/v1"
api_key_env_var = ""
api_style = "openai"
backend = "generic"

[[models]]
name = "codestral:latest"
provider = "ollama"
alias = "codestral-local"

L’avantage est direct : vos données ne quittent jamais votre machine. C’est l’option à retenir pour travailler sur du code sensible, ou tout simplement pour continuer à coder dans un train sans connexion.

Points clés à retenir

• Vibe supporte tout provider compatible avec le format d’API OpenAI
• Un provider se déclare avec [[providers]] dans config.toml
• Chaque modèle est rattaché à un provider et peut avoir un alias
• /model permet de basculer entre modèles en cours de session
• Les providers locaux (Ollama, vLLM) permettent de travailler hors-ligne