Mistral Vibe: Default Model Option
Mistral VibeMistral Vibe v2.24.0 introduced a new "Default" (unpinned) model option in /model and /config, letting users track Mistral's recommended model without locking their session to a specific alias. Previously, choosing a model meant pinning to one version indefinitely; the new option automatically follows whichever model Mistral currently recommends, while server-side default model routing ensures any explicit pin a user has set is never silently overridden by backend experiments. The change gives casual users a lower-maintenance way to always run on a well-supported model, while preserving full control for anyone who wants to stick with a specific version.
Key Takeaways
- New "Default" model option lets users follow Mistral's recommended model automatically instead of manually re-pinning after every model release.
- Explicit pins always win — server-side experiment routing for the "Default" option can never override a model a user has pinned via
/model,/config, or a config file. - Config precedence hardened — experiment variants now route through Mistral Vibe's config schema, so TOML settings, environment variables, and CLI overrides take precedence over GrowthBook A/B assignments.
- Lower maintenance for casual users who no longer need to manually track and switch to newly released models.
- No behavior change for power users — sessions with an explicit model pin see zero change in routing behavior after this update.
- Shipped alongside broader config work in v2.24.0, including an admin config layer and composable user/project config layers, continuing Mistral Vibe's push toward a more layered, predictable configuration system.
A New Way to Track Mistral's Recommended Model
Mistral Vibe has historically asked users to pick a specific model and stick with it, whether through an explicit --model flag, a saved alias in config.toml, or a selection made in the /model picker. With v2.24.0, Mistral Vibe introduced a third option: "Default", an unpinned setting that tells the client to always defer to whichever model Mistral currently recommends for the Vibe agent, rather than freezing on one alias indefinitely.
The option shows up alongside existing choices in both the /model command and the newer /config settings browser, so switching to it — or back to an explicit pin — takes a single keystroke rather than an edit to a TOML file.
Server-Side Routing, With Pins Always Winning
Behind the "Default" option sits a new server-side routing layer: when a session is unpinned, Mistral Vibe now resolves the active model via an experiment run on Mistral's backend, letting the company roll out recommended-model changes to unpinned users without shipping a client update. Critically, this routing only ever applies to sessions left on "Default" — any user who has explicitly pinned a model alias, whether through /model, /config, or a config file, keeps that exact model, and the experiment can never override it.
This routing plumbing rides on a broader change also shipped in v2.24.0: experiment variants are now resolved through Mistral Vibe's own config schema, so TOML settings, environment variables, and explicit overrides always take precedence over any A/B assignment coming from Mistral's growth experimentation platform. In practice, that means power users who like to lock in a specific model — say, for reproducibility in CI, or because they've found a favorite — see no behavior change at all, while everyone else benefits from Mistral automatically keeping their agent on a well-supported, current model without any manual upgrade step.
Why It Matters
Model churn is a recurring pain point for AI coding tools: new models ship frequently, and users who never revisit their configuration can end up stuck for months on an older, possibly deprecated alias. The "Default" option removes that maintenance burden for anyone who doesn't have a strong reason to pin, while leaving pinning fully available — and now explicitly guaranteed to be respected — for everyone else.