Epic: embed Mistral Vibe as a hosted ACP agent (vibe-acp) — successor to the vibe-direct wire emulation #1709

Direction

Drew (2026-11-05): "eventually vibe direct needs to be embedded per that project" — Vibe's end state in our stack is embedded the way Mistral's own project intends: the real vibe agent hosted by the fork, not wire-emulated by it.

Current state — the shim

vibe-direct today is a wire-protocol provider in packages/ai (packages/ai/src/providers/vibe.ts + vibe-auth.ts, landed in #1653):

• Reuses the MistralChat route against https://api.mistral.ai/v1 (the same wire the binary uses), rebranded to provider id vibe, with Vibe's model presets and request defaults (temperature 1.0, reasoning_effort "high").
• Stamps requests with the binary's attribution (metadata.call_source = "vibe_code").
• Resolves the credential the way the binary does: config → env MISTRAL_API_KEY → ~/.vibe/.env → OS keyring (service ai.mistral.vibe).
• The vibe provider: native wire-protocol emulation of the Mistral Vibe binary (no ACP host, no subprocess) #1653 commit says it plainly: "No vibe subprocess, no ACP host." It emulates the binary's requests; the binary's agent (tools, skills, subagents, session semantics) is not in the loop.

Deployed route (developing-today/code .opencode/opencode.jsonc): model mistral-vibe-cli-latest, providers ["vibe-direct", "mistral"], vibe-direct attempted first.

Vibe's intended embedding surface (primary sources)

Mistral documents ACP as the embedding path:

• "Vibe implements the Agent Client Protocol (ACP) and is published in the ACP registry… If your client has no agent registry, install the CLI and point the client at the vibe-acp command it installs." — https://docs.mistral.ai/vibe/code/use-vibe-in-other-ides
• "One agent, three surfaces… They share the same engine, configuration, and customization layer (agents, skills, MCP servers)" + ACP for other clients — https://docs.mistral.ai/vibe/code/choose-cli-vscode-web-sessions
• ACP registry id: mistral-vibe; ACP command: vibe-acp.

Installed on the laptop (vibe 3.1.0, verified 2026-11-05): three entrypoints —

• vibe — interactive CLI + headless programmatic mode (-p/--prompt, --output json|streaming, --output-dir writes export.json with token usage/cost).
• vibe-acp — "Run Mistral Vibe in ACP mode": JSON-RPC 2.0 over stdio, protocol v1.
• vibe-app-server — an app-server surface ("Unified Harness connections", --multiplex) — noted for the design record; ACP is the documented, registry-published path and the one this epic builds on.

What the host provides over ACP (observed live, see spike): the client spawns vibe-acp, drives initialize → session/new → session/prompt; the agent streams session/update (message chunks, tool calls, usage updates), delegates approvals back via session/request_permission, and exposes session modes (ask / accept-edits / auto-approve) and config options (model, reasoning effort) for the host to present and set. Session state (journal, resume) stays the agent's, under ~/.vibe.

Spike result (2026-11-05, laptop amd-6) — PROVEN

A minimal ACP host (211-line Python client, stdlib only) drove one real end-to-end turn through vibe-acp on the Vibe plan credential:

• initialize → protocolVersion 1, agent @mistralai/mistral-vibe 3.1.0; capabilities: loadSession, prompt image + embeddedContext, session list/fork/close. No authenticate call needed — the keyring credential was already live.
• session/new → session 48475654-f48c-f816-04aa-56fd06364bd4; model config option mistral-medium-3.5 (the model behind alias mistral-vibe-cli-latest), effort high, default mode accept-edits.
• session/prompt (instructed to run echo VIBE-EMBED-SPIKE-OK via its bash tool) → tool call bash: echo VIBE-EMBED-SPIKE-OK, reply exactly MARKER=VIBE-EMBED-SPIKE-OK, stopReason: end_turn, usage: 16,864 total tokens (16,643 in / 221 out, 3,072 cached read) in the prompt response, plus streaming usage_update notifications.
• Artifacts on the laptop: ~/work/spikes/vibe-acp-embed-2026-11-05/ (acp_client.py, transcript.jsonl, summary.json, run.log).

The embedded contract works tonight, unmodified, on the plan credential — no console cookies involved.

Target architecture

The fork hosts vibe-acp as an embedded agent runtime: a session in the fork maps to an ACP session in a supervised vibe-acp process; prompts/streaming/tool calls flow over ACP; host approvals answer session/request_permission; modes + model/effort surface as session config; usage lands in the quota pipeline with call_source=vibe_code parity. The embedded route registers switchboard-style beside vibe-direct (definition present, enablement a flag) and the shim retires only after parity acceptance.

Auth rule (Drew, standing): the embedded path rides the keyring/OAuth credential with its own refresh — never a browser console cookie. Anything browser-born in any provider must have auto-renew built in; Vibe's keyring credential already satisfies this and the design must keep it that way.

Children

• ACP client runtime: host vibe-acp (lifecycle, streaming, session mapping)
• Permission + mode bridge (session/request_permission → fork approvals; modes/model/effort config options)
• Embedded auth: keyring credential lifecycle + refresh for the hosted process
• Usage attribution: ACP usage → quota gatherer, vibe_code parity (adjacent: quota: mistral browser-dependent usage read (Vibe plan) — producer + watchdog adapter #1 openchamber#1630)
• Switchboard slice: embedded route disabled-by-default beside vibe-direct; parity acceptance + cutover criteria

Design note: ~/workspace/scratch/vibe-embed-2026-11-05/design.md (fleet scratch, 2026-11-05).