Memtrace: a bi-temporal code graph for coding agents, shipped as a closed private beta

The problem Memtrace targets: agents that cannot see what a change breaks

A coding agent working from file reads has no reliable model of what depends on the function it is about to rewrite. It re-reads files, rebuilds a partial picture each session, and when several agents work the same repository they each build a different partial picture. The README frames the failure mode directly: an agent refactors a function and tests break that nobody saw. Memtrace's answer is to move that structural knowledge out of the agent's context window and into a queryable graph that every session and every agent shares.

The intended user is a team running more than one coding agent on the same repository, or a single developer who wants the agent to answer questions like which callers reach this symbol and what changed since a given point in time. The README lists Cursor, Claude Code, Codex, DeepSeek Harness, Hermes, VS Code and Windsurf as the agent surfaces, and the repository topics include MCP and mcp-server, so the integration path is the Model Context Protocol rather than a bespoke plugin per editor.

What the bi-temporal graph actually stores

The README describes Memtrace as a bi-temporal episodic structural knowledge graph built on an AST foundation, adding two dimensions over tools that answer what is in the repo right now. The first is temporal memory: every symbol carries history, so a query can ask what the graph looked like at an earlier point rather than only what it looks like now. The second is the structural layer itself, functions, classes and call edges, extracted by Tree-sitter across what the README calls 20+ languages in one badge and 16+ in its benchmark table, a discrepancy worth noting since the two numbers appear in the same document.

Indexing runs in Rust with Tree-sitter and, per the README, makes zero LLM calls, which is why it claims no API cost. Framework-aware scanners are listed for Vapor, Lapis, Kong, GitHub Actions, Terraform and RLS policies, meaning the graph is not purely syntax-level for those stacks. Everything is described as local: source stays on the machine. The README states the only outbound traffic is license validation, aggregate node and edge counts, and opt-out crash telemetry, with no source, file paths or symbol names, and names MEMTRACE_TELEMETRY=off as the switch. That claim is documented in PRIVACY.md and TELEMETRY.md, which I have not read; treat the README's summary as the vendor's own description, not an independently verified audit.

MCP is the integration surface, not an editor plugin

The repository topics include mcp-server, and the README's DeepSeek Harness section shows the shape of integration: Memtrace is added as a plugin to an existing agent host rather than replacing it. The example command registers a GitHub-hosted plugin into a named profile, after which the user asks the agent to index the workspace and then to pull blast radius, evolution, or an architecture briefing. Those three query types map onto the graph's structural and temporal dimensions, and the fact that they are invoked as agent tools rather than CLI subcommands is the design decision that matters here.

The consequence is that Memtrace's usefulness is bounded by the host agent's tool-calling behaviour. If the agent does not call the graph tools, the graph does nothing. There is no described mechanism that forces an agent to consult the call graph before editing a file, so the guarantee is availability of structural context, not enforcement of it. That is a real difference from a linter or a type checker, which fail the build when ignored.

Installing it, and the gate in front of the install

The README gives two installation paths. For DeepSeek Harness, install the host first with `npm install -g @deepseek-ai/dsh`, then add the Memtrace plugin with `npx -y @deepseek-ai/dsh plugin --profile web add github:syncable-dev/dsh-plugin-memtrace`. For direct use, `npm install -g memtrace` is the documented command, and the README says you are indexing in about 90 seconds after that. The telemetry opt-out is the environment variable `MEMTRACE_TELEMETRY=off`.

The gate is the part that matters more than the commands. The README states Memtrace is in private beta, with access rolled out in batches, and directs readers to a waitlist at memtrace.io. The license badge reads Proprietary EULA, and the repository's license field is NOASSERTION, which GitHub uses when it cannot classify a license file. So the public repository is not the product: it is documentation, benchmark write-ups and issue tracking around a binary you obtain after clearing the waitlist. If you are evaluating Memtrace for a procurement process, the npm install command is not the blocker; the EULA and the beta gate are.

Where the design costs you: coverage, freshness and the beta channel

Two limitations follow from the architecture as described. First, a Tree-sitter graph is a syntactic approximation. The README claims 81.6% recall on Django callers against a competing tool's 5.3%, and 96.6% exact-symbol accuracy. Recall below 100% means some real call edges are absent, and an agent that trusts the graph without checking will occasionally miss a dependent. Dynamic dispatch, decorators, generated code and metaprogramming are the usual places where syntax-level extraction loses edges, and nothing in the supplied material says how Memtrace handles them. The framework scanners for Vapor, Lapis, Kong, Terraform and RLS policies suggest the team patches specific gaps case by case, which implies gaps exist.

Second, freshness depends on re-indexing. The README cites a 42.5 ms p95 incremental re-index, which is fast, but an incremental index still has to be triggered. If an agent edits files and the graph is not refreshed before the next query, the temporal layer will faithfully report a state that no longer exists. Nothing in the material describes a file watcher or a hook that forces re-index after a write, so verify that before relying on the graph mid-session. The private beta adds a third cost: the README says fixes ship from real bug reports within a week, which reads as a fast loop but also as a product where you are expected to file the bugs. Version numbers in the release list, v1.1.11 through v1.2.0 within four days, are consistent with that cadence and with the churn that comes with it.

How it differs from AST-only code graph tools

The README names GitNexus and CodeGrapherContext as the closest existing work and characterises both as AST-based graphs that answer what is in the repository right now. The stated difference is the temporal dimension: Memtrace keeps symbol history so a query can reconstruct an earlier state, which is what makes the replay and evolution queries possible. On the README's own numbers, the two tools are close on exact symbol lookup, 96.6% versus 97.0%, with Memtrace claiming 128x lower latency, and Memtrace claims a much larger gap on graph caller recall and incremental re-index time.

Those figures come from the project's benchmark suite with ground truth taken from Python's ast module and pyright LSP rather than from any tool's own index, which is a defensible methodology choice. They are still the vendor's numbers on the vendor's corpora, and I have not run them. The honest summary of the difference is narrower than the headline table: if you only need current-state symbol lookup, an AST-only tool is a reasonable substitute and the temporal layer buys you nothing. If you need to ask what changed and what depended on it, the bi-temporal model is the reason to pick Memtrace, and it is also the part you cannot evaluate without access.

Licence, maintenance and what the beta implies for upgrades

The licence is a proprietary EULA, per the README badge, and the repository's machine-readable licence field is NOASSERTION. That combination means you should read the actual EULA text before deploying this in a commercial setting, and I am not in a position to interpret it. The practical implications to check are whether the licence permits use by a team rather than a single developer, whether it permits use on client code, and what happens to your indexed graph data if the licence lapses.

Maintenance cost is tied to the release cadence. Three releases landed between 2026-09-03 and 2026-09-06, and the README ties the LeanCTX compression features to v0.3.57+, a version numbering scheme that does not line up with the v1.2.0 release tag. That mismatch is worth resolving with the vendor before you pin a version, because it suggests either a renumbering or documentation that has not been updated. Upgrading a globally installed npm package means every agent host on the machine picks up the new build at once, so a regression in the graph affects all of them simultaneously. Pin the version in your install and test one repository before rolling it out.

Editorial conclusion

Adopt Memtrace if you run several coding agents against one repository and want them sharing a call graph with temporal history, and if you are comfortable with a proprietary EULA and a waitlist gate. Do not adopt it if you need an auditable open source dependency, if your codebase is not covered by its Tree-sitter and framework scanners, or if you cannot accept license-validation traffic leaving the machine. Before committing, verify three things: that your account clears the private beta, that `npm install -g memtrace` resolves to a version matching the v1.2.0 release notes, and that the MCP tools your agent actually calls return the blast-radius and evolution data you expect on one real refactor.

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. syncable-dev/memtrace-public on GitHub