Lokal statt Credit-Limit – Mein Setup aus Qwen3.6-27B, OpenCode, LSP und CodeGraph

Das Problem: Wenn AI-Credits zum Flaschenhals werden

Nachdem KI-Anbieter wie GitHub Copilot ihr Preismodell auf AI-Credits umgestellt haben, bin ich ziemlich schnell an meine Limits gekommen. Vor allem mit dem Ansatz, den ich in meiner Agentic-Coding-Serie beschrieben habe. Wie man dort herauslesen kann, liegt der Fokus darauf, dass die KI-Agenten ihre Aufgaben in einem strukturierten Prozess abarbeiten. Die Ergebnisse werden dabei fortlaufend in Dokumente geschrieben – das geht jedoch massiv auf den Token-Verbrauch. Der Grund dafür ist strukturell und in dieser Analyse zu Code Graphs gut beschrieben: Ohne strukturierten Index liest ein Agent für jede Frage aufs Neue ganze Dateien ein. Also musste eine neue Lösung her, die es mir ermöglicht, weiterhin performant und qualitativ hochwertige Ergebnisse zu erzielen, ohne ständig mein AI-Credit-Limit in kürzester Zeit zu sprengen. Dazu habe ich mir überlegt, ob ich einige Aufgaben aus meiner Agentic-Coding-Serie auf kleinere, spezialisierte LLMs auslagern kann, um dann die großen und schweren Aufgaben gezielt auf die mächtigeren LLMs zu verteilen. Hier ist das lokale, hochperformante Setup, das mein Problem gelöst hat:

Der Kern des Setups: Die Werkzeuge im Detail

Um maximale Effizienz und Unabhängigkeit von Cloud-Kosten zu erreichen, greife ich auf eine Kombination aus modernsten lokalen Modellen, intelligenten Protokollen und Graph-Indizes zurück.

1. Das Gehirn: Qwen3.6 (27B)

Für die komplexen Aufgaben, die tiefes logisches Verständnis und Code-Synthese erfordern, setze ich auf das Qwen3.6-27B Modell des Qwen-Teams von Alibaba Cloud. Dieses dichte 27-Milliarden-Parameter-Modell wurde speziell für "Agentic Coding" und multischrittbasiertes Problemlösen optimiert. Die Modellkarte nennt ein Kontextfenster von 262.144 Token – nativ, erweiterbar auf gut eine Million – und einen Thinking Mode, der standardmäßig aktiv ist: Das Modell schreibt seine Überlegungen in einen <think>-Block, bevor es die eigentliche Antwort formuliert. Wie nah es damit an die geschlossenen Cloud-Modelle herankommt, ordne ich im Fazit mit konkreten Zahlen ein – hier zählt erst einmal, dass es komplett lokal auf meiner eigenen Hardware läuft. Wer es selbst ausprobieren will, findet es unter anderem bei OpenRouter, in LM Studio und in den vLLM-Recipes.

2. Der Orchestrator: OpenCode

Die Steuerung der AI-Agenten übernimmt OpenCode, ein mächtiger, quelloffener KI-Coding-Agent. Das Besondere an OpenCode ist seine absolute Flexibilität: Es ist nicht an einen einzigen Provider gebunden, sondern erlaubt es mir über ein interaktives Terminal-Interface (TUI), über 75 verschiedene LLM-Provider sowie vollständig lokale Modelle (z. B. via Ollama oder vLLM) parallel anzusteuern. Die Tool-Dokumentation zeigt, was standardmäßig mitkommt: Datei-Modifikationen, parallele Multi-Session-Agenten und native Tool-Ausführungen. Der komplette Code liegt offen auf GitHub.

3. Die Code-Intelligenz: LSP (Language Server Protocol)

Damit der Agent nicht "blind" agiert, ist OpenCode mit LSP (Language Server Protocol) gekoppelt. Dieses von Microsoft standardisierte Language Server Protocol löst ein fundamentales Problem von KI-Modellen: Für jedes LLM – egal wie groß – ist Code mathematisch gesehen erst einmal nur eine bloße Aneinanderreihung von Wörtern und Zeichen. Das Modell rät statistisch, welches Wort als Nächstes folgen müsste, versteht aber nicht die realen Compiler-Regeln im Hintergrund. Erst durch das LSP bekommen die Wörter für den KI-Agenten eine echte, deterministische Bedeutung. Es verbindet den Agenten direkt mit denselben Sprachanalysatoren, die auch deine IDE nutzt – rust-analyzer, pyright und viele weitere. Statt mühsam zu "erraten", ob eine Funktion existiert oder die Typen stimmen, liefert das LSP dem Agenten sofort unbestreitbare Fakten:

• Echte Semantik: Der Agent versteht sofort, wo eine Funktion definiert ist (Go to Definition) und wo sie überall im Projekt aufgerufen wird (Find References).
• Fehler-Feedback in Echtzeit: Erzeugt der Agent syntaktischen Unsinn, schlägt das LSP sofort mit präzisen Compiler-Warnungen und Fehlermeldungen (Diagnostics) Alarm. Der Agent kann sich so selbst korrigieren, noch bevor der Code überhaupt testweise ausgeführt wird.

4. Der Token-Sparer: CodeGraph, ASTs und Tree-Sitter

Das größte Problem bei Agenten-Workflows ist das ständige, teure Einlesen kompletter Dateien via grep oder glob. Hier kommt das Open-Source-Projekt CodeGraph ins Spiel (der Einstieg in die Dokumentation ist schnell durchgelesen). Doch wie schafft es dieses Tool, die Codebase so effizient für den Agenten aufzubereiten? Der Schlüssel liegt darin, wie CodeGraph den Quellcode versteht. Es nutzt eine Bibliothek namens tree-sitter, um den Textcode in einen sogenannten AST (Abstract Syntax Tree / Abstrakter Syntaxbaum) zu verwandeln:

• Was ist ein AST? Stell dir deinen Quellcode wie einen geschriebenen Text vor. Ein AST zerlegt diesen Text in eine hierarchische Baumstruktur. Statt einer flachen Textdatei sieht das System nun einen Baum: Der Stamm ist die Datei, dicke Äste sind Klassen, kleinere Äste sind Methoden oder Funktionen, und die Blätter sind Variablen und Ausdrücke. Jedes Element im Code bekommt einen festen Platz in dieser logischen Hierarchie.

Wie hilft das dem KI-Agenten, schneller und besser Infos zu finden? CodeGraph parst alle ASTs deines Projekts und speichert diese strukturierten Informationen (welche Funktion ruft welche andere Funktion auf? Wo wird welche Klasse importiert?) in einer blitzschnellen, lokalen SQLite-Datenbank. Wenn dein Agent nun eine Information sucht, muss er nicht mehr mühsam tausende Zeilen Code per Textsuche scannen und dafür wertvolle Token verbrauchen. Über das Model Context Protocol (MCP) fragt der Agent direkt die CodeGraph-Datenbank ab. Er erhält in Millisekunden eine exakte Antwort wie: "Funktion X wird in Datei Y in Zeile 42 aufgerufen". Das Ergebnis dieser intelligenten Indexierung? In der eigenen Messung des Projekts sind es 69 % weniger Token und 60 % geringere Kosten – weil der Kontext für das LLM extrem schlank und präzise gehalten wird. Wie diese Zahlen zustande kommen, schlüssele ich im Fazit auf.

Unter der Haube: Vom Quellcode zum Wissensgraphen

Um zu verstehen, warum das Setup so performant ist, lohnt ein Blick unter die Haube. CodeGraph arbeitet in zwei Schritten: Zuerst zerlegt tree-sitter den flachen Quellcode in einen hierarchischen AST. Danach verknüpft CodeGraph diese Bäume zu einem globalen Wissensgraphen über das gesamte Projekt – auf dev.to ist dieser Ablauf unter dem treffenden Titel „Stop Your AI Agent From Grepping the Same Files 50 Times" anschaulich aufgedröselt.

Schritt 1: Von flachem Text zum Baum

Schreibe ich eine simple Rabatt-Funktion, sieht ein Agent ohne Index erst einmal nur eine flache Textwüste. Tree-sitter übersetzt exakt denselben Text in Sekundenbruchteilen in eine klare Baumstruktur:

Schritt 2: Textsuche gegen Graph-Abfrage

Warum spart das nun Token und Zeit? Der Unterschied wird sichtbar, sobald der Agent wissen will, wo berechne_rabatt definiert ist und wer die Funktion aufruft:

Wird der Agent dadurch wirklich schneller?

Ja – und das lässt sich inzwischen belegen. Das Setup adressiert das größte Nadelöhr lokaler Modelle: die Latenz.

Durchsucht ein Agent ein großes Projekt per klassischer Textsuche, muss er in mehreren Schleifen ganze Dateien einlesen, um den Kontext zu verstehen. Jede dieser Schleifen kostet einen weiteren LLM-Aufruf. Bei einem lokalen Modell wie Qwen3.6-27B schlägt das unmittelbar auf die Wall-Clock-Time durch, weil bei jedem Schritt tausende Zeilen Kontext neu evaluiert werden müssen. Welches Suchwerkzeug wann das richtige ist, vergleicht „Code Search for AI Agents: Which Tool When?" im Detail.

Weniger Tool-Aufrufe. Das im März 2026 veröffentlichte Paper „Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP" hat genau das über 31 reale Repositories hinweg gemessen: Agenten mit Graph-Index kamen mit 2,1-mal weniger Tool-Aufrufen und zehnmal weniger Token aus als ein Agent, der sich per Datei-Exploration durchhangelt. Da jeder Tool-Aufruf bei einem lokal laufenden Modell echte Sekunden kostet, ist das der größte einzelne Hebel im ganzen Setup.

Zur Ehrlichkeit gehört allerdings die zweite Zahl aus demselben Paper: Bei der Antwortqualität lag der Graph-Ansatz mit 83 % unter dem Datei-Explorer mit 92 %. Der Index ersetzt das Lesen von Code also nicht – er priorisiert es. Wer ausschließlich den Graphen befragt, verliert Kontext, den das direkte Einlesen mitliefert. Für mich heißt das in der Praxis: CodeGraph für Navigation, Aufrufketten und Abhängigkeiten – und das direkte Lesen genau dort, wo es wirklich um die Details geht.

Kein Context Stuffing. Klassische Agenten füttern das Modell nebenbei mit „Context-Müll": irrelevanten Codezeilen rund um den eigentlichen Suchtreffer. Und je größer der Kontext im Prompt, desto träger antwortet ein lokales LLM – die Time-to-First-Token steigt spürbar. Weil CodeGraph über MCP deterministische Fakten liefert (exakte Symbol-Positionen, Import-Abhängigkeiten) statt Textschätzungen, bleibt der Prompt schlank und das Modell antwortet entsprechend zügig.

Unterm Strich wirkt das Setup an zwei Stellen gleichzeitig: Der Agent dreht weniger Denk-Schleifen, und pro Schleife antwortet das lokale Modell schneller, weil es nicht durch große, irrelevante Codemengen ausgebremst wird. Dass Graph-basierte Ansätze genau an dieser Stelle Kosten und Komplexität drücken, ist kein Einzelbefund von CodeGraph, sondern zieht sich durch die gesamte GraphRAG-Literatur.

Fazit: Was das Setup leistet – und was nicht

Das Credit-Problem ist gelöst. Kleinere Aufgaben – Log-Ausgaben, Dokumentation, Boilerplate – wandern zu kleineren Modellen, Qwen übernimmt Architektur und komplexere Refactorings, und das alles läuft lokal auf meiner eigenen Hardware. Kein Token-Zähler im Nacken, keine AI-Credits, keine Überraschung am Monatsende. Wie sich OpenCode mit lokalen LLMs konkret aufsetzen lässt, ist auf dev.to Schritt für Schritt beschrieben; eine deutschsprachige Einführung ins lokale Ausführen von LLMs gibt es ebenfalls.

Ich will hier aber nicht so tun, als hätte ich damit die Cloud überflüssig gemacht: Dieses Setup ersetzt Fable 5 oder Opus 5 nicht. Der Vergleich in „Qwen 3.6 27B as a Local Claude Code Replacement" sortiert Qwen3.6-27B auf SWE-bench Verified bei 77,2 % ein, Claude 4.5 Opus bei 80,9 % – und hält ausdrücklich fest, dass der Abstand zu den aktuellen Anthropic-Modellen noch deutlich größer ist als diese knapp vier Punkte.

Im Alltag spürbarer als der Benchmark-Abstand sind zwei andere Beobachtungen aus derselben Analyse: eine Fehlerrate von rund 12 % bei Tool-Call-Formaten gegenüber 0,5 % bei Claude, und ein deutliches Abdriften bei langen Kontexten jenseits von etwa 14.000 Token. Das riesige Kontextfenster auf dem Datenblatt heißt eben nicht, dass das Modell über die volle Länge den Faden behält. Das Fazit dort trifft es gut: ein brauchbarer Reasoning-Layer, aber noch kein verlässlicher Execution-Layer für vollautonome Läufe.

Genau deshalb fahre ich das Setup hybrid – und das ist auch das Muster, das dieselbe Analyse am Ende empfiehlt: Claude plant, Qwen tippt. Die konzeptionelle Schwerarbeit aus meiner Agentic-Coding-Serie – Use Cases, Lösungskonzept, Realisierungsplan – bleibt bei den Anthropic-Modellen; die hochvolumige Umsetzung wandert auf die eigene Hardware. Das ist kein Kompromiss aus Geiz, sondern eine ziemlich saubere Arbeitsteilung nach Stärken.

Der Hebel funktioniert auch mit Claude Code

Und hier ist der Punkt, den ich beim Bauen selbst unterschätzt habe: CodeGraph und LSP sind keine Krücken für schwache lokale Modelle. Der Token-Effekt tritt genauso ein, wenn man ganz normal Claude Code mit Anthropic-Modellen fährt – der Agent hört schlicht auf, dieselben Dateien immer wieder durchzugreppen.

Die Zahlen dazu stammen aus CodeGraphs eigener Validierung vom 21. Juli 2026, und die wurde exakt so gemessen: Claude Code headless mit Claude Opus 4.8, einmal mit und einmal ohne CodeGraph, über sieben reale Open-Source-Repositories in sieben Sprachen (unter anderem VS Code, Django, Tokio und Gin), jeweils im Median aus vier Läufen pro Variante. Das Ergebnis: 89 % weniger Tool-Aufrufe, 69 % weniger Token, 60 % geringere Kosten. Im Extremfall Tokio waren es 3 statt 57 Tool-Aufrufen.

Wer also gar nicht auf lokale Modelle umsteigen will oder kann, nimmt trotzdem den größten Teil der Ersparnis mit – und behält dabei die Qualität der Cloud-Modelle. Der Index rechnet sich unabhängig davon, welches Modell darüber läuft.