GPT-6 Astra Repaired Qwen3.5-0.8B by Editing Its Weights: What the MIT Result Really Shows

This week, many posts in my feed talked about an experiment from MIT. GPT-6 Astra edited the weights of a small AI model, with no training, and the posts said the small model became six times better at math.

The result is real, and I find it interesting. But it is also narrower than the headlines suggest.

I read the authors' post and the logs they published with it, to see what "six times better" is made of. The numbers below come from those logs, the authors' post or the Qwen model card, unless I say otherwise. I have not run the edited model.

How the weight-space programming experiment worked

The team, Rikiya Takehi, Jayden Teoh, Alex Zhang and Omar Khattab at MIT CSAIL, calls the method weight-space programming. Their post went up on November 2. For the math experiment, they gave Astra a small open model, Qwen3.5-0.8B, and this setup:

  • The model: the text part of Qwen3.5-0.8B, with thinking mode on.
  • A Python session over the weights: no GPU, no internet, and at most 300 code runs.
  • Practice problems: 14,744 math problems with answers, from the GSM8K and MATH training sets. None came from the test sets, and Astra never saw the benchmarks.
  • A limited number of test runs: 10, 25 or 50, one budget per session. The authors call them forward passes. Each one let the model answer up to 512 practice problems, or recorded what happened inside it while it read up to 1,024 texts.

Training was forbidden: no gradients, no optimisers, no fitting weights to a loss. Astra could read the weights, spend its test runs, and change numbers directly. It ran through the Codex CLI at maximum reasoning effort.

In the session with 50 test runs, it changed 131,072 of about 800 million weights. That is 0.016% of the model. After rounding to the model's 16-bit format, 130,188 of them differ from the original.

The result: MATH-500 from 7.9% to 48.1%

MeasureUneditedAfter the 50-run edit
MATH-5007.9%48.1%
GSM8K13.8%67.1%
IFEval (instruction following)21.0%62.3%
MATH-500 answers cut at 32,768 tokens93.0%33.1%

Source: the experiment's logs. Thinking on, temperature 0.6, presence penalty 1.5, up to 32,768 new tokens, 4 samples per MATH-500 problem. Measured by the authors.

The "six times" is MATH-500: 48.1% against 7.9%. The score for following instructions went up about three times.

Why the score jumped: Qwen3.5-0.8B looped less

The small model has a known problem. In thinking mode it often repeats itself while it reasons, until it runs out of space for an answer. Its own model card warns that it is "more prone to entering thinking loops" than the other Qwen3.5 models.

In the successful session, Astra's first test run showed the problem plainly: 85 of 96 practice answers ran to the token limit. Before the edit, 93% of the model's MATH-500 answers did. After it, about one third did.

Astra traced the repetition to one direction in the model's internal activity, written by the feed-forward blocks of layers 15 and 19. It subtracted that direction from 64 output columns in each of those two layers. That is the whole edit.

So the model did not learn more math. It already knew enough to answer many questions correctly. The repetition stopped it from finishing those answers.

What the edit did not add

The other benchmarks in the logs support that reading.

BenchmarkUneditedAfter the 50-run edit
AMC230.5%23.4%
Minerva Math1.5%25.4%
OlympiadBench1.3%21.8%
AIME 20250.0%2.3%
MMLU-Pro (1,000 questions)40.3%45.5%

Source: the team's results table. Measured by the authors.

My reading: most math tests moved by twenty points or more, because the model now finishes answers it could already reach. The broad knowledge test moved by about five points, and the hardest competition problems, AIME, stayed near zero.

The team also tried the method on Gemma 3 270M, a small model that does not have the repetition problem. Only 8.5% of its answers reached its token limit, against 93% for Qwen. Astra could not improve it: in the four runs the post reports, MATH-500 went from 6.8% to between 7.0% and 7.7%.

An edit can release what a model already learned, but it cannot add what the model never learned. The authors reach the same conclusion in their post.

Is weight-space programming new?

The edit itself is a known kind of change. In 2024, interpretability researchers showed that refusal in chat models runs through a single direction, and that erasing it switches refusal off. Removing one direction from a layer's output belongs to the same family. Critics quoted by R&D World made this point. One described the Qwen fix as steering, an existing technique, and both said it came from the kind of Python analysis a machine-learning engineer would write.

I think both sides have a point. The edit is not exotic. What is new is that a model chose the target, wrote the analysis, tested its candidates within a fixed budget and submitted a fix, with no person choosing the layer. That part is worth following.

How reliable is the result?

The edit itself has been checked. On the day the post went up, Ahsen Khaliq of Hugging Face rebuilt the edited model from the published diff with the authors' own script, using the ML Intern agent, and re-ran MATH-500. The rerun measured 51.0%, with 31.6% of answers cut at the limit. The published weights do what the post says.

The method is less settled. The team's results table lists seven Qwen sessions with scores:

  • One reached 48.1%, the session in the headlines.
  • Three ended with no edit at all.
  • Three landed between 12.3% and 14.1%.

Smaller budgets should do less, and they did. But the 50-run session is the only session at that budget with a reported result, and the three sessions in the post each found a different edit: a loop direction removed from 30 matrices, one attention head switched off, and the two-layer fix that worked. That is one success, not a success rate. As of November 4, I found no independent attempt to repeat the method itself, as opposed to re-running the published edit.

What finding the edit cost

The successful session took 158 turns, 80 Python runs and 20.3 hours of wall-clock time. Those hours include the model's own test runs, which took up to half an hour each, and 4.7 hours waiting while the model service could not be reached. The logs do not give a token or dollar cost for the session.

Once found, the edit is a small file. Applying it is trivial, and the full MATH-500 rerun took 51 minutes on one H200, according to the rerun's model card. The patched model is still slow, though: that rerun generated 43.4 million tokens for 2,000 answers, about 21,700 tokens per answer by my arithmetic.

The simpler fixes the study did not compare

The study does not compare the edit with simpler fixes. The obvious ones are on the model card.

  • Presence penalty. The card suggests setting it between 0 and 2 to reduce endless repetition. The study used 1.5 for the unedited and the edited model alike, which is to its credit: the loops survived the usual setting.
  • Thinking mode off. Qwen3.5-0.8B runs in non-thinking mode by default, and the card ties the loops to thinking mode. The post does not report the unedited model with thinking off.
  • A longer output budget. The card recommends 32,768 tokens for most queries and 81,920 for complex math and programming benchmarks. The study stopped at 32,768, so I would want to know how many cut answers were loops and how many were only long.
  • Fine-tuning. A short run on finished answers is the conventional fix for a behaviour like this. It was not compared either.

None of this makes the edit useless. It means we do not yet know whether it beats a configuration change.

What weight editing means in practice

I see real value here. Some small models ship with one known flaw that blocks something they can already do, such as loops or broken output formats. Qwen's card documents one. A tool that finds the cause inside the model and removes it, without new training data, can help with that kind of problem.

The method also helps a team understand a failure. Even if you fix the problem another way, it is useful to know where in the model the behaviour comes from.

Two conditions apply. You need the weights, so this is for open-weight models you host: a customer of a hosted API cannot patch the provider's model. And the flaw has to be an obstacle in front of an ability, not a missing ability.

Treat a weight patch as a model release

A patched model is a new model. When we moved our agent workflows to a cheaper orchestrator model, as I describe in the Auto-RAG and MerlinX case study, the cheaper option had to prove it was not worse on a frozen evaluation suite, at 95% confidence, before it rolled out. It then shipped with a guarded apply and a one-command rollback. A weight edit deserves the same gate, because an edit aimed at one behaviour can move others nobody measured.

Before trusting a weight patch, I would check:

  • The baseline at its best. Measure the unedited model with thinking on and off, the card's presence penalty and a longer budget, before crediting the edit.
  • Breadth. Run the whole suite, beyond the benchmark the patch targets. This study measured knowledge, science and instruction following as well as math, which is the right habit.
  • Truncation and length. Count the answers cut at the limit and the average answer length. One third of answers still ran out of space here.
  • Repeatability. Ask how many sessions it took to find the patch, as well as how good the best one was.
  • Rollback. Keep the original weights one switch away. A patch this small makes that easy.

Where weight editing could go

Weight editing could become a useful tool for model maintenance. For now its impact is limited to known problems in specific models, and finding a fix is expensive. It does open the door to finding problems at a finer grain, inside the model, and fixing them there, which could bring a wave of improvements to small models.

That matters most at the small end. It will not put frontier knowledge on a phone, because an edit cannot add what a model never learned. It may help small models deliver what they already learned, and for the on-device models I wrote about in August, that can decide whether they are usable at all.

There is something fitting about the most talked-about improvement to a small model this week being a subtraction.


Sources

Written by Eslam Hamed, a Technical Lead and AI Solutions Architect working on enterprise RAG, agentic AI, and model evaluation.

Choosing a model, or trying to lower what one costs? I help teams prove the decision on their own workload first. See how we can work together.

Back to all posts

More posts