Devstral 2 paired code-agent weights with an execution-capable CLI
Mistral released Devstral 2 on December 9, 2025, introducing 123B and 24B coding models with distinct licenses and the Mistral Vibe CLI.
Historical reporting: Mistral’s December 9, 2025 announcement released Devstral 2 (123B) under a modified MIT license, Devstral Small 2 (24B) under Apache 2.0, and the Apache 2.0 Mistral Vibe CLI. Current Mistral documentation marks Devstral 2 deprecated, a later lifecycle fact that does not rewrite the launch event.

Key takeaways
- Devstral 2 combined two differently licensed model artifacts with a CLI that could inspect, modify, and execute work.
- A code-agent benchmark is supplier evidence about an evaluation setup, not authority to change an unfamiliar repository or environment.
- The 123B and 24B variants imply distinct capacity and deployment choices before a user-facing coding workflow is enabled.
The December event linked two coding models and a native CLI[source 1]
On December 9, 2025, Mistral announced Devstral 2, Devstral Small 2, and Mistral Vibe. The launch identified Devstral 2 as a 123B-parameter dense transformer with a 256K context window, and Devstral Small 2 as a 24B model with the same stated context window. It presented Vibe as a native command-line agent for end-to-end code automation, creating a release that included both model weights and an execution-facing interface.
That packaging changes the risk boundary. A code completion can be reviewed as text, while a CLI that explores a file tree, edits files, invokes version control, and runs commands can produce effects before its final prose is read. The dated event establishes availability and intended capability; a host still decides what each tool may read, write, execute, or send outside a working directory.
The two model variants shipped with different licenses[source 1]
Mistral said Devstral 2 used a modified MIT license, while Devstral Small 2 used Apache 2.0; the launch also said Mistral Vibe was Apache 2.0. These are materially different artifact terms, so an integration cannot use the name “Devstral 2” as shorthand for a single licensing answer. The selected checkpoint, its license, any bundled code, and the CLI version should be preserved together before reuse or redistribution decisions are made.
Mistral also described Devstral 2 as free through its API at launch and gave later intended API prices, while identifying different hardware targets for the large and small variants. Hosted API access and local weights have separate service, data, and operational boundaries. A team should not infer that a permissive weight license grants hosted capacity, that an API trial fixes future cost, or that a model card supplies authorization for its agent to operate production tools.
Supplier coding scores and hardware advice are conditions, not outcomes[source 1][source 2]
Mistral reported 72.2% on SWE-bench Verified for Devstral 2 and 68.0% for Devstral Small 2, and described a 0.2 temperature recommendation for Vibe. Those are vendor-reported results and configuration guidance under Mistral’s evaluation and agent setup. They do not measure correctness for another repository, its tests, dependency graph, secrets policy, or failure recovery path.
The launch said the 123B model was optimized for data-center GPUs with a stated minimum of four H100-class GPUs, while the smaller model targeted single-GPU use. This establishes a real deployment tradeoff: model selection affects more than token quality, including hardware inventory, queueing, context limits, and cost controls. The current docs later mark Devstral 2 deprecated; use that for lifecycle planning, not as launch-day feature evidence.
Vibe’s tool surface needs an execution boundary outside the model[source 1][source 2]
Mistral described Vibe as supporting file manipulation, code search, version control, command execution, programmable scripting, and configurable tool permissions. Those capabilities make a narrow allowlist and a logged execution boundary part of the agent product, rather than optional wrapper code. A useful session can keep proposed patches separate from applied changes, show the exact command before it runs, and require a distinct approval for network, credential, production, or destructive operations.
This is a direct implication of an execution-capable CLI, not an assertion that Devstral or Vibe is unsafe. It preserves the useful distinction between a model proposing a repair and a system accepting responsibility for its effects. That distinction also enables evaluation: reviewers can inspect selected files, arguments, command output, diff, and tests instead of relying on an agent’s account of what it did.
