Most of us have felt it by now. The Context Tax.
Slow token bleed just to re-establish what the AI already knew last session. A real dollar cost.
But the problem started before AI tools existed. I once spent nearly a full week reverse-engineering a Django SaaS I was dropped into. Reading someone else's code. Mapping flows I had not written. Just to get to a place where I could build something new.
Then came the AI boom. Same problem, different shape.
I would return to a client project after a few months away, my own code, and stand there asking why I wrote a function that long. IDE agents helped. But every new session meant re-attaching files, re-explaining architecture, and burning 500 to 1,000 tokens before writing a single useful prompt.
I tried managing it manually:
NOTES.md
file here.It was frustrating, but functional. Then the frontier model companies started repricing. I had an annual VS Code subscription active. I could see the math shifting under me.
Before the price changes landed, I started researching memory layers. Not as a vague concept. As something I could build, own, and run locally. Something queryable. Something that traveled with the project.
That is what zerikai_memory became. It can run behind Claude Desktop via MCP. That is where it gets interesting.
The more I learned about how LLMs hallucinate, the more I knew I had to stay as close to the source of truth as possible. The file scanner is entirely LLM-free.
I reached for Tree-Sitter because it builds a Concrete Syntax Tree directly from source files. Full structural fidelity. Zero model inference touching your data. Right now it parses Python, JavaScript, TypeScript, HTML, and Markdown. More languages coming.
What I did not expect was how well it handles Markdown. That turned out to be the real asset.
When the scanner hits a .md
or .mdx
file, _extract_markdown()
in code_indexer.py
parses it into a CST and walks the tree recursively:
Getting Started > Installation > Docker
.
[ChromaDB vector store] <- lives in .brain/, isolated per workspace
|
v Query triggers L1 -> L2 -> L3 -> L4
[L1: Vector search] L2 distance, top-N results
[L2: Lexical re-rank] boosts exact keyword + entity matches
[L3: Mode routing] cloud / local / hybrid
[L4: Synthesis] answer with inline #file:line citations
|
v
[Your IDE gets clean, cited context. Not a file dump.]
The pipeline returns only the most relevant sections.
The IDE or Claude Desktop session calls the memory via MCP.
The context window stays lean. It does not dump entire files into the chat context.
Precise source references back. Not raw context dumps. My API bill stays manageable.
Once I realized I could drop research, reading logs, and saved notes into Markdown, scan them into memory, and query them through Claude Desktop, the workflow changed.
Here is my deep research workflow:
zerikai_memory
indexes it.The research workflow is one example. Any Claude Desktop workflow that benefits from persistent, queryable context can plug into the same pattern.
Ten research results indexed. Sitting in memory. Accessible from any new chat session. I do not re-explain context. I do not re-paste 5,000-word documents. I just query.
I can also ask the memory to save useful chunks from a live session under a custom title. A conversation that produced something worth keeping does not disappear when the terminal closes.
A marketing brief built on indexed market data reads differently than one built from stale training data. A legal response built on precedent you actually looked up. A PRD that reflects real technical context. The memory layer is not just saving tokens. It changes what you can produce with them.
For Markdown files, you still need an IDE to run the MCP server.
Step 1: Clone and install
git clone https://github.com/KikeVen/zerikai_memory.git
cd zerikai_memory
python -m venv .venv
source .venv/bin/activate # macOS / Linux
pip install -r requirements.txt
python -c "from main import scan_workspace, query_memory; print('OK')"
Edit the .env
file in the clone directory. Point it at your preferred LLM in Ollama or DeepSeek (requires an API key).
If there are files or directories you do not want scanned in the workspace you want indexed, add a .memignore
file to the project root and list them there. The scanner skips them.
Step 2: Add it to your IDE/coding CLI MCP config
{
"mcpServers": {
"universal-brain": {
"command": "/absolute/path/to/zerikai_memory/.venv/bin/python",
"args": ["/absolute/path/to/zerikai_memory/main.py"]
}
}
}
Every path must be absolute. Relative paths cause silent startup failures. No error message. You will spend an hour debugging nothing.
Step 3: Scan your workspace
Open the VS Code command palette (or IDE/coding CLI). Call #universal-brain
. Scan the workspace for the first time:
"Set up memory for this project"
It runs in the background. Poll with scan_status
to track progress. Once complete, the codebase is indexed. The project brief lives in .brain/contexts/
. For a full list of tool commands, visit docs
Step 4: Query it
query_memory: where does data flow after the payments endpoint?
That is it.
Visit zerikai_memory on GitHub to install it.