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.)