Mistral Vibe: Subagent Limits Raised to 32 With New Concurrency Settings
Mistral VibeMistral Vibe 3.0.2 raised the default subagent limits to 32 alive and 32 running concurrently, up from 8 and 4. It also added max_subagents and max_concurrent_subagents settings so users can tune how many subagents exist and run at once. Failed subagents now stay in the subagent list instead of disappearing.
Key Takeaways
- Default limits jumped to 32 alive and 32 concurrent subagents, from 8 and 4, giving much more parallelism out of the box.
- New
max_subagentsandmax_concurrent_subagentssettings let users tune the ceiling in either direction. - Higher defaults can raise usage and cost on fan-out tasks, so cost-conscious users should set limits explicitly.
- Failed subagents now remain in the list marked as failed, which makes large parallel runs easier to debug.
- The change shows subagents becoming a first-class way to work in Mistral Vibe rather than an occasional helper.
- It pairs with the permission enforcement fixes in the same release, which matter more as more subagents run at once.
More parallel subagents by default
Mistral Vibe 3.0.2 makes it possible to run far more subagents in parallel without any configuration. The default ceiling is now 32 subagents alive and 32 running concurrently. The previous defaults were 8 alive and 4 running concurrently. Work that fans out across many files, modules or investigations can therefore proceed with much more parallelism.
New settings
Two new settings, max_subagents and max_concurrent_subagents, let users control these limits. max_subagents caps how many subagents can be alive at once, and max_concurrent_subagents caps how many can be running at once. Users on constrained machines, rate-limited accounts or cost-sensitive setups can lower the values. Users who want maximum parallelism can raise them.
Failed subagents stay visible
The same release fixes a small but useful detail. Subagents whose last turn failed now stay in the subagent list marked as failed. Before, they disappeared, which made it hard to see what had gone wrong in a large fan-out.
Things to keep in mind
Higher defaults mean more simultaneous model calls, which can increase usage and cost on a single task. Users who relied on the old limits as an implicit guardrail should set the new options explicitly.