Lokaler LLM-Coding-Agent: Ollama und LM Studio einrichten

Ein lokaler LLM-Coding-Agent ist eine Coding-CLI wie opencode, Aider, Goose, Qwen Code, Crush oder Codex, die statt auf eine gehostete API auf ein Modell zeigt, das über Ollama oder LM Studio auf deinem eigenen Rechner läuft. Du startest einen lokalen Server (Ollama lauscht auf http://localhost:11434, LM Studio auf http://127.0.0.1:1234), wählst ein Modell mit Tool-Calling-Unterstützung, setzt seine Kontextlänge deutlich über den Standard und sagst der CLI, dass sie diesen Endpunkt nutzen soll. Das funktioniert, hält deinen Code auf deinem Rechner und kostet nichts pro Token. Es ist aber auch langsamer und weniger leistungsfähig als die besten gehosteten Modelle, weshalb die meisten am Ende ein Hybrid-Setup betreiben.

Was „lokal“ hier eigentlich bedeutet

Ein Coding-Agent besteht aus zwei Teilen: der CLI, die Dateien liest, Befehle ausführt und Code bearbeitet, und dem Modell, das entscheidet, was als Nächstes passiert. Lokal zu gehen ersetzt nur den zweiten Teil. Die CLI führt dieselbe Schleife aus; sie schickt ihre Anfragen nur an einen Server auf localhost statt an die API eines Anbieters.

Die beiden gängigen lokalen Server sprechen beide eine OpenAI-kompatible API:

Laut Ollamas Doku verlangen OpenAI-Clients zwar einen API-Key-Wert, Ollama ignoriert ihn aber, sodass für einen lokalen Server jeder Platzhalter funktioniert.

Die Einstellung, die alle übersehen: die Kontextlänge

Kläre das, bevor du eine CLI auswählst. Agenten schicken viel Kontext: einen System-Prompt, Tool-Definitionen, Dateiinhalte und Befehlsausgaben. Ein lokaler Server mit kleinem Fenster schneidet das meiste davon unbemerkt ab.

Ollamas Standard-Kontextfenster hängt von deinem VRAM ab: 4k Tokens unter 24 GiB, 32k zwischen 24 und 48 GiB und 256k ab 48 GiB. Die Aider-Doku ergänzt, dass Ollama Kontext, der das Fenster übersteigt, stillschweigend verwirft. Die Goose-Doku nennt einen Standard von 4096 Tokens zu niedrig, und Ollamas eigene Codex-Anleitung verlangt mindestens 64k.

Erhöhe den Wert beim Start des Servers und prüfe ihn dann:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve
ollama ps   # CONTEXT column shows the allocated length

Die Ollama-App hat in den Einstellungen einen Regler für die Kontextlänge, der dasselbe tut. Zeigt ollama ps in der Spalte PROCESSOR das Modell teilweise auf der CPU, ist Kontext oder Modell zu groß für deine GPU, und alles wird langsamer.

Welche CLIs lokale Modelle unterstützen

Hier steht, was die jeweilige Dokumentation selbst bestätigt. Wir listen nur Setups auf, die wir prüfen konnten.

Codex

Codex hat den kürzesten Weg. Laut Doku läuft es gegen einen lokalen „Open-Source“-Provider wie Ollama oder LM Studio, wenn du --oss übergibst:

codex --oss                     # default local model
codex --oss -m gpt-oss:120b     # a specific model

Den Standard-Provider legst du in ~/.codex/config.toml mit oss_provider = "ollama" (oder "lmstudio") fest. Ollama bietet außerdem ollama launch codex, das ein Profil für dich einrichtet. In Codex wechselt /model zwischen installierten Modellen mit Tool-Unterstützung.

opencode

opencode nimmt jeden OpenAI-kompatiblen Server als benutzerdefinierten Provider in opencode.json auf:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen3": { "name": "Qwen3 (local)" } }
    }
  }
}

Für LM Studio nimmst du http://127.0.0.1:1234/v1 als Basis-URL und den in LM Studio angezeigten Modellbezeichner. Die opencode-Doku hat einen nützlichen Tipp: Funktionieren Tool-Aufrufe nicht, erhöhe num_ctx in Ollama, beginnend bei etwa 16k bis 32k.

Aider

Aider spricht direkt mit Ollama. Die Doku empfiehlt das Präfix ollama_chat/:

export OLLAMA_API_BASE=http://127.0.0.1:11434
aider --model ollama_chat/<model>

Für LM Studio oder jeden anderen OpenAI-kompatiblen Server setzt du OPENAI_API_BASE und OPENAI_API_KEY und nutzt dann aider --model openai/<model-name>. Eine feste Kontextgröße kommt in .aider.model.settings.yml als num_ctx unter extra_params.

Goose

Goose führt Ollama und LM Studio als Provider auf. Starte goose configure, wähle Ollama und gib einen Modellnamen ein. Goose nutzt localhost:11434, sofern OLLAMA_HOST nichts anderes sagt; LM Studio steht standardmäßig auf localhost:1234 ohne API-Key. Die Goose-Doku ist beim Hauptproblem deutlich: Goose setzt stark auf Tool Calling, ein Modell ohne diese Fähigkeit kann nur chatten.

Qwen Code

Qwen Code unterstützt jeden OpenAI-kompatiblen Endpunkt, und die README nennt lokale Modelle über Ollama oder vLLM. Richte die Standardvariablen auf deinen Server:

export OPENAI_BASE_URL=http://localhost:11434/v1
export OPENAI_API_KEY=ollama   # any placeholder for a local server
export OPENAI_MODEL=<model>
qwen

Dasselbe kann in ~/.qwen/settings.json unter modelProviders stehen, oder du richtest es interaktiv mit /auth ein.

Crush

Crush unterstützt ollama und lmstudio als Provider-Typen. Seine README zeigt Ollama mit der Basis-URL http://localhost:11434/v1. Das Modell wählst du in Crush mit Ctrl+L.

Wenn der lokale Agent Probleme macht

Die meisten Probleme mit einem lokalen Coding-Agenten gehen auf eine Handvoll Ursachen zurück. Prüfe sie in dieser Reihenfolge:

• Er vergisst mitten in der Aufgabe Dateien oder Anweisungen. Der Kontext ist zu klein, und der Server schneidet ab. Erhöhe OLLAMA_CONTEXT_LENGTH (oder num_ctx) und bestätige es mit ollama ps.
• Tool-Aufrufe schlagen fehl oder kommen als Klartext zurück. Entweder unterstützt das Modell kein Tool Calling, oder der Kontext ist für die Tool-Definitionen zu kurz. Probiere ein Modell mit Tool-Unterstützung und ein größeres Fenster; die opencode-Doku schlägt einen Start bei etwa 16k bis 32k vor.
• Die CLI meldet, das Modell existiere nicht. Der Name in der CLI muss exakt dem Bezeichner des Servers entsprechen: dem Tag aus ollama list oder dem Bezeichner im Server-Panel von LM Studio.
• Connection refused. Der Server läuft nicht, oder die CLI erwartet eine andere Adresse. Ollama nutzt 11434, LM Studio 1234, und manche CLIs wollen das Suffix /v1, während Aiders OLLAMA_API_BASE es nicht hat.
• Alles ist sehr langsam. Modell oder Kontext passen nicht auf die GPU. ollama ps zeigt den CPU-Anteil; nimm ein kleineres Modell oder einen kürzeren Kontext.

Die Hardware-Realität

Hier scheitern die meisten Erwartungen. Ein lokaler Coding-Agent ist eine schwerere Aufgabe als lokaler Chat:

• Das Modell muss in den Speicher passen. VRAM der GPU am PC, Unified Memory bei Apple Silicon. Passt es nicht, laufen Layer auf die CPU über, und die Generierung wird stark langsamer.
• Auch Kontext kostet Speicher. Ein 64k-Fenster auf den Modellgewichten braucht deutlich mehr Platz als ein 4k-Chat. Deshalb koppelt Ollama seine Standard-Kontextlänge an den VRAM.
• Kleine Modelle tun sich mit Tools schwer. Agenten sind auf zuverlässige Tool-Aufrufe und das Befolgen eines langen System-Prompts angewiesen. Kleine Modelle erzeugen oft fehlerhafte Aufrufe, drehen Schleifen oder hören zu früh auf. Goose weist darauf hin, dass manche Modelle, etwa das native DeepSeek-R1, Tool Calling gar nicht unterstützen.
• Die Geschwindigkeit summiert sich. Ein Agent stellt pro Aufgabe viele Anfragen, jede mit großem Prompt. Ein Modell, das sich im Chat gut anfühlt, kann eine Aufgabe mit zehn Schritten sehr lang machen.

Ein praktischer Einstieg: Nimm das größte Coding-Modell mit Tool-Unterstützung, das komplett auf deine GPU passt und mindestens 32k bis 64k Kontext schafft, bestätige es mit ollama ps und teste es an einer kleinen, echten Aufgabe, bevor du ihm Größeres anvertraust.

Warum lokal: Datenschutz und Kontrolle

Der Hauptgrund ist, dass die Inferenz auf deinem Rechner bleibt:

• Deine Prompts und dein Code gehen nicht an einen Modellanbieter.
• Es funktioniert offline und in Air-Gap-Umgebungen.
• Keine Rechnung pro Token und keine Nutzungslimits, an die du stoßen könntest.
• Das Modell ändert sich nicht unter deinen Händen; du entscheidest, wann du aktualisierst.

Zwei Einschränkungen halten das ehrlich. Erstens kann die CLI trotzdem das Netzwerk nutzen: Codex mit Ollamas Launch-Profil hat Websuche, und manche CLIs haben Telemetrie. Prüfe die Einstellungen jedes Tools, wenn überhaupt nichts den Rechner verlassen soll. Zweitens macht lokales Laufen den Agenten selbst nicht sicherer. Er führt weiterhin Befehle aus und bearbeitet Dateien, daher gelten die üblichen Sicherheitspraktiken für Coding-Agenten.

Kompromisse gegenüber gehosteten Modellen

Der Abstand ist bei abgegrenzten Aufgaben am kleinsten: einen Test schreiben, eine Funktion erklären, ein kleines Refactoring, eine Commit-Nachricht. Am größten ist er bei langer, mehrstufiger Arbeit über viele Dateien, wo der Agent einen Plan halten und sich von eigenen Fehlern erholen muss.

Ein Hybrid-Setup, das funktioniert

Eine Aufteilung funktioniert meist besser als ein Alles-oder-nichts-Wechsel:

1. Sensible oder Offline-Arbeit läuft lokal. Code, der den Rechner nicht verlassen darf, Kunden-Repos mit strengen Auflagen, Arbeit im Flugzeug.
2. Routinemäßige, abgegrenzte Aufgaben laufen lokal. Tests, Doku, kleine Fixes und Erklärungen.
3. Schwere Aufgaben gehen an ein gehostetes Modell. Architekturänderungen, knifflige Bugs, große Refactorings.
4. Review in einem frischen Kontext. Lass einen zweiten Agenten den Diff des ersten prüfen, egal welches Modell ihn geschrieben hat.

Am einfachsten betreibst du das mit zwei oder mehr Agenten gleichzeitig: einer auf einem lokalen Endpunkt, einer auf einem gehosteten Modell, jeder in einem eigenen Ordner oder Git-Worktree, damit sie nicht dieselben Dateien bearbeiten.

Lokale und gehostete Agenten in AgentVera nebeneinander betreiben

AgentVera ist eine Desktop-App, die viele CLI-Agenten nebeneinander in einem Workspace laufen lässt, was zum obigen Hybrid-Setup passt. Damit klar ist, was sie tut und was nicht:

• Sie hat keine eingebaute Ollama- oder LM-Studio-Integration. Jeder Agent nutzt sein eigenes Provider-Setup: goose configure für Goose, die eigene Konfiguration von opencode und /connect, Aiders Umgebungsvariablen oder .aider.conf.yml, Qwen Codes Anmeldung oder API-Key, die Einstellungen von Crush (Ctrl+L).
• Das Feld „Model“ wird an die CLI durchgereicht. Bei Agenten wie Qwen Code, Goose und Aider geht das, was du dort einträgst, als --model an die CLI. Bei Goose lautet der Hinweis: „If left empty, the model chosen with goose configure is used.“
• Agenten können Umgebungsvariablen mitführen. Unter Settings → Accounts → Accounts of other agents speichert ein Konto, das „With an API key“ hinzugefügt wurde, einen „Variable name“ und seinen Wert. Für Qwen Code ist OPENAI_BASE_URL einer der vorgeschlagenen Namen, und jeder andere Name lässt sich eintippen. Das gehört zum Kontenwechsel in den Plänen Pro und Team.
• Kontext-Werkzeuge reichen über Claude Code hinaus. Die Kontextgröße wird aus dem eigenen Verlauf jeder CLI gemessen, und Auto-Compact nutzt den eigenen Compact-Befehl der CLI, wo es einen gibt. Bei einem kleinen lokalen Fenster ist das umso wichtiger.

Realistisch sieht es also so aus: Du richtest das lokale Modell in der CLI so ein, wie es ihre Doku beschreibt, und AgentVera lässt dich diesen Agenten neben einem gehosteten laufen lassen, beide im Blick behalten und ihre Arbeit getrennt halten.