I wrote a code-graph plugin for Claude Code and tested it against three popular ones on a real task. None of them helped.
Every Claude Code session starts the same way. The agent does not know my codebase, so it greps, reads files and guesses what a change will break.
I thought it would be great to give it a map. The agent asks one question, "what does this change affect?", and gets a short list of files and tests. The map is built from imports and from the contracts between packages:
- HTTP routes
- GraphQL operations
- tables
- queues
- env variables
So I built that tool and called it gsttt. A week later I had tables and charts in which it beat three popular tools. Then I tested all four on real work, and none of them made a measurable difference.
This post is the whole story, from the idea to the moral. It includes the test setup, so you can check my work or redo it on your own repository.
The short version
- The idea: a map of the code should help an agent find what a change affects.
- The tool: I built gsttt, and my own benchmark said it beat Graphify, GitNexus and codebase-memory-mcp.
- The first reality check: on nine real commits, the installed tool was never called: 0 of 36 runs.
- The last try: on one large real task, all four tools cost the same as no tool, inside the noise.
- The moral: the agent did not need the graph. The bill followed which model does the code reviews and how many review rounds run.
Contents
- [The idea and the build](#the-idea-and-the-build)
- [The first reality check](#the-first-reality-check)
- [One last try with a real task](#one-last-try-with-a-real-task)
- [The result](#the-result)
- [Did the agents use the tools](#did-the-agents-use-the-tools)
- [What moves the bill](#what-moves-the-bill)
- [The moral](#the-moral)
- [Limits](#limits)
- [If you want to reproduce it](#if-you-want-to-reproduce-it)
The idea and the build
The code-graph tools I found did not treat contracts between packages as first-class edges. A GraphQL field in the server and the client query that uses it are an example. I wanted that link in the map, so I wrote my own on October 28.
It is written in Rust, mostly with Claude Code.
To see if it worked, I built a small multi-language fixture repository. I added fourteen questions with truth lists, such as "what depends on this file". Mean recall:
| Tool | Mean recall |
|---|---|
| gsttt | 87% |
| GitNexus | 73% |
| codebase-memory-mcp | 72% |
| Graphify | 46% |
On Amplication, an open-source TypeScript monorepo, the TypeScript compiler also listed 97.3% of the callers gsttt found for 200 random methods.
I was pleased. Then I looked at what the benchmark measured.
I had written the fixture and the questions, knowing what gsttt does. A benchmark you write for your own tool measures whether it does what you built it to do.
The first reality check
So I ran the tool on real work: nine real merged changes, five from Amplication and four from a private monorepo. Each agent got a ticket written from the commit message, and I compared its diff with the real one. The model was Sonnet 5.5 at high effort, 99 runs in all.
- Installed only: the agent never called gsttt. 0 of 36 runs, and 0 in 107 real sessions of mine.
- With one sentence in the ticket ("Use gsttt to find what the change affects."), it called gsttt in all 27 runs.
- The result: 4.4 more turns, about 4% more money, and no better recall of the real files: 0.64 against 0.66.
I tried to fix that:
- a skill text that says when to call the tool
- answers in functions instead of files
- cheaper answers
- hints placed in the planning step and at stop time
Nothing helped beyond the noise.
An offline check on 420 commits compared gsttt with git co-change history. At the same list size, git history found 13 points more of the real files. For these agents, the graph carried no information they could not get from search.
But those were small commits. A large change across many packages might be where a map pays off.
One last try with a real task
I also wanted the other tools in the picture. They have between 48,000 and 142,000 GitHub stars, and gsttt has 0. So I picked one large real task and ran all four tools on it.
The task is a merged change in a private TypeScript monorepo for a SaaS product: an annual billing interval with a discount. It touches:
- price calculation, the payment integration and the checkout service
- a GraphQL contract on both sides, regenerated into three packages
- a plan picker, a pricing section and translations in five locales
- tests and an OpenSpec change proposal
The real diff is 36 files, +1,183 and -96 lines. I chose it from 377 recorded sessions in that repository. It was the cheapest of four that edited at least eight files across three packages without any tool.
The original session used Claude Opus 5.5 at xhigh effort. It took 57 turns and 15 sub-agents, cost about $8.10 and also made commits and a pull request.
The codebase has six packages and 2,809 tracked files, about 282k lines of TypeScript. It carries its own agent setup, which stayed in every run: a CLAUDE.md, two sub-agent definitions and nine skills.
The setup:
- Each run starts in a fresh git repository with one commit, the parent state. The agent has no network and cannot read outside its folder.
- The ticket is 335 words. Every run used Claude Opus 5.5 at xhigh effort, Claude Code 2.1.318, with a $15 cap.
- Plugin only: the tool is installed as its README says, and nothing else.
- Enforced (bare rounds only): the ticket also demands a tool call before the first edit and before the end. The gate never fired, because the agent called the tool first anyway.
Two environments. The first one was a mistake.
- Bare (rounds 1 and 2) loaded only the repository's own files. It is clean, but I never work that way, so its dollar figures do not describe my sessions.
- Harness (round 3) also loads my own setup: my agorch plugin and superpowers, the two plugins of the original session, plus my instructions and rules.
- In both, nothing else is loaded and nothing reaches outside the machine. Every run's start is audited against its arm.
The tools are these four, at the versions I ran:
| Tool | Version | Licence | Stars |
|---|---|---|---|
| gsttt | 0.1.196 | Apache-2.0 | 0 |
| CodeGraph | 1.6.2 | MIT | 77k |
| Graphify | 0.9.102 | Apache-2.0 | 142k |
| GitNexus | 1.6.12 | PolyForm Noncommercial | 48k |
I am the author of gsttt. No index build calls a model.
The checks are mechanical:
- typecheck of three packages
- the server and client test suites
- the GraphQL schema compared with the committed one
- nine held-out test files from the real change
- a 16-item checklist from the real diff, judged blind
The result
Cost is total_cost_usd at list prices, sub-agents included.
| Setup | Runs | Cost per run, USD | Mean |
|---|---|---|---|
| no harness, baselines | 3 | 10.72, 11.74, 11.84 | 11.43 |
| no harness, plugin only (four tools) | 4 | 11.75, 12.37, 11.25, 11.28 | 11.66 |
| harness, baselines | 5 | 6.84, 7.39, 7.83, 8.73, 9.28 | 8.01 |
| harness, gsttt | 2 | 9.44, 9.31 | 9.38 |
| harness, Graphify | 3 | 8.19, 10.29, 8.54 | 9.01 |
| harness, CodeGraph | 2 | 7.75, 9.55 | 8.65 |
| harness, GitNexus | 2 | 7.40, 9.72 | 8.56 |
!Dot chart of the cost per run in USD for no tool, gsttt, Graphify, CodeGraph and GitNexus, without and with my harness. In both panels the tool runs fall inside or next to the spread of the baselines.
The full-size chart
Quality did not move
Every run delivered the whole change:
- File recall against the real diff is 1.00 (0.97 once).
- The checklist is 16 of 16.
- The typechecks are clean and the GraphQL schema equals the real one.
The nine held-out tests failed in every run, because they pin names the original author chose. The unaided agent already solved the task, so a tool had nothing to add except savings.
The savings are inside the noise
The three bare baselines differ by 1.12 dollars, so a difference of about a dollar cannot be read. The harness baseline mean is 8.01.
| Tool | Runs | Difference from baseline mean |
|---|---|---|
| gsttt | 2 | +1.36 |
| Graphify | 3 | +1.00 |
| CodeGraph | 2 | +0.64 |
| GitNexus | 2 | +0.55 |
None is distinguishable from the baseline. The same tool run twice differs by 0.13 (gsttt) to 2.32 dollars (GitNexus). In the two big gaps, one run had one review round and the other had two.
gsttt has the highest mean, and both its runs had two review rounds. I wrote this tool, so weigh that.
Did the agents use the tools
Maybe the agents just ignored them. They did not. In every plugin-only run the agent used its tool unasked, because of what each installer writes into the project.
- Graphify adds a CLAUDE.md rule to query it before the first grep, two hooks and a 100 KB skill. The agent's first command was a graphify query.
- CodeGraph adds an MCP tool and a hook that injects 9,223 characters of context at the first prompt. The agent called codegraph_explore twice, each answer about 23k characters.
- GitNexus adds about 45 lines of MUST and NEVER rules, 12 skills and two hooks. The agent called impact 12 times, and the hook added a note to 10 of 90 Bash calls.
- gsttt writes nothing into the repository. The agent called impact three times.
The CodeGraph run was the most expensive of the twelve bare runs, $12.37. I cannot say what drove it.
The gsttt calls contradict my earlier 0 of 36 for installed-only gsttt. The model, the task and the plugin version differ, and one run per tool is not a rate.
So the tools were used, and the agent still did not need them.
What moves the bill
If the tools do not move the cost, something else does. The harness makes the same task $3.42 cheaper, 30%. My instructions send review and builder agents to Sonnet.
- In all 43 review launches of the 14 harness runs, the agent passed model: "sonnet". Without the harness, 34 of 40 ran on Opus.
- No experiment changed only the reviewer model, so this is a reading of the numbers.
The spread inside the harness is wider, 6.84 to 9.28 among the baselines. It follows the review rounds the agent runs:
| Review rounds | Baselines, mean USD | Tool runs, mean USD |
|---|---|---|
| one | 7.35 | 7.90 |
| two | 9.00 | 9.42 |
I do not know why the agent runs one round in some runs and two in others. It moves the cost by about two dollars, more than any tool did.
The moral
On paper, this looks great. A graph of how your code connects is a fun thing to build, and it is fun to look at.
Many people install tool after tool and believe that the more tools they add, the better their harness and their model get. I started from the same belief.
On this task, Claude did not care about these cool graphs of the codebase. It found every file without them. What moved the bill was boring: which model does the reviews and how many review rounds run.
So before you add the next tool to your harness, measure it on one real task of yours. Run the baseline at least three times first. If the number does not move, the tool is decoration.
Limits
- One task, one repository, one model at one effort. No statistical test.
- Recall and the checklist saturated at the maximum, and one AI agent judged the checklist. The typecheck, the tests and the schema equality carry the correctness evidence.
- Runs are few: the bare environment has 3 baselines and one run per tool arm, the harness 5 baselines, 2 runs per tool and 3 for Graphify.
- In round 1, ten claude.ai connectors were registered by mistake. No connector tool was called. Hooks of Graphify and GitNexus may have run twice in their round-1 enforced runs.
- The harness comes from one original session. I trust the direction, cheaper reviews and a wider spread, more than the exact figures.
- Wall-clock time is not comparable, because two runs shared the machine.
- I wrote one of the four tools and designed the test. The checks are mechanical, but weigh that.
- A task where the unaided agent misses files would be a fairer test of a code graph. This one did not have that problem.
If you want to reproduce it
1. Pick a merged change in your repository that spans a few packages.
2. Rebuild the parent commit as a single commit and write the ticket from the issue.
3. Run each setup with the same model and effort, in a folder the agent cannot leave, with your own setup loaded.
4. Install each tool as its README says, writing into the project and not into your global config.
5. Set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 for headless runs with sub-agents. By default the process stops background tasks 10 minutes after the last turn.
6. Run the baseline at least three times before trusting a difference.
The test runs, the blind judging and the first draft of this write-up were done by Claude Code agents from the run logs.
TencentDB Agent Memory, Read From the Source: It Needs a Second LLM and Searches by Keyword by Default
*Code read at commit badbd21 on 13 October 2026.* The guides and news pages that rank for [TencentDB Agent Memory](TencentCloud/TencentDB-Agent-Memory) repeat three claims its source code does not support: that it builds memory without any model API, that it runs hybrid vector search out of the box, and that no conversation data leaves the machine. In the shipped setup, every memory layer above the raw transcript is written by a second language model whose example endpoint is DeepSeek's hosted API, and recall is BM25 keyword search because embeddings are switched off. The project itself is a self-hosted memory server that sits between your coding agent and its model as an API proxy, turns conversations into layered notes, and hands the agent a summary at the start of each session plus search endpoints it can call. It is MIT licensed, built by Tencent Cloud's database team, and had about 28,700 GitHub stars on 13 October 2026. We read the repository at [commit badbd21](github.com/TencentCloud/TencentDB-Agent-Memory/tr…) (release 2.0.3-beta.1, pushed on 13 October 2026), following the write path, the read path and the proxy through the code itself, and we checked the result against the pages that rank for the project's name, including its README, its press release and the guides that rank alongside them. Code-level claims link to the file at commit badbd21. We build [Maximem Synap](maximem.ai), a managed memory service that competes with it; for one organisation's coding agents that must stay on its own machines, TencentDB Agent Memory is the better choice. ## TencentDB Agent Memory runs four services in three containers, with an API proxy in front TencentDB Agent Memory is four services shipped as three Docker containers. Memory-core (port 8420) holds the conversation memory pipeline, the skill store and the access-control service. Memory-hub combines the admin panel (port 8125) with a knowledge service (port 8424) that builds a Wiki from your documents and a code graph from your repositories. The proxy (port 8096) is an LLM API reverse proxy that speaks the Anthropic Messages, OpenAI Chat Completions and OpenAI Responses formats, which is how it plugs into [Claude Code](claude.com), [Codex](openai.com), CodeBuddy, WorkBuddy, [Hermes Agent](nousresearch/hermes-agent), [OpenClaw](openclaw/openclaw) and DeepSeek Harness without code changes: you point the agent's base URL at the proxy. The [install template](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) lists the ports, and building from source needs [Node 22.16 or later](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). Storage defaults to SQLite with FTS5 for keyword search and sqlite-vec for vectors, with Tencent Cloud VectorDB as an optional backend and MongoDB marked experimental. Nothing ties it to Tencent Cloud, although the built-in document and code importers target Tencent-internal tools (iWiki and Gongfeng). Its borrowings are credited openly: the code graph is the [`@colbymchenry/codegraph`](colbymchenry/codegraph) package wrapped as a service, the skill pipeline adapts code from Hermes Agent, and the Wiki follows [Andrej Karpathy's LLM Wiki idea](gist.github.com). ## A second language model builds the memory, and tool output never reaches it After each main turn the proxy sends memory-core the user's message (with harness wrappers stripped) and the assistant's text reply, and [nothing else](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). Tool calls and tool results are not part of that write. For a coding agent this is the largest single design decision in the project, because the file paths, commands, stack traces and test output that a coding session actually turns on live in tool results, and the memory pipeline never sees them. A separate, opt-in skill pipeline does read tool calls, but only to draft reusable SKILL.md files, and nothing from it becomes a fact in memory. Memory is built in four layers. Raw messages land as L0, stored as daily JSONL files and as SQLite rows indexed for keyword search. A language model then extracts L1 "atoms" from them: short, self-contained statements typed as persona, episodic or instruction memories, or as work facts, tasks, methods and artifacts when the [code-mode prompt](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) is selected. A tool-using agent rewrites up to 15 markdown "scene" files from those atoms as L2, and a second agent run keeps a single persona file as L3, capped at 2,000 characters (1,200 in code mode). Building memory needs a language model. There is no rule-based or regex extractor in the code. If extraction is turned off, or no model is configured, the L1, L2 and L3 runs [log a skip and return nothing](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), and the only memory left is the raw L0 transcript. The deployment template requires a memory model endpoint and uses [DeepSeek's API](api-docs.deepseek.com) as its example. Any OpenAI- or Anthropic-compatible endpoint works, including a local server such as [Ollama](ollama.com) or [vLLM](vllm-project/vllm), but the shipped template does not do this for you. Extraction fires every 5 turns, after 10 minutes of idle time, or on a warm-up schedule of 1, 2, 4 and 5 turns for a new session, and each run reads at most 10 new messages. A run makes one extraction call and up to one deduplication call. Scene updates run at most every 15 minutes per active session and the persona updates after every 50 new atoms or when the scene agent asks for it. A 20-turn session therefore costs roughly four to twelve extraction and deduplication calls plus one to three multi-step agent runs, none of which block the user's turn. Changed facts are reconciled only within a session. For each new atom, memory-core pulls the five most similar existing atoms by keyword and vector search (there is no similarity threshold) and asks the model, in one batched call, whether to store, update, merge or skip. An update or merge [hard-deletes the old rows](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) and writes a new row with a higher version number; no pointer to the replaced fact survives at L1. The comparison is [limited to the same session](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), so when a user says "we moved the API to v3" on Tuesday and "the API is on v2" was recorded the previous week, both atoms stay in L1 and both can come back from search. The scene layer does keep an evolution trail and a section for unresolved contradictions, which makes L2 the only layer that records change over time. Search applies no recency, validity or superseded filter either, so nothing in the read path prefers the newer of two conflicting atoms. L0 and L1 are kept forever by default; the [retention setting](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) defaults to zero days, which means no cleanup. ## The model has to search for memories itself, and search is keyword-only out of the box At the start of a session the proxy writes a block into the system prompt containing the full L3 persona (truncated at 6,000 characters) and an index of L2 scene paths with 200-character summaries. That block is built once and cached for the session, so it does not disturb prompt caching after the first turn. The proxy also adds a text guide telling the model it can use its own shell tool to `curl` a set of read-only search endpoints on the proxy for L1 atoms, L0 conversations and full scene files. Per-turn automatic recall, where relevant atoms are attached to every user message, exists in the code but is [not registered](github.com/TencentCloud/TencentDB-Agent-Memory/bl…); the comment beside it says it was retired because it broke the KV and prompt cache. So a specific fact reaches the model only when the model decides to search, writes a curl command, runs it through its tool loop and reads the result. That costs a full tool round trip, and an agent without a shell tool, or without network access to the proxy, cannot search at all. Out of the box, search is BM25 keyword search only, although the code fuses BM25 and vector results by [reciprocal rank fusion](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), with k set to 60, equal weights, five results by default and no reranker. The shipped Docker deployment sets the embedding provider to [`none`](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), and the config loader [turns a "local" embedding provider into "disabled"](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) with a message asking for a remote one. [GreenNode's integration write-up](greennode.ai) hit exactly this: hybrid recall returned an error without an embedding service, and they fell back to keyword search. BM25 also [defaults to Chinese tokenisation](github.com/TencentCloud/TencentDB-Agent-Memory/bl…); English deployments should set `bm25.language: en`. If memory-core is unreachable, the proxy [passes the original request through](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) without memory, so the agent keeps working. ## Conversation text leaves the machine through the memory model The "fully local, nothing leaves the building" framing in [several](pasqualepillitteri.it) [articles](aitoolly.com) is half right. The storage is local and there is no vector database subscription. Telemetry to Langfuse, Opik, ClickHouse and Kafka is off by default and needs endpoints you supply. But in the shipped setup, conversation text goes to the memory model in batches of up to 10 messages for extraction, scene and persona summaries go to it for L2 and L3, and imported documents go to it in chunks of up to 12,000 characters to build the Wiki. If that endpoint is a hosted API, a second provider now receives your conversations alongside the one your agent already uses. The proxy also forwards every agent request to its upstream model, so the setup is only as local as that upstream. For agent memory to be private in the sense the coverage implies, three things have to run on your own hardware: the memory model, the embedding model, and the agent's own model. TencentDB Agent Memory can run the memory model and the embedding model on your hardware (or run with embeddings off), and the agent's own model is your choice. There is no PII handling of conversation content anywhere in the code. The only redaction we found [masks API keys and tokens in logs](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). User text is stored exactly as written, sent unchanged to the memory model, and the persona layer exists to build a profile of the user. We found no encryption at rest for memory data, and while delete endpoints exist for conversations and atoms, there is no export-and-erase workflow for a data-subject request. Articles pitching the project for [HIPAA or GDPR workloads](neura.market) are describing where the files sit; the code has no compliance feature. ## Access control is enforced inside memory-core and thinner around it Memory-core has a real access-control model, enforced on the server: assets are private to their owner (team admins included), shared with the team, restricted to named users, roles or agents, or bound to specific agents, and the [permission checker](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) fails closed. Around memory-core, the services are looser. The memory-core gateway's bearer key is [left empty in the deployment template](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), and in the default setup several read paths in the proxy and the knowledge service depend on network isolation, with no authentication check of their own. Keep all four services on a private network, and do not expose the proxy port beyond the machines that run your agents. ## Neither the PersonaMem result nor the token savings can be reproduced from the repository The README's one benchmark row, [PersonaMem](bowen-upenn/PersonaMem) accuracy of 48% without the project and 76% with it (labelled as a 59% relative gain), compares against no memory and cannot be reproduced from the repository. The 48% is not another memory product's score, although at least [one guide](regolo.ai) presents it as Mem0's, and (76 − 48) ÷ 48 is 58.3%. The repository contains no script, dataset split, model name or configuration for the run. Token-saving figures of 30% to 61% that appear in [several](jimmysong.io) [pages](pasqualepillitteri.it) (from WideSearch, SWE-bench and AA-LCR runs on OpenClaw) come from the 1.x README. They are not in the current README, and the public git history starts after them, so there is nothing left in the repository to check them against. ## Plan for a beta: no committed tests and four setup traps The public git history begins at the 2.0.0-beta.1 release on 22 July 2026, so the 1.x code behind earlier coverage is not in the repository. No test files are committed, even though the package scripts refer to them, and the [CI workflow](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) checks that the package builds and runs no behavioural tests. Version labels disagree across the README (2.0.0), the roadmap (2.0.1-beta.1), the latest tag (2.0.3-beta.1) and the memory-core package (1.0.2-beta.1). Plan for these four setup traps: embeddings off by default, Chinese keyword tokenisation by default, a team-and-agent picker that can interrupt the first turn of a session unless the team, agent and task headers are set, and an agent that needs a shell tool with network access to the proxy for any memory search. Teams on 1.x get a [migration tool](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). For integrating from your own application there is an [HTTP API](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) for conversations, atoms, scenes, persona and skills; note that it has no endpoint to create a new atom directly, so new facts only enter L1 through model extraction. A separate context-offload feature for long sessions also ships, switched off by default. ## Team memory, the Wiki and the code graph are the strongest part of the project You create teams and agents in the panel, then give each agent a loadout of assets: a chat memory, a set of skills, a Wiki built from product documents, and a code graph for the repositories it works on. Cold start is handled by importing existing repositories, documents and past agent sessions. Skills are versioned, private by default and shared after review, so an agent does not run an unreviewed skill. The code graph answers callers, callees and impact questions before an agent edits code, which a conversation-memory product does not attempt. Asset routing to agents is still manual, and the code graph handles public HTTPS repositories best, both of which the README notes itself. ## Seven of nine published claims do not hold against the code | Claim in published coverage | What the code at commit badbd21 does | |---|---| | Builds memory with no model API | Needs a memory model for every layer above raw transcripts; the template's example is DeepSeek's API | | Hybrid vector and keyword recall by default | Embeddings off in the shipped deploy; local embeddings disabled in config; recall is BM25 only | | Recalls relevant memories before every turn | Per-turn recall retired to protect the prompt cache; the model must search through curl | | Captures tool calls and their output | Captures the user message and the assistant's text; tool output only reaches the opt-in skill pipeline | | Nothing leaves the machine | Conversation text goes to the memory model; requests go to the upstream model | | Suitable for HIPAA or GDPR data | No PII handling, no encryption at rest, unlimited retention by default | | PersonaMem 48% to 76% | No reproduction code; 48% is a no-memory baseline | | Self-hosted, MIT, SQLite, no vector database subscription | Accurate | | Team-level sharing with access control | Accurate, enforced in memory-core | ## A proxy saves integration work and costs you control over what is remembered Putting memory in the request path is what makes TencentDB Agent Memory zero-code, and it is a real advantage when you want the same memory behind several off-the-shelf agents. The cost is that the proxy sees every request, holds or forwards your model API keys, depends on the model choosing to search for anything beyond the session-start summary, and decides what to capture from the traffic it can parse, which here excludes tool output. SDK-based layers such as [Mem0](mem0ai/mem0) and [Zep](getzep.com) ask for code changes, and in return your application decides exactly what is written and when context is fetched, with nothing intercepting the model call. ## Maximem Synap scopes memory per customer, controls sensitive data, links changed facts and pre-fetches recall Maximem Synap is a managed memory service your application calls from an SDK. It does not proxy your model calls, so your agent keeps talking to its model directly. The two products overlap on conversation memory and differ on almost everything around it. | | TencentDB Agent Memory | Maximem Synap | |---|---|---| | Deployment | Self-hosted, three containers, MIT | Managed cloud; self-hosted and air-gapped for enterprise engagements | | Integration | Base-URL proxy, no code | SDK (Python, TypeScript), REST, hosted MCP, 23 framework integrations | | Scoping | Team, user, agent and task, with private, team, restricted and agent visibility | Client, customer and user, plus conversation, assigned when a memory is written; nested ladders as an extension | | Sensitive data | None for content; secrets masked in logs | Detected per kind of data, with control over storage, whether the model provider sees it, and what each API key can reveal; payment details, keys and PINs never stored | | Changing facts | Merge within a session; both kept across sessions | Old fact linked to its replacement; a poorer replacement does not overwrite a richer fact | | Consolidation | Scene and persona rewrites on timers | Meditation every few hours, Nap daily, Sleep in quiet hours with consolidation and conscious forgetting | | Recall | Model-issued curl search; BM25 by default | Context pre-fetched into an in-process cache while the conversation runs | | Published accuracy | PersonaMem 48% to 76%, no reproduction code | 92% LongMemEval and 93.2% LoCoMo, reproduced on our open harness | | Docs and code memory | Wiki and code graph | Not offered | Synap assigns scope when a memory is written, not when it is read, and visibility flows one way: a user-scoped fetch can draw on customer-wide and client-wide memory, and a customer-scoped fetch never reaches into an individual user's memory. That is the property a B2B product needs when one deployment serves many customers. TencentDB Agent Memory scopes by team, user, agent and task, which fits one organisation's own teams and agents. Synap finds sensitive values in the content it receives and applies the treatment you choose per category, including showing the model an alias in place of the real value, as described in the [sensitive data guide](docs.maximem.ai). Seven field types, such as full card numbers, passwords and private keys, are never stored under any setting. The 92% on [LongMemEval](xiaowu0162/LongMemEval) is 460 of the 500 questions in LongMemEval_S; the 93.2% on [LoCoMo](snap-research/locomo) covers categories 1 to 4 of locomo10 (1,540 questions) and excludes the adversarial category 5. Both use gpt-5-mini as the answer model and as the judge, both were published in [arXiv 2607.21503](arxiv.org) on 23 July 2026, and the [harness](maximem-ai/memory_and_context_eval_harness) and [run outputs](maximem-ai/eval_benchmark_runs_output) are public, with configuration on our [evals page](maximem.ai). We report the most-reproduced result across runs and have not yet published the run count or spread. In-conversation retrieval returns in under 15ms at P75 because reads are served from the cache Synap fills ahead of time inside your process; that is a different measurement from a cold search, and different again from TencentDB Agent Memory's recall, which includes a model tool round trip. Choose TencentDB Agent Memory if you want everything on your own machines, your agents are coding agents with a shell tool, you want docs and code graphs alongside chat memory, and your users are your own team. Choose Synap if you are building a product that serves many customers, need sensitive-data controls a security reviewer can inspect, need facts to stay current across sessions, or need recall inside a latency budget such as a voice turn. ## Test stale facts and tool-output facts before you commit Replay 50 real conversations through the proxy as separate sessions, with one fact that changes between sessions and one fact that only ever appeared in tool output. Then ask questions with and without the entity's name, and count three things: answers that return the stale value, answers that miss the tool-output fact, and how many searches the model ran to answer. Run it once with embeddings off, as shipped, and once with an embedding server configured, and set `bm25.language` to match your users. If you are building a product for your own customers, run the stale-fact test first, since cross-session reconciliation is where the current pipeline is thinnest; if the agents are your team's coding agents, start with the tool-output test. ## Frequently asked questions **Is TencentDB Agent Memory fully local?** The storage is local, but building memory needs a language model, and the shipped template points at a hosted API. It is fully local only if the memory model, any embedding model and the agent's own model all run on your hardware. **Does TencentDB Agent Memory need an LLM?** Yes, for every layer above the raw transcript. Without one it keeps L0 conversations and supports keyword search over them, and nothing else. **Does TencentDB Agent Memory use a vector database?** It supports sqlite-vec and Tencent Cloud VectorDB, but the shipped deployment turns embeddings off, so recall is BM25 keyword search until you configure a remote or self-hosted embedding endpoint. **Does TencentDB Agent Memory handle PII?** No. It masks API keys in logs and stores and forwards conversation content unchanged. **Is the PersonaMem result reproducible?** Not from the repository, which contains no evaluation code, data or configuration for it. **How is it different from Mem0?** TencentDB Agent Memory is a proxy that needs no code changes and adds team sharing, a Wiki and a code graph; Mem0 is an SDK your application calls, so your code decides what is stored and when it is fetched. **Is it the same as Tencent Cloud's "agent long-term memory" for PostgreSQL?** No. That [Tencent Cloud document](tencentcloud.com) describes a pattern on TencentDB for PostgreSQL, a managed database product, and is unrelated to this open-source repository.
Mentions
I wrote a code-graph plugin for Claude Code and tested it against three popular ones on a real task. None of them helped. Every Claude Code session starts the same way. The agent does not know my codebase, so it greps, reads files and guesses what a change will break. I thought it would be great to give it a map. The agent asks one question, "what does this change affect?", and gets a short list of files and tests. The map is built from imports and from the contracts between packages: - HTTP routes - GraphQL operations - tables - queues - env variables So I built that tool and called it gsttt. A week later I had tables and charts in which it beat three popular tools. Then I tested all four on real work, and none of them made a measurable difference. This post is the whole story, from the idea to the moral. It includes the test setup, so you can check my work or redo it on your own repository. The short version - The idea: a map of the code should help an agent find what a change affects. - The tool: I built gsttt, and my own benchmark said it beat Graphify, GitNexus and codebase-memory-mcp. - The first reality check: on nine real commits, the installed tool was never called: 0 of 36 runs. - The last try: on one large real task, all four tools cost the same as no tool, inside the noise. - The moral: the agent did not need the graph. The bill followed which model does the code reviews and how many review rounds run. Contents - [The idea and the build](#the-idea-and-the-build) - [The first reality check](#the-first-reality-check) - [One last try with a real task](#one-last-try-with-a-real-task) - [The result](#the-result) - [Did the agents use the tools](#did-the-agents-use-the-tools) - [What moves the bill](#what-moves-the-bill) - [The moral](#the-moral) - [Limits](#limits) - [If you want to reproduce it](#if-you-want-to-reproduce-it) The idea and the build The code-graph tools I found did not treat contracts between packages as first-class edges. A GraphQL field in the server and the client query that uses it are an example. I wanted that link in the map, so I wrote my own on October 28. It is written in Rust, mostly with Claude Code. To see if it worked, I built a small multi-language fixture repository. I added fourteen questions with truth lists, such as "what depends on this file". Mean recall: | Tool | Mean recall | |---|---| | gsttt | 87% | | GitNexus | 73% | | codebase-memory-mcp | 72% | | Graphify | 46% | On Amplication, an open-source TypeScript monorepo, the TypeScript compiler also listed 97.3% of the callers gsttt found for 200 random methods. I was pleased. Then I looked at what the benchmark measured. I had written the fixture and the questions, knowing what gsttt does. A benchmark you write for your own tool measures whether it does what you built it to do. The first reality check So I ran the tool on real work: nine real merged changes, five from Amplication and four from a private monorepo. Each agent got a ticket written from the commit message, and I compared its diff with the real one. The model was Sonnet 5.5 at high effort, 99 runs in all. - Installed only: the agent never called gsttt. 0 of 36 runs, and 0 in 107 real sessions of mine. - With one sentence in the ticket ("Use gsttt to find what the change affects."), it called gsttt in all 27 runs. - The result: 4.4 more turns, about 4% more money, and no better recall of the real files: 0.64 against 0.66. I tried to fix that: - a skill text that says when to call the tool - answers in functions instead of files - cheaper answers - hints placed in the planning step and at stop time Nothing helped beyond the noise. An offline check on 420 commits compared gsttt with git co-change history. At the same list size, git history found 13 points more of the real files. For these agents, the graph carried no information they could not get from search. But those were small commits. A large change across many packages might be where a map pays off. One last try with a real task I also wanted the other tools in the picture. They have between 48,000 and 142,000 GitHub stars, and gsttt has 0. So I picked one large real task and ran all four tools on it. The task is a merged change in a private TypeScript monorepo for a SaaS product: an annual billing interval with a discount. It touches: - price calculation, the payment integration and the checkout service - a GraphQL contract on both sides, regenerated into three packages - a plan picker, a pricing section and translations in five locales - tests and an OpenSpec change proposal The real diff is 36 files, +1,183 and -96 lines. I chose it from 377 recorded sessions in that repository. It was the cheapest of four that edited at least eight files across three packages without any tool. The original session used Claude Opus 5.5 at xhigh effort. It took 57 turns and 15 sub-agents, cost about $8.10 and also made commits and a pull request. The codebase has six packages and 2,809 tracked files, about 282k lines of TypeScript. It carries its own agent setup, which stayed in every run: a CLAUDE.md, two sub-agent definitions and nine skills. The setup: - Each run starts in a fresh git repository with one commit, the parent state. The agent has no network and cannot read outside its folder. - The ticket is 335 words. Every run used Claude Opus 5.5 at xhigh effort, Claude Code 2.1.318, with a $15 cap. - Plugin only: the tool is installed as its README says, and nothing else. - Enforced (bare rounds only): the ticket also demands a tool call before the first edit and before the end. The gate never fired, because the agent called the tool first anyway. Two environments. The first one was a mistake. - Bare (rounds 1 and 2) loaded only the repository's own files. It is clean, but I never work that way, so its dollar figures do not describe my sessions. - Harness (round 3) also loads my own setup: my agorch plugin and superpowers, the two plugins of the original session, plus my instructions and rules. - In both, nothing else is loaded and nothing reaches outside the machine. Every run's start is audited against its arm. The tools are these four, at the versions I ran: | Tool | Version | Licence | Stars | |---|---|---|---| | gsttt | 0.1.196 | Apache-2.0 | 0 | | CodeGraph | 1.6.2 | MIT | 77k | | Graphify | 0.9.102 | Apache-2.0 | 142k | | GitNexus | 1.6.12 | PolyForm Noncommercial | 48k | I am the author of gsttt. No index build calls a model. The checks are mechanical: - typecheck of three packages - the server and client test suites - the GraphQL schema compared with the committed one - nine held-out test files from the real change - a 16-item checklist from the real diff, judged blind The result Cost is total_cost_usd at list prices, sub-agents included. | Setup | Runs | Cost per run, USD | Mean | |---|---|---|---| | no harness, baselines | 3 | 10.72, 11.74, 11.84 | 11.43 | | no harness, plugin only (four tools) | 4 | 11.75, 12.37, 11.25, 11.28 | 11.66 | | harness, baselines | 5 | 6.84, 7.39, 7.83, 8.73, 9.28 | 8.01 | | harness, gsttt | 2 | 9.44, 9.31 | 9.38 | | harness, Graphify | 3 | 8.19, 10.29, 8.54 | 9.01 | | harness, CodeGraph | 2 | 7.75, 9.55 | 8.65 | | harness, GitNexus | 2 | 7.40, 9.72 | 8.56 | !Dot chart of the cost per run in USD for no tool, gsttt, Graphify, CodeGraph and GitNexus, without and with my harness. In both panels the tool runs fall inside or next to the spread of the baselines. The full-size chart Quality did not move Every run delivered the whole change: - File recall against the real diff is 1.00 (0.97 once). - The checklist is 16 of 16. - The typechecks are clean and the GraphQL schema equals the real one. The nine held-out tests failed in every run, because they pin names the original author chose. The unaided agent already solved the task, so a tool had nothing to add except savings. The savings are inside the noise The three bare baselines differ by 1.12 dollars, so a difference of about a dollar cannot be read. The harness baseline mean is 8.01. | Tool | Runs | Difference from baseline mean | |---|---|---| | gsttt | 2 | +1.36 | | Graphify | 3 | +1.00 | | CodeGraph | 2 | +0.64 | | GitNexus | 2 | +0.55 | None is distinguishable from the baseline. The same tool run twice differs by 0.13 (gsttt) to 2.32 dollars (GitNexus). In the two big gaps, one run had one review round and the other had two. gsttt has the highest mean, and both its runs had two review rounds. I wrote this tool, so weigh that. Did the agents use the tools Maybe the agents just ignored them. They did not. In every plugin-only run the agent used its tool unasked, because of what each installer writes into the project. - Graphify adds a CLAUDE.md rule to query it before the first grep, two hooks and a 100 KB skill. The agent's first command was a graphify query. - CodeGraph adds an MCP tool and a hook that injects 9,223 characters of context at the first prompt. The agent called codegraph_explore twice, each answer about 23k characters. - GitNexus adds about 45 lines of MUST and NEVER rules, 12 skills and two hooks. The agent called impact 12 times, and the hook added a note to 10 of 90 Bash calls. - gsttt writes nothing into the repository. The agent called impact three times. The CodeGraph run was the most expensive of the twelve bare runs, $12.37. I cannot say what drove it. The gsttt calls contradict my earlier 0 of 36 for installed-only gsttt. The model, the task and the plugin version differ, and one run per tool is not a rate. So the tools were used, and the agent still did not need them. What moves the bill If the tools do not move the cost, something else does. The harness makes the same task $3.42 cheaper, 30%. My instructions send review and builder agents to Sonnet. - In all 43 review launches of the 14 harness runs, the agent passed model: "sonnet". Without the harness, 34 of 40 ran on Opus. - No experiment changed only the reviewer model, so this is a reading of the numbers. The spread inside the harness is wider, 6.84 to 9.28 among the baselines. It follows the review rounds the agent runs: | Review rounds | Baselines, mean USD | Tool runs, mean USD | |---|---|---| | one | 7.35 | 7.90 | | two | 9.00 | 9.42 | I do not know why the agent runs one round in some runs and two in others. It moves the cost by about two dollars, more than any tool did. The moral On paper, this looks great. A graph of how your code connects is a fun thing to build, and it is fun to look at. Many people install tool after tool and believe that the more tools they add, the better their harness and their model get. I started from the same belief. On this task, Claude did not care about these cool graphs of the codebase. It found every file without them. What moved the bill was boring: which model does the reviews and how many review rounds run. So before you add the next tool to your harness, measure it on one real task of yours. Run the baseline at least three times first. If the number does not move, the tool is decoration. Limits - One task, one repository, one model at one effort. No statistical test. - Recall and the checklist saturated at the maximum, and one AI agent judged the checklist. The typecheck, the tests and the schema equality carry the correctness evidence. - Runs are few: the bare environment has 3 baselines and one run per tool arm, the harness 5 baselines, 2 runs per tool and 3 for Graphify. - In round 1, ten claude.ai connectors were registered by mistake. No connector tool was called. Hooks of Graphify and GitNexus may have run twice in their round-1 enforced runs. - The harness comes from one original session. I trust the direction, cheaper reviews and a wider spread, more than the exact figures. - Wall-clock time is not comparable, because two runs shared the machine. - I wrote one of the four tools and designed the test. The checks are mechanical, but weigh that. - A task where the unaided agent misses files would be a fairer test of a code graph. This one did not have that problem. If you want to reproduce it 1. Pick a merged change in your repository that spans a few packages. 2. Rebuild the parent commit as a single commit and write the ticket from the issue. 3. Run each setup with the same model and effort, in a folder the agent cannot leave, with your own setup loaded. 4. Install each tool as its README says, writing into the project and not into your global config. 5. Set CLAUDE_CODE_PRINT_BG_WAIT_CEILING_MS=0 for headless runs with sub-agents. By default the process stops background tasks 10 minutes after the last turn. 6. Run the baseline at least three times before trusting a difference. The test runs, the blind judging and the first draft of this write-up were done by Claude Code agents from the run logs.
仓库：colbymchenry/codegraph 文档站：colbymchenry.github.io Release v1.6.2：github.com/colbymchenry/codegraph/releases/tag/v1… LICENSE（MIT）：github.com/colbymchenry/codegraph/blob/main/LICEN… 装完接线：新终端 codegraph install，项目内 codegraph init
Index a small repo with CodeGraph, ask an agent to trace a call chain, compare against your IDE’s references. Fifteen minutes to know if it’s accurate enough to trust. colbymchenry/codegraph
Index a small repo with CodeGraph, ask an agent to trace a call chain, compare against your IDE’s references. Fifteen minutes to know if it’s accurate enough to trust. colbymchenry/codegraph
Blast radius of a code change is a graph problem. CodeGraph builds an AST-derived graph of symbols, calls, and imports, then exposes it to Claude Code, Cursor, and Copilot over MCP. Verify it against known call paths before trusting it. colbymchenry/codegraph
Blast radius of a code change is a graph problem. CodeGraph builds an AST-derived graph of symbols, calls, and imports, then exposes it to Claude Code, Cursor, and Copilot over MCP. Verify it against known call paths before trusting it. colbymchenry/codegraph
Give your AI coding agent a pre-built map of your codebase: fewer tokens, fewer tool calls, 100% local. 🔗 colbymchenry/codegraph Credits: colbymchenry/codegraph #codegraph #c #rust
@JC_builds So… it’s colbymchenry/codegraph?
@JC_builds What's the difference between this tool and other tools like MinishLab/semble and colbymchenry/codegraph?
TencentDB Agent Memory, Read From the Source: It Needs a Second LLM and Searches by Keyword by Default *Code read at commit badbd21 on 13 October 2026.* The guides and news pages that rank for [TencentDB Agent Memory](TencentCloud/TencentDB-Agent-Memory) repeat three claims its source code does not support: that it builds memory without any model API, that it runs hybrid vector search out of the box, and that no conversation data leaves the machine. In the shipped setup, every memory layer above the raw transcript is written by a second language model whose example endpoint is DeepSeek's hosted API, and recall is BM25 keyword search because embeddings are switched off. The project itself is a self-hosted memory server that sits between your coding agent and its model as an API proxy, turns conversations into layered notes, and hands the agent a summary at the start of each session plus search endpoints it can call. It is MIT licensed, built by Tencent Cloud's database team, and had about 28,700 GitHub stars on 13 October 2026. We read the repository at [commit badbd21](github.com/TencentCloud/TencentDB-Agent-Memory/tr…) (release 2.0.3-beta.1, pushed on 13 October 2026), following the write path, the read path and the proxy through the code itself, and we checked the result against the pages that rank for the project's name, including its README, its press release and the guides that rank alongside them. Code-level claims link to the file at commit badbd21. We build [Maximem Synap](maximem.ai), a managed memory service that competes with it; for one organisation's coding agents that must stay on its own machines, TencentDB Agent Memory is the better choice. ## TencentDB Agent Memory runs four services in three containers, with an API proxy in front TencentDB Agent Memory is four services shipped as three Docker containers. Memory-core (port 8420) holds the conversation memory pipeline, the skill store and the access-control service. Memory-hub combines the admin panel (port 8125) with a knowledge service (port 8424) that builds a Wiki from your documents and a code graph from your repositories. The proxy (port 8096) is an LLM API reverse proxy that speaks the Anthropic Messages, OpenAI Chat Completions and OpenAI Responses formats, which is how it plugs into [Claude Code](claude.com), [Codex](openai.com), CodeBuddy, WorkBuddy, [Hermes Agent](nousresearch/hermes-agent), [OpenClaw](openclaw/openclaw) and DeepSeek Harness without code changes: you point the agent's base URL at the proxy. The [install template](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) lists the ports, and building from source needs [Node 22.16 or later](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). Storage defaults to SQLite with FTS5 for keyword search and sqlite-vec for vectors, with Tencent Cloud VectorDB as an optional backend and MongoDB marked experimental. Nothing ties it to Tencent Cloud, although the built-in document and code importers target Tencent-internal tools (iWiki and Gongfeng). Its borrowings are credited openly: the code graph is the [`@colbymchenry/codegraph`](colbymchenry/codegraph) package wrapped as a service, the skill pipeline adapts code from Hermes Agent, and the Wiki follows [Andrej Karpathy's LLM Wiki idea](gist.github.com). ## A second language model builds the memory, and tool output never reaches it After each main turn the proxy sends memory-core the user's message (with harness wrappers stripped) and the assistant's text reply, and [nothing else](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). Tool calls and tool results are not part of that write. For a coding agent this is the largest single design decision in the project, because the file paths, commands, stack traces and test output that a coding session actually turns on live in tool results, and the memory pipeline never sees them. A separate, opt-in skill pipeline does read tool calls, but only to draft reusable SKILL.md files, and nothing from it becomes a fact in memory. Memory is built in four layers. Raw messages land as L0, stored as daily JSONL files and as SQLite rows indexed for keyword search. A language model then extracts L1 "atoms" from them: short, self-contained statements typed as persona, episodic or instruction memories, or as work facts, tasks, methods and artifacts when the [code-mode prompt](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) is selected. A tool-using agent rewrites up to 15 markdown "scene" files from those atoms as L2, and a second agent run keeps a single persona file as L3, capped at 2,000 characters (1,200 in code mode). Building memory needs a language model. There is no rule-based or regex extractor in the code. If extraction is turned off, or no model is configured, the L1, L2 and L3 runs [log a skip and return nothing](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), and the only memory left is the raw L0 transcript. The deployment template requires a memory model endpoint and uses [DeepSeek's API](api-docs.deepseek.com) as its example. Any OpenAI- or Anthropic-compatible endpoint works, including a local server such as [Ollama](ollama.com) or [vLLM](vllm-project/vllm), but the shipped template does not do this for you. Extraction fires every 5 turns, after 10 minutes of idle time, or on a warm-up schedule of 1, 2, 4 and 5 turns for a new session, and each run reads at most 10 new messages. A run makes one extraction call and up to one deduplication call. Scene updates run at most every 15 minutes per active session and the persona updates after every 50 new atoms or when the scene agent asks for it. A 20-turn session therefore costs roughly four to twelve extraction and deduplication calls plus one to three multi-step agent runs, none of which block the user's turn. Changed facts are reconciled only within a session. For each new atom, memory-core pulls the five most similar existing atoms by keyword and vector search (there is no similarity threshold) and asks the model, in one batched call, whether to store, update, merge or skip. An update or merge [hard-deletes the old rows](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) and writes a new row with a higher version number; no pointer to the replaced fact survives at L1. The comparison is [limited to the same session](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), so when a user says "we moved the API to v3" on Tuesday and "the API is on v2" was recorded the previous week, both atoms stay in L1 and both can come back from search. The scene layer does keep an evolution trail and a section for unresolved contradictions, which makes L2 the only layer that records change over time. Search applies no recency, validity or superseded filter either, so nothing in the read path prefers the newer of two conflicting atoms. L0 and L1 are kept forever by default; the [retention setting](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) defaults to zero days, which means no cleanup. ## The model has to search for memories itself, and search is keyword-only out of the box At the start of a session the proxy writes a block into the system prompt containing the full L3 persona (truncated at 6,000 characters) and an index of L2 scene paths with 200-character summaries. That block is built once and cached for the session, so it does not disturb prompt caching after the first turn. The proxy also adds a text guide telling the model it can use its own shell tool to `curl` a set of read-only search endpoints on the proxy for L1 atoms, L0 conversations and full scene files. Per-turn automatic recall, where relevant atoms are attached to every user message, exists in the code but is [not registered](github.com/TencentCloud/TencentDB-Agent-Memory/bl…); the comment beside it says it was retired because it broke the KV and prompt cache. So a specific fact reaches the model only when the model decides to search, writes a curl command, runs it through its tool loop and reads the result. That costs a full tool round trip, and an agent without a shell tool, or without network access to the proxy, cannot search at all. Out of the box, search is BM25 keyword search only, although the code fuses BM25 and vector results by [reciprocal rank fusion](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), with k set to 60, equal weights, five results by default and no reranker. The shipped Docker deployment sets the embedding provider to [`none`](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), and the config loader [turns a "local" embedding provider into "disabled"](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) with a message asking for a remote one. [GreenNode's integration write-up](greennode.ai) hit exactly this: hybrid recall returned an error without an embedding service, and they fell back to keyword search. BM25 also [defaults to Chinese tokenisation](github.com/TencentCloud/TencentDB-Agent-Memory/bl…); English deployments should set `bm25.language: en`. If memory-core is unreachable, the proxy [passes the original request through](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) without memory, so the agent keeps working. ## Conversation text leaves the machine through the memory model The "fully local, nothing leaves the building" framing in [several](pasqualepillitteri.it) [articles](aitoolly.com) is half right. The storage is local and there is no vector database subscription. Telemetry to Langfuse, Opik, ClickHouse and Kafka is off by default and needs endpoints you supply. But in the shipped setup, conversation text goes to the memory model in batches of up to 10 messages for extraction, scene and persona summaries go to it for L2 and L3, and imported documents go to it in chunks of up to 12,000 characters to build the Wiki. If that endpoint is a hosted API, a second provider now receives your conversations alongside the one your agent already uses. The proxy also forwards every agent request to its upstream model, so the setup is only as local as that upstream. For agent memory to be private in the sense the coverage implies, three things have to run on your own hardware: the memory model, the embedding model, and the agent's own model. TencentDB Agent Memory can run the memory model and the embedding model on your hardware (or run with embeddings off), and the agent's own model is your choice. There is no PII handling of conversation content anywhere in the code. The only redaction we found [masks API keys and tokens in logs](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). User text is stored exactly as written, sent unchanged to the memory model, and the persona layer exists to build a profile of the user. We found no encryption at rest for memory data, and while delete endpoints exist for conversations and atoms, there is no export-and-erase workflow for a data-subject request. Articles pitching the project for [HIPAA or GDPR workloads](neura.market) are describing where the files sit; the code has no compliance feature. ## Access control is enforced inside memory-core and thinner around it Memory-core has a real access-control model, enforced on the server: assets are private to their owner (team admins included), shared with the team, restricted to named users, roles or agents, or bound to specific agents, and the [permission checker](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) fails closed. Around memory-core, the services are looser. The memory-core gateway's bearer key is [left empty in the deployment template](github.com/TencentCloud/TencentDB-Agent-Memory/bl…), and in the default setup several read paths in the proxy and the knowledge service depend on network isolation, with no authentication check of their own. Keep all four services on a private network, and do not expose the proxy port beyond the machines that run your agents. ## Neither the PersonaMem result nor the token savings can be reproduced from the repository The README's one benchmark row, [PersonaMem](bowen-upenn/PersonaMem) accuracy of 48% without the project and 76% with it (labelled as a 59% relative gain), compares against no memory and cannot be reproduced from the repository. The 48% is not another memory product's score, although at least [one guide](regolo.ai) presents it as Mem0's, and (76 − 48) ÷ 48 is 58.3%. The repository contains no script, dataset split, model name or configuration for the run. Token-saving figures of 30% to 61% that appear in [several](jimmysong.io) [pages](pasqualepillitteri.it) (from WideSearch, SWE-bench and AA-LCR runs on OpenClaw) come from the 1.x README. They are not in the current README, and the public git history starts after them, so there is nothing left in the repository to check them against. ## Plan for a beta: no committed tests and four setup traps The public git history begins at the 2.0.0-beta.1 release on 22 July 2026, so the 1.x code behind earlier coverage is not in the repository. No test files are committed, even though the package scripts refer to them, and the [CI workflow](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) checks that the package builds and runs no behavioural tests. Version labels disagree across the README (2.0.0), the roadmap (2.0.1-beta.1), the latest tag (2.0.3-beta.1) and the memory-core package (1.0.2-beta.1). Plan for these four setup traps: embeddings off by default, Chinese keyword tokenisation by default, a team-and-agent picker that can interrupt the first turn of a session unless the team, agent and task headers are set, and an agent that needs a shell tool with network access to the proxy for any memory search. Teams on 1.x get a [migration tool](github.com/TencentCloud/TencentDB-Agent-Memory/bl…). For integrating from your own application there is an [HTTP API](github.com/TencentCloud/TencentDB-Agent-Memory/bl…) for conversations, atoms, scenes, persona and skills; note that it has no endpoint to create a new atom directly, so new facts only enter L1 through model extraction. A separate context-offload feature for long sessions also ships, switched off by default. ## Team memory, the Wiki and the code graph are the strongest part of the project You create teams and agents in the panel, then give each agent a loadout of assets: a chat memory, a set of skills, a Wiki built from product documents, and a code graph for the repositories it works on. Cold start is handled by importing existing repositories, documents and past agent sessions. Skills are versioned, private by default and shared after review, so an agent does not run an unreviewed skill. The code graph answers callers, callees and impact questions before an agent edits code, which a conversation-memory product does not attempt. Asset routing to agents is still manual, and the code graph handles public HTTPS repositories best, both of which the README notes itself. ## Seven of nine published claims do not hold against the code | Claim in published coverage | What the code at commit badbd21 does | |---|---| | Builds memory with no model API | Needs a memory model for every layer above raw transcripts; the template's example is DeepSeek's API | | Hybrid vector and keyword recall by default | Embeddings off in the shipped deploy; local embeddings disabled in config; recall is BM25 only | | Recalls relevant memories before every turn | Per-turn recall retired to protect the prompt cache; the model must search through curl | | Captures tool calls and their output | Captures the user message and the assistant's text; tool output only reaches the opt-in skill pipeline | | Nothing leaves the machine | Conversation text goes to the memory model; requests go to the upstream model | | Suitable for HIPAA or GDPR data | No PII handling, no encryption at rest, unlimited retention by default | | PersonaMem 48% to 76% | No reproduction code; 48% is a no-memory baseline | | Self-hosted, MIT, SQLite, no vector database subscription | Accurate | | Team-level sharing with access control | Accurate, enforced in memory-core | ## A proxy saves integration work and costs you control over what is remembered Putting memory in the request path is what makes TencentDB Agent Memory zero-code, and it is a real advantage when you want the same memory behind several off-the-shelf agents. The cost is that the proxy sees every request, holds or forwards your model API keys, depends on the model choosing to search for anything beyond the session-start summary, and decides what to capture from the traffic it can parse, which here excludes tool output. SDK-based layers such as [Mem0](mem0ai/mem0) and [Zep](getzep.com) ask for code changes, and in return your application decides exactly what is written and when context is fetched, with nothing intercepting the model call. ## Maximem Synap scopes memory per customer, controls sensitive data, links changed facts and pre-fetches recall Maximem Synap is a managed memory service your application calls from an SDK. It does not proxy your model calls, so your agent keeps talking to its model directly. The two products overlap on conversation memory and differ on almost everything around it. | | TencentDB Agent Memory | Maximem Synap | |---|---|---| | Deployment | Self-hosted, three containers, MIT | Managed cloud; self-hosted and air-gapped for enterprise engagements | | Integration | Base-URL proxy, no code | SDK (Python, TypeScript), REST, hosted MCP, 23 framework integrations | | Scoping | Team, user, agent and task, with private, team, restricted and agent visibility | Client, customer and user, plus conversation, assigned when a memory is written; nested ladders as an extension | | Sensitive data | None for content; secrets masked in logs | Detected per kind of data, with control over storage, whether the model provider sees it, and what each API key can reveal; payment details, keys and PINs never stored | | Changing facts | Merge within a session; both kept across sessions | Old fact linked to its replacement; a poorer replacement does not overwrite a richer fact | | Consolidation | Scene and persona rewrites on timers | Meditation every few hours, Nap daily, Sleep in quiet hours with consolidation and conscious forgetting | | Recall | Model-issued curl search; BM25 by default | Context pre-fetched into an in-process cache while the conversation runs | | Published accuracy | PersonaMem 48% to 76%, no reproduction code | 92% LongMemEval and 93.2% LoCoMo, reproduced on our open harness | | Docs and code memory | Wiki and code graph | Not offered | Synap assigns scope when a memory is written, not when it is read, and visibility flows one way: a user-scoped fetch can draw on customer-wide and client-wide memory, and a customer-scoped fetch never reaches into an individual user's memory. That is the property a B2B product needs when one deployment serves many customers. TencentDB Agent Memory scopes by team, user, agent and task, which fits one organisation's own teams and agents. Synap finds sensitive values in the content it receives and applies the treatment you choose per category, including showing the model an alias in place of the real value, as described in the [sensitive data guide](docs.maximem.ai). Seven field types, such as full card numbers, passwords and private keys, are never stored under any setting. The 92% on [LongMemEval](xiaowu0162/LongMemEval) is 460 of the 500 questions in LongMemEval_S; the 93.2% on [LoCoMo](snap-research/locomo) covers categories 1 to 4 of locomo10 (1,540 questions) and excludes the adversarial category 5. Both use gpt-5-mini as the answer model and as the judge, both were published in [arXiv 2607.21503](arxiv.org) on 23 July 2026, and the [harness](maximem-ai/memory_and_context_eval_harness) and [run outputs](maximem-ai/eval_benchmark_runs_output) are public, with configuration on our [evals page](maximem.ai). We report the most-reproduced result across runs and have not yet published the run count or spread. In-conversation retrieval returns in under 15ms at P75 because reads are served from the cache Synap fills ahead of time inside your process; that is a different measurement from a cold search, and different again from TencentDB Agent Memory's recall, which includes a model tool round trip. Choose TencentDB Agent Memory if you want everything on your own machines, your agents are coding agents with a shell tool, you want docs and code graphs alongside chat memory, and your users are your own team. Choose Synap if you are building a product that serves many customers, need sensitive-data controls a security reviewer can inspect, need facts to stay current across sessions, or need recall inside a latency budget such as a voice turn. ## Test stale facts and tool-output facts before you commit Replay 50 real conversations through the proxy as separate sessions, with one fact that changes between sessions and one fact that only ever appeared in tool output. Then ask questions with and without the entity's name, and count three things: answers that return the stale value, answers that miss the tool-output fact, and how many searches the model ran to answer. Run it once with embeddings off, as shipped, and once with an embedding server configured, and set `bm25.language` to match your users. If you are building a product for your own customers, run the stale-fact test first, since cross-session reconciliation is where the current pipeline is thinnest; if the agents are your team's coding agents, start with the tool-output test. ## Frequently asked questions **Is TencentDB Agent Memory fully local?** The storage is local, but building memory needs a language model, and the shipped template points at a hosted API. It is fully local only if the memory model, any embedding model and the agent's own model all run on your hardware. **Does TencentDB Agent Memory need an LLM?** Yes, for every layer above the raw transcript. Without one it keeps L0 conversations and supports keyword search over them, and nothing else. **Does TencentDB Agent Memory use a vector database?** It supports sqlite-vec and Tencent Cloud VectorDB, but the shipped deployment turns embeddings off, so recall is BM25 keyword search until you configure a remote or self-hosted embedding endpoint. **Does TencentDB Agent Memory handle PII?** No. It masks API keys in logs and stores and forwards conversation content unchanged. **Is the PersonaMem result reproducible?** Not from the repository, which contains no evaluation code, data or configuration for it. **How is it different from Mem0?** TencentDB Agent Memory is a proxy that needs no code changes and adds team sharing, a Wiki and a code graph; Mem0 is an SDK your application calls, so your code decides what is stored and when it is fetched. **Is it the same as Tencent Cloud's "agent long-term memory" for PostgreSQL?** No. That [Tencent Cloud document](tencentcloud.com) describes a pattern on TencentDB for PostgreSQL, a managed database product, and is unrelated to this open-source repository.