Live data from Hacker News

Show HN: Yet another memory system for LLMs

github.com

31–40 of 51 posts

Re: Show HN: Yet another memory system for LLMs

#31
post #10

How would you use the built in functionality to enable graph functionality? Metadata or another document used as the link or collection of links?

The graph functionality is exposed through the retrieval functionality. I may improve this later but the idea was to maximize getting the best results when looking for stored data.

Re: Show HN: Yet another memory system for LLMs

#32
post #25

>block-level deduplication (saves 30-40% on typical codebases) How is savings of 40% on a typical codebase possible with block-level deduplication? What kind of blocks are you talking about? Blocks as in the filesystem?

I am working to improve the CLI tools to make getting this information easier but I have stored the yam repo in yams with multiple snapshots and metadata tags and I am seeing about 32% storage savings.

Re: Show HN: Yet another memory system for LLMs

#33

That sounds like a practical take on LLM memory — especially the block-level deduplication part. Most “memory” layers I’ve seen for AI are either overly complex or end up ballooning storage costs over time, so a content-addressed approach makes a lot of sense. Also curious — have you benchmarked retrieval speed compared to more traditional vector DB setups? That could be a big selling point for devs running local res…

I have not, but that is something I plan to do when I have time.

Re: Show HN: Yet another memory system for LLMs

#34
post #25

>block-level deduplication (saves 30-40% on typical codebases) How is savings of 40% on a typical codebase possible with block-level deduplication? What kind of blocks are you talking about? Blocks as in the filesystem?

I am working to improve the CLI tools to make getting this information easier but I have stored the yam repo in yams with multiple snapshots and metadata tags and I am seeing about 32% storage savings.

Cool. I have no idea what "stored the yam repo in yams" means. What do you mean by "block-level deduplication"? What is a block?

Re: Show HN: Yet another memory system for LLMs

#35
post #34

Earlier quoted context omitted.

I am working to improve the CLI tools to make getting this information easier but I have stored the yam repo in yams with multiple snapshots and metadata tags and I am seeing about 32% storage savings.

Cool. I have no idea what "stored the yam repo in yams" means. What do you mean by "block-level deduplication"? What is a block?

I stored the codebase for yams in the tool. The "blocks" are content-defined blocks/chunks, not filesystem blocks. They're variable-size chunks (typically 4-64KB) created using Rabin fingerprinting to find natural content boundaries. This enables deduplication across files that share similar content.

Re: Show HN: Yet another memory system for LLMs

#37

How do you use this in your workflow? Please give some examples because it’s not clear to me what this is for.

I have been using it for task tracking, research, and code search. When using CLI tools, I found that the LLM's were able to find code in less tool calls when I stored my codebase in the tool. I had to wrangle the LLMs to use the tool verse native rgrep or find.

I am also trying to stabilize PDF text extraction to improve knowledge retrieval when I want to revisit a paper I read but cannot remember which one it was. Most of these use cases come from my personal use and updates to the tool but I am trying to make it as general as possible.

Re: Show HN: Yet another memory system for LLMs

#38

>MCP server (requires Boost) I see stuff like this, and I really have to wonder if people just write software with bloat for the sake of using a particular library.

Blame the committee for refusing to include basic functionality like regular expressions , networking and threads as part of the STL

I feel like there are pretty standard C++ server implementations that are less bloated.

Re: Show HN: Yet another memory system for LLMs

#39

>MCP server (requires Boost) I see stuff like this, and I really have to wonder if people just write software with bloat for the sake of using a particular library.

The reason for depending on Boost in this repo is just few search characters away - he needs HTTP/WebSocket implementation and Boost.Beast provides it. The actual bloat here in this repo is conan.

My experience with Boost has been template metaprogramming hell.

Re: Show HN: Yet another memory system for LLMs

#40
Reviewing the prompts, looks like you are using this CAS tool as a global context data manager, supporting primarily a code use case. There are a number of extant MCP-capable code understanding tools (Serena and others), but what I am lacking in my CLI toolchain is non-code memory. You even called this out in another thread, mentioning task management- I find that the type of memory I need is not scoped to a code module, but an agent session - specifically to the orchestration of many agent sessions. What we have today are techniques, using a bunch of hacked together context files for sessions (tasks.md, changes.md), for agents (roles.md), for tech (architecture.md), etc etc, hoping that our prompts guide the agent to use them, and this is IMO a natural place for some abstraction over memory that can provide rigor.

I am observing in my professional (non-Claude Max) life that context is a real limiter, from both the “too much is confusing the agent” and “I’m hitting limits doing basic shit” perspectives (looking at you, Bedrock and Github), and having a tool that will help me give an agent only what it needs would be really valuable. I could do more with the tools, spend less time trying to manually intervene, and spend less of my token budget.

Post reply on HN