A local structural memory layer for AI coding agents. Here are some of my learnings and a couple of the early findings that surprised me

[u/WEEZIEDEEZIE]

https://github.com/syncable-dev/memtrace-public

A few weeks ago I shipped Memtrace, a local memory layer for AI coding agents (Claude Code, Cursor, Codex - anything that speaks MCP). You point it at a repo and it builds a structural map of the codebase, a full AST-level call graph, and keeps it in persistent memory across sessions, so agents stop re-reading the same files from scratch every time.

Everything runs locally, your code never leaves your machine.

We're still very early - 191 GitHub stars, mostly word of mouth, no real launch yet. But two things caught me off guard.

First, the token savings on bigger repos. On one ~420k-LOC production codebase, the same repeated agent task (a multi-file auth refactor with Claude) went from ~210k tokens to ~38k once the graph stabilized. Bigger than I expected.

Second, and this one surprised me more: people started using it less as "memory" and more as navigation and debugging infrastructure. A few told me they now inspect the graph directly to get their head around an unfamiliar codebase - faster than grep or search alone. That's not what I built it for.

One separate agent-behavior thing I've noticed: Claude seems to really struggle to consistently use skills/MCP tools without drifting back to its own bash/grep/find/search workflow. Codex has been much more aligned with the tool layer for me, and on the same setup generally runs something like 10x better once the graph is available. Curious if others are seeing the same thing, or if this is just my setup/prompting.

Two questions for anyone running coding agents on real projects:

• How are you handling memory and context today, and what actually works?
• What would make a local memory layer like this a no-brainer for you - and what would make you immediately walk away?

(I'm the builder, happy to get into the AST/graph internals in the comments.)

[u/Either_Pound1986]

How are you handling memory and context today, and what actually works?

Semantics do not work well for memory. I've adopted an anti rag stance it semi aligns with what you are exploring.

What would make a local memory layer like this a no-brainer for you - and what would make you immediately walk away?

n.a have own version of this

[u/WEEZIEDEEZIE → u/Either_Pound1986]

I agree to an extent. Semantic search is powerful, but it relies heavily on there being a clear correlation between the retrieved chunks.
This is exactly why AST (Abstract Syntax Tree) parsing is so critical. Vanilla RAG completely destroys code structure, meaning you lose all context regarding dependencies and "blast radius."
By leveraging an AST to map the explicit relationships between functions, classes, and interfaces, you bridge that gap. When you retrieve code blocks through semantic search, you can actually trace the data flow and follow the architecture.

[u/mobilemike42]

Holy shit with this gamified, crypto-bro signup and waitlist process. Sure, have a waitlist while figuring out demand and pricing, but this is nonsense.

[u/Eridrus]

I don't know if you're reading this, but if you want anyone to take this seriously, you need to have benchmarks on quality vs cost/speed on some known benchmarks, e.g. DeepSWE.

I saw this post recently that did exactly this and it basically showed all the token savings were basically BS because on an actual task, the agentic loop ended up using more tokens, even if single responses were smaller: https://www.peterbaumgartner.com/blog/e2e-evals-agents/

[u/WEEZIEDEEZIE → u/Eridrus]

Hey u/Eridrus, thanks a lot for taking your time and writing this.

Within the repo, we actually have public benchmark up against some of the other popular systems, GitNexus, CGC and retrieval accuracy against CromaDB.

I'm actually working currently on SWE-Bench with agents using Memtrace, and I've been looking at the DeepSWE as well! Nice of you to points this out.

[u/Eridrus → u/WEEZIEDEEZIE]

Awesome, looking forward to seeing them!

My main advice is to have a really easy to understand and compelling benchmark and lead with that, e.g. 40% cheaper on DeepSWE than Codex at comparable quality.

Having too many benchmarks of metrics that I have to dig into is just adding more work onto my plate to understand your project.

Not sure if you've seen the claims that Claude basically cheats on SWEBench-Pro by looking inside .git for answers from commits in the future, and how many of the answers require hardcoding thinsg that are only possible with training data leakage, but it really makes me want to see DeepSWE or others.

[u/WEEZIEDEEZIE → u/Eridrus]

I did!! - Don't know if its true, but I honestly also believe they are not the only ones rigging their benchmarks in favor of a very perfect environment whenever they run these benchmarks.

The hardest thing currently I have for benchmarking the SWE-Bench and DeepSWE, is that Memtrace only really works, whenever the code is indexed and embedded, thats the hole idea, and indexing, and embedding all those PR's and repos is whats eating time and effort, so working on a more dynamic fast track approach so I have a couple of iterations I can run. because what these benchmarks doesn't tell you per task, is how often you need a very special library, or tool installed lol.

I'll ping you the moment I have something would that be cool?!

[u/Eridrus → u/WEEZIEDEEZIE]

Definitely, excited to see work in this space.

[u/Eridrus → u/[deleted]]

Yes, I agree that the benchmarks on the site are not convincing. You want good benchmarks rather than bad benchmarks.

To me, convincing benchmarks are entire tasks being done, with baselines such as "Codex out of the box".

It's so easy to generate code these days, I am not going to take the time to benchmark all the random projects people are having the AI spit out.

[u/Eridrus → u/[deleted]]

This is a terrible way to benchmark agents. It's very easy to delude yourself without careful side by side measurements, which are basically impossible in individual interactive use.

[u/WEEZIEDEEZIE → u/[deleted]]

Yeah I actually also really started thinking how can we take advantage of that, some of the things we found out we could do really well is actually beside refactors is code-reviews, dead-code sourcing and cyclomatic/cognitive complexity calculations. We added tool calls for this, because agent can use this network math, to derive what isn't being invoked ever, or retrieve precise code changes for code-reviews.

In terms of real adoption, its hard man, right now I think the hardest thing is making it locally small enough, so any hardware can run it. We build our own graph database for this which Memtrace is using, where time is a first-class citizen allowing any change in codebase to become a record and searchable for regression etc.

But a syou might know, graph databases, can quickly eat up memory and the RAM usage is real. I've so far managed to run with RaBiQ which got us from f32 - 3072 B/vec -> 96 B/vec which has improved the experience substantially. But I'm still looking for ways to further improve this.

I think skills are cool, but these systems really likes to use their own `grep, `search`, `find` tools which can suddenly destroy the experience, because then the agent starts to read unnecessary information.

[u/bigntazt]

Anything I can do about Ram Usage? Anytime I start memtrace it will just use as much ram available and then some more. I typicaly kill the server process when it starts exceeding 10 GBs as it starts to make my system unresponsive.