MemT-1.0 released: a memory-native model

MemT-1.0 is a family of memory-native foundation models from MemTensor. Instead of pulling history back in through an external retrieval module, it adds a native memory block beside the backbone’s attention. Earlier context lives in the model’s own state, and the original text is not re-read at inference. MemTensor released the family on October 20; the technical report had been on arXiv since October 19 (2610.26825). At 128K tokens of history, the report says the smaller model’s persistent state per trajectory is about 1/66 of a full-context KV cache.

Key points

Storage and speed: At 128K tokens, MemT-1.0-Nano’s persistent state per trajectory is about 1/66 of a full-context KV cache, and its end-to-end inference is about 1.86 times faster. These are the paper’s figures, and the storage count excludes shared weights.
Benchmarks: Across 11 memory benchmarks, the two MemT models rank first and second among the paper’s parametric-memory methods. The paper’s own table still puts the textual system MemOS at 68.55, ahead of the larger MemT model’s 50.60.
Licenses: The GitHub repository is under PolyForm Noncommercial 1.0.0, the paper under CC BY-NC-SA 4.0, and the Nano weights card says Apache-2.0. The second model’s card is tagged MIT. No official source explains the difference.

Background

Long-term memory for a language model usually comes in two forms. Textual memory systems store history as text or vectors and retrieve pieces when needed; MemOS and Mem0 belong to this group. The other option keeps the whole history in the context window, so cost grows with length. MemT-1.0 takes a third path: history is written into a fixed-size memory state that the model reads at inference.

MemTensor’s earlier project, MemOS, is a textual system; its repository, MemTensor/MemOS, was posted to Hacker News in August 2025. Two of our recent entries cover other approaches. Tencent’s Hy Memory 2.0 is a three-tier memory system with its own 30B-A3B memory model. ai-memory 3.1.1 shares one git-tracked markdown memory between Claude Code and Codex. Both keep memory outside the model. MemT-1.0 does not.

The facts

The specs come from the model table in the GitHub README.

Model	Backbone	Total parameters	Active parameters	Trainable memory parameters	Dynamic memory state
MemT-1.0-Nano	Qwen3.6-35B-A3B	36B	3B	451M	10M
MemT-1.0 Flash	DeepSeek-V4-Flash	288B	17B	3.61B	336M

Table 2 of the paper gives average scores across 11 memory benchmarks. Six of its rows are below, with each backbone in parentheses.

System	Paper group	Average
MemOS (DeepSeek-V4-Flash)	Textual memory	68.55
Mem0 (DeepSeek-V4-Flash)	Textual memory	65.53
Full context (DeepSeek-V4-Flash)	Textual memory	64.98
DenseRAG (DeepSeek-V4-Flash)	Textual memory	57.28
MemT-1.0 Flash (DeepSeek-V4-Flash)	Parametric memory	50.60
MemT-1.0-Nano (Qwen3.6-35B-A3B)	Parametric memory	46.97

The gap is widest on the two long-history tests. On LongMemEval-S, the Flash model scores 37.20 and MemOS 83.20. On BEAM-1M the figures are 37.04 and 72.59. The paper concedes that the strongest textual systems remain well ahead on both.

The speed and storage figures come from the same paper:

Metric	Value	Basis
Nano end-to-end inference speedup	About 1.20x at 64K, 1.86x at 128K, 3.99x at 256K	Versus full context
Persistent state per trajectory	About 1/33 at 64K, 1/66 at 128K	Versus full context; excludes shared backbone weights, embedders and hyper-memory parameters
Storage at 256K (Figure 3 labels)	Full context 5.061 GiB; Nano 40.00 MiB	The roughly 130x ratio is our arithmetic, not stated in the paper
Nano query time to first token	104–112 ms; full context is 445 ms at 256K	Paper text

The 1/66 ratio measures persistent state, not total inference memory: the current step’s KV cache and the model weights are outside the count. On training, the paper reports 34B tokens. Over two post-training epochs, sampled checkpoints rose from an average of 36.65 to 46.80, and moving from 2 to 4 memory experts added 2.69 points at the 5,500-step checkpoint. On SWE-bench Verified, Nano’s average success rate rose from 66.07% without experience to 69.33% when experience was injected before execution.

What others say

NetEase Smart (October 20) puts the 256K case at about 40 MiB for MemT against 5.06 GiB for the conventional approach, roughly 130 times. That matches the labels in the paper’s Figure 3, where Nano is 40.00 MiB and full context 5.061 GiB. The 130x ratio is our arithmetic; the paper does not state it. Its latency figures (104–112 ms against 445 ms) also match the paper.

ifanr (October 20) reports that MemTensor officially released and open-sourced MemT 1.0 that day. The word “open-sourced” needs a caveat. The repository license bars commercial use, and common open-source definitions generally do not count such a license as open source, so the headline says “releases.” ifanr’s margins over the strongest parametric baselines (12.5 and 8.9 points) match the paper. It also reports an ablation in which removing post-training drops Nano from 47.0 to 36.3. Table 4 of the paper matches this: the w/o PT setting, a checkpoint after continued pre-training only, averages 36.3, 10.7 points below full Nano.

Security firm Socket reported that on September 23, 2026, a threat actor published malicious releases of two packages under MemTensor’s name: versions 0.1.21, 0.1.23 and 0.1.25 of the npm package @memtensor/memos-cloud-openclaw-plugin, and version 2.0.34 of the PyPI package MemoryOS. The payload searched for credentials for GitHub, npm, PyPI, AWS and other services. A RelayShield post on September 28, summarizing Aikido’s analysis, says the attacker “seized their release access.” Socket says it could not confirm how the attacker got publishing access. On October 20, those versions were no longer in the npm and PyPI version lists; npm’s latest tag points to 0.1.24, and PyPI’s newest release is 2.0.33. We found no response from MemTensor in the two security write-ups, the npm and PyPI registry records, Hacker News or the organization’s GitHub issues.

A Hacker News search through Algolia finds no discussion of MemT-1.0. Searches for MemTensor turn up two threads on the September incident and the 2025 MemOS post.

Our take

For engineers building long-running agents, the design is worth a look. State size does not grow with history, and inference does not re-read the raw record. The cost is capacity. The paper’s limitations section says a fixed-size state loses memory fidelity on tasks that need precise recall.

Three things stand in the way. The licenses do not line up: the code is noncommercial, the Nano card says Apache-2.0, and the README says the weights fall outside the repository licenses, with terms to come “with the corresponding releases.” Ask the authors before any commercial use. The benchmark table is the authors’ own, and textual systems still lead on the long-history tests. The setup is also heavy: the examples need Linux, NVIDIA CUDA, Python 3.11 or newer, and two GPUs for the server.

The September incident belongs in the trust assessment too. It involved an npm plugin and the PyPI package MemoryOS, not this repository or these weights, and we have not verified MemT-1.0’s release artifacts. But RelayShield’s account of Aikido’s analysis says release access was taken over in September, and we found no vendor statement. Install from the repository’s inference directory, as the README describes, not by package name.

What to watch: a formal weight license, independent reproductions of the benchmark table, and any response from MemTensor on the September incident.

How to try it

The README route needs Linux with NVIDIA CUDA and Python 3.11 or newer. From the repository’s inference directory, run uv pip install '.[server]', then sh start_memt_nano.sh /models/MemT-1.0-Nano. The server listens at http://127.0.0.1:30000, and the example uses two GPUs. Save session memory with save_state, then restore it by passing the returned path as state.