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.

Ripgrep: lexical search that scales to any repo

For finding code, Atlarix runs `grep` and `glob` on bundled ripgrep directly over your workspace — no index to build, no background watcher, honoring your .gitignore and .atlarixignore. There's nothing to parse on workspace open and nothing running between searches, so memory stays low and constant no matter how large the repo gets — there's no ceiling to hit on a giant monorepo. The agent searches, reads exact file:line results, and reasons over them.

Structure comes from search and reading, not a graph

The structural questions — what calls this function, where is this symbol defined, what imports this module — get answered the way an engineer answers them: a targeted search, then reading the files that matter. There's no separate structural map to build or keep in sync. The model chains `grep` and `read_file` and grounds every answer in exact file:line citations. Less machinery, nothing to drift.

The model is the natural-language layer

The deliberate design choice — the same one Claude Code and opencode make — is to keep retrieval purely lexical and let the agent do the reasoning. There's no semantic-recall lane translating your question into vector space, and no structural map either. The model reads sharp grep results and the files behind them 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. Bundled ripgrep for fast lexical search, native tool history so any model can use it, and the model's own reasoning on top. No embeddings, no vector database, no index at all — by design.