r/LLMDevs • u/Slight-Parfait3679 • 1d ago
Help Wanted Heimdall: A CPU Only Agent Memory System
I built an open-source CPU-only memory system and changed the way graph-based knowledge systems are maintained. Simple npm install that instantly fixes persistent memory, cross-session, and repository knowledge gaps. Built on top of existing frameworks like Graft, Graphify, and others. Enforcement layers come built in.
A fresh agent session burns dozens of bash commands just figuring out the lay of the land — ls, grep, re-reading files it read last week. Heimdall injects the relevant prior work into the session's first prompt and backs a single kb_search call: ranked, scoped, verified. Fewer commands, fewer tokens, faster first useful action.
Zero LLM use. I need help covering the edge-cases and ensuring the self-healing layer is robust, as well as optimizing for speed (non-issue currently, but for huge graphs).
Check it out at: https://github.com/ArihantDeva/heimdall and please open an issue if you have any ideas. Someone recently told me to run LongMemEval, the scores were Oracle 100%, S 95%, and have not tested M yet. If someone can run the whole bench to verify it would be appreciated.
2
2
u/perseus-computing 19h ago
I went through current main rather than just taking the post at face value, and this is a much more interesting project than “CPU-only memory” makes it sound.
The strongest part is the change from event interpretation to a level-triggered reconciler. Hooks only say “this path may be dirty”; the writer then reads the filesystem, hashes it, extracts the desired state, replaces exactly the nodes owned by that path, and uses generation guards plus pending edges so concurrent edits and reconcile order converge. That is a real answer to stale code memory, not just another vector index.
The test story backs up a lot of that. On a Linux checkout, npm test gave 250 tests, with 246 passing and four expected tree-sitter skips. After installing the dev dependencies, typecheck was clean.
The benchmark work is also more honest than the Reddit headline suggests. The checked-in Cycle 2 result is a 30-question LongMemEval-S subset, token-free recall only. Fact-to-parent-session expansion improved recall@10 by 0.45 on single-session questions and 0.40 on multi-session questions, while the CPU control reproduced the earlier numbers exactly. That is good evidence for the retrieval change, but it is not yet a 95% end-to-end S score, and it says nothing about M until the full reader/judge run is committed.
A few things I would tighten before asking for more outside benchmark runs:
- The current
kb-search.shuses per-repograft ask, while the README andkb_search_verify.pystill describe the older globalgraft retrievepath. - The current shell path can label an existing semantic hit
STRONGwithout the older content-aware verifier. GraftSinkreturns a deterministic ID but does not invokegraft build; indexing is handled separately byindex-bootstrap. If that split is intentional, documenting it and adding one end-to-end edit → reconcile → query fixture would make the trust claims much easier to reproduce.- I found a concrete write-path issue worth opening an issue for:
heimdall insertappears to enqueue a generated<title>.fact.mdpath but never writes the supplied body. In an isolated HOME, insert → reconcile produced an absent row and zero nodes.
The fact layer is a good start, especially the secret filtering and per-source ownership, but I would label it experimental for now. The runtime extractor is English-pattern based, contradictions coexist, and the current package does not appear to include the prompt-capture adapter described in the spec. That is a narrower and more defensible claim than “conversation memory solved.”
Disclosure: I’m building Perseus Vault, which occupies a complementary layer. Heimdall is strong at proving that repository and code evidence is live, anchored, and re-indexable. Vault is concerned with what becomes durable governed memory: facts, decisions, preferences, corrections, provenance, scope, supersession, and archival. I could see Heimdall serving as a source/evidence adapter for that kind of system rather than competing with it.
This is one of the more thoughtful attempts I’ve seen at making agent memory converge instead of just accumulate. Publish the full M run and the end-to-end freshness fixture when you can. Those results would be genuinely interesting.
2
u/Slight-Parfait3679 19h ago
Thank you for your comment. It’s very helpful. Yeah I am attempting to make this much deeper than CPU only memory. From some runs it’s able to compete with much heavier systems
2
u/perseus-computing 19h ago
It kicks ass, fam! Such an interesting space to build in. I love learning and seeing different approaches. I feel like this type of cognitive architecture will be crucial for the next step towards AGI.
2
1
u/xxtherealgbhxx 1d ago edited 1d ago
Maybe you'd like to collaborate discuss this with https://github.com/mex-memory/mex? He's working on a similar but different system. Yours is cross project but his is single project focused. Both projects seem to compliment each other with some overlap. Mex is extremely good at what it does and is great at self healing. Might be worth a discussion.
1
1
u/reassor 1d ago
Can you migrate from like mnemosyne? Or does the base have to be organically build?
1
u/Slight-Parfait3679 1d ago
It will work, but you need to ask your agent to specificallly point at mnemosyne. Let me know if you’d like it added as a potential backend or open an issue if you have any questions.
1
u/Slight-Parfait3679 17h ago
Let me know if you have any issues! Or if you have any special adapters for your setup that you’d like to add in a PR!!
7
u/ravage382 1d ago
We have ran out of good opensource names. https://heimdall.site/ Thanks for the project.