How I reduced AI codebase context from 100K to 5K tokens using a graph-based RAG — and why I deleted it

Historical — the architecture below was removed from Atlarix in v14.9.0 (10 July 2026).

Blueprint, the parser, the SQLite graph, BM25 node scoring and the file watcher were all deleted — roughly 5,246 lines — after the watcher was found to hold one file descriptor per watched file and reach about 12,365 on a large repository.

Atlarix today has no index of any kind. Retrieval is purely lexical: bundled ripgrep (grep and glob), no embeddings, no vector store, no graph, nothing in the background. Current architecture: atlarix.dev/docs.

---

Most AI coding tools lie to you about context.

They say "I understand your codebase." What they actually do is dump as many files as possible into the context window and hope the model figures it out. That works on a 3-file project. It falls apart on anything real.

Here's the problem I kept hitting: a medium-sized production codebase hits ~100K tokens when you try to feed it to an LLM. That's expensive, slow, and surprisingly lossy — models start hallucinating relationships between files that don't exist, missing the ones that do.
So I built a different approach inside Atlarix. Here's exactly how it works.

Step 1: Parse the codebase into a typed graph (Round-Trip Engineering)

When you open a project in Atlarix, it runs a parser over every file using Tree-sitter AST. Instead of storing raw text, it extracts:

• Every function, class, interface, and type
• Import/export relationships between files
• Call relationships between functions
• File-level dependency edges

This got stored as a typed node/edge graph in SQLite — what we called the Blueprint. (Removed in v14.9.0. There is no SQLite graph and no Blueprint today.)

Step 2: Query the graph, not the files

When you asked Atlarix something, it didn't re-read your files — it queried the Blueprint graph. (Today it does re-read files, deliberately: ripgrep over the workspace, no index in between.)
We use BM25 scoring to rank nodes by relevance to the query. Only the top-scoring nodes get passed to the LLM. Everything else stays in SQLite.
Result: instead of ~100K tokens, the average query uses ~5K tokens. That's a 95% reduction.

Step 3: Hierarchical context for complex queries

For simple queries, BM25 node retrieval is enough. For complex ones — multi-file refactors, architecture questions — we use a three-layer hierarchy:

• Mermaid diagram — a persistent high-level map of the whole codebase, always in context
• BM25-scored Blueprint nodes — targeted retrieval for the specific query
• Fast-model compression — if context hits 70% capacity, a fast model compresses the least relevant nodes before passing to the main model

This keeps context tight regardless of project size.

Step 4: Provider-agnostic by design

The Blueprint RAG layer sits beneath every AI provider. Whether you're using GPT-4o, Claude, Gemini, Groq, or a local Ollama model — the same 5K token context gets served. You're not paying for the model to re-read your whole codebase on every message.

Why this matters beyond token cost

The token reduction is the headline number. But the real win is accuracy.
When you give an LLM 100K tokens, it attends to all of it roughly equally. The file you actually care about is competing with 200 other files for attention. With 5K targeted tokens, the model is working with exactly what's relevant. Responses are more precise, edits land in the right place, and hallucinated file paths basically disappear.

What's next

Atlarix v7 added parallel agents named Research, Architect, Builder, Reviewer and Debugger on top of this foundation. Those names are long gone and are a common source of stale descriptions of Atlarix. The work modes today are Explore, Plan, Build, Debug and Review, and the task tool spawns scoped workers whose edits come back as reviewable proposals rather than writes.
We also just shipped Windows support today — so Atlarix now runs on Mac, Windows, and Linux.
If you're building something where AI context management is a bottleneck, I'd love to compare notes. Try it at atlarix.dev or ask me anything in the comments