Tencent Open-Sources Hy Memory 2.0: A 30B Model That Decides What AI Agents Should Remember

Anyone doing vibe coding knows the feeling: start a new session and the agent has amnesia — you re-explain the project background, past decisions, and every pitfall all over again. Memory is the watershed between an agent that's a disposable tool and one that's a long-term partner. But how memory should work has never had a standard answer: some go all-in on vectors, some stuff everything into context, some skip memory entirely.

On October 16, Tencent Hunyuan upgraded its agent memory framework Hy Memory to 2.0 and open-sourced all three layers: Hy-Memory-30B-A3B, a model trained specifically for memory writing (Apache 2.0, now on Hugging Face), the hy-memory Python framework, and MemHub, a local-first app that unifies user-authorized conversation and coding traces from 10 AI tools — Claude Code, Cursor, Codex, OpenCode, Qwen Code and more — into a single local data directory. This isn't a demo drop; it treats "memory" as an engineering discipline: chat, working, and coding each get a differently shaped memory.

The repo was created October 15 and had 697 stars by October 18. More notably, within three days of open-sourcing, an independent third-party review appeared — a LongMemEval measurement with a stinging conclusion: "memory systems are only as good as the LLM that writes them." This article puts the official claims and that critique side by side, because the real judgment lives in the gap between them.

Memory isn't "vectors all the way down": three scenes, three memory shapes

Hy Memory 2.0's core design bet: there is no universal memory shape — the task scene determines what memory looks like. Writes first pass through a scene router, then into different pipelines:

Three task scenes, three memory shapes. Adapted from the official Hy Memory README.

The chat scene uses 8-layer cognitive memory, abstracting upward from L0 raw dialogue: L1 raw conversation (append-only), L2 atomic facts (versioned, immutable records), L3 session summaries, up to L6 mental models (abstract narrative templates, graph layer) and L7 prospective intentions — L7 even carries an expiry, demoting to ordinary facts once expired. Note L4 (identity) and L5 (knowledge) are currently reserved slots: the hierarchy is built for future extension, not a made-up "8 layers."

The working scene (documents, spreadsheets, research, content creation) is two-layer: facts + reusable experiences. One session with tool calls produces both at once — the fact layer gets exactly one record ("what this session did": task, approach, result, with verbatim sources), the experience layer gets 0–N records ("what's reusable next time a similar task comes up," passing a value threshold, with task, search keys, solution, boundary environments, confidence). The layers link to each other (facts point to derived experiences, experiences point back to source facts), and superseded facts stay traceable through a task-progress chain.

The coding scene reuses working's two-layer pipeline and schema, with three differences: the extraction spec is software-engineering-specific (the subject must be code or a decision; record exact coordinates like file/function/branch instead of pasting code); storage is fully isolated (separate database and collections); and most importantly, it adds a version-evolution diff chain — how many times the same code was changed, and why each time.

There's a sound intuition hiding in this design: chat memory needs "who this person is and what they want" (the more abstract the better), working memory needs "what was done and what was learned" (facts separated from experiences), coding memory needs "how the code became what it is" (the evolution trajectory is itself knowledge). The problem with "vectors all the way down" is that it stuffs three completely different things into one shape.

The framework also ships three modes — lite / pro / ultra: lite is raw vector read/write with zero LLM calls (the scene parameter is ignored); pro adds LLM extraction and reconciliation; ultra adds System 2 schema induction and a cross-domain sweeper (graph DB always on). The tiering is pragmatic: not all memory deserves LLM money; ingestion cost should be tiered too.

The 30B model that decides "what to remember"

The most ambitious of the three open-sourced layers is Hy-Memory-30B-A3B: a 30B-total / 3B-active MoE model trained specifically for the task of memory writing — via attributed reinforcement learning, targeting high-precision long-term memory extraction and conflict reconciliation. The technical report is arXiv:2610.22196; the model is Apache 2.0 on Hugging Face.

Its positioning is precise: a drop-in replacement for the generic models doing "memory writing" inside Mem0, MemOS, and Hy Memory itself. Tencent has carved "writing memory" out as a subtask worth training a dedicated model for. Behind that is a judgment: the hardest part of a memory pipeline isn't retrieval (vector retrieval is mature) — it's "turning a conversation into memories worth keeping": what to extract, how, and whose version wins on conflict.

The official self-reported score: 55.49% average across four frameworks versus 54.62% for Claude Opus 5. That sentence needs a vendor self-test watermark — the test sets and methodology are their own, so take the numbers lightly. What's genuinely interesting isn't 55.49 vs 54.62, but the fact that a purpose-trained memory-writing model can spar with a general frontier model at all. If memory writing can be made an independent, optimizable, swappable component, there's a lot of architectural refactoring ahead for memory systems.

MemHub: a local memory hub across 10 tools

If the model and framework answer "how memory works," MemHub answers "where memory lives" — a long-argued question among vibe coding readers. MemHub is a local-first desktop app + CLI: it unifies user-authorized conversation history and coding traces from 10 AI tools (Claude Code, Cursor, Codex, OpenCode, Qwen Code, etc.) into one locally managed data directory, enabling cross-application memory recall.

A few product details stand out: local-first means memory lands locally first, and cross-app recall doesn't transit third-party servers; there's a signed macOS desktop build (v1.0.4) plus memhub-cli on npm (1.0.5) — aiming at both click-around users and terminal natives; writes support source isolation (source="cursor" | "codex"), so retrieval can be scoped to one tool's memories. That's a clear-eyed design: cross-app recall is a capability, but users need the right to say "don't mix that app's stuff in."

For vibe coding workflows, the pain point is concrete: you might edit code in Cursor in the morning, restructure architecture in Claude Code in the afternoon, run tests in Codex at night — each tool remembers only its own slice. MemHub wants to be the local hub that "remembers everything." The premise is per-app user authorization, and whether that chain is clean determines whether this memory courier is legitimate.

An independent review pours cold water

Three days after open-sourcing, an independent review landed on dev.to. The author, teolex2020, builds Aura, a competing memory product — a conflict he discloses explicitly, which arguably makes the review more credible. He measured Hy Memory on LongMemEval, under the blunt title "Tencent's Hy Memory Is Only as Good as the LLM That Writes It."

Independent review data: the stronger the writing model, the better the score. Source: dev.to / teolex2020, 2026-10-16.

First result: with cheap Gemini Flash doing memory writing, Hy answered 43% of 60 questions correctly, versus 95% for the author's Aura (which uses no LLM at write time — local embeddings only). The breakdown stings: on "what did the assistant say" questions, Hy scored 0% — 32 of its 34 misses were "I do not have that information." He ran a control: retrieving 40 memories (~7,900 characters, comparable to what Aura could read) still scored 45% — the information wasn't lost at search time, it was lost when conversations were turned into facts, at write time.

The second result is more informative: switching the writer to Claude Opus 5.5 (expensive, ~$5 per question, only 18 questions tested) lifted knowledge-update questions from 6/10 to 9/10, matching Aura; Hy also keeps old values as history ("Current: 25:50 … History: 27:12"), which the reviewer calls the right design. But "assistant said" only rose from 0/8 to 4/8 — half of what the assistant suggested still never made it into memory.

This critique is only fair when read against the official design: Hy's chat memory stores "atomic facts" at L2, which naturally favors "what the user said" — the assistant's suggestions and reasoning tend to get filtered as "procedural content" during fact extraction. That's an architectural tradeoff, not a bug — but its cost lands squarely on vibe coding's core scenario (continuing code, continuing debugging), where Hy currently loses. The coding scene's two-layer + diff chain is built to cover exactly this, but the review tested the chat pipeline — don't conflate the two.

Judgment: memory engineering is won at "write time," not "read time"

Put the launch and the review together and one judgment surfaces: a memory system's quality is decided at write time, not read time. The write step sets the information ceiling — what gets dropped at write time can never be found at read time (40 memories still scoring 45% is the evidence). Vector retrieval, reranking, graph layers — all retrieval-side optimizations dance under a ceiling set at write time.

That also explains why Tencent trained a dedicated 30B memory-writing model: it's a bet that "writing" can be an independent, optimizable, swappable component. If the bet holds, competition shifts from "whose retrieval engine is stronger" to "whose writer is more accurate" — the track gets rebuilt. And the independent review accidentally confirms the same conclusion from the other side: a stronger writer immediately lifts scores. Both sides agree "writing is the key" — the vendor uses it to validate, the reviewer to poke holes.

For vibe coding readers, three actionable points: first, when choosing a memory solution, check how its write pipeline handles assistant output — many solutions default to remembering only what the user said, which is fatal for pair-programming scenarios; second, the version-evolution diff chain idea is worth remembering on its own — "how many times this code changed and why" is trajectory information no vector retrieval can dig up; third, local-first plus cross-tool unification is the right direction, but check the authorization chain before adopting — the fuller the memory, the larger the leak surface.

A few boundary notes to avoid confusion: this article covers Tencent Hunyuan's Hy Memory 2.0 — not Tencent Cloud's TencentDB Agent Memory v2.0 (announced 2026-08-03), a different team's older project; the official 55.49%-vs-54.62% figures are vendor self-test numbers with vendor-defined test sets and methodology — keep that qualifier when citing; the independent review's sample is small (only 18 questions with the Opus writer) and its author is a competitor — trust the direction, discount the exact numbers.

Hy Memory 2.0 is a fairly complete answer to memory as engineering: scene-shaped memories, a purpose-trained writer model, a local-first cross-tool hub. But the independent review reminds everyone: no matter how pretty the answer sheet, the grader is "the model that writes the memory." The next war in memory systems won't be fought in vector databases — it'll be fought in the write pipeline.