Mistral Vibe CLI mit Devstral lokal: Einrichtung route
Mistral Vibe CLI ist der von Mistral AI veröffentlichte Coding-Agent im Terminal, der laut Ankündigung Devstral 2 unter der Apache-2.0-Lizenz verwendet. Standardmäßig sendet er Ihre Anfragen an die API von Mistral. Dieser Leitfaden installiert ihn und verbindet ihn anschließend über die in der Dokumentation „offline models“ beschriebene config.toml-Datei mit einem von Ollama auf Ihrem Rechner bereitgestellten Devstral Small 2. Zum Abschluss geht es um die tatsächlichen Grenzen eines Coding-Agenten, der vollständig lokal läuft.
#Mistral Vibe CLI: was es ist und was es nicht ist
Mistral Vibe CLI ist ein in Python geschriebenes Kommandozeilenprogramm, das im Dezember 2025 gleichzeitig mit Devstral 2 und Devstral Small 2 veröffentlicht wurde. Sie starten es im Verzeichnis eines Projekts, beschreiben eine Aufgabe in natürlicher Sprache, und der Agent liest Ihre Dateien, schlägt Änderungen vor, führt Befehle aus und iteriert bis zum Ergebnis. Das Prinzip entspricht Claude Code, OpenCode oder Aider, ist aber auf die Devstral-Modelle ausgerichtet, die für diese agentische Schleife trainiert wurden.
Der Quellcode ist auf GitHub im Repository mistralai/mistral-vibe unter der Apache-2.0-Lizenz veröffentlicht, laut Ankündigung von Mistral. Sie können ihn lesen, ändern und gebührenfrei in Unternehmen verwenden. Die CLI kann mit der API von Mistral kommunizieren, aber auch mit jedem Server, der eine API im OpenAI-Format bereitstellt: Ollama, llama.cpp, LM Studio oder vLLM. Dieser zweite, auf der Seite „offline models“ dokumentierte Modus ist für uns hier relevant.
Warum sollte man eine lokale Vibe CLI statt der API verwenden? Drei Gründe werden immer wieder genannt. Der Code verlässt die Maschine nicht, was bei proprietärem Code oder Code unter einer Vertraulichkeitsvereinbarung wichtig ist. Es gibt weder nutzungsabhängige Abrechnungen noch ein Kontingent: Sie bezahlen den Strom und die Hardware, die Sie bereits besitzen. Schließlich funktioniert das Tool auch offline oder hinter einer strengen Firewall. Dafür verzichten Sie auf das 123 Milliarden Parameter große Modell Devstral 2, das für einen Arbeitsplatzrechner zu groß ist, und akzeptieren eine geringere Geschwindigkeit als bei einem Produktionsserver.
#Voraussetzungen: Python, Ollama und ausreichend Speicher für Devstral Small 2
Dieser Guide führt Sie zum Modell. Das Kit führt Sie zum Copiloten, der in Ihrem Editor Code schreibt.
- Lebenslanger Online-Zugang
- PDF + Dateien
- Erstattung binnen 30 Tagen
Bevor Sie irgendetwas installieren, überprüfen Sie diese vier Punkte. Sie verhindern drei Viertel der Probleme, die bei lokalen Coding-Agenten auftreten.
- System
- Linux oder macOS sind die Hauptziele. Unter Windows verwenden Sie WSL2 (Ubuntu): Die CLI wird wie unter Linux installiert, und Ollama für Windows bleibt von WSL aus über die Adresse localhost erreichbar.
- Aktuelles Python
- Die CLI wird als Python-Paket verteilt. Das Repository nennt die erforderliche Mindestversion in seiner README; zum Zeitpunkt der Ankündigung war dies Python 3.12 oder neuer. Überprüfen Sie dies mit python3 --version, bevor Sie fortfahren.
- Ollama installiert und gestartet
- Ollama stellt das Modell bereit und bietet unter http://localhost:11434 eine OpenAI-kompatible API an. Falls noch nicht geschehen, behandelt unser Installationsleitfaden für Ollama alle drei Systeme.
- Speicherbedarf für ein 24B-Modell
- Devstral Small 2 verfügt über 24 Milliarden Parameter. In der Quantisierung Q4_K_M belegen die Gewichte etwa 14 GB, hinzu kommt der Kontext-Cache. Rechnen Sie für einen komfortablen Betrieb mit einer 24-GB-GPU (RTX 3090, RTX 4090) oder einem Mac mit 32 GB Unified Memory. In der Ankündigung von Mistral wird außerdem „eine RTX 4090 oder ein Mac mit 32 GB RAM“ als Zielkonfiguration genannt.
Mit einer 16-GB-GPU (RTX 4080, RTX 5070 Ti für Desktop-PCs) läuft das Q4-Modell, aber der Kontext wird schnell in den Systemspeicher ausgelagert und die Geschwindigkeit sinkt. Mit 12 GB (RTX 3060, RTX 4070) verteilt Ollama die Schichten auf GPU und CPU: Der Agent funktioniert, aber jeder Schleifendurchlauf dauert mehrere Dutzend Sekunden. Wir haben diese Durchsatzraten auf diesen Karten nicht quantifiziert; merken Sie sich einfach, dass 24 GB die Komfortgrenze für ein 24B-Modell im Agentenbetrieb sind, bei dem der Kontext mit jeder gelesenen Datei wächst.
#Mistral Vibe CLI installieren
Mistral bietet ein Installationsskript mit einem einzigen Befehl an, das die CLI in einer isolierten Umgebung einrichtet. Dies ist die im README des Repositorys empfohlene Methode.
Wenn Sie die Installation selbst kontrollieren möchten, wird das Paket unter dem Namen mistral-vibe auf PyPI veröffentlicht. Das Tool uv installiert es in einer eigenen Umgebung, ohne Ihre anderen Python-Projekte anzutasten. Das klassische pip funktioniert ebenfalls, vorzugsweise in einer virtuellen Umgebung.
Überprüfen Sie anschließend, ob der Befehl vibe verfügbar ist. Wenn das Terminal ihn nicht findet, schließen Sie es und öffnen Sie es erneut: Das Installationsskript fügt Ihrem PATH ein Verzeichnis hinzu, das beim nächsten Start der Shell berücksichtigt wird.
#Devstral Small 2 in Ollama vorbereiten
Devstral Small 2 wird von Mistral unter der Apache-2.0-Lizenz veröffentlicht und verfügt über ein Kontextfenster von 256 000 Tokens. Ollama bietet es in seiner Bibliothek an; der nachstehende Befehl lädt die Standardversion in 4-Bit-Quantisierung herunter. Der Download umfasst etwa 14 GB.
Der genaue Modellname in der Bibliothek Ollama kann sich ändern (Quantisierungsvariante, Größen-Suffix). Wenn der Befehl fehlschlägt, suchen Sie auf ollama.com/library nach „devstral“ und übernehmen Sie den angezeigten Namen. Genau diesen Namen, wie er in ollama list erscheint, tragen Sie in die Vibe-Konfiguration ein.
Eine entscheidende Einstellung fehlt noch: die Kontextlänge. Ollama lädt Modelle standardmäßig mit einem kurzen Kontext, häufig 4 096 Tokens. Für einen Coding-Agenten ist das viel zu wenig: Der System-Prompt von Vibe, die Liste der Tools, der Inhalt gelesener Dateien und der Sitzungsverlauf überschreiten diese Größe bereits nach wenigen Austauschen. Das Modell vergisst dann den Anfang der Unterhaltung, und der Agent dreht sich im Kreis. Legen Sie mindestens einen Kontext von 32 000 Tokens fest, zum Beispiel mit einem abgeleiteten Modelfile.
Sie können den globalen Kontext beim Start des Dienstes Ollama auch mit der Umgebungsvariable OLLAMA_CONTEXT_LENGTH festlegen. Das Modelfile hat den Vorteil, dass es nur dieses Modell betrifft und einen eindeutigen Namen beibehält. Ein längerer Kontext verbraucht mehr Speicher: Bei 32k Tokens auf einem 24B-Modell sollten Sie je nach Art des KV-Caches 2 bis 4 GB zusätzlichen Speicher einplanen. Bei 24 GB liegt die komfortable Grenze; ab 64k sollten Sie den Speicher mit nvidia-smi überwachen.
#Das lokale Modell in config.toml verbinden
Mistral Vibe CLI liest seine Konfiguration aus der Datei ~/.vibe/config.toml. Die Dokumentation „offline models“ beschreibt darin zwei Tabellen: providers, das einen Server und seine Adresse definiert, und models, das einen Modellnamen einem Anbieter zuordnet. Ein Schlüssel active_model legt das standardmäßig verwendete Modell fest. Hier ist eine vollständige Konfiguration für das oben vorbereitete Ollama.
Drei Details bedürfen einer Erklärung. Die Adresse endet mit /v1, weil Vibe den OpenAI-Dialekt spricht und Ollama dieses Format nur unter diesem Präfix bereitstellt; die native API von Ollama ohne /v1 ist daher nicht geeignet. Das Feld api_key_env_var bleibt leer: Ollama erfordert lokal keine Authentifizierung. Die Preise stehen auf null, damit die von der CLI angezeigte Kostenschätzung konsistent bleibt; sie haben keinerlei Auswirkungen auf die Funktionsweise.
Bei einem anderen lokalen Server ändert sich nur der Abschnitt providers. Mit llama.cpp (llama-server) lautet die Adresse im Allgemeinen http://localhost:8080/v1; mit LM Studio lautet sie http://localhost:1234/v1; mit vLLM lautet sie http://localhost:8000/v1. In allen Fällen muss das Feld name des Modells die Kennung enthalten, die dieser Server erwartet und über seine Route /v1/models zurückgibt.
Sie können mehrere Modelle deklarieren, zum Beispiel Devstral Small 2 lokal und Devstral 2 über die API Mistral, und dann innerhalb der Sitzung zwischen ihnen wechseln. Beim Anbieter Mistral wird der API-Schlüssel aus einer Umgebungsvariable gelesen, üblicherweise MISTRAL_API_KEY; der Schlüssel muss nicht im Klartext in der Datei stehen. Wenn Ihr Ziel 100 % lokal ist, fügen Sie einfach keinen entfernten Anbieter hinzu: Nichts verlässt dann die Maschine.
#Erste Sitzung: vibe starten und das Modell überprüfen
- 01In ein Projekt wechselnÖffnen Sie ein Terminal im Verzeichnis eines Git-Repositorys, vorzugsweise in einem sauberen (git status ohne ausstehende Änderungen). Der Agent arbeitet mit den Dateien im aktuellen Verzeichnis; ein sauberes Repository ermöglicht es Ihnen, seine Änderungen mit git diff zu prüfen und mit git checkout rückgängig zu machen.
- 02Die CLI startenGeben Sie vibe ein. Beim allerersten Start kann die CLI vorschlagen, einen API-Schlüssel von Mistral einzugeben und den Ordner ~/.vibe zu erstellen. Wenn Sie config.toml zuvor angelegt haben, ist Ihr lokaler Anbieter bereits bekannt. Wenn die Schlüsselabfrage trotzdem erscheint, konsultieren Sie /help: Je nach Version können Sie sie überspringen oder leer lassen, wenn ein lokaler Anbieter konfiguriert ist.
- 03Aktives Modell überprüfenDie Oberfläche zeigt das aktuelle Modell an. Es sollte sich um Ihren Alias devstral-small-local handeln. Der Befehl /help listet die in der Sitzung verfügbaren Befehle auf, darunter den Befehl zum Modellwechsel, falls Sie mehrere Modelle deklariert haben.
- 04Eine erste klar abgegrenzte Aufgabe erteilenBeginnen Sie mit kleinen Aufgaben: „Lesen Sie die README und fassen Sie die Architektur des Projekts in fünf Zeilen zusammen“, dann „Fügen Sie einen Unit-Test für die Funktion X in der Datei Y hinzu“. Beobachten Sie die erste Antwort: Wenn das Modell antwortet, ohne ein Tool zu verwenden, oder einen Dateipfad erfindet, liegt das Problem meist an einem zu kurzen Kontext oder daran, dass das Modell nicht für Tool Calling vorbereitet wurde.
- 05Vor dem Akzeptieren prüfenVibe bittet vor sensiblen Aktionen wie dem Schreiben von Dateien oder dem Ausführen von Befehlen um Bestätigung. Lesen Sie jeden vorgeschlagenen Diff. Ein lokales 24B-Modell macht häufiger Fehler als ein über die API bereitgestelltes 123B-Modell, insbesondere bei großen Codebasen: Die Prüfung ist Teil des Arbeitsablaufs und nicht die Ausnahme.
Behalten Sie während der Sitzung die Auslastung von Ollama im Auge: Der Befehl ollama ps zeigt das geladene Modell, den GPU- und CPU-Anteil sowie den effektiven Kontext an. Wenn Sie eine teilweise Verteilung auf die CPU sehen, obwohl Sie davon ausgingen, dass das Modell in den Videospeicher passt, hat der Kontext die Grafikkarte zum Überlaufen gebracht.
#Grenzen eines zu 100 % lokalen Vibe CLI
Ein lokaler Code-Agent funktioniert, lässt sich aber nicht eins zu eins mit der API-Version vergleichen. Das können Sie erwarten, ohne erfundene Zahlen: Wir haben für diesen Leitfaden keinen Benchmark durchgeführt, und die von Mistral veröffentlichten Werte beziehen sich auf Modelle, die unter Referenzbedingungen bereitgestellt werden, nicht auf einen Desktop-Computer mit einem quantisierten Modell.
- Devstral 2 bleibt außer Reichweite
- Das große Modell mit 123 Milliarden Parametern benötigt selbst in stark quantisierter Form Dutzende Gigabyte Speicher. Lokal arbeiten Sie mit Devstral Small 2, dessen Mistral 68,0 % auf SWE-bench Verified angibt, gegenüber 72,2 % für Devstral 2. Der Abstand ist bei diesem Benchmark gering, macht sich aber bei langen Aufgaben und umfangreichen Repositories bemerkbar.
- Die Quantisierung verändert das Modell
- Die angegebene Punktzahl gilt für vollständige Gewichte. Ein Q4_K_M verschlechtert die Genauigkeit leicht; ein Q8_0 erhält sie besser, benötigt aber allein für die Gewichte etwa 26 GB, also eine 32-GB-Karte oder einen gut ausgestatteten Mac. Die Wahl der Quantisierung ist ein Kompromiss, den Sie bewusst eingehen sollten.
- Der lokale Kontext ist deutlich kürzer als 256k
- Devstral Small 2 akzeptiert 256 000 Tokens, aber auf 24 GB werden Sie diese nicht nutzen können. Zwischen 32k und 64k Tokens deckt der Agent ein Modul oder einen kleinen Dienst ab. Für ein Monorepo müssen Sie die Aufgabe Datei für Datei eingrenzen.
- Die Geschwindigkeit hängt von der Hardware ab, nicht von der CLI
- Ein dichtes 24B-Modell erzeugt bei gleicher Speichermenge langsamer Text als ein ähnlich großes MoE-Modell. Jeder Schleifendurchlauf des Agenten umfasst ein erneutes Lesen des gesamten Kontexts: Je länger die Sitzung dauert, desto länger dauert jede Antwort. Planen Sie kurze Sitzungen und teilen Sie Aufgaben auf.
- Tool-Aufrufe und Formate
- Der Agent basiert auf strukturierten Tool-Aufrufen. Ein quantisiertes Modell kann gelegentlich einen fehlerhaft formatierten Aufruf erzeugen, den die CLI ablehnt. Devstral wurde für diese Art der Nutzung trainiert und kommt damit deutlich besser zurecht als ein allgemeines Modell, aber das Phänomen tritt nicht mit null Wahrscheinlichkeit auf.
- Ein junges Tool
- Die CLI wurde im Dezember 2025 veröffentlicht und entwickelt sich schnell weiter. Befehle, Konfigurationsformat und Editor-Integration ändern sich. Aktualisieren Sie regelmäßig (uv tool upgrade mistral-vibe oder starten Sie das Installationsskript erneut) und lesen Sie das Änderungsprotokoll auf GitHub, bevor Sie sich über ein Verhalten beschweren.
Die Ankündigung von Mistral erwähnt außerdem eine Integration in Editoren über das ACP-Protokoll, insbesondere mit Zed. Wenn Sie einen Editor dem Terminal vorziehen, zeigt unser Leitfaden Zed + Ollama, wie dieser Editor bereits mit einem lokalen Modell kommuniziert; beide zu kombinieren bedeutet, Vibe den Agenten steuern und Zed die Diffs anzeigen zu lassen.
#Fehlerbehebung
- „vibe: Befehl nicht gefunden“
- Das Verzeichnis der ausführbaren Dateien befindet sich nicht in Ihrem PATH. Öffnen Sie das Terminal erneut. Bei uv lautet der Pfad normalerweise ~/.local/bin; überprüfen Sie ihn mit uv tool dir --bin und fügen Sie ihn bei Bedarf Ihrer Shell-Datei hinzu.
- Verbindungsfehler zu localhost:11434
- Ollama ist nicht gestartet oder hört an einer anderen Adresse. Testen Sie curl http://localhost:11434/v1/models. Stellen Sie unter WSL2 sicher, dass Ollama auf der Windows-Seite läuft und die Variable OLLAMA_HOST nicht eingeschränkt wurde.
- Das Modell ist dem Server unbekannt
- Das Feld name im Abschnitt models entspricht keinem Modell, das in ollama list vorhanden ist. Übernehmen Sie den genauen Namen einschließlich Suffix, auch den Namen Ihres abgeleiteten Modelfile, falls Sie eines erstellt haben.
- Der Agent vergisst, was er gerade gelesen hat
- Kontext zu kurz. Überprüfen Sie mit ollama ps, welcher Kontextwert tatsächlich geladen ist; wenn er 4 096 beträgt, wurden Ihre Modelfile- oder OLLAMA_CONTEXT_LENGTH-Einstellungen nicht übernommen.
- Sehr langsame Antworten, GPU kaum ausgelastet
- Ein Teil des Modells befindet sich auf der CPU. Reduzieren Sie den Kontext, wechseln Sie zu einer leichteren Quantisierung oder schließen Sie die anderen von Ollama geladenen Modelle (OLLAMA_MAX_LOADED_MODELS).
- Die CLI verlangt einen API-Schlüssel, obwohl alles lokal läuft
- Versionsabhängiges Verhalten. Überprüfen Sie, dass sich config.toml tatsächlich unter ~/.vibe/config.toml befindet und active_model auf einen vorhandenen Alias verweist, und konsultieren Sie anschließend die Seite „offline models“ in der Dokumentation für die aktuelle Vorgehensweise.
#Weiterführende Informationen
Vibe CLI ist eine gute Wahl, wenn Sie dem Mistral-Ökosystem und Devstral verbunden sind. Wenn Sie vor der Einrichtung vergleichen möchten, spielt OpenCode in derselben Kategorie und unterstützt mehr Anbieter; die Frage nach dem lokalen Coding-Modell stellt sich unabhängig vom gewählten Agenten.
Haben Sie Feedback, einen Fehler entdeckt oder möchten Sie etwas präzisieren? Geben Sie uns Bescheid – so wird der Guide für alle besser.