Claude Code lokal mit Ollama und Gemma 4 Guide

Letztes Update: 18. April 2026 – dieser Beitrag wurde inhaltlich überarbeitet. URL und Veröffentlichungsdatum bleiben unverändert. TL;DR: Das Claude-Code-Terminal-Tool lässt sich seit Ollama v0.14.0 auch mit offenen Modellen wie Gemma 4 oder Qwen3-Coder betreiben. Was man dabei bekommt, ist nicht Claude – sondern das Framework mit einem anderen Modell dahinter. Die Intelligenz kommt vom Modell, nicht vom CLI. Für Routine-Coding auf eigenen Repos kann das reichen. Als Ersatz für Claude Opus oder Sonnet taugt es aktuell nicht – und der reale Hardware-Bedarf wird häufig unterschätzt.

Worum es wirklich geht – und worum nicht

Das Setup wird oft so beschrieben so, als würde man Claude selbst auf dem Rechner betreiben. Das ist falsch. Was passiert: Claude Code ist ein CLI-Framework, das mit einem API-Endpunkt im Anthropic-Format spricht. Ollama stellt genau diesen Endpunkt lokal bereit – und routet die Anfragen an irgendein offenes Modell weiter. Man bekommt also das Claude-Code-Frontend mit einem anderen Gehirn. Ob dieses Gehirn Claude Opus 4.6, Gemma 4 31B oder Qwen3-Coder heißt, entscheidet über die tatsächliche Qualität. Der wichtigste Satz dieses Artikels: Die Intelligenz kommt vom Modell, nicht vom Framework.

Was Claude Code lokal wirklich ist

Claude Code ist Anthropics agentisches CLI-Tool – ein Terminal-Frontend, das Dateien liest, Code schreibt, Kommandos ausführt und sich durch Repos navigiert. Die eigentliche Intelligenz kommt aus der API dahinter. Im Standardbetrieb spricht das CLI mit Anthropics Cloud und nutzt dort Claude Sonnet, Opus oder Haiku. Seit dem 16. Januar 2026 implementiert Ollama die Anthropic Messages API als lokalen Endpunkt. Damit lässt sich Claude Code auf lokale Modelle umleiten. Was man an der Stelle einsetzt, ist ein völlig anderes Modell – häufig deutlich kleiner, deutlich schwächer und mit anderen Stärken als Anthropics Frontier-Modelle. Ollama empfiehlt im eigenen Blogpost explizit nicht Gemma 4, sondern gpt-oss:20b und qwen3-coder als Claude-Code-Backend. Das ist ein wichtiger Hinweis.

Welches Modell passt: Gemma 4 oder Qwen3-Coder?

Für reines Coding ist Qwen3-Coder in aktuellen Benchmarks die stärkere Wahl. Qwen 3.5 erreicht 72,4 Prozent auf SWE-bench – dem Standard-Benchmark für reale Software-Engineering-Aufgaben, bei dem Modelle GitHub-Issues in echten Repos lösen müssen. Google veröffentlicht für Gemma 4 31B auf den offiziellen Seiten (Hugging Face, Google AI Developers) keine SWE-bench-Zahlen. Das ist bei einem Modell, das als „enhanced coding capabilities" beworben wird, auffällig. Gemma 4 glänzt dagegen in anderen Disziplinen: algorithmische Coding-Probleme (LiveCodeBench v6: 80,0 Prozent), Competitive Programming (Codeforces ELO: 2.150), Mathematik (AIME 2026: 89,2 Prozent), Reasoning (MMLU Pro: 85,2 Prozent). Das sind beeindruckende Werte, aber sie messen andere Fähigkeiten als das, was Claude Code im Alltag von einem Coding-Agenten verlangt: Codebase-Navigation, Patch-Generierung, Tool-Use über viele Schritte. Praktische Empfehlung: Wer primär codet, sollte zuerst qwen3-coder testen. Gemma 4 ist die bessere Wahl, wenn man ein Allround-Modell mit Multimodalität und starkem Reasoning will.

Wie groß ist die Qualitätslücke zu Claude Opus?

Realistisch ist die Lücke erheblich. Claude Opus 4.6 und GPT-5.2 liegen auf den meisten Reasoning- und Coding-Benchmarks sieben bis zehn Punkte vor Gemma 4 31B. Auf dem Artificial Analysis Intelligence Index v4.0 erreicht Gemma 4 31B (Reasoning-Modus) einen Score von 39. Claude Opus 4.6 und GPT-5.2 liegen dort im Bereich 60+. Auf LMArena erreicht Gemma 4 31B einen Score von rund 1.452 – solide, aber Frontier-Modelle liegen bei 1.500+. Wichtiger noch: Gemma 4 zeigt in agentischen Workflows bekannte Schwächen. Tool-Call-Loops, in denen das Modell immer wieder dieselben Tools aufruft ohne Fortschritt, treten bei lokalen Modellen deutlich häufiger auf als bei Frontier-Modellen. Bei langen Kontexten fällt die Qualität zusätzlich ab (MRCR v2 bei 128K Kontext: Gemma 4 31B = 66,4 Prozent, 26B MoE = 44,1 Prozent). Ehrlicher Vergleich: Gemma 4 ist kein Ersatz für Opus. Es ist ein solider Copilot für klar umgrenzte, kürzere Aufgaben auf bekanntem Code.

Wie wird das Setup eingerichtet?

Die folgenden Schritte basieren auf der offiziellen Ollama-Dokumentation vom 16. Januar 2026 und funktionieren auf macOS, Linux und Windows.

Schritt 1: Ollama installieren

macOS / Linux: macOS via Homebrew: Nach der Installation läuft der lokale API-Server unter http://localhost:11434.

Schritt 2: Claude Code installieren

macOS / Linux / WSL: Windows PowerShell:

Schritt 3: Modell herunterladen

Empfehlung für Coding auf normalem Laptop: Alternative – Gemma 4 E4B (Allround, kompakt): Für Workstations mit 24+ GB VRAM:

Schritt 4: Umgebungsvariablen korrekt setzen

An dieser Stelle kursieren falsche Variablen. Korrekt laut offizieller Ollama-Dokumentation: Nicht ANTHROPICAPIKEY und nicht irgendein Dummy-String. Für Dauerbetrieb: in ~/.zshrc oder ~/.bashrc eintragen.

Schritt 5: Claude Code starten

Ollama empfiehlt eine Kontextlänge von mindestens 32.000 Token – Claude Code ist sehr kontextintensiv.

Warum ist der Attribution-Header-Fix Pflicht?

Ab Claude-Code-Version 2.1.36 sendet das CLI einen x-anthropic-billing-header mit jeder Anfrage. Dieser Header ändert sich pro Request und invalidiert bei lokalen Inferenz-Servern den KV-Cache. Folge: Bis zu 90 Prozent langsamere Inferenz, weil jeder Prompt komplett neu verarbeitet werden muss. Der Fix funktioniert nicht als Shell-Variable, sondern muss in die Claude-Code-Konfiguration: Die zweite Variable unterdrückt Telemetrie, die sonst bei unbekannten Endpunkten 404-Schleifen erzeugt (auf macOS bis hin zu Port-Exhaustion).

Welche Hardware brauche ich wirklich?

An dieser Stelle wird gerne geschummelt. Die oft zitierte Aussage „läuft ab 6 GB RAM" gilt für die kleinste Variante E2B, nicht für das 31B-Modell. Die realen Anforderungen pro Modell: • gemma4:e2b – 7,2 GB auf Disk, ~4 GB VRAM (Q4), ~6–8 GB RAM mit Kontext. Moderne Laptops, auch CPU-only. • gemma4:e4b – 9,6 GB auf Disk, ~6 GB VRAM, ~10–12 GB RAM mit Kontext. 16 GB RAM Notebook. • gemma4:26b – 18 GB auf Disk, ~14 GB VRAM, ~20 GB VRAM mit Kontext. RTX 3090/4090 oder M-Series 32 GB. • gemma4:31b – 20 GB auf Disk, 17–20 GB VRAM nur fürs Modell, 24–32 GB VRAM mit Kontext. RTX 4090 24 GB / 5090 32 GB / M3 Max 36+ GB. Das 31B-Modell hat zusätzlich einen festen KV-Cache von 3,6 GB (Sliding Window Attention), der immer reserviert werden muss. Mit nutzbarem Kontextfenster landet man daher bei mindestens 24 GB VRAM – unquantisiert sogar bei 96 GB (RTX Pro 6000 Klasse). Realistische Token-Raten: Auf Apple Silicon M3 Max mit 36 GB Unified Memory generiert das 31B-Modell typischerweise 10–15 Token pro Sekunde. Das 26B-MoE kommt auf etwa 40 Token pro Sekunde, weil nur 3,8 Milliarden Parameter pro Token aktiv sind. Die E-Varianten laufen auf CPU mit 10–20 Token pro Sekunde. Wer die 31B-Variante auf einer 16-GB-Karte „zum Laufen bringt", landet im RAM-Offloading und fällt auf unter 1 Token pro Sekunde. Das ist technisch möglich, praktisch aber unbenutzbar.

Wann ergibt das lokale Setup Sinn?

Das lokale Setup ist stark in klar umrissenen Szenarien und schwach, sobald die Aufgaben komplexer werden. Sinnvolle Anwendungsfälle: • Routine-Coding auf bekannten Repos: Refactoring, Unit-Tests, Boilerplate-Generierung, einfache Bugfixes. Hier reichen auch kleinere Modelle. • Compliance-kritische Umgebungen: Code darf den eigenen Rechner nicht verlassen. Das ist in vielen Unternehmen ein harter Dealbreaker für Cloud-APIs. • Offline-Arbeit: Im Zug, im Flugzeug, ohne stabile Verbindung. • Token-Sparen bei hoher Request-Frequenz: Wer täglich viele Turns macht, kommt bei Cloud-APIs schnell auf dreistellige Beträge pro Monat. Wenig sinnvoll wird es bei: • Komplexer Multi-Step-Arbeit: Architektur-Entscheidungen, System-Design, große Refactorings über viele Dateien. Hier fällt die Qualität lokaler Modelle spürbar ab. • Agentischen Workflows mit vielen Tool-Calls: Tool-Call-Loops und abgebrochene Reasoning-Ketten sind hier ein bekanntes Problem. • Langen Kontexten über 64K Token: Lokale Modelle verlieren bei wachsendem Kontext überproportional an Qualität. Der pragmatische Ansatz heißt Split-Stack: Lokal für Routine, Cloud für harte Fälle. Die Base-URL zwischen Cloud und Local umschalten dauert eine Sekunde.

Alternative zu Ollama

LM Studio bietet seit Version 0.4.1 ebenfalls einen Anthropic-kompatiblen /v1/messages-Endpunkt auf Port 1234. Die Umgebungsvariablen heißen dort ANTHROPICAUTHTOKEN=lmstudio. Vorteil: grafische Oberfläche. Empfohlene Kontextgröße: mindestens 25.000 Token. llama.cpp ist die Variante mit maximaler Kontrolle über Quantisierung, KV-Cache-Typ und Batch-Size. Nativer Anthropic-Messages-API-Support ist enthalten. Mehr Handarbeit, dafür kein Overhead.

FAQ: Häufig gestellte Fragen

Bekomme ich mit „Claude Code lokal" wirklich Claude? Nein. Du bekommst das Claude-Code-CLI als Frontend und ein komplett anderes, in der Regel deutlich schwächeres Modell als Backend. Die Claude-Modelle (Opus, Sonnet, Haiku) laufen ausschließlich auf Anthropics Servern und sind nicht öffentlich als Download verfügbar. Welches Modell ist das beste für Claude Code? Für reines Coding empfiehlt Ollama qwen3-coder. Qwen 3.5 führt mit 72,4 Prozent auf SWE-bench unter den offenen Modellen. Gemma 4 ist besser, wenn man Allround-Reasoning, Multimodalität oder Mathematik braucht. Reichen 16 GB VRAM für Gemma 4 31B? Nein, nicht komfortabel. Q4-quantisiert braucht das Modell allein 17–20 GB, plus 3,6 GB festen KV-Cache. Mit 16 GB landet man schnell im RAM-Offloading und bei Token-Raten unter 1 pro Sekunde. 24 GB sind das praktische Minimum, 32 GB komfortabel. Kann ich zwischen lokalem und Cloud-Modell wechseln? Ja. ANTHROPICBASEURL entscheidet, wohin Claude Code seine Requests sendet. unset ANTHROPICBASEURL schaltet zurück auf die Anthropic-Cloud. Warum ist lokale Inferenz oft so langsam? In den meisten Fällen am Attribution Header ab Claude-Code 2.1.36. Ohne den Fix in ~/.claude/settings.json verlangsamt er die Inferenz um bis zu 90 Prozent. Ist Gemma 4 31B so gut wie Claude Sonnet 4.6? Nein. Auf den meisten Benchmarks liegen Frontier-Modelle wie Claude Opus 4.6 oder GPT-5.2 sieben bis zehn Punkte vor Gemma 4 31B. Bei komplexen, mehrstufigen Coding-Aufgaben ist der Unterschied in der Praxis klar spürbar. Was ist mit dem FoodTruck-Bench, auf dem Gemma 4 angeblich Sonnet schlägt? FoodTruck-Bench ist eine Business-Simulation (Food-Truck-Betrieb in Austin, TX), kein Coding-Benchmark. Die dortigen Ergebnisse sagen nichts über die Software-Engineering-Fähigkeiten eines Modells aus. Für Claude-Code-Workloads sind SWE-bench, Aider und LiveCodeBench die relevanten Metriken.

Fazit

Das Claude-Code-CLI mit offenen Modellen zu betreiben, ist eine sinnvolle Ergänzung – nicht ein Ersatz. Wer versteht, was er bekommt (ein solides 30-B-Parameter-Modell mit Claude-Code-Frontend, nicht Claude selbst), wird mit Qwen3-Coder oder Gemma 4 im Alltag für Routine-Aufgaben gut bedient. Wer glaubt, für 0 Euro eine Opus-Alternative zu bekommen, wird enttäuscht – und macht den Einstieg schwerer, als er sein müsste. Die ehrliche Version der Ansage lautet: Split-Stack. Lokal für das, was lokal gut geht. Cloud für den harten Rest. Und bei allen Zahlen, die einem online begegnen: erst checken, welches Modell und welcher Benchmark gemeint sind, bevor man die Hardware bestellt. Verifizierte Quellen: Ollama Blog (Claude Code with Anthropic API compatibility, 16.01.2026), Ollama Library (gemma4 Modellübersicht), Google AI Developers (Gemma 4 Model Card), Hugging Face (google/gemma-4-31B), The Kaitchup (Gemma 4 31B Memory & KV Cache Analyse), Artificial Analysis (Gemma 4 31B Performance Index), Aurigait (Gemma 4 vs. Qwen 3.5 Benchmarks), LM Studio Blog (Anthropic API Kompatibilität), Claude-Code-Router PR 1220 (Attribution-Header-Fix).