Hy-Memory-30B-A3B Quiet Release: Tencent Put a Memory Writer on Hugging Face With No Launch Post

Hy-Memory-30B-A3B is a 30-billion-parameter mixture-of-experts model from the Hunyuan team that does not answer questions. It writes memory. It decides what a long-running agent should keep, how precisely to phrase it, and how a new fact should overwrite an old one inside a persistent memory bank — the step that every agent framework has, up to now, handed to a general-purpose chat model. The weights went up on Hugging Face on October 15, 2026, the technical report followed the same day under arXiv 2610.22196, the GitHub repository opened that afternoon, and the tag v1.0.0 was cut on October 16. At the time of writing the repository records zero downloads and a single-digit like count on the model card. There is no vendor launch page, no pricing, no hosted endpoint, and no announcement we have been able to find outside the project's own README. Benchmarks age and prices move; the failure record does not: the documented AI incidents and agent failures behind models in this class are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

That is the honest shape of this release: a paper, a repo, a checkpoint, and an evaluation table that claims to beat Claude Opus 5. Everything below is either read directly out of the repository or labelled as the vendor's own unverified claim. Nothing here has been reproduced by a third party, because nothing here has been run by a third party.

What is actually in the repository, and what is not

The checkable facts, one line each:

• Model — tencent/Hy-Memory-30B-A3B, published under Apache 2.0, tagged English and Chinese.

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

• Architecture — 48 layers, of which 1 is a dense feed-forward block and 47 are sparse MoE blocks; 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.

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

• Footprint — 51 safetensors shards totalling about 60.1 GB in BF16.

• Served with — vLLM, tested against v0.31.0, behind an OpenAI-compatible endpoint. The card names no other runtime and no inference provider.

• Not present — there is no GGUF, no FP8 or NVFP4 build, no fine-tune, no quantisation, and no derivative of any kind in the Hugging Face search index. The team shipped one BF16 checkpoint at one precision.

That last line matters more than it reads. The Granite team shipped FP8, MXFP4, NVFP4 and GGUF builds of Granite 4.2 30B within days of the base weights. Liquid AI ships a Q4_K_M GGUF of LFM2.5-24B-A2B at 14.5 GB. Those vendors are telling you where they expect the model to run. A 60 GB BF16 checkpoint with no quantisation path tells you this one is aimed at whoever already has the GPUs — most likely the people running memory infrastructure at scale, which is exactly the audience the model card names.

What the model is actually for

The distinction between a memory writer and an agent is the whole point of this release, and it is easy to miss because the model card reads like every other model card.

An agent framework — Mem0, MemOS, Hy-Memory, EverMemOS — sits between a conversation and a persistent store. On every turn something has to read the incoming exchange, decide which fragments are worth keeping, phrase them so they can be found later, and reconcile them against what is already stored. Today that something is a frontier chat model with a framework-specific prompt bolted on. The paper's framing of the problem is the cost and the transfer: a general model behind a memory prompt is expensive to run on every turn, and a writer tuned for one framework's protocol does not move cleanly to another's.

Hy-Memory-30B-A3B is trained to be that writer across three frameworks at once — Mem0, MemOS and the project's own Hy-Memory, across chat, working and coding scenes — and it is then tested on a fourth, EverMemOS, that was held out of training entirely. The held-out harness is the most interesting design decision in the paper. Cross-framework transfer is the claim the entire model rests on, and holding one framework back is how you would test it if you were being serious about it.

The model is driven with reasoning_effort: "no_think" and temperature 0.0 in the project's own quickstart, which is a telling default. A writer does not need to deliberate; it needs to be deterministic and cheap, because it fires on every single turn.

The two-stage training, in plain terms

The card describes the recipe as Memory On-Policy Distillation followed by Attributed Memory Reinforcement Learning, and the second stage is where the paper's contribution sits.

In the first stage a teacher supplies dense supervision on memory states the student itself produced — on-policy, so the student is being corrected on its own mistakes rather than on a teacher's trajectories. In the second stage the framework builds memory banks from rollouts, scores them chunk by chunk, and carries the selected bank forward across windows instead of resetting between them. That carry-forward is the part that keeps training aligned with how the model is actually deployed, where a bank is never empty and every write lands on top of everything written before it. Credit is attributed at chunk level, with an explicit penalty for over-storage — a writer that keeps everything is useless, so the reward has to price that in.

None of that is independently verified. It is a coherent description of a training method, published with a repository that contains the code, which is more than most release-day claims come with.

The evaluation, read the way it should be read

Here is the headline, and here is everything wrong with taking it at face value.

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

• Claude Opus 5 — 54.62.

• DeepSeek V4.1 Flash — 53.64.

• Hy3 — 51.63.

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

• Qwen3-30B-A3B — 44.37.

A 3B-active specialist beating a frontier model by 0.87 of a point on a memory task is a plausible result — the task is narrow and the specialist was trained for it, which is the same argument that makes small code-completion models competitive on single-file edits. But the caveats are load-bearing. Every benchmark in the main matrix runs on a fixed 20% subsample rather than the full set. The evaluation changes only the writer, holding the harness, prompts, retrieval configuration, answer model and judge fixed, which is the right experimental design, but the design and the harness are the project's own. The per-harness spread is also wider than the macro average suggests: the model leads on Mem0 at 54.02 and Hy-Memory at 60.55, and its MemOS result of 50.51 is 0.01 of a point above Claude Opus 5's 50.50 — a dead heat dressed as a win. Its strongest number, 56.89 on the held-out EverMemOS harness, is the one that would matter most if it reproduced, and the one nobody has tried to reproduce.

Treat all of it as vendor-reported. Not as suspicious — as unreproduced, which is a different thing. A model released yesterday with a repo and a paper has earned the right to be tested, not the right to be believed.

That page is the only primary source for the whole release. There is no blog post, no vendor announcement, and no third-party write-up to cross-check it against.

What is still unconfirmed, stated plainly

• No independent benchmark of any kind exists. Nothing on Artificial Analysis, no arena placement, no third-party harness run.

• No reproduction of the cross-harness table. The held-out EverMemOS result in particular is a single vendor run.

• No real-world cost figure. Memory writes are a high-frequency, short-output workload, but nobody has published tokens-per-write or a cost-per-conversation on this model.

• No quantisation, so no measured memory footprint below 60 GB.

• No evidence about what it does when the memory framework changes its protocol — the paper tests transfer across frameworks, not across versions of one framework.

• Whether the team intends to host it. The card states the model is not deployed by any inference provider, and nothing in the repo suggests a hosted endpoint is coming.

If you want to run it, and where a router fits

Realistically this is a self-hosting decision. The path in the card is vLLM 0.31.0 behind an OpenAI-compatible API, which means the model drops into an existing harness as a base URL swap. That is the cheap part. The expensive part is that a 60 GB BF16 checkpoint with no quantised sibling needs serious hardware before it writes a single memory.

It is worth being precise about what a router does and does not do here. Hy-Memory-30B-A3B is not in OrcaRouter's catalogue and we do not host it — the route to it is the checkpoint and your own GPUs. What a router covers is the other half of the harness. A memory writer is invoked alongside an answer model, and the answer model is usually a hosted frontier model that reads the bank back and responds. OrcaRouter gives you one API key across 200+ hosted models at 0% markup, so provider price cuts pass through the same day, with automatic failover if a backend degrades. 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, a frontier model on the read path, one key in front of both.

The pattern is worth building even before you have the writer running, because it is identical whether the write path is Hy-Memory-30B-A3B or a general model with a memory prompt. The router does not care which, and swapping one for the other later should be a routing-table edit rather than a rewrite.

What to watch

Three things would move this from a paper to a product. A quantised build: an FP8 or a Q4 checkpoint is the difference between a datacentre model and one somebody can evaluate on a workstation, and its absence is the single biggest obstacle to anyone checking the numbers. An independent harness run: the held-out EverMemOS transfer claim is the whole thesis, and it deserves a test by someone with no stake in it. And a hosted endpoint: not because self-hosting is wrong, but because the model's own design — deterministic, no-think, short outputs, fired on every turn — is a natural fit for an API, and its absence suggests the team sees this as infrastructure it ships to people who already run infrastructure.

Until then the correct posture is the one the release itself invites. Read the repo, run the quickstart on whatever hardware you have, and treat the table as a hypothesis.