Add custom providers
On this page
Updated November 2, 2026 — Devstral. Devstral 2 (
devstral-2512) reached its end-of-life on July 31, 2026, and Devstral Small 2 on March 31, 2026: calls to these models are no longer guaranteed. The official table redirects them to Mistral Medium 3.5, which is itself deprecated in favor of Mistral Large 4. Codestral (codestral-2508) remains generally available for code completion. Check the model table to see where the-latestaliases point before reusing these examples.
Why use third-party providers?
By default, Vibe communicates with the Mistral API. But the tool’s architecture is designed to be agnostic: you can add any provider compatible with the OpenAI API format. This addresses four real-world needs. You can access models from other vendors—Claude, GPT, Llama—route through a relay like OpenRouter to compare multiple models on the same task, point to a local instance (Ollama, vLLM) when code must not leave the machine, or switch providers based on the nature of the work.
A typical scenario involves a team that works daily with Devstral 2 on the Mistral API but switches to a local instance whenever handling a client repository subject to confidentiality constraints.
Anatomy of a provider
You declare a provider in config.toml using the [[providers]] directive:
[[providers]]
name = "openrouter"
api_base = "https://openrouter.ai/api/v1"
api_key_env_var = "OPENROUTER_API_KEY"
api_style = "openai"
backend = "generic"
Each field has a specific role:
- name — Unique identifier for the provider (used to reference models)
- api_base — Base URL of the API (the
/chat/completionsendpoint will be appended automatically) - api_key_env_var — Name of the environment variable containing the API key
- api_style — API format. Use
"openai"for any OpenAI-compatible provider - backend — Backend type.
"generic"works for most cases
The classic pitfall concerns api_base: since Vibe appends /chat/completions itself, a URL that already includes this suffix will result in an invalid address and a hard-to-diagnose network error.
Examples of common providers
Here are the values to enter for the most widespread services. The two local providers have no key variable, as they require no authentication.
| Provider | api_base | api_key_env_var |
|---|---|---|
| OpenRouter | https://openrouter.ai/api/v1 | OPENROUTER_API_KEY |
| Ollama (local) | http://localhost:11434/v1 | — |
| Together AI | https://api.together.xyz/v1 | TOGETHER_API_KEY |
| Groq | https://api.groq.com/openai/v1 | GROQ_API_KEY |
| vLLM (self-hosted) | http://votre-serveur:8000/v1 | — |
Declaring a model on a provider
Declaring the provider isn’t enough: you must then attach the models you intend to use.
[[models]]
name = "mistralai/devstral-2512:free"
provider = "openrouter"
alias = "devstral-openrouter"
temperature = 0.2
The name field repeats the model identifier exactly as the provider knows it, character for character. provider must match the name of a provider declared earlier, otherwise Vibe won’t know where to send the request. alias defines a shorthand name to use within Vibe, and temperature sets creativity, from 0.0 for deterministic behavior to 1.0 for a more inventive model. For code, a low value like the one in the example yields much more stable results.
To enable this model by default, simply reuse its alias:
active_model = "devstral-openrouter"
Complete example: OpenRouter
Here is a complete configuration with one provider and two attached models:
# ~/.vibe/config.toml
# OpenRouter Provider
[[providers]]
name = "openrouter"
api_base = "https://openrouter.ai/api/v1"
api_key_env_var = "OPENROUTER_API_KEY"
api_style = "openai"
backend = "generic"
# Free Devstral model via OpenRouter
[[models]]
name = "mistralai/devstral-2512:free"
provider = "openrouter"
alias = "devstral-free"
temperature = 0.2
# Llama model via OpenRouter
[[models]]
name = "meta-llama/llama-3.3-70b-instruct"
provider = "openrouter"
alias = "llama-70b"
temperature = 0.3
Configuration alone isn’t enough: you still need to define the environment variable the provider expects, or calls will go out without authentication.
export OPENROUTER_API_KEY="sk-or-votre-cle-ici"
Once both models are declared, you have two interchangeable aliases. During a session, /model devstral-free switches between them without losing the conversation, allowing you to compare two responses on the same problem. At launch, the --model option does the same thing: vibe --model llama-70b.
Local provider with Ollama
The case of a locally served model deserves a separate example, as it requires no API key: the api_key_env_var field simply remains empty.
[[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"
The advantage is direct: your data never leaves your machine. This is the option to choose for working on sensitive code, or simply to keep coding on a train without an internet connection.
Key takeaways
- Vibe supports any provider compatible with the OpenAI API format
- Declare a provider with
[[providers]]in config.toml - Each model is attached to a provider and can have an alias
/modellets you switch between models during a session- Local providers (Ollama, vLLM) enable offline work