Reasoning and Memory in Language Models

Jul 2026 to present · Independent research · Pythia, Qwen2.5-Coder, PyTorch · Not yet published

Two questions about changing a language model after it is trained: can a small module installed inside a frozen model teach it to reason in several steps, and when should a deployed model learn a new fact in its weights instead of looking it up?

1. A reasoning graft that lost to its baseline

Recurrent reasoning models like TRM and HRM get strong results from small modules that iterate and decide for themselves when to stop. Interpretability work has also found a narrow band inside language models that multi-step reasoning passes through. The hypothesis: put a small recurrent module with learned halting at that band of a frozen model, train only the module (about 5% of the parameters), and the model gains reasoning it did not have.

The graft took frozen Pythia-1B from near 0% to 54% accuracy on eight-hop questions, and to 61% on entities it never saw in training. Those numbers reproduce. They also turned out not to answer the question, because the comparison that decides it had not been run: a plain LoRA adapter with the same number of trainable parameters on the same frozen model. When it was run, the adapter beat the graft on every held-out test, by 0.4 to 0.85 absolute accuracy, across three seeds. Neither method generalized past the number of hops it was trained on.

Follow-up experiments showed why:

• The graft reroutes and never builds. It redirects computation the frozen model already does. It never produced a value that was not already in the prompt.
• The extra rounds do nothing. On tasks it fails, the recurrence reaches a fixed point after the second round.
• The halting head cannot see convergence. A normalization layer on the recurrent state removes the one quantity that would signal it. Fixing that made halting informative and bought no accuracy, because the extra rounds had nothing to compute.

I wrote this up as a 12-page negative-result paper, along with four measurement pitfalls that affect anyone training a module inside a frozen transformer. The one I would pass on first: run the parameter-matched baseline before anything else. I ran it last.

2. Learn a fact, or look it up?

A deployed model keeps meeting facts it was never trained on. It can store them in its weights with a small update, or retrieve them into the prompt each time. I tested both on Pythia-410M and 1B, with synthetic facts and with real counterfactual edits (CounterFact).

• Looking it up was as accurate or better on every test. A simple retriever found the right fact for every held-out wording, at about 11 extra prompt tokens per question.
• So the choice is cost. On Pythia-410M, learning a fact in the weights only saves compute once it has been asked about roughly 2,400 times (about 1,300 at 1B). That leaves a narrow niche: facts that are asked often and rarely change.
• An update can be kept away from everything else. A gate that switches the update on only when a prompt names a learned entity fired on every such prompt and on no others, so unrelated text stayed as it was.
• One small adapter per entity avoids forgetting. Forty facts added over eight rounds all stayed correct with no replay of old data, at 20 times the parameters of one shared adapter. One seed so far.

Both lines of work are unpublished. The paper and the claims ledger behind every number here are available on request.