jpmschweitzer
6ebb4ab32b
Relocate online-mistral-analysis.md → docs/spikes/vibe-cli-integration-analysis.md Update D-105 references to new path. Generated by Mistral Vibe. Co-Authored-By: Mistral Vibe <vibe@mistral.ai>
85 lines
3.0 KiB
Markdown
85 lines
3.0 KiB
Markdown
# LLM Integration Decisions
|
|
|
|
Decisions around Large Language Model integration, driver abstraction, and
|
|
multi-LLM support in clide.
|
|
|
|
---
|
|
|
|
### D-105: Support Vibe CLI as opt-in alternative to Claude Code CLI
|
|
|
|
- **Date:** 2026-06-28
|
|
- **Status:** confirmed
|
|
- **Supersedes:** None
|
|
- **See Also:** docs/spikes/vibe-cli-integration-analysis.md, D-6 (CLI/UI parity), D-56 (single process)
|
|
- **Raised by:** Mistral Vibe evaluation
|
|
|
|
#### Decision
|
|
|
|
**We will support Vibe CLI as an opt-in alternative to Claude Code CLI in clide.**
|
|
|
|
Vibe CLI provides **stdio protocol, permission prompts, session persistence,
|
|
and MCP support** — making it a **~95% feature-parity drop-in replacement** for
|
|
Claude Code CLI. This enables users to select their preferred LLM driver on a
|
|
per-repo basis while maintaining full backward compatibility with the
|
|
existing Claude flow.
|
|
|
|
#### Context
|
|
|
|
Claude Code CLI is clide's current and primary LLM. User requested the
|
|
ability to switch to Mistral's offerings. Two paths were considered:
|
|
|
|
1. **Raw Mistral API** — Requires reimplementing stdio protocol, permission
|
|
prompts, session management. Effort: 3-4 weeks. Parity: ~70%.
|
|
|
|
2. **Vibe CLI** — Mistral's open-source CLI that **natively supports** stdio
|
|
protocol, permission prompts (`can_use_tool`), session persistence
|
|
(`--resume`), MCP servers, and JSONL transcripts. Effort: 1-2 weeks.
|
|
Parity: ~95%.
|
|
|
|
The analysis in `docs/spikes/vibe-cli-integration-analysis.md` confirms Vibe CLI is the
|
|
**production-ready path**.
|
|
|
|
#### Architectural Choice
|
|
|
|
**Direct Vibe CLI Integration (Option 1 from analysis):**
|
|
- Replace `claude` with `vibe` in clide's spawn logic
|
|
- Adapt `StreamJsonProcess` and `TranscriptReader` for minor JSONL differences
|
|
- Update `ClaudeConfig` to watch `.vibe/` instead of `.claude/`
|
|
- Reuse clide's existing MCP broker for team orchestration
|
|
|
|
**Fallback (Option 2):** Thin wrapper to normalize Vibe CLI output to match
|
|
Claude's stream-json exactly. Only if protocol differences prove significant
|
|
during testing.
|
|
|
|
#### Implementation Constraints
|
|
|
|
- **Claude remains primary** — Vibe CLI is opt-in; default driver stays `claude`
|
|
- **Per-repo setting** — `llm.driver` in `.clide/config.yaml`, similar to multi-
|
|
Claude-account mechanism
|
|
- **Zero regression** — All existing Claude functionality preserved
|
|
- **Minimal abstraction** — Leverage Vibe CLI's native parity; avoid thick
|
|
conversion layers
|
|
|
|
#### Success Criteria
|
|
|
|
- User can select `llm.driver: claude | mistral` in per-repo config
|
|
- Vibe CLI sessions work end-to-end: streaming, permissions, tools, MCP, session resume
|
|
- `make test` passes with both drivers
|
|
- No performance regression in Claude flow
|
|
- Migration effort: 1-2 weeks
|
|
|
|
#### Consequences
|
|
|
|
**Positive:**
|
|
- Users can choose their preferred LLM
|
|
- Local inference support (offline/private use cases)
|
|
- Minimal code changes (~1-2 weeks)
|
|
- Full feature parity maintained
|
|
|
|
**Negative:**
|
|
- Additional binary dependency (Vibe CLI)
|
|
- Maintenance burden for two drivers (mitigated by abstraction)
|
|
- Testing matrix doubles (mitigated by CI feature flags)
|
|
|
|
---
|