Search "how to give an AI your whole codebase" and the answer is almost always the same: embeddings. Chunk the repo, vectorize it, store it in a vector database, retrieve by similarity — RAG. Atlarix doesn't do that, on purpose. There is no embedding model and no vector index anywhere in the product. Here's how Atlarix gives the model real, whole-codebase context without RAG — and why, for code specifically, that's the better call.

Why RAG is the wrong default for code

Vector search is built for fuzzy semantic similarity over prose. Code isn't prose. The thing you actually need — "what calls this function," "where is this symbol defined," "what imports this module" — is structural and exact, not fuzzy. Embedding a codebase also means chunking it (which severs the call graph), maintaining an index as files change, and, for many tools, uploading vectors to the cloud. You pay in latency, drift, and privacy for similarity matching that doesn't answer the structural questions coding actually asks.

Blueprint: a structural map, not a vector store

Atlarix parses your project into Blueprint — a structural graph built with Universal Ctags and ast-grep edges. It knows your files, the symbols inside them, and how they connect (imports, calls, definitions). When the model needs architecture, it asks Blueprint for a focused, section-scoped slice — a few thousand tokens of real structure — instead of scanning hundreds of thousands of raw tokens or retrieving similarity-matched chunks.

FTS5 grep: lexical search that scales to any repo

For finding code, Atlarix uses a disk-backed SQLite FTS5 index that reranks `grep` results by relevance — the most relevant files first, each hit annotated with its enclosing function or class (zoekt-style) so the model jumps straight to the symbol. Because the index lives on disk per workspace, memory stays low and constant no matter how large the repo gets — there's no in-memory ceiling to hit on a giant monorepo.

The model is the natural-language layer

The deliberate design choice — the same one Claude Code and opencode make — is to keep retrieval lexical and structural and let the agent do the reasoning. There's no semantic-recall lane translating your question into vector space. The model reads Blueprint slices and sharp grep results and reasons over them directly. Less machinery, no index to drift, and answers grounded in exact file:line citations rather than nearest-neighbor guesses.

Why this even works for weak and local models

Retrieval is only half of it; the model has to use the results well. Atlarix carries tool calls and results as provider-native blocks (not flattened into prose), so weak and local models get clean tool_use/tool_result structure and multi-step prompt caching holds. For models without native function-calling, an XML/text tool-call fallback lets them participate anyway. That's what makes no-embeddings retrieval practical on open-weight models running on your own hardware.

What the data showed

We benchmarked this honestly and published it. On a real giant multi-repo, a structural-first "find the signup code" task returned exact file:line citations across three sub-projects with zero hallucination — and the broader v13 work brought a representative query from ~63K down to ~26K turn tokens. The deeper, peer-readable account (including the counterintuitive finding that more structure sometimes means more thorough exploration) lives in our published research post.

"Use your codebase as a RAG knowledge base" is the phrase everyone searches for — but the honest answer for code is that you don't need RAG at all. Blueprint for structure, FTS5 for lexical search, native tool history so any model can use them, and the model's own reasoning on top. No embeddings, no vector database, no index upload — by design.