Claude Code mit lokalem Modell auf Apple Silicon

Lokale Inference für Claude Code scheitert selten am Speicher. Sie scheitert an der Zeit pro Turn. Ich hab das am 28. Mai 2026 auf einem M5 Max mit 128 GB gemessen: ein dichtes 27B-Modell in MLX-4bit liefert 25 bis 29 Token pro Sekunde und denkt vor jeder Antwort nach, bei den drei größeren Aufgaben 332 bis 965 Tokens lang. Die Entscheidung hängt an drei Dingen: Dense oder MoE, erzwungenes Nachdenken, und wie zuverlässig das Modell Werkzeuge aufruft. Die Modellnamen weiter unten sind ein Stand vom Mai 2026, die drei Kriterien nicht.

Was ich gemessen habe

Hardware: M5 Max, 40-Core-GPU, 128 GB Unified Memory. Modell: qwopus3.6-27b-v2-mlx, dicht, 27 Milliarden Parameter, MLX-4bit, 15,15 GB auf der Platte und 14,11 GiB geladen. Engine: LM Studio, Kontextfenster 16384, Temperatur 0,2. Ladezeit 3,73 Sekunden. Auf dem M4 Pro davor war mir derselbe Versuch mit einem FP4-Quant bei rund 0,1 Token pro Sekunde Prefill um die Ohren geflogen, weil dem Chip die Neural Accelerators fehlen, die Apple für die MLX-Beschleunigung nennt.

Vier Aufgaben, alle aus echter Arbeit: eine Funktion schreiben, ein Werkzeug aufrufen, sauberes JSON ausgeben, einen Bug finden.

| Aufgabe | Ergebnis | Zeit | Tokens (davon Denken) | |---|---|---|---| | Code schreiben (Levenshtein-Sortierung) | erst abgeschnitten, im zweiten Lauf korrekt | 46 s | 1328 (965) | | Werkzeug aufrufen (TODOs suchen) | valider Call | 4 s | 73 (37) | | JSON-Struktur ausgeben | korrekt | 17 s | 356 (332) | | Bugfix (async in forEach) | korrekte Diagnose plus Fix | 39 s | 927 (850) |

4 von 4 inhaltlich korrekt. Das Modell kann es. Nur eben nicht in der Zeit, die agentisches Arbeiten braucht.

Im ersten Lauf der ersten Aufgabe stand das Token-Budget auf 1400. Das Modell hat 1399 Tokens lang gedacht und keine einzige Zeile Code geschrieben. Beim zweiten Versuch mit 3072 hat es von selbst bei 1328 aufgehört. max_tokens ist eine Obergrenze, kein Ziel. Ein höheres Limit erzeugt keinen längeren Output, es verhindert nur das Abschneiden.

Die Einstellung, die sonst alles auffrisst

Wenn du es probierst, setz das hier, bevor du an irgendeiner anderen Schraube drehst:

export CLAUDE_CODE_ATTRIBUTION_HEADER=0

Claude Code hängt sonst pro Request einen Header an, der das server-seitige Prompt-Caching bustet. Der berichtete Effekt liegt bei rund 90 Prozent Verlangsamung. So steht es in Issue #50085, gemeldet von wadabum:

"using any sort of custom ANTHROPIC_BASE_URL has a good chance to make practically anything uncacheable."

Ohne diese Zeile ist es gleichgültig, welches Modell du nimmst.

Zwei weitere Punkte aus derselben Kategorie: der Systemprompt plus die Werkzeugdefinitionen belegen etwa 20.000 bis 25.000 Tokens, bevor du das erste Wort tippst. Ein Modell mit 32K Kontext ist damit eine Demo, keine Arbeitsumgebung. Und wenn du Subagenten nutzt, entscheidet eine eigene Variable, welches Modell die bekommen. Falls du daneben noch eine zweite Session im selben Arbeitsverzeichnis laufen hast, kommt ein ganz anderes Problem dazu, das ich in zwei Sessions, ein Arbeitsverzeichnis beschrieben habe.

Kriterium 1: Dense oder MoE

25 bis 29 Token pro Sekunde sind für ein dichtes 27B-Modell in 4-bit auf dieser Hardware kein Ausreißer, sondern der Normalfall. Bei einem Mixture-of-Experts derselben Größenordnung, also etwa 35 Milliarden Parameter mit rund 3 Milliarden aktiven, wäre das 2- bis 4-Fache drin, weil pro Token nur ein Bruchteil der Gewichte rechnet. Gemessen hab ich das nicht, das steht so in der Recherche, die ich vor dem Test gemacht habe.

Das ist der einzige der drei Punkte, den du allein über die Modellwahl löst. Kein Flag, keine Einstellung, keine schnellere Engine holt dir den Faktor zurück, wenn die Architektur dicht ist.

Kriterium 2: die Thinking-Tax

Das getestete Modell hat vor jeder Antwort nachgedacht: 37 Tokens beim reinen Werkzeugaufruf, 332 bis 965 bei allem anderen. Auch bei einer Frage, die mit einem Einzeiler beantwortet ist. /no_think wurde ignoriert, danach waren es immer noch 668 Reasoning-Tokens.

Dense-Speed mal Thinking-Tax ergibt 4 bis 46 Sekunden pro Turn. Ein Claude-Code-Task, der Dateien liest, editiert, Tests laufen lässt und nachbessert, hat 10 bis 30 Turns. Das sind 10 bis 25 Minuten für etwas, das bei mir mit Opus in einer bis zwei Minuten durch ist. Bei drei solchen Tasks am Vormittag geht sich das nicht mehr aus.

Deshalb ist die Suchrichtung nicht "welches Modell ist am klügsten", sondern "welches Modell antwortet ohne Vorlauf". Ein Modell ohne erzwungenen Thinking-Modus ist für agentische Arbeit mehr wert als ein paar Punkte SWE-bench.

Kriterium 3: Werkzeuge, nicht Code

Der Punkt, der am seltensten geprüft wird, ist der, an dem lokale Modelle am deutlichsten verlieren. Code schreiben können sie. Werkzeuge in der richtigen Reihenfolge aufrufen, das Ergebnis lesen und daraus den nächsten Schritt ableiten, das können sie schlechter.

Die Zahlen dazu stammen aus der Web-Recherche zum Test, nicht aus meiner Messung, also Richtwerte: die lokal lauffähigen Modelle liegen bei rund 62 bis 73 Prozent auf SWE-bench Verified, gegen 87,6 Prozent bei Opus und 79,6 Prozent bei Sonnet. Bei reiner Tool-Orchestrierung ist der Abstand größer. Um wie viel, sag ich nicht in Zahlen: die Werte, die ich dazu gefunden habe, hängen an keinem Benchmark, den ich benennen kann.

Der typische Fehlerfall ist unangenehm leise: das Modell schreibt in Prosa, was es tun würde, statt den Werkzeugaufruf abzusetzen. Kein Fehler, kein Abbruch, nur ein Schritt, der nie passiert ist. Wer lokal fährt, braucht deshalb dieselben Prüfstufen wie sonst auch, nur konsequenter. Wie diese Kette bei mir aussieht, steht in sechs Stufen vor dem Schreibzugriff.

Was lokal wirklich spart

Realistisch ist eine 3- bis 5-fache Ersparnis, also grob 15 bis 50 Dollar im Monat statt 100 bis 200. Gerechnet, nicht gemessen, und nur im Hybrid-Betrieb: lokal für Routine und Subagenten, das große Modell für die langen Läufe. Die beworbenen 10x kommen aus Rechnungen, die den Vollausbau lokal annehmen und die Wartezeit nicht mitzählen.

Bevor du diesen Weg gehst, lohnt die Gegenrechnung mit dem, was du heute tatsächlich zahlst. In den meisten Fällen ist der größere Hebel nicht der Modellanbieter, sondern wie viel Kontext du pro Turn verheizt. Im AI Builder-Guide ist das eine eigene Lektion: Messpunkte, Budget pro Task, und die Stellen, an denen Kosten unbemerkt entstehen.

Wer aus Datenschutz- oder Airgap-Gründen lokal fährt, bleibt dabei. Wer nur wegen der Rechnung kommt, kehrt meist zurück, sobald der erste längere Task 20 Minuten gebraucht hat. Das ist kein Messwert, das lese ich in den Community-Threads.

Häufige Fragen

Brauche ich 128 GB?

Nein, aber die Speichergröße entscheidet, welche Klasse überhaupt in Frage kommt. Faustregel aus meiner Entscheidungsmatrix: die Modelldatei soll höchstens 60 bis 70 Prozent des RAM belegen, der Rest geht an macOS, den KV-Cache und die Apps. Mit 16 GB bist du bei 8B bis 14B in 4-bit, mit 24 GB kommen 24B-Modelle dazu, ab 32 GB wird ein MoE mit wenigen aktiven Parametern realistisch. Auf 128 GB ist die Speichergröße kein Kriterium mehr, dort entscheiden nur noch Qualität, Tool-Calls und Geschwindigkeit.

Ollama oder LM Studio?

Beide sprechen den Anthropic-Endpunkt inzwischen nativ, Claude Code dockt also ohne Router an. Der Unterschied, der in langen Sessions zählt: Prompt-Caching. Ohne Caching zahlst du den kompletten Systemprompt bei jedem Turn neu, und der ist, siehe oben, fünfstellig. Gemessen hab ich diesen Test über LM Studio.

Und wenn das Modell gut klingt, aber niemand es kennt?

Dann schau, worauf es trainiert wurde. Das Modell in meinem Test war auf Traces eines großen kommerziellen Modells destilliert, also genau der Fall, den dessen Nutzungsbedingungen ausschließen. Für einen Benchmark habe ich das in Kauf genommen. Für den Dauerbetrieb ist das kein Kandidat.

Was davon in drei Monaten noch stimmt

Über meiner eigenen Messnotiz steht seit dem Tag der Messung dieser Satz:

VOR WIEDERVERWENDUNG NEU RECHERCHIEREN. Dieser Snapshot ist vom 2026-05-28. Lokale Modelle und Inference-Engines ändern sich im Wochentakt.

Das gilt für die Modellnamen und die Versionsstände, und deshalb stehen sie in diesem Artikel nur als Beispiel eines Zeitpunkts. Was bleibt, ist die Reihenfolge der Prüfung: erst die Architektur (dicht oder MoE), dann das Antwortverhalten (denkt es ungefragt), dann die Werkzeugtreue. Wer diese drei Fragen vor dem Download beantwortet, spart sich einen Nachmittag.

Eine zweite Zeile aus derselben Sammlung, aufgeschrieben nach dem Fehlschlag auf dem M4 Pro:

Wenn der Original-Hersteller (hier Apple) eine Hardware-Generation als Voraussetzung nennt, vertraue dem mehr als Tech-Blogs die "läuft überall" sagen.

Das war die teuerste Lektion aus dem Versuch davor, und sie hat mit lokalen Modellen nur am Rand zu tun.

Falls du an diesem Punkt merkst, dass dir das alles zu tief geht, und du erst einmal sehen willst, wie die Arbeit mit einem Agenten überhaupt abläuft: der Gratis-Kurs Werkbank beantwortet die Frage vor der Modellwahl.