Claude Code auf einem lokalen Modell ist jetzt 2x schneller (Dank Ollama + MLX)
Ollama 0.19 verdoppelt die lokale Inferenz-Geschwindigkeit auf Apple Silicon dank MLX. Ich habe es mit Claude Code und Qwen 3.5 getestet. So hat sich das für Coding Agents verändert.
Kemal Esensoy·aktualisiert am April 27, 2026
Ich verbringe viel Zeit in Claude Code. Es ist das Tool, das den Großteil meines Coding-Workflows antreibt. Und jeden Monat erinnert mich die API-Rechnung daran, wie viel Zeit genau.
Als Ollama Version 0.19 mit Apples MLX Framework veröffentlichte, habe ich nicht nur den Blogpost gelesen. Ich habe es auf meinen Mac Studio gezogen, Claude Code darauf gerichtet und die gleichen Aufgaben laufen lassen, für die ich vorher Anthropic bezahlt habe. Hier ist, was tatsächlich passiert ist.
Warum mich lokale Coding Agents überhaupt interessieren
Ich sag es mal so: wenn du Claude Code ein paar Stunden am Tag nutzt, fünf Tage die Woche, summieren sich die API-Kosten. Schnell. Wir reden von hunderten Dollar pro Monat für eine Ein-Mann-Agentur. Das ist echtes Geld.
Aber es geht nicht nur um die Rechnung. Ich reise. Ich arbeite aus Zügen und Flugzeugen. Ich hatte Projekte, bei denen Kundendaten aus Compliance-Gründen die Maschine nicht verlassen durften. In all diesen Fällen wäre ein lokales Modell, das mit meinem Workflow mithalten kann, ein Gamechanger.
Das Problem war immer das gleiche: lokale Modelle fühlten sich an wie gegen eine Wand zu reden. Du tippst einen Prompt, wartest, schaust dem Cursor beim Blinken zu, und bekommst irgendwann etwas zurück, das... okay war. Brauchbar für einfache Sachen. Bei weitem nicht schnell genug für den Hin-und-Her-Rhythmus, der Coding Agents nützlich macht.
Das hat sich letzten Monat geändert.
Was Ollama 0.19 wirklich verändert hat
Das ist kein kleines Versions-Update. Ollama 0.19 hat das gesamte Inference-Backend auf Apple Silicon ausgetauscht. Statt llama.cpp (das der Community jahrelang gute Dienste geleistet hat) läuft Ollama jetzt auf Apples MLX Framework.
Warum ist das wichtig? MLX wurde speziell für Apples Unified Memory Architektur gebaut. Auf einem Mac teilen sich CPU und GPU den gleichen Speicherpool. llama.cpp wurde für die CUDA-Welt designed, wo CPU- und GPU-Speicher getrennt sind, also mussten Daten hin und her kopiert werden. MLX überspringt das komplett.
Zusätzlich zum Backend-Wechsel brachte Ollama 0.19 NVFP4 Quantisierung mit. Das ist NVIDIAs Format, um Modelle in weniger Speicher zu quetschen und dabei die Ausgabequalität nah an voller Präzision zu halten. Das praktische Ergebnis: du kannst größere Modelle auf der gleichen Hardware laufen lassen, und die Ergebnisse stimmen mit dem überein, was Cloud-Inference-Anbieter liefern.
Das Caching wurde auch schlauer. Ollama nutzt jetzt seinen Cache über Konversationen hinweg wieder, speichert Snapshots an intelligenten Stellen im Prompt und hält gemeinsame Präfixe länger am Leben. Für Coding Agents, die immer wieder den gleichen System-Prompt abfeuern, ist das ein großer Unterschied.
Die Benchmarks, die wirklich zählen
Ollamas offizielle Zahlen auf einem M5 Max sind beeindruckend: 1.810 Tokens pro Sekunde beim Prefill (vorher 1.154) und 112 Tokens pro Sekunde beim Decode (vorher 58). Das sind 57% und 93% Verbesserung, mit Qwen3.5-35B-A3B in NVFP4.
Aber ich habe keinen M5 Max. Ich habe einen M1 Max Mac Studio mit 64GB Unified Memory. Und ehrlich gesagt war der Unterschied auf meiner Maschine sogar noch dramatischer: die Decode-Geschwindigkeit ging von 3,19 Tokens pro Sekunde mit dem alten llama.cpp Backend auf 23,39 Tokens pro Sekunde mit MLX. Das sind ungefähr 7x schneller. Gleiche Maschine, gleiches Modell, gleicher Prompt.
Bei 23 Tokens pro Sekunde bekommst du Antworten schnell genug, um eine echte Konversation aufrechtzuerhalten. Es ist nicht Sonnet-Qualität, aber die Geschwindigkeitslücke zwischen lokal und Cloud hat sich dramatisch geschlossen. Benchmarks erzählen nur einen Teil der Geschichte. Der echte Test ist, ob du es tatsächlich für die Arbeit nutzen kannst.
Einrichtung: Von Null zum lokalen Coding Agent
Das Setup ist überraschend einfach. Lade Ollama 0.19 herunter, dann:
ollama launch claude --model qwen3.5:35b-a3b-coding-nvfp4
Das startet eine Ollama-Instanz mit eingebauter Anthropic API Kompatibilität. Seit Ollama v0.14 spricht es das gleiche API-Format wie Claude, also braucht Claude Code keinen Proxy und keine spezielle Konfiguration. Du richtest ANTHROPIC_BASE_URL auf deine lokale Ollama-Instanz und fertig.
Das funktioniert auch mit LM Studio (v0.4.1+), llama.cpp direkt oder vLLM. Die Kernanforderung ist überall gleich: das Modell braucht ein 64k+ Token Context Window und Tool Calling. Ohne Tool Calling können Coding Agents nicht arbeiten.
Ein wichtiger Hinweis: du brauchst einen Mac mit mindestens 32GB Unified Memory. Das Qwen3.5-35B-A3B Modell hat eine Mixture-of-Experts-Architektur, was hilft (nur 3B Parameter sind pro Token aktiv), aber das gesamte Modell muss trotzdem in den Speicher passen. Wenn dich interessiert, wie Claude Code unter der Haube mit Tools kommuniziert: MCP ist das Protokoll, das es möglich macht.
Qwen 3.5 vs 3.6: Welches Modell du tatsächlich nutzen solltest
Ollama 0.19 wurde für Qwen3.5-35B-A3B optimiert. Es ist ein Mixture-of-Experts-Modell: 35 Milliarden Parameter insgesamt, aber nur 3 Milliarden aktiv pro Token. Deshalb läuft es so schnell auf Consumer-Hardware. Du bekommst das Wissen eines 35B-Modells mit der Geschwindigkeit eines 3B-Modells.
Aber hier kommt's: Qwen3.6-35B-A3B ist am 16. April erschienen. Es erreicht 73,4% auf SWE-bench Verified und 51,5 auf Terminal-Bench 2.0. Das sind ernsthafte Zahlen für ein Modell, das du auf einem MacBook laufen lassen kannst.
Für einfache Codegenerierung, Tests schreiben und Refactoring innerhalb einer Datei sind beide Modelle überraschend gut. Wo sie an ihre Grenzen stoßen, ist komplexes Multi-File-Reasoning, Navigation in unbekannten Codebasen und das Finden subtiler Bugs, die tiefes Kontextverständnis erfordern. Für solche Arbeit macht ein Spec-Driven-Ansatz mit einem Frontier-Modell immer noch mehr Sinn.
Was das für Solo-Entwickler wirklich ändert
Folgendes passiert, wenn die Grenzkosten bei 0 Dollar liegen: du hörst auf zu rationieren.
Wenn jeder API-Call Geld kostet, entwickelst du die Gewohnheit, mental abzuwägen, ob ein Prompt "es wert" ist. Soll ich es bitten, diese Funktion zu refactoren, oder mach ich's einfach selbst? Ist diese Frage komplex genug, um die Tokens zu rechtfertigen? Mit einem lokalen Modell verschwindet diese Reibung. Du fragst einfach. Du experimentierst. Du probierst Dinge aus, die du nicht versucht hättest, als jeder Versuch ein paar Cent gekostet hat.
Offline Coding ist jetzt auch Realität. Ich habe letzte Woche Teile eines Kundenprojekts auf einem Flug geschrieben, mit Ollama lokal. Kein WLAN, keine API, nur mein Mac und ein lokales Modell. Boilerplate-Generierung und Test-Scaffolding hat es perfekt erledigt.
Es sind nicht nur Coding Agents. Ich habe WunderType gebaut, eine macOS Menu-Bar-App, die Text in jeder App mit Ollama lokal korrigiert und umschreibt. Das MLX-Update hat es spürbar schneller gemacht. Was sich vorher wie eine Pause angefühlt hat, fühlt sich jetzt sofort an. Wenn dich interessiert, warum ich es gebaut habe, hier ist die Geschichte.
Aber seien wir ehrlich: lokale Modelle machen andere Fehler als Cloud-Modelle. Sie halluzinieren andere Dinge, übersehen andere Grenzfälle und scheitern auf Arten, die du nicht erwartest, wenn du von Sonnet oder Opus verwöhnt bist. Die Fehler sind billiger, aber es sind trotzdem Fehler.
Mein ehrliches Fazit nach einer Woche
Nach einer Woche täglicher Nutzung dieses Setups: hier ist mein Stand.
Gut für: schnelle Edits, Boilerplate-Generierung, Tests schreiben, Code erklären, einfache Refactors, Inline-Dokumentation und alles, wo Geschwindigkeit wichtiger ist als Tiefe.
Noch nicht bereit für: komplexes Multi-Step-Reasoning über Dateien hinweg, Debugging subtiler Probleme in unbekanntem Code oder alles, was das tiefe Kontextverständnis braucht, in dem Frontier-Modelle glänzen.
Der echte Durchbruch ist nicht, Cloud-Modelle komplett zu ersetzen. Es ist der 80/20-Split: lokal für die 80% der Aufgaben, die keine Frontier-Intelligenz brauchen, API für die 20%, die sie brauchen. Allein das kann deine monatliche API-Rechnung deutlich senken.
Das ist das erste Mal, dass sich ein lokaler Coding Agent im Alltag brauchbar anfühlt, nicht nur für Demos oder Wochenend-Experimente. Als ich Claude Code 20 Minuten lang ein Wochenendprojekt redesignen ließ, lief ein Frontier-Modell. Könnte ein lokales Modell das gleiche? Noch nicht. Aber mit 7x der Geschwindigkeit auf meinem M1 Max kommt es jeden Monat näher.
Wenn du eine Agentur betreibst, freelancst oder einfach alleine Dinge baust und Kosten senken willst ohne Fähigkeiten einzubüßen, ist das einen Versuch wert. Lass uns reden, wenn du Hilfe bei der Einrichtung eines AI-gestützten Entwicklungs-Workflows brauchst, der für dein Budget Sinn macht.
Über den Autor
Kemal Esensoy
Kemal Esensoy, Gründer von Wunderlandmedia, begann seine Karriere als freiberuflicher Webentwickler und Designer. Er führte Web-Design-Kurse mit über 3.000 Studenten durch. Heute leitet er eine preisgekrönte Full-Stack-Agentur, die sich auf Webentwicklung, SEO und digitales Marketing spezialisiert hat.