Hy Memory 2.0 Is Out: Tencent Open-Sourced a Memory Writer, a Framework and a Mac App in One Drop

T​encent H​unyuan shipped three things at once this week, and only two of them are installable today. Hy-Memory-30B-A3B is a 30-billion-parameter mixture-of-experts model whose entire job is writing memory — deciding what an agent keeps, how it phrases it, and how new evidence overwrites old. Hy Memory 2.0 is the framework around it: a Python package, hy-memory, covering chat, working and coding memory. And MemHub is the app — a local-first CLI and macOS product that pulls conversation history and coding traces out of ten different AI tools into one memory store on your own disk. The headline on the announcement post is that Hy-Memory-30B-A3B beats Claude Opus 5 across major memory frameworks. That is true as far as it goes, and the interesting part is how far it goes: on three of the four frameworks the margin is under six tenths of a point, and the whole comparison runs on a fifth of each benchmark. Every provider outage and rollback we have tracked is logged in the Orca AI Incident Archive, which carries the full record set alongside this incident's neighbouring entries.

Everything below is read either out of T​encent's own repository, package registry and technical report, or labelled as T​encent's own claim. Nothing here has been reproduced by anyone else, because as of writing nobody else has run it.

What actually shipped, and when

The three layers landed within about 24 hours of each other, and the release notes are unusually specific about which of them are finished:

• The model — tencent/Hy-Memory-30B-A3B was published to Hugging Face on 15 October 2026 (09:52 UTC), under Apache 2.0, with the technical report, arXiv 2610.22196, submitted the same day.

• The framework — hy-memory==2.0.1 was uploaded to PyPI on 15 October 2026 at 17:24 UTC, and the monorepo was open-sourced the same day. The GitHub v1.0.0 release tag was cut on 16 October at 08:44 UTC.

• The app — MemHub's release assets exist: a notarised macOS arm64 disk image at 303 MB in GitHub's counting, plus Linux arm64 and x64 runtime bundles at 245 MB and 251 MB. Windows is listed as unsupported.

• The gap — the project's own changelog states that MemHub "has no public release yet," that its source version is 1.0.0 (build 4), and that both npm publication and GitHub Release artifacts are still pending. The npm package it intends to use, memhub-cli, returns a 404 from the registry. The disk images are attached to the release; the command-line installer that is supposed to fetch them is not published.

That last point is worth reading twice, because it is the difference between a launch and a release candidate. The Apple build is signed and notarised, which is real work, and the release page has accrued a small handful of downloads. But the documented install path starts with an npm package that does not exist at the time of writing. If you were planning to try MemHub this week, budget for a source checkout rather than a one-line install.

Hy-Memory-30B-A3B, the model

The configuration file is the least romantic and most useful document in the whole release. It describes a standard, well-understood MoE shape rather than anything exotic:

• Parameters — 30B total, roughly 3B active per token, which is what the A3B suffix means.

• Architecture — 48 layers, of which one is dense and 47 are sparse MoE; 128 experts per block with top-8 routing plus one shared expert; hidden size 2,048; expert intermediate width 768; 32 attention heads against 4 key-value heads with query-key normalisation; a sigmoid router with an expert bias term and a scaling factor of 2.826.

• Context — 262,144 positions, with a RoPE base of 11,158,840.

• Footprint — 51 safetensors shards, about 60.1 GB in BF16. That is the only precision T​encent shipped.

• Serving — the card is written around vLLM, tested against v0.31.0, behind an O​penAI-compatible endpoint, and it also names SGLang and Docker Model Runner as supported runtimes. It is not deployed by any inference provider, and the Hugging Face search index turns up no GGUF, no FP8 or NVFP4 build, and no fine-tune.

That absence is the practical obstacle. A vendor shipping a 60 GB BF16 checkpoint and nothing else is telling you where it expects the model to run, and the answer is a machine you already own or rent in a datacentre. There is no quantised sibling anyone can evaluate on a workstation.

The model is driven with reasoning_effort: "no_think" and temperature 0.0 in T​encent's own quickstart. A memory writer fires on every conversation turn to decide what to keep, so deliberating is the wrong trade: it needs to be deterministic, short-output and cheap. That design choice is also the strongest argument for the model existing at all, since it is exactly the workload where a frontier chat model is most wasteful.

The 55.49, read the way it should be read

T​encent trained the writer across three memory frameworks — Mem0, MemOS and its own Hy-Memory — and then evaluated it on a fourth, EverMemOS, that was held out of training entirely. Holding one harness back is the right way to test a transfer claim, and cross-framework transfer is the entire thesis of the paper.

The results, which are T​encent's own and unreproduced:

• Hy-Memory-30B-A3B — 55.49 macro average across the four harnesses.

• Claude Opus 5 — 54.62.

• DeepSeek V4.1 Flash — 53.64.

• T​encent Hy3 — 51.63.

• Qwen3.6-35B-A3B — 50.37.

• Hy3-A3B Base — 47.66, the same model before memory-specific training, which is where the headline 7.8-point training gain comes from.

• Qwen3-30B-A3B — 44.37.

Broken out by harness, the win gets thinner. Against Claude Opus 5 the margins are 54.02 to 53.43 on Mem0, 60.55 to 60.53 on Hy-Memory, 50.51 to 50.50 on MemOS, and 56.89 to 54.04 on EverMemOS. Three of those four are statistical noise wearing a laurel — a two-hundredths-of-a-point lead on the Hy-Memory harness is not a lead. The entire separation between a 3B-active specialist and a frontier model sits in the one harness that was held out of training, where the gap is 2.85 points and where the claim is also least likely to have been tuned against.

Two design details matter as much as the numbers. Every figure in the main matrix runs on a fixed 20% subsample rather than the full benchmark, and the evaluation varies only the writer, holding the harness, prompts, retrieval configuration, answer model and judge fixed. That second choice is good experimental hygiene — it isolates the variable under test — but it is T​encent's harness and T​encent's judge. Treat the table as a hypothesis with a repository attached, which is more than most release-day claims come with and less than a result.

The framework numbers are the bigger claim

The model comparison is the quote T​encent put in the post. The framework comparison is the one that would change a reader's architecture if it holds.

On the company's own site, Hy Memory 2.0 is ranked first among open-source memory frameworks on four benchmarks — ahead of Mem0, MemOS, EverOS, OpenViking, RepoMemory and a plain sliding-window RAG baseline — across the three scenes it covers:

• Chat — 72.6% on LoCoMo, across 1,527 non-adversarial questions.

• Working — 55.31% average on MemoryArena (a travel-planning and bundled-shopping suite), 10.2 points clear of the next framework.

• Coding — 64.2% on CodeMemoryBench question answering and 35.6% solve rate, plus 28.3% solve rate on SWE-ContextBench.

• Footprint — memory storage of 6.06% of input tokens, against 31.9% to 41.2% for the frameworks it is compared against.

The footprint figure is the one worth stealing. Memory systems fail in production for two reasons: they forget the wrong things, and they grow without bound. A bank that costs six per cent of the conversation it summarises is a different operational proposition from one that costs forty, and that is the dimension where a routing-and-cost audience should care regardless of whether the accuracy ordering survives scrutiny. The evaluation protocol is published alongside: memory model DeepSeek V4.1 Flash, answer and judge model GPT-5.6-sol, storage measured as bank tokens over input tokens with the bank counting generated memory only.

T​encent also lists internal deployments — a stock-assistant recall test with a 40-point multi-hop improvement, a knowledge-base plugin, and a news-app preference evaluation averaging 91.68 out of 100 — across finance, news, knowledge management, office agents, social and gaming. Those are the company's own product metrics, not benchmarks, and they should be read as evidence that the thing runs somewhere real rather than as evidence that it beats anything.

MemHub is the piece most readers could actually use

The model needs GPUs. The framework needs an engineering team. MemHub needs a laptop.

It is a local-first desktop and command-line product that consolidates history from AI tools you have already authorised into a single managed runtime and a single data directory — so a preference you set in one coding agent is available to the next. T​encent names ten supported integrations: WorkBuddy, Cursor, Codex, C​laude Code, OpenCode, OpenClaw, Q​wen Code, Pi, Hermes and D​eepSeek Harness. The stated data path is ~/.one-memory, with SQLite for working and coding metadata and ChromaDB plus Kuzu as the default stores, and the security documentation is explicit that the product does not collect screen contents, accessibility trees, OCR, clipboard or background audio.

The claims to be sceptical about are the ones about deletion. The CLI distinguishes three levels: uninstalling the npm package removes only the CLI, memhub uninstall removes the services, managed runtime and CLI links but keeps your memory, and only a separate memhub delete-data command deletes the store — after stopping the runtime and confirming the exact path. That is a better design than most tools in this category, and it is also a description of intended behaviour in a release whose installer is not yet published. Anyone adopting it for work that matters should verify the deletion path themselves before trusting it with anything they would not want retained.

What is still unconfirmed, stated plainly

• No independent benchmark of any kind. No third-party harness run, no arena placement, and nothing reproduced outside T​encent.

• No reproduction of the cross-harness table, and in particular of the held-out EverMemOS result, which carries the whole transfer thesis on a single vendor run.

• No quantisation, so no measured memory footprint below 60 GB and no workstation-scale evaluation path.

• No hosted endpoint, and no inference provider named on the model card.

• No published npm package for MemHub, so the documented install path does not yet work end to end.

• No cost-per-conversation figure. Memory writing is a high-frequency, short-output workload; nobody has published tokens-per-write or what a memory-enabled assistant actually costs to run per user per month.

Where a router fits, and where it does not

Be precise about this, because it would be easy to overstate. Hy-Memory-30B-A3B is not in OrcaRouter's catalogue and we do not host it. The route to the writer is the checkpoint on Hugging Face and your own hardware. Nothing about a routing layer changes that.

What a router covers is the other half of the harness. A memory system is a write path and a read path, and T​encent's published evaluation says out loud what the read path usually is: the writer decides what to store, and a separate frontier model reads the bank back and answers. In T​encent's own configuration those are DeepSeek V4.1 Flash on the memory model and GPT-5.6-sol as answer and judge. OrcaRouter serves both on one key at list price with no markup, so a vendor price change is live on our side the same day rather than at the next contract renewal.

The routing DSL is the piece that fits this architecture specifically. It composes a self-hosted endpoint and a hosted one into a single call, which is exactly the shape of a memory system — a cheap specialist on the write path you run yourself, a frontier model on the read path you rent. The same setup makes the risky part survivable: point the writer at your own Hy-Memory-30B-A3B deployment, keep a general model behind automatic failover, and a bad write path degrades the answer instead of taking down the application. That pattern is worth building before you have the writer running, because it is identical whether the write path is a specialist checkpoint or a general model with a memory prompt.

Who should act, and who should wait

If you run agents with long-lived memory and you already have GPUs, the write path is the honest place to spend a week: the checkpoint is Apache 2.0, and a memory writer is the rare model whose value you can measure on your own traffic rather than on someone's benchmark table. If you are a user rather than an operator, MemHub is the interesting one, and it is also the one to wait on until the installer exists and someone outside T​encent has exercised the deletion path. And if you are choosing a model on the strength of the announcement, the correct posture is the one the release itself invites: 55.49 against 54.62 is a tie on three harnesses and a real gap on the fourth, and the fourth is the one nobody has checked.