Mistral Vibe: Setup and /whoami Now Show Which Credential Is Actually Used
Mistral VibeMistral Vibe 3.0.4 makes it clearer which credential a session is really using. /whoami now reports whether the key comes from the shell, a .env file or the keyring, and setup warns when an API key already set in the shell would override the one it saves. --setup with a non-Mistral model also offers Mistral browser sign-in, and a new preserve_api_base option protects custom endpoints.
Key Takeaways
/whoaminow reports the credential source (shell,.envor keyring), so users can see where the active key comes from.- Setup warns when a shell-set API key overrides the key it just saved, removing a common silent-failure cause.
--setupwith a non-Mistral model now offers Mistral browser sign-in alongside the provider's API key.- The new
preserve_api_base = trueprovider option keeps a customapi_basefrom being overwritten by/whoami. - The changes mainly help users with keys in multiple places and those on proxied or split-horizon networks.
- The release ships alongside a wider UX cleanup in 3.0.4, including release-notes browsing and clearer status rows.
Why credentials were confusing
Mistral Vibe can pick up an API key from several places: an environment variable in the shell, a .env file, or the system keyring. When more than one is present, the shell value wins, so a freshly saved key could silently be ignored. Version 3.0.4 targets this confusion directly.
Setup warns about a shell key that overrides the saved one
When setup saves an API key, Mistral Vibe now checks whether a key set in the shell environment will override it. If so, it shows a warning instead of finishing quietly. Users who ran setup, saw it succeed, and still hit authentication errors from a stale shell variable get an explanation at the moment it matters.
/whoami shows the credential source
The /whoami command now states which credential source is in use: the shell, a .env file, or the keyring. Together with the setup warning, users can confirm in one command where the active key comes from, rather than guessing which of several locations took effect.
Mistral sign-in alongside non-Mistral providers
Running --setup with a non-Mistral model, such as litellm or a local model, now offers Mistral browser sign-in next to the provider's API key. Users who mix a local or third-party model with Mistral services no longer have to choose between configuring one or the other during onboarding.
Protecting custom API endpoints
A new provider option, preserve_api_base = true, keeps a custom api_base that /whoami would otherwise overwrite. This is aimed at split-horizon and proxied deployments, where the endpoint users reach is intentionally different from the default.
Who benefits
Most affected are users with credentials in more than one location, people switching between personal and organization keys, and teams routing traffic through a proxy.