π Why this one is worth reading
Most coverage of a vendor release repeats the vendor's numbers. This video does something else: it opens the benchmark table, divides the columns itself, and reports where the arithmetic disagrees with the printed figure.
"Divide the SWE-bench token columns yourself. 3,474 million down to 2,375. That is a 31.6% cut. The row next to it says 33.1β¦ These figures are checkable. So check them."
He is right. 3474.1 β 2375.4 is a 31.63% reduction; the README prints 33.09%. The AA-LCR row divides out to 30.98% β exactly the printed number. So one row is inconsistent and the others are not, which is the shape of a normalisation choice rather than an inflated claim, and that is precisely how he characterises it.
The reason to cover this rather than the release itself: the engine is genuinely interesting, but the more transferable thing here is the method. A benchmark table with both raw values and a percentage is self-checking β anyone can divide. Most vendor tables publish only the percentage, and that difference is not stylistic.
π§ The problem: context rot 0:28
The framing is concrete rather than abstract: an agent 40 turns into a job, having read 9 files and run 12 commands, about to ask the same question it asked on turn 4. Every turn drags the whole history back into the prompt.
The obvious fix β a bigger context window β is the one the video rules out first, citing Chroma's context-rot study across 18 frontier models on trivial tasks (copy this text, find this sentence). Accuracy falls as input grows, and starts falling long before the window is full.
"A 200,000-token window can start degrading around 50,000. The number on the box is not the number you get in practice."
The Chroma study is real β research.trychroma.com/context-rot resolves and is the widely-cited 2025 evaluation. The specific per-model degradation figures were not independently reproduced for this article.
The consequence that makes the rest follow: an agent that remembers by hoarding gets slower, more expensive and less accurate simultaneously. Those usually trade off against each other. When all three move the same way, the strategy is wrong rather than under-tuned.
Scale check from the video: one SWE-bench session of 50 consecutive coding tasks burned 3.5 billion tokens β roughly 3,500 full million-token context windows on a single benchmark run.
Scale check from the video: one SWE-bench session of 50 consecutive coding tasks burned 3.5 billion tokens β roughly 3,500 full million-token context windows on a single benchmark run.
π Idea one: fold the logs 2:42
The observation underneath is simple and correct: in a long task the token hogs are not your instructions β they are the intermediate logs. Search results, stack traces, file dumps.
So the plugin moves them out. Full tool output is written to Markdown files on disk; what stays in the prompt is a Mermaid graph of what happened, with an ID on every node. When the agent hits an error and needs detail, it greps the node_id and pulls the raw text back.
"That is the constraint they kept. Compress, but never lose the road back to the evidence. None of that is summarization. A summary is one way. This is a folded diagram you can open again."
Confirmed in the README, which describes the same three-layer structure: raw tool outputs in
refs/*.md, step-level summaries in jsonl, and a top-layer Mermaid canvas the agent attends to β drilling down via node_id when something fails. Its own phrasing: "Lower layers preserve evidence; upper layers preserve structure."The distinction between compression and summarisation is the load-bearing one. A summary discards the original; you cannot recover what it dropped. A folded structure with intact pointers is reversible β and reversibility is what makes it safe to be aggressive. This is the same principle as keeping the raw transcript beside the article: the compressed form is for working in, the evidence remains addressable.
Two thresholds drive the folding, per the video: mild compression at half the context window, aggressive at 85%, with the canvas itself capped at 20% of the token budget so the map never eats the room it saves.
Two thresholds drive the folding, per the video: mild compression at half the context window, aggressive at 85%, with the canvas itself capped at 20% of the token budget so the map never eats the room it saves.
πΊ Idea two: the memory pyramid 4:51
The long-term half borrows explicitly from psychology, and the video spends real time on why β which is unusual and, here, earns its place.
Endel Tulving's 1972 split: episodic memory (events, with times attached) versus semantic memory (facts, with the event that taught them stripped away). You know Paris is the capital of France; you have no idea which afternoon you learned it. The interesting part is the arrow between them β episodes get replayed, patterns get extracted, the episode fades. Psychologists call it consolidation.
"Forgetting is not the bug in that system. It is the compression step."
Tencent's four layers are that arrow, written down:
| Layer | Contents | Refresh |
|---|---|---|
| L0 Conversation | Raw dialogue, exactly as said | β |
| L1 Atom | Atomic facts, preferences, constraints | Every 5 turns |
| L2 Scenario | Scene blocks β this project, this task type | β |
| L3 Persona | Habits, conventions, defaults | Every 50 new memories |
The README documents the same pyramid in the same order β "L0 Conversation (raw dialogue) β L1 Atom (atomic facts) β L2 Scenario (scene blocks) β L3 Persona (user profile)" β and the same read pattern: the Persona layer carries day-to-day preferences, and the system "drills down to Atoms only when details matter."
Why this is more than a metaphor. The agent reads top-down: persona first because it is cheap and usually sufficient, atoms when a specific fact matters, L0 when exact wording matters. That is a retrieval strategy with a cost gradient built into its shape β cheap answers are tried first and expensive ones are reached for only on demand.
The benchmark for this half is PersonaMem, where user preferences change across sessions and the test is whether the system tracks the change. Baseline 48% β 76% with the layers.
The benchmark for this half is PersonaMem, where user preferences change across sessions and the test is whether the system tracks the change. Baseline 48% β 76% with the layers.
π§ The boring plumbing 6:40
Deliberately unglamorous, and the video is right that this is a feature: SQLite with the sqlite-vec extension, running locally. No API key, no vendor endpoint, nothing leaving the machine unless you say so. One command to install into OpenClaw, Node 22+, works with no configuration.
Retrieval is hybrid β BM25 keyword search plus vector search, merged with reciprocal rank fusion, 5 results per recall, a 5-second timeout, and if it is slow it skips the injection rather than stalling your turn.
Confirmed: the README states the local backend is "SQLite + sqlite-vec, ready to use out of the box" and describes the hybrid BM25 + vector retrieval fused with RRF.
The design decision worth stealing is the timeout behaviour. A memory layer that blocks the turn when retrieval is slow makes the agent feel broken; one that silently skips injection degrades to "no memory this turn", which is the state the agent was in before the plugin existed. Fail toward the previous behaviour, not toward a stall.
And every layer is a file you can open β persona in Markdown, scenes in Markdown, task canvas in Mermaid. As the video puts it: "When recall goes wrong, you read it. Instead of squinting at a list of cosine scores." White-box by construction, which matters enormously when you have to explain a system's behaviour rather than just observe it.
And every layer is a file you can open β persona in Markdown, scenes in Markdown, task canvas in Mermaid. As the video puts it: "When recall goes wrong, you read it. Instead of squinting at a list of cosine scores." White-box by construction, which matters enormously when you have to explain a system's behaviour rather than just observe it.
π’ The numbers, divided out 7:24
The full table from the README, with the arithmetic checked independently for this article:
| Benchmark | Pass rate | Tokens | Printed Ξ | Recomputed |
|---|---|---|---|---|
| WideSearch | 33% β 50% (+51.52%) | 221.31M β 85.64M | β61.38% | β61.30% |
| SWE-bench | 58.4% β 64.2% (+9.93%) | 3474.1M β 2375.4M | β33.09% | β31.63% |
| AA-LCR | 44.0% β 47.5% (+7.95%) | 112.0M β 77.3M | β30.98% | β30.98% |
| PersonaMem | 48% β 76% (+59%) | β | β | β |
The pattern the headline hides: the gains shrink as the task gets harder. WideSearch β a wide, shallow benchmark of 200 questions where many easy facts must all be right at once β is the best case, and it is the number everyone quotes. SWE-bench, real coding work, moves +9.93%. AA-LCR, long-document reasoning over financial and legal filings, moves +7.95%.
The video says this plainly at 4:49: "Smaller gains as the task gets harder. Hold on to that." Single-digit improvements are still real improvements β but "+51.52% pass rate" as a headline describes one benchmark, not the system.
The video says this plainly at 4:49: "Smaller gains as the task gets harder. Hold on to that." Single-digit improvements are still real improvements β but "+51.52% pass rate" as a headline describes one benchmark, not the system.
Every number in that table was produced by the vendor. No independent reproduction has been published. The video says so directly and gives the reason it matters: "Mem0 published a paper ranking memory systems against each other. Zep published a rebuttal saying its system had been misconfigured and scored itself about 9 points higher⦠Everyone benchmarks on a different dataset so each of them gets to be first."
Of the secondary coverage checked for this article, only MarkTechPost carries the caveat β "these numbers come from Tencent's own evaluations". Every other outlet reproduces the table without it.
Of the secondary coverage checked for this article, only MarkTechPost carries the caveat β "these numbers come from Tencent's own evaluations". Every other outlet reproduces the table without it.
πΈ Where the saving leaks back 8:25
The sharpest practical finding, and one that would not occur to most readers: injecting memory means changing the front of the prompt every single turn. Providers cache that prefix, and identical opening tokens bill at a fraction of the price. Change the opening each turn and the cache stops hitting.
"Part of your token saving walks straight back out the door."
Issue #120 is real and open. Title: "prependContext + showInjected ε―Όθ΄ OpenAI-compatible provider εηΌηΌεε½δΈηιε / Prompt cache hit rate regression". Opened 31 May 2026, 99 comments, still open. The report documents degraded prefix-cache hit rates against OpenAI-compatible providers after enabling the plugin.
Why the video's read on this is the right one. The problem is public, argued in the open, and split into named follow-ups β moving persona and scene blocks into a stable prefix. That is more informative than a resolved issue would be: it shows the maintainers understand the failure mode and have not papered over it.
The wider repository health matches: 408 open issues, the most-discussed being #160 β "buildFtsQuery does not sanitize FTS5 operators", meaning user input can rewrite the search query β with 177 comments. A four-month-old repository moving fast with the mess visible. As the video puts it: "Read that as a maturity signal, not a scandal."
The wider repository health matches: 408 open issues, the most-discussed being #160 β "buildFtsQuery does not sanitize FTS5 operators", meaning user input can rewrite the search query β with 177 comments. A four-month-old repository moving fast with the mess visible. As the video puts it: "Read that as a maturity signal, not a scandal."
The practical implication for a token-cost decision: the benchmark table measures tokens consumed, not tokens billed. If your provider prices cached prefix tokens differently β and the major ones do β the net saving on your invoice is smaller than 61%, 33% or whatever row applies to your workload. Nobody has published that number.
π’ Who is paying for this 9:12
The licence checks out β with a caveat about how you check it. The
LICENSE file reads "TencentDB Agent Memory is licensed under the MIT" with the full MIT terms. GitHub's API reports NOASSERTION because the file has a Tencent preamble before the standard text. Read the file, not the API field.The business model is stated openly by the video rather than discovered: it is MIT and it does run entirely local, but it also ships a Tencent Cloud vector database backend and a managed memory service that launched days before the repository existed. The Docker image defaults to Tencent's own model endpoint.
"Open core with a cloud upsell. Standard practice and worth seeing clearly before you build a company on it."
The stranger detail is internal competition. The video reports that Tencent's Hunyuan team shipped a rival memory plugin for the same host framework weeks later β six layers instead of four, a fast/slow dual system, 35% fewer tokens by its own numbers. Two teams, one company, two memory plugins, one host.
Note: this article could not independently locate that second repository via GitHub search. Treat the specific claim as unverified; the general point β that this layer is unsettled enough for one company to fund two answers β stands on the field data below.
Note: this article could not independently locate that second repository via GitHub search. Treat the specific claim as unverified; the general point β that this layer is unsettled enough for one company to fund two answers β stands on the field data below.
| Project | Stars | Created |
|---|---|---|
| mem0ai/mem0 | 62,325 | Jun 2023 |
| letta-ai/letta (MemGPT) | 24,061 | Oct 2023 |
| MemTensor/MemOS | 10,546 | Jul 2025 |
| TencentCloud/TencentDB-Agent-Memory | 10,811 | Apr 2026 |
All four counts verified via the GitHub API. Tencent reached MemOS's star count in under four months against thirteen β roughly 89 stars a day, as the video says. Star velocity is an attention metric, not a quality one, but the ordering is real.
π¦ Memory as an asset 10:29
Version 2, shipped July, is the part with the longest half-life. Memory moves from a private cache to a shared asset in four types: chat memory, skills, a wiki, and a code graph.
The repository description confirms this exactly: "a team-level memory hub for AI Agents β turning conversations, docs, and code into four reusable memory assets (Chat Memory, Skill, LLM-Wiki, Code-Graph) that are governed, shared, and equipped across agents and frameworks." Five releases exist,
v2.0.0-beta.1 dated 22 July 2026.- Skill β not a prompt snippet: carries a version, resource files, trigger boundaries, execution steps and validation rules. "Closer to a package than a note." Private by default, shared with the team only after review.
- LLM-Wiki β Markdown entity pages the agent writes and maintains, linked to each other so knowledge compounds between sessions.
- Code-Graph β indexes the codebase's structure so an agent starts a task already knowing how the pieces connect.
- Cold start β point it at an existing repository, a folder of docs, or old agent sessions and it backfills graph, wiki and skills before the new agent does anything.
The framing that makes this matter: each asset carries an owner, a version and permissions β private, team, or a named access list. "Memory stops being a log and becomes an artifact with a license plate."
That is a meaningful shift. A log is exhaust; an artifact is something you review, version, share and are accountable for. Anyone maintaining a skills library recognises the pattern β the value is not in any single procedure but in the accumulated, curated set, and the moment it becomes shareable it needs governance.
That is a meaningful shift. A log is exhaust; an artifact is something you review, version, share and are accountable for. Anyone maintaining a skills library recognises the pattern β the value is not in any single procedure but in the accumulated, curated set, and the moment it becomes shareable it needs governance.
And the unanswered question the video closes on, which is the right one: "When memory becomes an asset you own, what happens when you switch frameworks, or leave the team that built it?" Portable memory is item one on the roadmap, and the box is unchecked. An asset you cannot take with you is a lock-in mechanism wearing an asset's clothes.
β οΈ The description got it wrong
One correction, and it is worth isolating because it cuts the other way from the usual complaint.
| Source | Claim |
|---|---|
| Video description | "cuts SWE-bench token usage by 61% while actually boosting pass rates" |
| The video itself | Attributes 61% to WideSearch, states SWE-bench separately as 58.4 β 64.2 on a third fewer tokens |
| The README | WideSearch β61.38%; SWE-bench β33.09% |
The description merges the best token figure from one benchmark with the existence of gains on another. The spoken content does not make that error β it separates the benchmarks correctly and explicitly notes the gains shrink on harder tasks.
Worth naming because the failure mode is now common: the video is careful, the metadata written to attract clicks is not, and most readers only ever see the metadata. If you evaluate this project from the description alone, you will expect a 61% saving on coding work and get roughly half that.
Worth naming because the failure mode is now common: the video is careful, the metadata written to attract clicks is not, and most readers only ever see the metadata. If you evaluate this project from the description alone, you will expect a 61% saving on coding work and get roughly half that.
π¦ Reading this from a bank
| Property | Implication in a regulated setting |
|---|---|
| Fully local by default β SQLite, no API key | No data egress. The decisive property for agent memory holding client context |
| Every layer is a readable file | Persona and scenes in Markdown, canvas in Mermaid β a memory system you can audit by opening it, not by interpreting embeddings |
| Full drill-down to raw evidence | Compression that keeps a deterministic path back to source is exactly what an audit trail requires |
| MIT licensed | Commercially usable, forkable, no vendor dependency in the local path |
| Vendor-only benchmarks | No independent reproduction. Fine for a pilot, insufficient for a model-risk file |
| 408 open issues, incl. unsanitised FTS5 query input | Issue #160 is a query-injection surface. Four-month-old code moving fast β not yet a production dependency |
| Docker default points at a Tencent endpoint | The "fully local" property is a configuration, not a guarantee. Verify the endpoint before deployment, not after |
| Memory as a governed, permissioned asset | Owner, version and access list per asset is closer to a records-management model than anything else in this space |
The idea that survives the specific product. The architecture here β keep a sketch in context, keep the evidence on disk, keep the path between them intact β is not Tencent's, and the video says so: "Every serious memory system being built right now is converging on the same shape."
For a regulated environment that convergence is the interesting news, because the shape it is converging on is auditable by construction. A flat vector store answers "here are some similar chunks". A layered store with intact pointers answers "here is what I concluded, here is the scene it came from, here is the exact sentence you said." Those are different in kind, and only the second one survives a question from a regulator.
For a regulated environment that convergence is the interesting news, because the shape it is converging on is auditable by construction. A flat vector store answers "here are some similar chunks". A layered store with intact pointers answers "here is what I concluded, here is the scene it came from, here is the exact sentence you said." Those are different in kind, and only the second one survives a question from a regulator.
π Claims checked
| Claim | Result |
|---|---|
| Repository exists, MIT, actively developed | 10,811 β, 1,024 forks, created 7 Apr 2026, 5 releases, pushed 29 Jul |
| Licence is MIT | LICENSE file says MIT. GitHub's API reports NOASSERTION due to the Tencent preamble β read the file |
| OpenClaw is the host framework, ~384k stars | Confirmed β openclaw/openclaw, 384,946 β |
| Chroma context-rot study across 18 models | Study exists and resolves; per-model figures not reproduced here |
L0βL3 pyramid, Mermaid canvas, node_id drill-down | All documented in the README in the same terms |
| SQLite + sqlite-vec, BM25 + vector with RRF | Confirmed in the README |
| WideSearch β61.38%, 33% β 50% | Table matches; recomputes to β61.30% |
| SWE-bench token cut printed as β33.09% | Recomputes to β31.63%. The video catches this on camera and calls it a normalisation choice |
| AA-LCR β30.98% | Divides out to exactly the printed figure |
| All benchmarks are vendor-produced | Confirmed. No independent reproduction found. Only MarkTechPost flags it among secondary coverage |
| Issue #120: prompt-cache regression | Real, open, 99 comments, filed 31 May 2026 |
| ~400 open issues; top thread ~177 comments | 408 open; #160 (FTS5 sanitisation) has 177 comments |
| Field sizes: Mem0 62k, Letta 24k, MemOS 10.5k | 62,325 / 24,061 / 10,546 β all confirmed |
| v2 assets: Chat Memory, Skill, LLM-Wiki, Code-Graph | Verbatim in the repository description; v2.0.0-beta.1 dated 22 Jul |
| Rival plugin from Tencent's Hunyuan team | Not located via GitHub search. Unverified |
| Description: "cuts SWE-bench tokens by 61%" | Wrong. 61% is WideSearch; SWE-bench is 33% printed / 31.6% actual. The video gets this right |
Method note. YouTube rate-limited caption access, so the transcript was produced locally with Whisper large-v3-turbo β 244 segments across the full 12:19. It mangled several proper nouns: Qwen 3 became "Quinn 3", Zep became "Zett", DeepSeek became "DeepSeq", Karpathy became "Carpathie", Hunyuan became "Hanyuan", and Tulving appeared as both "Endel-Tolving" and "Telving". All names above were corrected against vendor sources. Figures were checked against the repository README, the GitHub API, the LICENSE file and issue threads directly; the benchmark percentages were recomputed from the table's own raw token counts. Verified 2 August 2026.
π‘ Key takeaways
- Bigger context windows make agents worse, not better. Chroma's study found accuracy falling long before the window fills β a 200k window can start degrading around 50k.
- Hoarding fails on all three axes at once β slower, pricier, less accurate. When nothing trades off, the strategy is wrong rather than under-tuned.
- Compression with intact pointers is not summarisation. A summary is one-way; a folded diagram with
node_ids can be opened again. Reversibility is what makes aggression safe. - Forgetting is the compression step, not the bug. The L0βL3 pyramid is Tulving's consolidation arrow written as software, and it reads top-down so cheap answers come first.
- Fail toward the previous behaviour. Slow retrieval skips injection instead of stalling the turn β degrading to "no memory", which is where you started.
- A table with raw values and a percentage is self-checking. Divide it. One row here does not divide out: SWE-bench prints β33.09%, computes to β31.63%.
- The gains shrink as tasks get harder. +51.52% on WideSearch, +9.93% on SWE-bench, +7.95% on long-document reasoning. The headline is the best case.
- Every number is vendor-produced. No independent reproduction exists, and in this field rival labs have publicly disputed each other's configurations.
- Part of the saving leaks back through prompt caching. Changing the prompt prefix every turn breaks provider prefix caches β open issue #120, 99 comments, unresolved.
- 408 open issues including unsanitised query input is a maturity signal for a four-month-old repo, and a reason not to make it a production dependency yet.
- "Fully local" is a configuration, not a guarantee β the Docker image defaults to a Tencent endpoint. Open core with a cloud upsell, stated plainly.
- Memory is becoming a governed asset with an owner, version and permissions β and the unanswered question is portability. An asset you cannot take with you is lock-in in disguise.
π Resources & links
- China Just Open-Sourced Humanlike Memory for AI AgentsSource video β Cloud Codes, 12:20, 2 August 2026
- TencentCloud/TencentDB-Agent-Memory10,811 stars, MIT. The README documents the architecture and publishes the raw benchmark counts
- Issue #120 β prompt cache hit rate regressionWhere part of the token saving leaks back. Open, 99 comments
- Issue #160 β FTS5 operators not sanitisedThe most-discussed thread, 177 comments. Query-injection surface
- Chroma β Context RotThe study underneath the whole argument: accuracy falls as input grows
- OpenClawThe host runtime with the memory plugin slot β 384,946 stars
- Mem0The incumbent, 62,325 stars β and one side of the benchmark dispute
π Timestamp index
0:00The agent asking the same question twice
0:15221 million tokens for one benchmark run
0:28Chroma's context-rot study β 18 models
0:39Tencent's answer, April, MIT
1:05"It helped it remember less"
1:18What an agent actually is β a loop with no memory
1:413.5 billion tokens for 50 coding tasks
2:10Degradation of 30β50% on trivial tasks
2:29Who is shipping memory infrastructure
2:42Idea one β folding logs into Mermaid
3:24"Never lose the road back to the evidence"
3:37Compression thresholds and the 20% cap
3:49WideSearch β where the 61% comes from
4:49"Smaller gains as the task gets harder"
4:51Idea two β Tulving's 1972 split
5:38"Forgetting is the compression step"
5:45L0 β L1 β L2 β L3, and the refresh cadence
6:24PersonaMem β 48% to 76%
6:40SQLite, sqlite-vec, no API key
7:09Skip injection rather than stall the turn
7:24"Divide the columns yourself"
7:58Every result was produced by the vendor
8:07The Mem0 / Zep benchmark dispute
8:25Issue 120 β the prompt cache problem
8:53405 open issues, and the FTS5 thread
9:12Open core with a cloud upsell
9:34Two memory plugins inside one company
10:09The field β Mem0, Letta, MemOS
10:29Version 2 β memory as a shared asset
11:23Cold start from an existing repository
11:33"An artifact with a license plate"
12:05The unchecked box β portable memory