Der lokale Qwen-Stack von OpenCode und Ollama brachte einen Screenshot-Umbenenner zustande, blieb bei einem PDF-Projekt aber in der Fehlersuche stecken. So beschreibt ZDNET-Autor David Gewirtz seinen Versuch auf einem Mac Studio mit M4 Max und 128 GB Arbeitsspeicher. Die Ergebnisse stammen aus seinen konkreten Aufgaben, nicht aus einem allgemeinen Leistungsvergleich.
Ein funktionierender Prototyp sagt wenig darüber aus, ob ein Agent auch wiederholte Stapelverarbeitung und knifflige Fehlersuche zuverlässig bewältigt.
Was die lokale Kombination tatsächlich schaffte
Gewirtz verwendete OpenCode v2.2.5 als Coding-Agent, Ollama als Laufzeitumgebung für lokale Modelle und qwen3-coder-next:q4_K_M als Hauptmodell. Sein Kontextfenster fasste 64.000 Tokens. Diese Konfiguration nutzte er, um ein Werkzeug zum Umbenennen von Screenshots zu bauen.
Der Anlass war konkret: Gewirtz hatte einen Ordner mit mehr als 7.000 Screenshots. Das fertige Programm öffnete einen Bildordner, zeigte jeweils ein Bild und ließ einen neuen Dateinamen eingeben. Mit Return wurde die Datei gespeichert und das nächste Bild geöffnet.
Gewirtz zufolge dauerte die Entwicklung knapp sechs Tage. Vier davon steckte er in die Dateiliste, deren Code er schließlich verwarf. Eine neue OpenCode-Sitzung baute die Liste danach neu. Das fertige Werkzeug blieb einfach: Es hatte weder veränderbare Fensterbereiche noch Vorlagen für Dateinamen und Datum, Zoom oder eine schnelle Vor- und Zurücknavigation.
Warum das PDF-Projekt ins Stocken geriet
Bei einem weiteren Vorhaben sollte ein Programm PDFs nach ihrem Inhalt sortieren. Gewirtz berichtet, dass die lokale Kombination den Betreff eines einzelnen PDFs erkennen konnte, die Aufgabe bei größeren Stapeln aber nicht zuverlässig wiederholte. Der fünftägige Versuch kam bei der Fehlersuche an einem neuen macOS-27-Subsystem für die Erkennung von Dokumentinhalten auf dem Gerät nicht weiter.
Die beiden Ergebnisse zeigen unterschiedliche Anforderungen: Ein eng umrissenes Werkzeug mit einem überschaubaren Ablauf kam zustande; die wiederholte Verarbeitung vieler Dokumente und die Fehlersuche an der neuen Schnittstelle stockten. Gewirtz empfiehlt für seine Arbeit, Aufgaben klein zu halten, für einzelne Änderungen neue Sitzungen zu beginnen und Recherche vom Programmieren zu trennen. Datei- und Shell-Aktionen ließ er sich bestätigen, weil Coding-Agenten Befehle ausführen können, die Dateien verschieben oder löschen.
Zwei unterschiedliche Wege für lokale Coding-Agenten
Bei Gewirtz' Versuch ersetzte der lokale Modell-Stack sowohl das Modell als auch den Coding-Agent. Local-CLI ist dagegen ein eigener Kommandozeilen-Agent, der unterschiedliche kompatible Modell-Endpunkte ansprechen kann.
| Ansatz | Coding-Agent | Modellanbindung | Ausführung |
| Gewirtz' Versuch | OpenCode v2.2.5 | Qwen über Ollama | Lokal auf einem Mac Studio mit M4 Max |
| Local-CLI | Local-CLI | OpenAI-kompatible Endpunkte wie Ollama, vLLM und LM Studio sowie Azure OpenAI und Google Gemini | Lokal, On-Premises oder über Cloud-Anbieter, je nach Endpunkt |
Das aktuelle Local-CLI-Repository nennt Node.js 20 oder neuer als Voraussetzung. Die dokumentierte Installation lautet npm install -g local-cli-agent; anschließend startet local-cli den Einrichtungsassistenten für den Endpunkt. Das Projekt beschreibt außerdem eine MIT-Lizenz, einen Plan-und-Ausführen-Modus und einen überwachten Modus, der vor Dateiänderungen eine Zustimmung anfordert.
Die Projektbeschreibung nennt die Nutzung ohne API-Gebühren und die Ausführung im lokalen Netzwerk für lokale oder On-Premises-Modelle. Sie führt auch Cloud-Endpunkte wie Azure OpenAI und Google Gemini auf. Welche Art von Anbindung zum Einsatz kommt, entscheidet daher mit darüber, ob ein Local-CLI-Aufbau tatsächlich lokal läuft.
