anchor-engine-node

p95 search on a 28M-token corpus - <1GB RAM – runs on a $200 mini PC, a Raspberry Pi, or a phone - Pure JS/TS, compiled to WASM, no cloud dependencies What’s new in v4.6 - distill: lossless compression of your corpus into a single deduplicated YAML file. I tested it on 8 months of my own chat logs: 2336 → 1268 unique lines, 1.84:1 compression, 5 minutes on a Pixel 7. - MCP server (v4.7.0) – exposes search and distillation to any MCP client (Claude Code, Cursor, Qwen tools) - Adaptive concurrency – automatic switching between sequential (mobile) and parallel (desktop) processing The recursion I used Anchor to build itself. Every bug fix and design decision is in the graph – that's how I kept the complexity manageable. Where it fits If you're building local agents, personal knowledge bases, or mobile assistants and want memory that's inspectable, deterministic, and lightweight – this is for you. GitHub repo: https://github.com/RSBalchII/anchor-engine-node Whitepaper: https://github.com/RSBalchII/anchor-engine-node/blob/main/do... Happy to answer questions about the algorithm, the recursion, or the mobile optimizations.

to build a traversable semantic graph. *Atomization, not exhaustive extraction.* Projects like Kanon 2 are doing incredible work extracting every entity, citation, and clause from documents with remarkable precision. That's valuable for document intelligence. Anchor Engine takes a different path: we extract only the core concepts and relationships needed to support semantic memory. For example, "Apple announced M3 chips with 15% faster GPU performance" atomizes to nodes for [Apple, M3, GPU] and edges for [announced, has-performance]. Just enough structure for retrieval, lightweight enough to run anywhere. The result is a graph that's just rich enough for an LLM to retrieve relevant context, but lightweight enough to run offline in <3GB RAM—even on a Raspberry Pi or in a browser via WASM. *Why graph traversal instead of vector search?* - Embeddings drift over time and across models - Similarity scores are opaque and nondeterministic - Vector search often requires GPUs or cloud APIs - You can't inspect why something was retrieved STAR gives you deterministic, inspectable results. Same graph, same query, same output—every time. And because the graph is built through atomization, it stays small and portable. *Key technical details:* - Runs entirely offline in <3GB RAM. No API calls, no GPUs. - Compiled to WASM – embed it anywhere, including browsers. - Recursive architecture – we used Anchor Engine to help write its own code. The dogfooding is real: what would have taken months of context-switching became continuous progress. I could hold complexity in my head because the engine held it for me. - AGPL-3.0 – open source, always. *What it's not:* It's not a replacement for LLMs or vector databases. It's a memory layer—a deterministic, inspectable substrate that gives LLMs persistent context without cloud dependencies. And it's not a competitor to deep extraction models like Kanon 2; they could even complement each other (Kanon 2 builds the graph, Anchor Engine traverses it for memory). *The whitepaper* goes deep on the graph traversal math and includes benchmarks vs. vector search: https://github.com/RSBalchII/anchor-engine-node/blob/d9809ee... If you've ever wanted LLM memory that fits on a Raspberry Pi and doesn't hallucinate what it remembers—check it out, and I'd love your feedback on where graph traversal beats (or loses to) vector search. We're especially interested in feedback from people who've built RAG systems, experimented with symbolic memory, or worked on graph-based AI. Reddit discussion: https://www.reddit.com/r/LocalLLaMA/s/EoN7N3OyXK

only the core concepts and relationships needed to support semantic memory. The result is a graph that's just rich enough for an LLM to retrieve relevant context, but lightweight enough to run offline in <3GB RAM—even on a Raspberry Pi or in a browser via WASM. Why graph traversal instead of vector search? Embeddings drift over time and across models Similarity scores are opaque and nondeterministic Vector search often requires GPUs or cloud APIs You can't inspect why something was retrieved STAR gives you deterministic, inspectable results. Same graph, same query, same output—every time. And because the graph is built through atomization, it stays small and portable. Key technical details: Runs entirely offline in <3GB RAM. No API calls, no GPUs. Compiled to WASM – embed it anywhere, including browsers. Recursive architecture – we used Anchor Engine to help write its own code. The dogfooding is real. AGPL-3.0 – open source, always. What it's not: It's not a replacement for LLMs or vector databases. It's a memory layer—a deterministic, inspectable substrate that gives LLMs persistent context without cloud dependencies. And it's not a competitor to deep extraction models like Kanon 2; they could even complement each other (Kanon 2 builds the graph, Anchor Engine traverses it for memory). The whitepaper goes deep on the graph traversal math and includes benchmarks vs. vector search: https://github.com/RSBalchII/anchor-engine-node/blob/d9809ee... We're especially interested in feedback from people who've built RAG systems, experimented with symbolic memory, or worked on graph-based AI. If you've ever wanted to give an LLM long-term memory that fits on a Raspberry Pi, this might be interesting to you.

only the core concepts and relationships needed to support semantic memory. The result is a graph that's just rich enough for an LLM to retrieve relevant context, but lightweight enough to run offline in <3GB RAM—even on a Raspberry Pi or in a browser via WASM. Why graph traversal instead of vector search? Embeddings drift over time and across models Similarity scores are opaque and nondeterministic Vector search often requires GPUs or cloud APIs You can't inspect why something was retrieved STAR gives you deterministic, inspectable results. Same graph, same query, same output—every time. And because the graph is built through atomization, it stays small and portable. Key technical details: Runs entirely offline in <3GB RAM. No API calls, no GPUs. Compiled to WASM – embed it anywhere, including browsers. Recursive architecture – we used Anchor Engine to help write its own code. The dogfooding is real. AGPL-3.0 – open source, always. What it's not: It's not a replacement for LLMs or vector databases. It's a memory layer—a deterministic, inspectable substrate that gives LLMs persistent context without cloud dependencies. And it's not a competitor to deep extraction models like Kanon 2; they could even complement each other (Kanon 2 builds the graph, Anchor Engine traverses it for memory). The whitepaper goes deep on the graph traversal math and includes benchmarks vs. vector search: https://github.com/RSBalchII/anchor-engine-node/blob/main/do... We're especially interested in feedback from people who've built RAG systems, experimented with symbolic memory, or worked on graph-based AI. If you've ever wanted to give an LLM long-term memory that fits on a Raspberry Pi, this might be interesting to you.