The public human story around mistralai/mistral-vibe is a tension, not a contradiction. The repo is open, active, and busy with users. The project also tells would-be code contributors that the team is "not currently accepting contributions" while it iterates quickly.
The fast lane
Mistral published v2.15.0 on June 12, with binary assets for the CLI and ACP surfaces. The changelog says the release added experimental before_tool and after_tool hooks, message queue behavior, collapsed tool output, read-only shell defaults, session deletion, per-server MCP auth, and ACP max_turns.
The maturity signal is not just the version number. The package metadata marks the project as Python 3.12+, Apache-2.0, and "Production/Stable"; the README documents agents, subagents, tools, trust folders, MCP servers, hooks, skills, ACP, update settings, and telemetry controls.
The narrow door
The contributor guide changes the read. It thanks users, says the project is in active development, and encourages bug reports, ideas, and documentation feedback. Then it draws the line: the development setup is documented "even though we're not currently accepting contributions."
That line matters for users comparing agent-code tools. Some projects use the repo as a wide contributor workshop. Mistral Vibe currently looks more like a vendor-led codebase with a public issue desk, a detailed development surface, and a promise that the contribution process may open later.
The public pressure
The outside requests are specific. User ousamabenyounes opened issue 531 and PR 533 asking for a before-tool hook so command output tools such as RTK can rewrite shell calls before execution. The v2.15.0 changelog now foregrounds experimental tool hooks, although the public PR itself remains open.
Other public threads show the maintenance load: issue 762 reports streaming problems with local models, PR 774 proposes handling SSE comments, issue 777 reports Korean command-output mojibake, and PR 778 offers a matching encoding fix.
Why it matters
For builders, the question is not whether Vibe is "real." Its public release, package, docs, and protocol surfaces are real. The question is how much influence outside users can have while the maintainers are still shaping the core loop.
The strongest read today is feedback first, code later. Mistral Vibe is open enough for users to expose sharp integration gaps in public, but not yet open enough for the repo to behave like a normal contributor-driven agent project.