Lokaler Terminal-Agent · Ollama-Endpunkt · Repository-Tools
Der schnelle Weg besteht aus einem Befehl. Für einen zuverlässigen Aufbau brauchst du zusätzlich ein toolfähiges Modell, mindestens 64K konfigurierten Kontext für Repository-Arbeit, genug Speicher dafür und einen sicheren Git-Arbeitsbereich.
Schnellster unterstützter Weg
Installiere beide Anwendungen aus offiziellen Quellen, stelle sicher, dass Ollama läuft, und nutze dann den Integrationsbefehl:
ollama launch opencodeOllama lässt dich ein vorhandenes Modell auswählen und startet OpenCode mit einer lokalen Inline-Konfiguration. Die Integration überschreibt deine dauerhafte OpenCode-Konfiguration nicht.
Die Prüfung gegen die häufigsten Fehlstarts
Die OpenCode-Dokumentation von Ollama verlangt ein Kontextfenster von mindestens 64K. Darin liegen Repository-Auszüge, Tools, Befehlsausgaben und Verlauf. Ein Modell kann mit kleinerem Fenster laden und bei echter Agentenarbeit dennoch scheitern.
Reproduzierbare Einrichtung
Nutze zuerst den direkten Start. Eine manuelle Konfiguration brauchst du erst für ein festes Modell, einen anderen Host oder explizite Kontextregeln.
Lade Ollama herunter und folge dem OpenCode-Installationsratgeber für dein Betriebssystem. Prüfe beide Befehle in einem neuen Terminal.
Ein Autocomplete-Modell ist nicht automatisch ein guter Agent. Prüfe die Modellkarte auf Instruction Following, Tool- oder Function-Calling und Kontextunterstützung. Qwen3-Coder 30B-A3B ist eine aktuelle Referenz für agentisches Coding.
Führe ollama list aus und verwende genau den angezeigten Namen samt Tag. Ein anderer Tag kann eine andere Parameterzahl oder Quantisierung bezeichnen.
Führe ollama launch opencode aus, wähle das lokale Modell und öffne ein kleines Test-Repository. Mit ollama launch opencode --config kann Ollama die Konfiguration vorbereiten, ohne sofort eine interaktive Sitzung zu starten.
Lass den Agenten eine Datei lesen, eine kleine reversible Änderung vornehmen und einen harmlosen Testbefehl ausführen. Eine flüssige Antwort beweist noch keine funktionierenden strukturierten Tool-Aufrufe.
Beobachte Speicher, Verzögerung bei der Prompt-Verarbeitung, Ausgabegeschwindigkeit und Testerfolg. Reduziere bei Speichermangel Kontext oder Quantisierung; wähle ein stärkeres Modell, wenn Patches schnell, aber falsch sind.
Manuelle Provider-Konfiguration
Lege opencode.json an oder erweitere die Datei, wenn du einen festen lokalen Provider möchtest. Ersetze beide Platzhalter durch die exakte ID aus ollama list.
{ "$schema": "https://opencode.ai/config.json", "provider": { "ollama": { "npm": "@ai-sdk/openai-compatible", "name": "Ollama (local)", "options": { "baseURL": "http://localhost:11434/v1" }, "models": { "deine-modell-id": { "name": "Mein lokales Coding-Modell" } } } } }Bedeutung der Zeilen
Ersetze localhost nicht allein für einen bequemen Fernzugriff durch eine öffentliche Bind-Adresse. Dafür sind Authentifizierung, Firewall-Regeln und ein bewusstes Netzwerkkonzept nötig.
Modell + 64K Kontext + Reserve
OpenCode selbst verbraucht nicht den größten Speicheranteil. Geladenes Modell, Quantisierung, KV-Cache und parallele Sitzungen bestimmen das Hardwareziel.
| Lokale Modellklasse | Praktischer Hardwarestart | Passender Einsatz | Vor der Festlegung |
|---|---|---|---|
| 7B–14B quantisiert | 12–16 GB VRAM; 32 GB System-RAM | Fokussierter Chat, kleine Änderungen, erste Agententests | Prüfen, ob 64K Kontext passt und Tools zuverlässig arbeiten. |
| 20B–24B quantisiert | 24 GB VRAM; 64 GB System-RAM | Leistungsfähigere Arbeit mit einem Agenten | Reserve für Kontext, Anzeige und Build-Tools lassen. |
| 30B–32B quantisiert | 32 GB VRAM für Tempo oder mindestens 64 GB Unified Memory für Kapazität | Repository-Agenten und stärkere Code-Erzeugung | Dieselbe Quantisierung kann bei 32K passen und bei 64K knapp werden. |
| Großes Modell oder mehrere Agenten | 96–128 GB Unified beziehungsweise kohärenter Speicher | Kapazitätsorientierte Workflows und mehrere Dienste | Runtime-Unterstützung prüfen und anderes Tempoprofil als bei dedizierter GPU erwarten. |
Die Bereiche enthalten bewusst Arbeitsreserve, bleiben aber Schätzwerte. Entscheidend sind Modell-Datei, konfigurierter Kontext und gemessener Spitzenverbrauch. Der PC-Finder übersetzt diese Angaben in eine Hardwareklasse.
Fehlersuche nach Symptom
| Symptom | Wahrscheinliche Ursache | Prüfung | Sinnvoller nächster Schritt |
|---|---|---|---|
| Modell fehlt in der Liste | Ollama gestoppt, falscher Tag oder Grenze des Start-Pickers | ollama list und Ollama-Dienst | Exakten Tag laden oder installierte ID in opencode.json definieren. |
| Chat läuft, Änderungen nicht | Schwaches oder inkompatibles Tool-Calling | Modellkarte und Ein-Datei-Tool-Test | Toolfähiges Coding-Modell nutzen und keine fehlende Fähigkeit erzwingen. |
| Nach einiger Zeit Speichermangel | Kontext-Cache oder parallele Sitzungen | Konfigurierten Kontext und Speichermaximum | Andere Sitzungen schließen, Kontext bewusst reduzieren oder kleinere Quantisierung wählen. |
| Sehr langsam vor dem ersten Token | Lange Prompt-Verarbeitung, CPU-Offload oder kalter Modellstart | GPU-Offload, Promptlänge und Speicheraktivität | Modell im schnellen Speicher halten, irrelevanten Kontext verkleinern oder schnellere Hardware wählen. |
| Agent wiederholt sich oder verliert Dateien | Kontext abgeschnitten oder schwache Repository-Auswahl | Tatsächliche Kontextgrenze und OpenCode-Protokoll | Kontext nur bei genug Speicher erhöhen, Aufgabe teilen und Anweisungen knapp halten. |
| Endpunkt nicht erreichbar | Falscher Host/Port oder Dienst gestoppt | http://localhost:11434/v1 und lokale Firewall | Standard-Endpunkt lokal wiederherstellen, bevor Fernzugriff versucht wird. |
Lokale Inferenz ist nur eine Datenschutzschicht
OpenCode kann Dateien lesen und ändern sowie Terminalbefehle ausführen. Behandle die Modellausgabe wie den Beitrag eines unerfahrenen Teammitglieds: nützlich, schnell und immer zu prüfen.
Sauberen Branch oder Worktree und einen einfachen Rücksetzpunkt verwenden.
Nur das benötigte Projekt öffnen; Zugangsdaten und Produktiv-Dumps ausschließen.
Destruktive, privilegierte oder vernetzte Befehle nicht unverstanden freigeben.
Diff prüfen und projektbezogene Tests, Linter sowie Sicherheitschecks ausführen.
FAQ zu OpenCode und Ollama
Ja. Der lokale Ollama-Endpunkt auf localhost benötigt keinen Cloud-Provider-Key. Halte ihn lokal, solange du nicht bewusst Authentifizierung und Netzwerkschutz ergänzt.
Ein Agent braucht strukturierte Tool-Aufrufe, mehr Prompt-Kontext und genug Ausgabedisziplin zum Ändern von Dateien und Ausführen von Befehlen. Ein Modell mit überzeugendem Chattext muss diese Schritte nicht zuverlässig beherrschen.
Ollamas offizielle OpenCode-Integration empfiehlt für lokale Modelle mindestens 64K. Kleine fokussierte Aufgaben können weniger belegen; bei Repository-Arbeit füllen Tools, Dateien, Ausgaben und Verlauf den Prompt jedoch schnell.
Wähle die RTX 5090, wenn Modell und Kontext in 32 GB passen und Schleifengeschwindigkeit zählt. Wähle 128 GB Unified Memory, wenn größere Modelle, längerer Kontext oder mehrere Dienste mehr als 32 GB Kapazität benötigen.
Befehle aktuell halten
Direkter Start, 64K-Kontext, manuelle Konfiguration und Rangfolge. Offiziellen Ollama-Ratgeber öffnen.
Provider-Syntax, lokaler Endpunkt und Fehlersuche bei Tool-Aufrufen. Offiziellen OpenCode-Ratgeber öffnen.
Modellarchitektur, nativer Kontext, Tool-Nutzung und Hinweise bei Speichermangel. Offizielle Modellkarte öffnen.
Geschwindigkeit, Kapazität und konkrete Komplettsysteme im Hardware-Ratgeber für lokales Coding vergleichen.
PC noch nicht gewählt?
Gib Modellklasse, Kontext und Workflow an. Das Ergebnis trennt schnellen dedizierten VRAM von größerer Shared-Memory-Kapazität.