TTME: Evolving a Memory Instead of Weights Beats Test-Time Training on Math Discovery

If you want a language model to get better at a hard problem while it is working on it, the 2026 recipe has been test-time training: run reinforcement learning on the model's weights during the search itself. A new paper from UC Santa Barbara argues you may not need to touch the weights at all. Their method, Test-Time Memory Evolution (TTME), keeps the model frozen and instead evolves a small external memory of lessons and strategies. On five math construction tasks it reports better scores than test-time training (TTT) while cutting compute by 82.8% to 84.6% in FLOPs (paper on Hugging Face, arXiv, code). The paper, titled "Can Test-Time Memory Evolution Outperform Test-Time Training for Scientific Discovery?", was submitted on October 23, 2026 by Yepeng Liu and six co-authors including Dawn Song and Xin Eric Wang. This post explains what TTME does, what the tables actually show, and where the claims stop.

TL;DR: the questions people ask first #

What is test-time training, and why is it expensive? #

Scientific-discovery agents of this kind work like an evolutionary search. A model proposes programs or constructions, a verifier scores them, and the best candidates become the parents of the next round. This is the family of systems that includes AlphaEvolve, which we covered when Google described pairing Gemini with an evolutionary loop.

The recent twist, which the TTME authors call out in their abstract, is that test-time training frameworks let open-weight models outperform inference-only setups powered by frontier models on discovery tasks. Two frameworks matter here: TTT-Discover and ThetaEvolve. Both run online reinforcement learning during the search, so the model's weights change as it learns what works on this specific problem.

That works, but it has a price. Every weight update needs gradient computation, optimizer state and a training stack running next to the inference server. The authors note this makes efficiency a real concern when you scale to larger models. If you only have an inference endpoint, or a rented GPU you cannot train on, TTT is simply out of reach.

How does TTME work? #

TTME replaces only the TTT component. Everything else in the discovery framework stays the same, which is what makes the comparison fair in principle. The base model also performs all memory operations itself, so there is no second model involved. The memory has two parts.

Guideline Memory

Every two search steps, the model looks at recent outcomes and distills up to three operational lessons, with at most one of them about avoiding a failure. Each lesson has a trigger, a mechanism and an action. New lessons are compared with stored ones using Jaccard similarity (threshold 0.5), so near-duplicates merge instead of piling up. Entries expire after 20 steps without being reaffirmed, and at most 24 are kept.

That expiry rule is the interesting design choice. It stops the memory from growing into noise, which is the usual failure mode of agent memory, and it echoes the pruning idea we covered in why agents need curated documentation rather than raw memory.

Memory tree being pruned, illustrating how test-time memory evolution drops stale guideline entries

Strategy Memory

The second part learns from parent and child pairs. When a child candidate is valid and scores better than its parent, the model writes an "experience note" about what changed. Notes are grouped into strategy families and consolidated over time.

During search, a selector picks a strategy (one per parent in the experiments) and an adaptor turns it into a parent-specific instruction. Half the candidate budget is generated directly, and half is generated with that instruction. In effect the model keeps a notebook of "what tends to improve candidates like this one" and consults it.

What do the numbers show? #

The paper uses five math construction problems. Erdős minimum overlap, AC1 and AC3 are lower-is-better; AC2 and the 29 by 29 Hadamard determinant are higher-is-better. Under TTT-Discover the authors test Erdős, AC1 and AC2; under ThetaEvolve they test AC2, AC3 and Hadamard.

**TTT-Discover framework (paper's Table 1, selected rows):**

| Model | Method | Erdős (lower) | AC1 (lower) | AC2 (higher) | 
|---|---|---|---|---|

| Qwen3-8B | with TTT | 0.380932 | 1.50525 | 0.9472 | | Qwen3-8B | with TTME | 0.380927 | 1.504329 | 0.949248 | | gpt-oss-120b | with TTT | 0.380876 | 1.50287 | 0.9591 | | gpt-oss-120b | with TTME | 0.380862 | 1.502745 | 0.960784 |

**ThetaEvolve framework (Table 2, Distill-Qwen3-8B):**

| Method | AC2 (higher) | AC3 (lower) | Hadamard (higher) | 
|---|---|---|---|

| with TTT | 0.9469 | 1.4930 | 0.5764 | | with TTME | 0.948148 | 1.464224 | 0.579938 |

Look at the Erdős column: the gap is in the sixth decimal place. These are problems where progress comes in tiny increments, so small differences can still mean a new best construction, but readers should not expect dramatic jumps. The AC3 result (1.4930 to 1.4642) is the largest relative move.

The paper also reports that TTME reaches a TTT-level score within 25 steps on all three TTT-Discover tasks and both models, though it does not give the exact step where TTT's final score is matched.

Where the compute savings come from

For Qwen3-8B under TTT-Discover (Table 3, runtime excludes evaluation):

The FLOP reduction is far larger than the runtime reduction. That is plausible: the weight updates are FLOP-heavy, but wall-clock time is still dominated by generating candidates and waiting for verification, which both methods do.

Does the memory actually matter? The ablations #

Two ablations in the paper are worth knowing. First, on Qwen3-8B, adding TTT on top of TTME made AC2 worse (0.944141 versus 0.949248) and slightly worsened Erdős. So the two adaptation styles do not simply stack, at least in these runs.

Second, on gpt-oss-120b, removing either memory component hurt: dropping Guideline Memory or dropping Strategy Memory both gave worse AC1, AC2 and Erdős scores than the full system. The full TTME was best on all three tasks.

The authors also looked at search behaviour. TTME picks "combination" candidates, which merge ideas from several parents, more often than TTT: 10.2% versus 8.2% on AC1 and 24.7% versus 18.6% on AC2. Both methods raise the mean implementation validity rate over a run, but TTME finds better best-case scores.

Notebook with a bookmark, a picture of the strategy notes TTME keeps instead of updating weights

How to try it #

The repository is MIT licensed, with some components derived from ThetaEvolve under Apache-2.0. It requires Python 3.10 or newer, and searches need Linux.

• Verify the stored results on a CPU, no model download: install withpython -m pip install -c requirements.lock -e . , then runpython scripts/verify_results.py . A successful run ends with "9/9 constructions verified." The nine stored constructions cover AC1, AC2, AC3, Erdős and Hadamard.
• Run a search: install theprograms andserve extras, pointMODEL_PATH at a model snapshot (the docs use Qwen3-8B as the example) and runscripts/local/run_local.sh with an experiment config and an output directory. The launcher starts a model server and stops it when the search ends.
• Mind the safety note: generated programs run with the worker account's filesystem and network permissions. The docs recommend running evaluation workers in a container or a separate account. Treat it like any code-executing agent loop.

The repository includes the TTT-Discover search implementation for AC1, AC2 and Erdős. The ThetaEvolve results are provided as stored constructions plus scoring code, so you can check them but not rerun that framework from this repo.

What to be careful about #

The paper is honest about its limits, and they are real:

1. Narrow scope. Five math construction tasks, three models and two frameworks. The authors limit their conclusion to "the evaluated settings."
2. Baselines were not re-run under identical conditions. The TTT numbers come from the original papers, which used different step counts (50 for TTT-Discover, 65 for ThetaEvolve) and different serving setups (Tinker versus vLLM).
3. Seeds. The ThetaEvolve TTME runs use a single seed (3407) while the original TTT results come from three seeds. The TTT-Discover TTME results also appear to be single runs. With margins this small, variance matters.
4. Compute accounting. The comparison excludes evaluation time, and runtime is reported only for Qwen3-8B under TTT-Discover.
5. Verifiable tasks only. Math constructions have exact scorers. Memory distilled from noisy or subjective feedback is a different problem.

None of this makes the result wrong. It means the safest reading is "a cheap, promising alternative worth replicating," not "memory has replaced training."

Why it matters for builders #

The practical angle is access. Test-time training needs a training stack. A memory-based loop needs only an inference endpoint and some bookkeeping, which means it can run against hosted models and on modest hardware. If the finding holds up, the gap between teams with training infrastructure and teams with only API access narrows for this class of search problems.

It also connects to a wider pattern in agent research: improving behaviour by editing text the model reads rather than editing the model. We saw the same instinct in WikiSkill, which compiles agent experience into a persistent wiki, and in the discovery results described in AlphaProof Nexus and Gemini Cogentic's five math problems. Frozen weights plus a smart notebook is cheaper, easier to inspect and easier to roll back than a weight update, since you can read every entry in the memory.

For readers who build agents today, the transferable idea is the memory hygiene: extract a few lessons at a time, merge near-duplicates, expire what is not reaffirmed, and cap the size. Even if you never run a math search, that recipe applies to any long-running agent loop, including coding agents that accumulate notes across sessions. If you run code-executing loops like this one, a tool that gates dangerous actions is sensible; AgentBeam is the agent security platform from the explainx.ai team.

Bottom line #

TTME is a clean, well-scoped experiment: swap one component, keep the rest, and measure. The reported gains are small in score terms and large in compute terms, and the code lets anyone verify the stored constructions in minutes. What it does not yet have is independent replication, matched baselines or evidence beyond verifiable math. Watch for reruns on other discovery tasks.

Related reading #

Details reflect the paper and repository as of October 28, 2026 and may change in later versions.