Mistral Vibe CLI

A five-line [[providers]] block in .vibe/config.toml — api_base, api_key_env_var, api_style — points Vibe CLI at Kunavo, with the key living in an environment variable rather than the file.

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

Step by step

1. Create a key at /app/keys and copy it — it is shown once.
2. Open ~/.vibe/config.toml (or create ./.vibe/config.toml in the repository you want this to apply to) and paste the block above. There is no provider-add flow to click through: Mistral documents this file as hand-edited, and /config and /model only switch between presets that already exist.
3. Export the variable you named in api_key_env_var — export KUNAVO_API_KEY="sk-kn-...". Mistral's credential page documents ~/.vibe/.env as the file the CLI loads at startup for credentials, and its own third-party example uses a shell export for the non-Mistral key.
4. Add a [[models]] preset per id you want, each with its own alias, then point active_model at one of those aliases. The alias is local — it is what /model lists, and name is the id that actually travels to the endpoint.
5. Run vibe in a trusted folder and give it something that touches a file, not a greeting. A first turn that reads and edits exercises tool calling, which is where a misconfigured provider usually shows itself.

Checked against Mistral's Vibe Code CLI configuration page on September 21, 2026. Third-party settings move; if a field name here no longer matches what you see, that page is the authority, not this one.

Verify before you debug the client

One request settles whether a failure is the endpoint, the key, or the configuration file. If this returns JSON, the same base URL and key work 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-..."

Which model id to put in the field

Every text model is reachable as a model id — the live list is GET /v1/models, and the catalog with prices is on the models page. Rates are USD per 1M tokens, input / output.

Not all of your traffic goes to this provider

This is the part a config block cannot tell you, and it is specific to Vibe rather than to Kunavo. At v2.25.5 the CLI routes background “utility” completions — the small calls that name conversations and worktrees — to Mistral's own mistral-vibe-cli-fast model whenever a Mistral provider is usable, and the shipped defaults always configure one, even when the session's active model is yours. The source is explicit about both the preference and the fallback: when no Mistral provider is usable, the utility call goes to the session's active model instead.

So if you want every request in the session to land on the provider you configured, one of these has to be true:

• MISTRAL_API_KEY is unset, so the fast model's credential does not resolve and the utility call falls back; or
• the fast model's alias is excluded through allowed_models, which has the same effect by the allowlist rather than by the key.

The Smart Approve classifier goes further — its 2.25.1 changelog entry says it runs on the fast Mistral model regardless of the session's active model — so a Kunavo-only session realistically lives in accept-edits or plan rather than in Smart Approve. None of this breaks the configuration above; it just means the provider block is about your model turns, not about every packet the binary sends.

The other api_style values

The documentation lists one value for api_style and describes it as an example: "openai". The v2.25.5 source carries four more — "anthropic", "openai-responses", "reasoning" and "vertex-anthropic" — in a plain dictionary with no validation, which is why a typo surfaces at request time rather than when the file loads. Treat them as source-verified and undocumented, and note one trap if you try the Anthropic one: its adapter's endpoint is /v1/messages, so that api_base must be the bare origin, https://api.kunavo.com, with no /v1 — the opposite of the block above. Kunavo does answer /v1/messages, for ids beginning claude-. This page shows the openai style because that is the one Mistral documents.