You spent last afternoon walking your agent through every requirement detail. Today it opens a fresh session and politely asks what the project is about. This is not a context-window problem; it is that memory has never lived inside the model. Close the session, flush the KV cache, and nothing survives. On October 20, the Shanghai-based MemTensor team released MemT 1.0 with two base models: Flash, at 288B total parameters, and Nano, at 36B. By the team's account, this is the industry's first memory-native base model: memory is no longer an external retrieval layer but a first-class citizen of the architecture, read and written directly at every token of generation. The weights are publicly downloadable — but the license is not the anything-goes kind. Below: the license, the architecture, the benchmarks, and the caveats, with every number sourced — official figures labeled as the company's own, media retellings labeled as such, and nothing unpublished invented.
One: the license first — weights are open, but not commercially
The easiest trap comes first. Many media reports describe MemT 1.0 as "open source," yet the GitHub API returns NOASSERTION for the license field, because the LICENSE text is not a standard template. We fetched the LICENSE file and verified it directly: it is PolyForm Noncommercial 1.0.0, restricted to noncommercial use. In practical terms, the weights are publicly downloadable; personal study, research, and internal technical evaluation are fine, but commercial deployment requires a separate license from the team. The repository also ships a LICENSE-PAPER file covering the research paper.
"Publicly released weights" and "commercially usable open source" are different things, and in 2026 that distinction is no longer pedantry. For contrast: Tencent's Hy Memory 2.0, released days earlier, ships under Apache-2.0, so you can wire it into a commercial product with no extra steps. MemT 1.0 carries the banner of "the largest open parametric-memory model in the industry" (the team's own claim), yet its license sits on the noncommercial line. Decide your use case before downloading: evaluation research and revenue-generating deployment follow different compliance paths.
The repository lives here: MemTensor/MemT-1.0.
Repository address: github.com/MemTensor/MemT-1.0
As of October 20 it showed 194 stars, with the most recent push also on October 20 — the ecosystem is early. The weights are hosted on Hugging Face and ModelScope:
- Hugging Face MemT-1 collection
- HF address: huggingface.co/collections/MemTensor/memt-1
- ModelScope MemT-1 collection
- ModelScope address: modelscope.cn/collections/MemTensor/MemT-10
Two: what memory-native means — memory inside the forward pass
Start with an inventory of the three traditional memory types, then see which one MemT replaces.
Activation memory is the context window plus the KV cache: the entire history sits verbatim in the window, and attention can look back at any time. Fidelity is the best of the three, but the memory vanishes when the session ends, and every extra token of history makes each inference step heavier.
Parametric memory is the model's own weights: knowledge baked in during training. Updating it requires fine-tuning — you cannot edit a single fact, nor trace where a stored belief came from.
External knowledge bases are the RAG-style approach: memory lives outside the model and gets retrieved and injected as needed. Editable and traceable, but every step depends on retrieval quality — if retrieval misses, the model does not know.
MemT 1.0 takes a fourth path. Per the team's architecture description, it encodes history into a persistent, updatable internal state that the model reads and writes directly during generation of every token — memory is no longer an input; it is part of the forward pass.
The architecture has three layers of design. First, inside every Transformer layer, attention and parametric memory run in parallel: attention handles what to look at right now, parametric memory handles what history has deposited. Second, the memory state splits in two: dynamic local memory compresses history, while hyper-memory holds the projection and gating parameters — one stores content, the other governs how it is stored and retrieved. Third, Gated DeltaNet-2 updates the memory token by token through four explicit gates — erase, write, forget, and output — so each operation is an explicit decision rather than an implicit accumulation. Scaling comes from a mixture-of-storage design with densely routed memory experts, so memory capacity can expand independently of model parameters.
The training method is refreshingly blunt: a teacher model reads the full context, the student model sees only the memory state, and KL distillation optimizes only the memory parameters. In effect, the memory state is forced to carry the entire history on its own — whatever the teacher sees, the student must reconstruct equivalent decision grounds from memory alone.
The design has a family resemblance to the RNN era: both compress history into a rolling state. The difference is that RNNs were forced to cram everything into a vector too small to hold long-range dependencies, which is why attention displaced them. MemT's bet runs the other way — turn "remembering" back into a learnable module with real capacity and explicit read-write control, and ask whether it can carry history at a fraction of the raw-text cost. That balance is the proposition memory-native models need to prove.
Three: the two models — Flash and Nano
Two configurations shipped:
| Model | Total params | Active per token | Dynamic memory |
|---|---|---|---|
| MemT-1.0-Flash | 288B | 17B | 336M |
| MemT-1.0-Nano | 36B | 3B | 10M |
Both are described by the team as the industry's largest open parametric-memory models — "largest" refers to the parametric-memory portion. The training corpus was 34 billion tokens (per a NetEase report), in two stages: first learning memory writing, then memory retrieval. The ordering is deliberate: writing governs what to keep and how to compress; retrieval governs when to fetch and how to use.
The configuration choices follow convention: Flash targets flagship workloads with a sparse 17B-active design; Nano, at 3B active, is the small option for local and edge deployment.
Four: the benchmarks — official figures, including the loss to MemOS
Memory benchmarks (official figures): across 11 memory benchmarks, Flash scored 50.6 and Nano 47.0, ranking first and second among all parametric-memory methods; the strongest parametric baseline, Temp-LoRA, scored 38.1 — Flash leads by 12.5 points and Nano by 8.9.
One losing comparison is not hidden: these scores trail the team's own MemOS text-memory system. The team's explanation is that parametric memory trades some fidelity for learnability and scalability — verbatim memory is precise but storage-hungry and retrieval-dependent, while parametric memory is lossy but available instantly at inference. Publishing both of your own systems with trade-offs exposed is a posture worth noting, but every number here is still vendor-reported; no independent reproduction exists yet.
The coding-agent comparison is more interesting (official figures). On SWE-bench Verified's 500 tasks, the memory-less baseline scored 66.07%; injecting experience before execution raised it to 69.33%, and triggering memory during execution reached 69.73%. The three-pass all-success rate rose from 54.00% to 61.6% and 62.8%. On SWE-bench Multilingual: 60.00% rose to 62.89% and 63.56%, and the pass-cubed rate went from 45.33% to 53.67% and 55.33%. Memory is not just about remembering chats — deposited experience converts directly into coding performance, and triggering mid-execution beats injecting beforehand: fetching memory at the right moment matters more than fetching more of it.
Long-history efficiency (official figures, dual GPUs, single concurrent request, fixed 128-token decode): with 128K-token history, end-to-end speedup is 1.86x; with 256K history, 3.99x. Time-to-first-token is 104 to 112 milliseconds versus 445 milliseconds for the traditional approach (per the NetEase report).
Storage savings come in two figures — do not mix them: 1/66 is relative to the KV cache for persistent storage, while 1/130 is relative to a traditional full session state. For 256K-token history, the per-session memory state is about 40 MiB versus roughly 5.06 GiB traditionally. Both numbers are correct; the baselines differ, so state the comparator whenever citing either.
A note on reading the tables: a three-to-four-point gain on SWE-bench is unremarkable by leaderboard standards, but this is a controlled comparison — same model, the only variable being whether memory experience was present. That causal chain is cleaner than a total-score ranking.
Five: what it looks like in use — two concrete cases
The team provided a long-conversation recall test (official figures). In a 65K-token English conversation: information placed 4K tokens back is recalled precisely; at 16K, when asked about something absent from the history, the model correctly says "I don't know" — refusing to fabricate, which in long contexts is harder than recalling; at 32K, it performs chained rule reasoning across distant positions; at 64K, it distinguishes "confirmed" from "merely proposed" — having once floated "shall we try option A" is not the same as having settled on it, and the model tells the two apart.
The second case is Django's parse_http_date. With experience deposited, the agent first builds a reproduction test before changing code. A behavioral shift is more persuasive than a score shift: what memory stored was not the answer to a specific bug but the working habit of writing reproduction tests first — experience moved from data to habit.
The deployment design also deserves attention: the memory state is bound to a user or task trajectory, can be serialized and restored, and persists across sessions — resume tomorrow without re-explaining context. One detail: the raw text is not retained, only the memory state itself. Good for storage, but double-edged for privacy: with no original transcript, auditability of "what was remembered" depends on the state format and tooling the team provides.
Six: two routes — bolt-on memory versus memory-native
Some coverage context. The day before, we published Tencent's Hy Memory 2.0, a bolt-on memory framework: a model, an SDK, and a memory hub in three layers, with memory stored outside the model and injected by retrieval — any existing LLM can adopt it. This article's MemT 1.0 is a memory-native model: memory lives inside the architecture, read and written in the forward pass, with no reliance on an external retrieval chain.
One-line division of labor: Hy Memory bolts a memory system onto existing models; MemT builds memory into the model body itself. Two routes, each with an open-source representative shipped on consecutive days. As a rough selection rule: keep your current models and add memory capability — bolt-on; willing to switch base models for inference efficiency and cross-session continuity — native.
One combination play is worth remembering: MemT 1.0 paired with the team's own MemOS 3.0 forms a complete chain of verbatim plus parametric memory — the pair maps onto the trade-off in the benchmark section.
Seven: positioning and limits — a preview, for the record
Per Machine Heart's coverage, MemT 1.0 is currently a "preview" release. The team's stated direction is memory-driven recursive self-improvement: effective methods deposited in one round become the foundation for the next. Next steps named by the team: stronger long-term memory, larger capacity, and lower memory-update costs.
Three limits to weigh before adopting. First, all benchmarks are vendor-reported with no independent reproduction; the team did publish the comparison where it loses to MemOS, but final judgment awaits third-party testing. Second, the PolyForm Noncommercial 1.0.0 license bars commercial use without a separate agreement — price the compliance cost into any selection. Third, the fidelity loss of parametric memory is architectural; for accuracy-critical domains such as legal or medical records, proceed cautiously or pair it with a verbatim-memory system as a backstop.
FAQ
Q1: Is MemT 1.0 open source? Can I use it commercially? A1: The weights are publicly downloadable, but the license is PolyForm Noncommercial 1.0.0, restricted to noncommercial use; commercial deployment requires separate authorization from the team. The GitHub API reports NOASSERTION — the in-repo LICENSE file is authoritative, and a separate LICENSE-PAPER covers the paper.
Q2: How does memory-native differ from bolt-on memory (Mem0, Hy Memory, and the like)? A2: Bolt-on memory stores memories outside the model and injects them via retrieval, so any existing model can adopt it; memory-native encodes history into an internal model state read and written at every token — memory is part of the forward pass. Bolt-on wins on generality and editability; native wins on inference efficiency and cross-session continuity, at the cost of some fidelity.
Q3: How much storage does it actually save — 1/66 or 1/130? A3: Both figures are correct; the baselines differ. 1/66 is persistent storage relative to the KV cache; 1/130 is relative to a traditional full session state — for 256K-token history, about 40 MiB versus roughly 5.06 GiB traditionally.
Q4: Are the benchmarks trustworthy? A4: All figures are vendor-reported with no independent reproduction yet. Notably, the team also published the comparison where it trails its own MemOS text-memory system — but final conclusions should wait for third-party testing.
Q5: Is it worth trying now, and where do I get it? A5: The repository is at github.com/MemTensor/MemT-1.0, with weights downloadable from the Hugging Face and ModelScope collection pages. It is currently a preview release (per Machine Heart), suited to research and internal evaluation; for commercial scenarios, note the noncommercial license first — separate authorization is required.
Related reading
- AI Memory Framework, Open-Sourced: Tencent's 3B Tops Opus 5: AI Memory Framework, Open-Sourced: Tencent's 3B Tops Opus 5
- AI Agent Long-Term Memory Setup SOP: Making Agents Remember You Across Sessions: AI Agent Long-Term Memory Setup SOP
- codebase-memory-mcp Code Intelligence Engine: codebase-memory-mcp: a code intelligence engine for agents