Your agent sat through a half-hour briefing on your project's stack and naming conventions last week. Today it opens a fresh session and asks you to explain it all again. The model didn't get dumber; nobody is managing its memory. The context window closes, and everything inside evaporates. On October 16, 2026, Tencent Hunyuan took this chronic problem apart into three layers and open-sourced all of them at once: a 30B model built for writing and updating memories, a memory framework SDK, and MemHub, a local-first memory hub for the desktop. By the company's own paper, the framework layer ranks first among open-source systems on four benchmarks, and the accompanying model edged past the closed-source Opus 5 on a self-built composite — by 0.87 points. That last clause stays attached to every claim below.
Before anything else, weigh what "all three layers open-sourced" actually means. The standard move this year has been releasing weights while the surrounding ecosystem stays proprietary. Opening the model, the framework SDK, and the application layer simultaneously is far rarer, because each layer is a separate engineering effort with its own competitors. You can use just the model, just the framework, or just the desktop app that pools memories from your other tools — and for anyone studying how memory systems should be designed, all three layers in one repository saves a round of guesswork.
One: the timeline and the license
The version line first. Version 1.0 shipped in May 2026, closed-source, with the paper published under the name DCPM on arXiv (2606.09483). Version 2.0 arrived on October 16 with all three layers released. The GitHub repository was created on October 15; as of October 20 it showed 960 stars and 79 forks, written mostly in Python.
The license holds no surprises. We fetched the LICENSE file directly on October 20: it is Apache-2.0, and Tencent's copyright preamble imposes no additional restrictions. One quirk: the GitHub API classifies the license as Other/NOASSERTION because the text is not a standard template; the in-repo LICENSE is authoritative.
The repository lives here: Tencent-Hunyuan/Hy-Memory.
Repository address: github.com/Tencent-Hunyuan/Hy-Memory
Model weights are on Hugging Face: tencent/Hy-Memory-30B-A3B.
Weights address: huggingface.co/tencent/Hy-Memory-30B-A3B
The technical report is arXiv 2610.22196, and the product site is memory.hunyuan.tencent.com.
Two: three layers — model, SDK, application
Here is where the boundaries sit.
The model layer: Hy-Memory-30B-A3B. A sparse MoE with 30B total parameters and roughly 3B active per token. One naming note: official documents have mixed two spellings, "Hy-Memory-30A3B" and "Hy-Memory-30B-A3B"; we follow the Hugging Face repository name throughout. This is not a chat model with a good memory. Per a reading from the Zhinangtuan WeChat account (secondhand), it is a workstation model inside a memory framework, responsible for writing and updating memories — the kind of component you could swap into Mem0 or MemOS in place of their general-purpose LLMs. Training ran in two stages: online-policy distillation on memory operations, followed by attribution reinforcement learning that assigns credit to individual memory blocks. The model saw only three systems during training — Mem0, MemOS, and Hy-Memory; a fourth, EverMemOS, validated transfer.
The cost logic explains the positioning. Memory write and update are high-frequency operations: every turn can trigger extraction, merging, and conflict resolution. Running a 70B-class general model for this is expensive and slow. With 3B active, inference costs sit at the 3B level. A workstation model does not need to write poetry; it needs to handle memory chores fast and reliably.
The framework layer: Hy Memory SDK. Install with pip install hy-memory; the current PyPI version is 2.0.3, and the code lives in the same GitHub monorepo. Memory is organized into eight levels, L0 through L7. Two details stand out: L2, the FACT level, is versioned and immutable, while L7, the INTENTION level, carries an expiration time — intentions go stale, and the data structure admits it. Three runtime modes are available: lite, pro, and ultra, with ultra keeping System 2 schema induction always on. Storage: ChromaDB by default for vectors, with Qdrant and FAISS as alternatives; Kuzu by default for the graph store, swappable for Neo4j; SQLite for metadata.
The application layer: MemHub. A local memory hub, version 1.0.3, offering a CLI plus a macOS desktop app. After you grant access, it imports your historical sessions scattered across AI tools, distills them into a local memory store, and syncs new sessions in real time through a plugin mechanism. The README marks it as preview.
The three layers can be used independently or combined: SDK without MemHub works, and swapping the memory model into an existing framework works too. The layering also promises decoupled upgrades, though whether that holds in practice is something the community will verify.
Three: three kinds of memory — chat, working, code
The claim worth remembering from the official materials: this is, by the vendor's own account, the first memory framework to propose working memory and code memory as first-class categories.
Chat memory exists in many frameworks, but Hunyuan upgrades it into event threads: time, place, people, plus what happened afterward. Before writing, the system merges duplicates and strips out conflicts, then hands a clean thread to the model — rather than dumping raw transcripts into a vector store. If the user said they were on plan A in March and switched to plan B in October, the stale conclusion should not fight the new fact at retrieval time.
Working memory tracks task state: what the goal is, which decisions are settled, stage results, and reusable experience. Every piece of reusable experience carries applicability conditions, checked before reuse — "it worked last time" is not the same as "it will work this time."
Code memory is stored as version-evolution diff chains. The README says it stores real diffs with zero LLM calls, and includes a personality-filled self-description: "decorator, not a retriever" — it sits beside your development flow, keeping books passively. Zero LLM calls also means the diff itself is an exact record, with no risk of a model misremembering during summarization.
Four: reading the benchmarks, vendor-reported on both levels
Benchmarks come in two tiers, all self-reported by the vendor with no independent replication yet. Treat them as an official test report, not a third-party audit.
Model layer: on a fixed 20 percent subsample of benchmarks, the official paper averages six metrics with equal weights across four memory systems:
| System | Composite score |
|---|---|
| Hy-Memory-30B-A3B | 55.49 |
| Opus 5 (closed-source) | 54.62 |
| DeepSeek V4.1 Flash | 53.64 |
| Qwen3-30B-A3B (open, same size) | 44.37 |
An open model with 3B active parameters outscoring a closed flagship is where the headline comes from. But the caution from Zhinangtuan (secondhand) is worth heeding: a 0.87-point margin is small. The real gap is cost — the same work at a fraction of the inference bill, thanks to 3B activation. The same-size comparison is starker: against Qwen3-30B-A3B, also 30B total and 3B active, the lead exceeds 11 points, with no closed-source suspicion attached. Note also: equal weighting across six metrics means no single benchmark decides anything; the lead indicates no obvious weak spot, not a sweep.
Framework layer, first among open-source systems on all four benchmarks:
- Working memory, MemoryArena (travel planning and composite shopping, equal-weighted average): 55.31 percent, 10.2 points ahead of runner-up EverOS at 45.1 percent; Mem0 scored 38.78, MemOS 37.30, Simple RAG 41.22.
- Code memory, CodeMemoryBench: 64.2 percent QA accuracy and 35.6 percent task resolution, both first; on SWE-ContextBench (Lite Related), 28.3 percent resolution against 25.3 percent each for MemOS and Mem0 and 22.2 percent for Simple RAG.
- Chat memory, LoCoMo: 72.6 percent accuracy versus EverOS at 71.9 percent — only 0.7 points apart. But this benchmark carries a more concrete number: recalled tokens per question fell from 1,159 to 703, a 39.3 percent reduction. Per the Zhinangtuan reading (secondhand), the real victory here is the nearly 40 percent token saving — hard money in cost, latency, and attention.
For storage footprint, the official materials present a quadrant chart labeled "high effectiveness, low footprint" across all three memory types; exact figures were not published, so none are invented.
Five: MemHub — one memory out of many scattered sessions
MemHub deserves its own section because it is the layer closest to daily use. The logic: in one day you write code in one tool, revise requirements in another, and research in a third. Sessions scatter; none of the memories talk to each other. MemHub, once authorized, imports those historical sessions, distills them into one local memory store, and syncs new sessions back in real time through plugin integration.
How many tools does it support? Two counts disagree, and we present both. The official Tencent Hunyuan WeChat account says 10 AI tools, naming WorkBuddy, Cursor, Codex, Pi, Qwen Code, Hermes, DeepSeek Harness, OpenCode, and others. The README explicitly names 5: Claude Code, Cursor, Codex, OpenCode, and Qwen Code. The README ships with the code and reads as the conservative count; the WeChat figure likely includes adaptations still in testing. Check the plugin list on your own machine before committing.
Internal business validation (official figures) offers three sets of numbers. After integrating, Tencent's stock-supertag service saw multi-hop recall rise from 50 to 90 percent, overall pass rate from 64 to 81 percent, composite score from 64.3 to 79.6, and conflict resolution from 67 to 83 percent. In the iWiki scenario, answering with recalled memories alone scored 36.7 percent correct, versus 24.7 percent with the full raw conversations — a 48.6 percent relative gain from far less input. Tencent News's long-term preference evaluation averaged 91.68 points, with 87.8 percent of cases above 90.
Six: five limitations before you commit
The following come from third-party readings and are labeled secondhand:
First, every benchmark is self-built. The model-layer composite and the four framework benchmarks all originate from the official paper; credibility awaits independent community replication, which has not happened.
Second, Windows users cannot run MemHub. The v1.0.3 README states plainly that it supports the CLI plus macOS only; on Windows you are limited to the framework SDK.
Third, home-field advantage. The model trained on only three systems — Mem0, MemOS, and Hy-Memory — so it is naturally more familiar with the very systems it was benchmarked against. The EverMemOS transfer result is partial counterevidence, not full reassurance.
Fourth, multilingual coverage is unverified. Official data centers on English and Chinese scenarios; other languages have no published numbers.
Fifth, MemHub is in preview, the desktop app is macOS-only, and interfaces can change without notice.
The combination of the first and third deserves the most weight: self-built benchmarks plus home-field advantage means the evidence behind "first among open-source" currently comes entirely from the party setting the exam. That does not make the numbers wrong, but until the community reruns this suite against current versions of Mem0 and Letta, "official test report" is the more accurate label.
Seven: the ready-made route and the build-it-yourself route do not conflict
A note on division of labor. This site published a long-term memory SOP in August 2026 covering how to assemble your own system from components like mem0 and Letta — the right path for teams that want full control over data flow and behavior. This article covers Tencent's ready-made three-layer option, for teams that want to run first and decide later. The two do not conflict: two weeks of real sessions on the ready-made stack costs far less than writing integration code on day one. Adjacent territory: our context-compression SOP addresses windows that cannot fit everything — compression governs density within a session, memory governs survival across sessions.
FAQ
Q1: Is this genuinely open-source? Any license restrictions? A1: Yes. All three layers are open: model weights on Hugging Face, SDK and MemHub on GitHub. The LICENSE file confirms Apache-2.0, with no additional restrictions in Tencent's copyright preamble. The GitHub API tags it Other due to non-standard license text; the in-repo LICENSE is authoritative.
Q2: Do I have to use the 30B model? A2: No. The three layers work independently, and the SDK runs on its own (pip install hy-memory, currently 2.0.3). Per the Zhinangtuan reading (secondhand), the model layer is a memory workstation model that can replace the general-purpose LLM inside frameworks like Mem0 or MemOS.
Q3: Can Windows users run MemHub? A3: Not currently. The v1.0.3 README limits support to the CLI and the macOS desktop app, and the project is in preview. Windows users can build on the framework SDK instead.
Q4: Are the benchmarks trustworthy? A4: All are vendor-built, vendor-reported, with no independent replication yet. Two reference points: the 0.87-point lead over Opus 5 is thin, but the 39.3 percent reduction in recalled tokens on LoCoMo is a hard cost-side gain.
Q5: How does this compare with building my own memory system? A5: For out-of-the-box validation, take the three-layer stack as-is; for full control over data flow and behavior, follow this site's August 2026 self-build SOP. A common path: prove the value with the ready-made stack, then decide whether to build your own.
Related reading
- AI Agent Long-Term Memory Setup SOP: Making Agents Remember You Across Sessions: AI Agent Long-Term Memory Setup SOP
- AI Agent Memory Tools Compared: Mem0, Zep, Letta, and How to Pick: Six AI agent memory tools, compared
- codebase-memory-mcp Code Intelligence Engine: codebase-memory-mcp: a code intelligence engine for agents