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

URL: https://agentvera.dev/de/blog/local-llm-coding-agent/ · Veröffentlicht: 2026-10-23

Lokalen LLM-Coding-Agenten mit Ollama oder LM Studio betreiben: welche CLIs lokale Endpunkte nutzen, Hardware-Bedarf, Datenschutz, Kompromisse und Hybrid-Setup.

**Kurz gesagt:**

- Ollama stellt eine OpenAI-kompatible API unter localhost:11434 bereit, LM Studio unter 127.0.0.1:1234; Coding-CLIs wie Codex, opencode, Aider, Goose, Qwen Code und Crush können darauf zeigen.
- Ollamas Standard-Kontext beträgt unter 24 GiB VRAM nur 4k Tokens und verwirft Überlauf stillschweigend; erhöhe ihn mit OLLAMA_CONTEXT_LENGTH. Für Codex verlangt Ollama mindestens 64k.
- Lokale Modelle halten den Code auf deinem Rechner und kosten nichts pro Token, sind aber langsamer und bei Aufgaben über mehrere Dateien schwächer; meist lohnt sich ein Hybrid mit einem gehosteten Modell.

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](/de/glossary/coding-agent/ "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:

| Server | Standardadresse | So startest du ihn |
| --- | --- | --- |
| Ollama | `http://localhost:11434/v1` | Die Ollama-App oder `ollama serve` |
| LM Studio | `http://127.0.0.1:1234/v1` | Tab „Developer“ → „Start server“ oder `lms server start` |

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](/de/glossary/context-window/ "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:

```bash
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.

| CLI | Lokaler Weg | Wo es konfiguriert wird |
| --- | --- | --- |
| Codex | `--oss` mit Ollama oder LM Studio | Flag oder `oss_provider` in `config.toml` |
| opencode | Jeder OpenAI-kompatible Provider | Abschnitt `provider` in `opencode.json` |
| Aider | `ollama_chat/<model>` oder `openai/<model>` | Umgebungsvariablen |
| Goose | Ollama, LM Studio und weitere Provider | `goose configure` |
| Qwen Code | Jeder OpenAI-kompatible Endpunkt | `OPENAI_*`-Variablen oder `~/.qwen/settings.json` |
| Crush | Provider-Typen `ollama` und `lmstudio` | Seine Provider-Konfiguration |

### Codex

[Codex](/de/agents/codex/ "Codex CLI") 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:

```bash
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](/de/agents/opencode/ "opencode") nimmt jeden OpenAI-kompatiblen Server als benutzerdefinierten Provider in `opencode.json` auf:

```json
{
  "$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](/de/agents/aider/ "Aider") spricht direkt mit Ollama. Die Doku empfiehlt das Präfix `ollama_chat/`:

```bash
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](/de/agents/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](/de/agents/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:

```bash
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](/de/blog/ai-coding-agent-security/ "Sicherheit von KI-Coding-Agenten").

## Kompromisse gegenüber gehosteten Modellen

| | Lokales Modell | Gehostetes Frontier-Modell |
| --- | --- | --- |
| Code verlässt den Rechner | Nein | Ja, zum Anbieter |
| Kosten | Hardware und Strom | Pro Token oder Abo |
| Nutzungslimits | Keine | Planabhängig |
| Qualität bei schweren Aufgaben über mehrere Dateien | Geringer, abhängig von der Modellgröße | Das Beste, was verfügbar ist |
| Zuverlässigkeit der Tool-Aufrufe | Je nach Modell unterschiedlich | Stark |
| Kontextfenster | Durch deinen Speicher begrenzt | Sehr groß |
| Geschwindigkeit | Hängt von deiner Hardware ab | Schnell und gleichmäßig |

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](/de/features/workspace/ "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](/de/features/account-switching/ "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.

## Häufige Fragen

**Welche Coding-Agent-CLIs funktionieren mit einem lokalen LLM?** opencode, Aider, Goose, Qwen Code, Crush und Codex dokumentieren alle einen Weg, einen lokalen oder OpenAI-kompatiblen Endpunkt zu nutzen. Codex hat ein eingebautes Flag --oss für Ollama und LM Studio; die anderen verwenden eine Provider-Konfiguration, ein Modell-Präfix oder Umgebungsvariablen.

**Brauche ich eine GPU, um einen lokalen Coding-Agenten zu betreiben?** Nicht zwingend, aber sie hilft enorm. Coding-Agenten brauchen Tool Calling und einen langen Kontext, also ein ziemlich großes Modell und viel Speicher. Ohne leistungsfähige GPU oder viel Unified Memory werden die Antworten so langsam, dass Agentenarbeit zur Qual wird.

**Warum ignoriert mein lokales Modell Dateien oder vergisst Anweisungen?** Meist ist die Kontextlänge zu klein. Ollamas Standard hängt vom VRAM ab und liegt bei Rechnern mit unter 24 GiB bei 4k; was nicht hineinpasst, wird stillschweigend verworfen. Erhöhe sie mit OLLAMA_CONTEXT_LENGTH oder einer num_ctx-Einstellung; Ollama empfiehlt für Codex mindestens 64k.

**Ist ein lokales Modell komplett privat?** Die Inferenz bleibt auf deinem Rechner, Prompts und Code gehen also nicht an einen Modellanbieter. Die CLI selbst kann trotzdem Telemetrie, Websuche oder andere Netzwerkfunktionen haben; prüfe ihre Einstellungen, wenn nichts den Rechner verlassen soll.

**Unterstützt AgentVera lokale Modelle?** AgentVera lässt die CLI-Agenten, die sie unterstützen, nebeneinander laufen, etwa opencode, Aider, Goose, Qwen Code, Crush und Codex. Jede CLI behält ihre eigene Provider-Konfiguration; AgentVera reicht das Feld „Model“ durch und kann einem Agenten Umgebungsvariablen mitgeben, hat aber keine eigene Ollama-Integration.

---

**Über AgentVera.** AgentVera ist eine Desktop-App für macOS, Windows und Linux, entwickelt von Solviera Teknoloji. Sie führt 18 KI-Coding-Agenten (Claude Code, Codex, Gemini CLI, Copilot, Cursor, Antigravity, opencode, Hermes, Qwen Code, Kimi Code, Kiro, Amp, Droid, Goose, Vibe, Crush, Aider, Cline) nebeneinander aus, pro Projekt, in echten Terminals mit den eigenen CLI-Installationen und Logins des Nutzers. Der kostenlose Plan hat unbegrenzt viele Agenten. Download: https://agentvera.dev/de/download/ · Preise: https://agentvera.dev/de/pricing/