Mistral has turned Le Chat into Vibe, a unified agent with separate modes for professional work and software development. Announced on May 28, 2026, Vibe carries existing plans, settings, and conversation history forward while adding long-running Work and Code experiences.

The separation is sensible. Researching a market, drafting a presentation, and updating email require connected business apps and approval rules. Refactoring a repository requires a terminal, isolated branch, tests, and a pull request. Both are agentic, but their tools and failure modes are different.

Vibe retains a Chat mode for quick conversations and legacy Le Chat features during the transition. Mistral says Chat will eventually be sunset, with history preserved, while migration paths for some legacy Agents are still planned.

Work Mode: outcomes across apps and sources

Work is available through Vibe’s web and mobile interfaces. A user describes an outcome, the agent gathers context, creates a plan, calls tools, shows progress, and prepares a result for review.

Mistral positions it for:

Connectors can include Gmail, Outlook, Slack, Notion, Linear, GitHub, Atlassian, Google Drive, SharePoint, Stripe, and other services. Actual access depends on the user, plan, organization, and connected account.

Work asks for approval before sensitive actions such as sending email, modifying data, or deleting. It also shows tool calls and progress so a user can redirect the task before completion.

Skills, projects, and schedules

Reusable skills let teams encode a stable procedure rather than repeat a long prompt. Projects preserve relevant context across related work. Schedules can run a prompt once or on daily, weekly, monthly, or yearly cadence.

These features move Vibe toward process automation. A scheduled agent needs production controls:

  1. a named owner;
  2. approved sources and destinations;
  3. a defined schedule and expiry;
  4. duplicate prevention;
  5. failure alerts;
  6. spending or usage limits;
  7. review after connector or schema changes.

Visible progress during an interactive run does not guarantee that a future scheduled run will see the same data or interface.

Code Mode: repositories, terminals, and pull requests

Code is available through a CLI, VS Code extension, and remote web sessions. The agent can read and edit files, run commands, implement features, fix bugs, refactor code, test changes, and prepare pull requests.

Each surface fits a different working style:

Surface Best fit
CLI local repositories, scripting, terminal-native work
VS Code inline iteration and project-wide changes in the editor
Remote web persistent sandbox sessions attached to GitHub

Remote sessions can continue while the local machine is off and can run in parallel. They operate in an isolated sandbox and leave a branch or pull request for review. The Git operations remain attributed through the user’s GitHub connection.

Mistral’s teleport feature can move a live CLI session to the cloud while preserving history and branch state. That is useful when local work becomes long-running, but secrets and environment differences still need review.

Permissions differ by surface

The VS Code extension uses session-scoped permissions with always, never, or ask policies for files, commands, and directories. The CLI supports interactive and programmatic execution. Mistral recommends bounding programmatic runs with maximum turns and limiting enabled tools.

Remote sessions add GitHub and cloud-sandbox boundaries. Work adds connectors and business actions. A unified brand does not imply one permission model.

Teams should document:

Do not use an auto-approval profile merely to avoid interruptions on an unfamiliar repository or external system.

Connected content must remain untrusted. An email, issue, webpage, or repository file can contain text that tries to redirect the agent or request a tool action. Work and Code should follow the user’s task and developer policy, not instructions discovered inside data. Require confirmation when a source introduces a new recipient, command, dependency, or destination.

For Code, inspect dependency changes and generated scripts before execution. For Work, show which connector supplied each important fact and which action will modify a system. A unified agent can carry context across a long task, but provenance must remain granular enough to identify the source of a bad instruction.

Chat remains a transitional mode

Chat preserves turn-based use and several older Le Chat features, including legacy Agents, Think mode, Deep Research, Code Interpreter, and Memories. Mistral is reimagining some of these in Work as skills or built-in behavior.

That means a workflow may not move one-to-one from Chat into Work. Test how instructions, memories, code execution, and citations behave before retiring an existing process. “Same history” is not the same as “same execution semantics.”

Launch pricing and availability

Mistral announced:

Plans and included usage can change, so current pricing should be checked before purchase. Long-running work is not costless simply because it is included in a subscription. Agent time, tool APIs, connected SaaS services, cloud sandboxes, and human review all contribute to total cost.

Measure cost per accepted deliverable or merged change. Track tool calls, elapsed time, retries, reviewer corrections, test failures, and abandoned sessions.

Strengths and limitations of the unified approach

A single agent identity reduces context switching. Users can move from research to implementation, and developers can choose local or remote code surfaces.

The risk is assuming continuity where boundaries differ. A Work report may cite external sources; a Code change needs tests. A remote session may lack a local dependency. A connector may expose stale or incomplete data. A polished output can still be wrong.

Use mode-specific acceptance criteria:

Long-running agents need durable state

An agent conversation is not a reliable system of record for external work. Persist job IDs, branches, commits, approvals, and outputs in the systems that own them.

If a run is interrupted, resume from known state rather than asking the model to infer what probably happened. External writes should be idempotent, and expensive calls should be checked before retry.

From a Vibe plan to a retryable media workflow

Vibe Work could assemble a campaign brief from approved documents, while Vibe Code could build the surrounding application or validation script. The actual media transformation can remain a separate, explicit service.

For example, Vibe might determine that a licensed audio track must be added to an approved video. A user reviews the plan. Codex or Claude can then call Medux through MCP to perform the task. Medux is not a native Vibe integration; it is an external media layer accessed through a separately authorized client.

The Codex MCP video-editing tutorial shows the relevant lifecycle: inspect inputs, obtain signed upload URLs, upload assets, start an asynchronous task, poll status, and download the result.

The controller should persist:

If Vibe restarts, it first queries the existing Medux task instead of launching another paid job. If the media result fails validation, the agent diagnoses the evidence and proposes a retry; it does not silently resubmit. Vibe’s long-horizon planning and visible progress are useful, but reliability comes from durable external state and explicit retry rules.

This pattern preserves a clean responsibility boundary. Vibe can plan, coordinate, and explain; the MCP client authorizes access; Medux runs the media operation; and a reviewer accepts the artifact. Each layer can then be audited or replaced without treating one conversational transcript as the entire production system.