OpenCode lokal betreiben: Ollama als Provider auf Linux

Worum es geht#

Ein Coding Agent ist nur dann nützlich, wenn man ihm Code anvertraut. Für Projekte, die noch nicht öffentlich sind oder nicht in eine Cloud-API sollen, ist ein lokales Modell der naheliegende Weg: Modell auf der eigenen Maschine, kein Datenabfluss, keine API-Kosten pro Token.

OpenCode bringt dafür die passende Provider-Schicht mit. Die Dokumentation nennt ausdrücklich, dass neben Cloud-Anbietern auch lokale Modelle unterstützt werden – unter anderem über Ollama, LM Studio und llama.cpp.

Das Setup#

1. Ollama installieren und Modell laden#

# Ollama installieren (Linux)
curl -fsSL https://ollama.com/install.sh | sh

# Modell laden und starten
ollama pull <modellname>
ollama serve

Nach dem Start prüfe ich, ob der lokale Server antwortet:

curl http://localhost:11434/api/tags

Wenn hier JSON mit Modellliste kommt, läuft der lokale Teil.

2. In OpenCode konfigurieren#

OpenCode liest eine JSON-Konfiguration. Die dokumentierten Felder sind provider mit Optionen wie baseURL sowie ein globales model:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "options": {
        "baseURL": "http://localhost:11434"
      }
    }
  }
}

Für projektbezogene Einstellungen gibt es eine Konfiguration im Projektverzeichnis; die Konfigurationen mehrerer Ebenen werden zusammengeführt, nicht ersetzt. Das ist praktisch, wenn eine globale Standardkonfiguration und ein projektspezifisches Modell gewünscht sind.

3. Modell auswählen#

/models

Innerhalb von OpenCode wählbar. Zugangsdaten für Provider landen laut Dokumentation in ~/.local/share/opencode/auth.json. Für lokale Endpunkte ist das in der Regel irrelevant – da gibt es nichts zu speichern, weil nichts in die Cloud geht. Diese Datei gehört trotzdem in die Liste der Dinge, die nicht in ein Repository gehören.

Wo es noch hakt#

Das ist der Teil, den die meisten Anleitungen weglassen:

Tool Calling ist nicht bei jedem Modell gleich gut. Die Dokumentation weist selbst darauf hin, dass nur wenige Modelle sowohl guten Code schreiben als auch zuverlässig Werkzeuge aufrufen. Genau daran hängt aber der Agent-Arbeitsablauf. Ein Modell, das schön erklärt, aber kein Tool aufruft, ist für einen Coding Agent wenig wert.

Lokale Modelle sind kleiner. Ein Modell, das lokal auf normaler Hardware läuft, ist meist ein kleineres. Das ist ein spürbarer Qualitätsunterschied – bei Code-Snippets, bei Refactoring über mehrere Dateien und bei der Fähigkeit, den eigenen Fehler zu erkennen.

Kontextfenster und Geschwindigkeit. Große Kontexte kosten lokal Zeit, und die erste Antwort wartet. Für schnelle Iterationen ist das unangenehm, für Batch-Aufgaben egal.

Meine Einschätzung#

Für mich ist der lokale Weg kein Ersatz für ein Cloud-Modell, sondern eine Option für bestimmte Fälle: ausgelizenzierte Arbeit, Kundensysteme, Dinge, die nicht in ein Fremdsystem gegeben werden dürfen. Und eine gute Lernkurve, weil man beim lokalen Setup keine Token-Bremse hat.

Wenn du das für dein Projekt brauchst#

Ein lokaler Coding Agent ist Teil eines Ganzen: Modelle, Berechtigungen, Protokollierung, Backup. Wenn du das für dein Repository aufsetzen willst, helfe ich beim Aufbau – oder ich baue dir die Anwendung drumherum.