Local Instead of a Credit Limit – My Setup with Qwen3.6-27B, OpenCode, LSP and CodeGraph

The Problem: When AI Credits Become the Bottleneck

After AI vendors like GitHub Copilot switched their pricing model to AI credits, I hit my limits pretty quickly. Above all with the approach I described in my Agentic Coding series. As you can read there, the focus is on having the AI agents work through their tasks in a structured process. The results are continuously written into documents along the way – and that eats into your token budget massively. The reason for this is structural, and this analysis of code graphs describes it well: without a structured index, an agent reads entire files from scratch for every single question. So a new solution was needed – one that would let me keep producing fast, high-quality results without blowing through my AI credit limit in no time. To get there, I asked myself whether I could offload some of the tasks from my Agentic Coding series to smaller, specialized LLMs, and then deliberately route the big, heavy work to the more powerful ones. Here is the local, high-performance setup that solved my problem:

The Core of the Setup: The Tools in Detail

To achieve maximum efficiency and independence from cloud costs, I rely on a combination of state-of-the-art local models, intelligent protocols and graph indexes.

1. The Brain: Qwen3.6 (27B)

For the complex tasks that require deep logical understanding and code synthesis, I use the Qwen3.6-27B model from the Qwen team at Alibaba Cloud. This dense 27-billion-parameter model was optimized specifically for "agentic coding" and multi-step problem solving. The model card lists a context window of 262,144 tokens – natively, extensible to a good million – and a thinking mode that is active by default: the model writes its reasoning into a <think> block before formulating the actual answer. How close that gets it to the closed cloud models is something I put into perspective with concrete numbers in the conclusion – what counts here first of all is that it runs entirely locally on my own hardware. If you want to try it yourself, you'll find it on OpenRouter, in LM Studio and in the vLLM recipes, among others.

2. The Orchestrator: OpenCode

OpenCode, a powerful open-source AI coding agent, handles the orchestration of the agents. What makes OpenCode special is its sheer flexibility: it isn't tied to a single provider but lets me drive more than 75 different LLM providers as well as fully local models (e.g. via Ollama or vLLM) in parallel, through an interactive terminal interface (TUI). The tool documentation shows what ships by default: file modifications, parallel multi-session agents and native tool execution. The complete code is out in the open on GitHub.

3. The Code Intelligence: LSP (Language Server Protocol)

So that the agent doesn't operate "blind", OpenCode is coupled with LSP (Language Server Protocol). This Language Server Protocol, standardized by Microsoft, solves a fundamental problem of AI models: for every LLM – no matter how large – code is, mathematically speaking, nothing more than a sequence of words and characters. The model statistically guesses which word should come next, but it doesn't understand the real compiler rules behind the scenes. Only through LSP do those words take on real, deterministic meaning for the AI agent. It connects the agent directly to the same language analyzers your IDE uses – rust-analyzer, pyright and many more. Instead of laboriously "guessing" whether a function exists or the types line up, LSP hands the agent indisputable facts right away:

• Real semantics: the agent immediately understands where a function is defined (Go to Definition) and everywhere it is called across the project (Find References).
• Real-time error feedback: if the agent produces syntactic nonsense, LSP raises the alarm instantly with precise compiler warnings and error messages (diagnostics). That lets the agent correct itself before the code is ever run as a test.

4. The Token Saver: CodeGraph, ASTs and Tree-sitter

The biggest problem in agent workflows is the constant, expensive reading of entire files via grep or glob. This is where the open-source project CodeGraph comes in (the introduction in the documentation is a quick read). But how does this tool manage to prepare the codebase so efficiently for the agent? The key lies in how CodeGraph understands source code. It uses a library called tree-sitter to turn the text of your code into what's known as an AST (Abstract Syntax Tree):

• What is an AST? Picture your source code as a piece of written text. An AST breaks that text down into a hierarchical tree structure. Instead of a flat text file, the system now sees a tree: the trunk is the file, the thick branches are classes, the smaller branches are methods or functions, and the leaves are variables and expressions. Every element in the code gets a fixed place in this logical hierarchy.

So how does that help the AI agent find information faster and better? CodeGraph parses all the ASTs of your project and stores this structured information (which function calls which other function? where is which class imported?) in a blazing-fast local SQLite database. When your agent now looks for a piece of information, it no longer has to scan thousands of lines of code via text search and burn valuable tokens doing so. Through the Model Context Protocol (MCP), the agent queries the CodeGraph database directly. Within milliseconds it gets an exact answer such as: "Function X is called in file Y at line 42." The result of this intelligent indexing? In the project's own benchmark, it comes to 69 % fewer tokens and 60 % lower costs – because the context for the LLM is kept extremely lean and precise. How those numbers come about is something I break down in the conclusion.

Under the Hood: From Source Code to Knowledge Graph

To understand why the setup performs so well, it's worth a look under the hood. CodeGraph works in two steps: first, tree-sitter breaks the flat source code down into a hierarchical AST. Then CodeGraph links those trees into a global knowledge graph spanning the entire project – on dev.to, this process is laid out vividly under the fitting title „Stop Your AI Agent From Grepping the Same Files 50 Times".

Step 1: From Flat Text to a Tree

If I write a simple discount function, an agent without an index sees nothing but a flat desert of text at first. Tree-sitter translates that exact same text into a clear tree structure in a fraction of a second:

Step 2: Text Search versus Graph Query

So why does this save tokens and time? The difference becomes visible the moment the agent wants to know where calculate_discount is defined and who calls the function:

Does the Agent Actually Get Faster?

Yes – and by now there's evidence for it. The setup addresses the biggest bottleneck of local models: latency.

When an agent searches a large project via classic text search, it has to read entire files across several loops in order to understand the context. Each of those loops costs another LLM call. With a local model like Qwen3.6-27B, that hits wall-clock time directly, because thousands of lines of context have to be re-evaluated at every step. Which search tool is the right one when is compared in detail in „Code Search for AI Agents: Which Tool When?".

Fewer tool calls. The paper „Codebase-Memory: Tree-Sitter-Based Knowledge Graphs for LLM Code Exploration via MCP", published in March 2026, measured exactly this across 31 real-world repositories: agents with a graph index got by with 2.1× fewer tool calls and ten times fewer tokens than an agent working its way through file exploration. Since every tool call costs real seconds on a locally running model, this is the single biggest lever in the whole setup.

Honesty requires the second number from the same paper, though: on answer quality, the graph approach came in at 83 %, below the file explorer at 92 %. So the index doesn't replace reading code – it prioritizes it. Anyone who queries only the graph loses context that reading directly would have delivered along the way. In practice, that means this for me: CodeGraph for navigation, call chains and dependencies – and reading directly exactly where the details genuinely matter.

No context stuffing. Classic agents incidentally feed the model "context garbage": irrelevant lines of code surrounding the actual search hit. And the larger the context in the prompt, the more sluggishly a local LLM responds – time-to-first-token rises noticeably. Because CodeGraph delivers deterministic facts through MCP (exact symbol positions, import dependencies) instead of text-based guesses, the prompt stays lean and the model answers correspondingly quickly.

The bottom line is that the setup works on two fronts at once: the agent runs fewer thinking loops, and per loop the local model responds faster because it isn't slowed down by large, irrelevant amounts of code. That graph-based approaches cut cost and complexity at exactly this point is not an isolated finding for CodeGraph but runs through the entire GraphRAG literature.

Conclusion: What the Setup Delivers – and What It Doesn't

The credit problem is solved. Smaller tasks – log output, documentation, boilerplate – move to smaller models, Qwen takes on architecture and more complex refactorings, and all of it runs locally on my own hardware. No token counter breathing down my neck, no AI credits, no surprise at the end of the month. How to concretely set up OpenCode with local LLMs is described step by step on dev.to; there is also a German-language introduction to running LLMs locally.

But I don't want to pretend I've made the cloud redundant here: this setup does not replace Fable 5 or Opus 5. The comparison in „Qwen 3.6 27B as a Local Claude Code Replacement" places Qwen3.6-27B at 77.2 % on SWE-bench Verified and Claude 4.5 Opus at 80.9 % – and states explicitly that the gap to the current Anthropic models is considerably larger than those not-quite-four points.

More noticeable in day-to-day work than the benchmark gap are two other observations from the same analysis: an error rate of roughly 12 % on tool-call formats compared to 0.5 % for Claude, and a clear drift on long contexts beyond around 14,000 tokens. A huge context window on the spec sheet does not mean the model holds the thread across its full length. The verdict there puts it well: a usable reasoning layer, but not yet a reliable execution layer for fully autonomous runs.

That's exactly why I run the setup as a hybrid – and it's also the pattern the same analysis recommends in the end: Claude plans, Qwen types. The conceptual heavy lifting from my Agentic Coding series – use cases, solution concept, implementation plan – stays with the Anthropic models; the high-volume implementation moves to my own hardware. That's not a compromise born of stinginess, but a rather clean division of labor along each side's strengths.

The Lever Works with Claude Code Too

And here's the point I underestimated myself while building this: CodeGraph and LSP are not crutches for weak local models. The token effect kicks in just the same when you run plain Claude Code with Anthropic models – the agent simply stops grepping through the same files over and over.

The numbers for this come from CodeGraph's own validation of July 21, 2026, and it was measured exactly that way: Claude Code headless with Claude Opus 4.8, once with and once without CodeGraph, across seven real-world open-source repositories in seven languages (VS Code, Django, Tokio and Gin among them), each at the median of four runs per arm. The result: 89 % fewer tool calls, 69 % fewer tokens, 60 % lower costs. In the extreme case, Tokio, it was 3 tool calls instead of 57.

So anyone who doesn't want to or can't switch to local models still takes home the largest part of the savings – while keeping the quality of the cloud models. The index pays off regardless of which model runs on top of it.