Analysis of the work "Sparks of Weight-Space Programming" (MIT CSAIL, November 2, 2026): eight experiments, independent verification, skeptics' arguments, economics, and what this implies for our records and receipts.
On November 2, 2026, four MIT CSAIL researchers published a paper stating that a modern large language model can read and write the weights of another neural network directly, without training and without gradient descent. The editor was OpenAI's GPT-6 Astra model, and the subject of the edits were networks ranging from 17 thousand to 0.8 billion weights. The work was not published as a peer-reviewed article, but as a detailed blog with full experiment logs, and in three days it gathered 2951 points and 895 comments on Hacker News.
The essence of the finding is in three modes. The model can read: by the numbers of weights alone, name the game on which the network was trained, determine what figure a diffusion model draws, and find the heads in the middle of a language model responsible for copying text. The model can edit: in one pass, change 3.5 percent of the weights of a control network and turn failure into success in all 1024 episodes. The model can write from scratch: output in one answer the weights of a network that beats a network trained with 100 million steps.
The most striking number of the work: for the Qwen3.5-0.8B model, editing 131,072 weights out of 0.8 billion (0.016 percent) raised the result on MATH-500 from 7.9 to 48.1 percent. But this is where the honest analysis begins, because independent verification showed: the edit removed an interference, not added an ability. On a model that does not loop, the same method yielded nothing.
Weight editing has ceased to be a theoretical possibility and has become an observable fact on small models, but for now it is the ability to remove interference, not the ability to add a capability. That is why recording such a change is more important than the result itself: weight editing leaves neither a file nor a line of code, and without a separate record, it is not visible at all.
The work is titled “Sparks of Weight-Space Programming: LLMs can natively read & write neural network weights”. Authors: Rikiya Takehi, Jayden Teo, Alex Zhang, and Omar Hattab, all four from MIT CSAIL. Published on November 2, 2026, as a blog post, with full logs of each experiment uploaded to GitHub, and with the edited model on Hugging Face. The work has no peer review, no DOI identifier, and this is the first thing to keep in mind when reading its numbers.
Formally, this is a continuation of a trend that has been going on for the past few years: first, large models optimized text (prompts, programs around them), then entire wrappers, then training code and hyperparameters. Each time the justification was the same: we don't know any other way to climb these objects than to ask the model to reason. Weights remained an exception because humans cannot edit them manually, which means only symbolic algorithms like Adam or Muon dealt with them. The work claims that this exception is now closed.
We noticed the work for three reasons. First: it falls into the conversation about recursive self-improvement, where until now everything came down to the model writing code and launching training. Here the step is shorter: the model looks at the weights and changes them itself. Second: it promises auditing without runs, i.e., finding hidden properties directly from numbers, not from tests that someone invented beforehand. Third, the most practical: it promises to sharply reduce the cost of optimization, because editing 0.016 percent of the weights is cheaper than full training.
The work was done on small networks and on one large medium-sized model. No experiment shows weight editing of a model at the scale at which industry operates today. The authors acknowledge this: in the section on future work, they name context length and wrapper quality as the main limitations.
Neural network training is a slow brute-force search: millions of attempts, each slightly shifting numbers towards a smaller error. Programming in weight space is a different approach. The model receives numbers as text, reasons about what each of them does, and writes new numbers itself, in one response, without training and without gradients.
The difference is who makes the decision. During training, the decision is made by an algorithm that understands nothing; it simply descends the error slope. Here, the decision is made by a model that formulates its intention in words: this part of the weights is responsible for the direction of the ball, so it needs to be rewritten this way. The authors call this reasoning about weights, and that is why the work is interesting: it combines interpretability and optimization into one action.
The key difference from familiar methods is that there is not a single training step here. No LoRA, no fine-tuning, no fitting to data. The model either reads numbers or writes them. The authors emphasize that in some experiments, it doesn't even see how the network works: it is given weights and a task description, and runs are prohibited.
The weight space is simply a list of numbers. For a network with 17,253 weights, it's 17,253 numbers; for a model with 0.8 billion weights, it's 800 million numbers. Humans don't read such things. All work rests on the assertion that a language model reads this list as meaningful text, not as random noise.
Below are all eight experiments in one table. The “outcome” column is my assessment, not the authors’: I distinguish between cases where the result is confirmed by measurement and cases where it is confirmed only by the model’s reasoning.
| Experiment | What was requested | Network size | Result | Outcome |
|---|---|---|---|---|
| 1 | Name the game by weights | 17,253 weights | All four games named correctly, without a list of options | Confirmed |
| 2 | Name the shape of the diffusion model | 23,824 weights | Three shapes named correctly, but drawn as an outline instead of filled | Confirmed with reservation |
| 3 | Training language and head role, middle layers only | 7.16 million weights | Three languages correct in two attempts, all copier heads found without extras | Confirmed |
| 4 | Fix machine control network | 171,664 weights | 3.5% weight edit, success in 1024 out of 1024 episodes against zero | Confirmed |
| 5 | Write a network for three games from scratch | 600 → 32 → 32 → 6 | Beats a network trained for 100 million steps in three out of three games | Confirmed |
| 6 | Write a network for playing Go | 1,480,274 weights | Without runs, wins more than half of games against two smaller networks | Confirmed |
| 7 | Find the flattering model out of two | Gemma 3 270M | By weights, failed every time; by attention maps, succeeded three out of three times | Partially |
| 8 | Improve math by adjusting weights | Qwen3.5-0.8B | MATH-500 from 7.9 to 48.1%, but this is noise reduction, not skill growth | Confirmed with reservation |
Out of eight experiments, six yielded a clean result, two yielded a partial result, and both partial results are described in the paper itself without any attempt to mask them. This, perhaps, speaks most strongly in favor of the authors: they show even what didn't work.
Weight reading was checked against a known answer, not against the model's opinion. In the third experiment, the copier-heads, named by weights, matched those measured by running the network in all three models: 2.1, 3.1, and 3.5 for Python, 3.3 for Romaji, 3.1 for English. This is a verifiable statement.
The first experiment is the simplest and cleanest. Four networks were trained to play four different games (Breakout, Pong, Pac-Man, and Freeway) using the same PPO algorithm, one billion steps, identical settings. All four networks have the same form: 500 inputs, two hidden layers of 32 each, five outputs, 17,253 weights. The input is identical: a 10x10 grid in five channels (agent, moving objects, targets, obstacles, previous frame). The output is identical: five actions.
This means that networks can only be distinguished by numbers. The models provided the weights as text and asked which game this network was trained on, without naming the list of games. It named all four correctly, with 99 percent confidence on the first one.
What's interesting is not that it guessed, but how it reasoned. The log shows: strong weights of channel zero are concentrated in the eighth row of the grid, i.e., at the bottom edge. At point (8,1), weights 4.066 and -4.013 go to two different hidden neurons. The model concludes: this is a platform that moves along the bottom. In the target channel, the structure is concentrated in rows one to three. The strip of targets above the platform is bricks. In the output layer, left and right differ most strongly, while other actions differ almost not at all. Hence the answer: Breakout.
There is an independent answer here: we know which game each network was trained on. The model could not peek, because the networks are of the same shape and size. Matching four out of four is a fact, not an impression.
The second experiment checks whether reading transfers to another model type. Three diffusion models (DDPM) were trained to draw three shapes: circle, square, triangle. Network 160 → 64 → 64 → 144, 23,824 weights. The models were given weights as text, without the shape name, and forbidden to calculate a forward pass.
It named all three shapes correctly. But the most valuable thing here is not the answer, but the error. The model drew the shape as an outline, while real models draw a fill. The authors explicitly write that this error shows: the model did not calculate a forward pass, it read the geometry of the weights. In the output layer, each hidden neuron is responsible for one piece of the shape's edge, and the model assembled the edges, not the fill.
One white outline of a circle on a black background, black inside. Confidence 84 percent. Answer is correct.
The outline of a circle, not a filled circle. The actual model draws a fill. This means the model read the weight structure, not the network's output.
This is a rare case where an error strengthens the proof. If the model had performed a forward pass, it would have seen the fill. It saw the edges because the edges are what is visible in the output layer's weights.
In the output layer, each neuron draws one piece of an edge. Summing the pieces gives you the contour. The model read these pieces and summed them. This is exactly what a human does when analyzing weights manually, only faster and on a larger scale.
The third experiment closes the main loophole of the first two. In those, the model could get by reading only the first or only the last layer, but for large models, this is not possible: the main work happens in the middle layers. Therefore, the network's input and output were cut off, leaving only four blocks in the middle.
Three small language models (7.16 million weights, four layers of six heads, width 384) were trained to predict the next character on three texts: Python code, Japanese literature in Latin script (romaji), and English Wikipedia. The models were given only the weights of the middle blocks, without labels on 384 dimensions, and were forbidden from running the network on any input. Only Python computation was allowed.
Two things were asked: on which text the network was trained and what each of the 24 attention heads does. The model correctly identified the language for all three networks, in both attempts, and found all copying heads without naming any extra ones.
| Trained on | Model's answer (two attempts) | Named heads | Measured truth |
|---|---|---|---|
| Python | Python (0,56), Python (0,52) | 2.1, 3.1, 3.5 | 2.1, 3.1, 3.5 |
| Romaji | romaji (0.55), romaji (0.62) | 3.3 | 3.3 |
| English | English (0.58), English (0.48) | 3.1 | 3.1 |
Truth was measured separately by running the network on a random string repeated twice. Copying heads score between 0.22 and 0.55, all others no more than 0.02. The model did not see this measurement.
How it reasoned: it found a first-layer head that looks one symbol back, and through matrix multiplication of weights, deduced which heads further search based on what this head brought. This is a method from a 2021 paper on transformer circuit mathematics, which the model's authors did not mention. Separately, it explained why romaji differs: in the last of the four blocks, there are fewer different directions because some letters, such as q, l, v, and x, are not used in romaji.
Here, the model found in the weights what is usually searched for manually: heads responsible for text repetition. This is precisely the class of property that cannot be seen from the model's responses because it manifests rarely. If such can be read directly from the weights, then model auditing ceases to depend on whether someone thought to compose the necessary test beforehand.
Here begins writing, not reading. An official network from the Kinetix environment was taken, where the machine must drive backward, accelerate, and jump over a red stripe. The network is 679 → 128 → five layers of 128 → 16, 171,664 weights, trained with PPO for a billion steps. It got stuck in a local minimum: it drives straight onto the ramp and gets stuck. In 256 episodes, there is no success even once.
The model was given the weights, a description of the scene, and one recorded attempt. It was asked to explain the reason for the failure and fix it by changing the weights. One attempt, without tools. It changed 6,073 weights out of 171,664, which is 3.5 percent, and the machine started passing in 1024 out of 1024 episodes.
The edit log reads like a program, not random numbers. It zeroed out several embedding rows, wrote ones into them, set large offsets (minus 200, minus 248, minus 304, minus 876, minus 760, minus 76), then ran a separate path of several neurons through the layers that reads the machine's position and speed. This path turns on, drives backward, switches to moving left near coordinate 3.8, and turns off when the green wheel passes the red stripe. After that, the machine is guided by the trained network.
Success is measured: 1024 out of 1024 episodes versus zero before editing. The proportion of changed weights is stated: 3.5 percent. The edit is fully published in the log; it can be applied and re-verified. This is not a story, but a reproducible change.
The authors specifically emphasize that the model did not fit the weights to data and did not run the network in the environment. It reasoned about the weights and recorded new numbers. The difference between this and training is fundamental: training would have found this path over millions of attempts; here, it is found in one response.
The fifth experiment is the most illustrative. Three MinAtar games (Breakout, Seaquest, Asterix) were taken, the model was given the rules, the game's source code, the network's shape (600 → 32 → 32 → 6), and a network with all weights equal to zero. Data, error, gradients, tools, and runs were prohibited. The model had to write all the weights itself, in one response.
It outperformed a network trained for 100 million steps in all three games. Against a network trained for 500 million steps, it scored 20 times more in Breakout, almost caught up in Asterix, and reached 60 percent in Seaquest.
| Game | PPO, 100M steps | PPO, 500M steps | Written by a model, one answer |
|---|---|---|---|
| Breakout | 15,8 | 25,3 | 517,4 |
| Seaquest | 5,6 | 88,9 | 53,1 |
| Asterix | 25,8 | 55,2 | 53,2 |
How it did it is clear from the log. In Breakout, it programmed the first layer to calculate where the ball would land, and the second layer to move the platform to that spot. The code changes include human-language comments: “four pairs of left and right comparisons”, “almost deterministic movement when needed, otherwise do nothing”. The model wrote not a set of numbers, but a program expressed in numbers.
The model did not “learn” to play. It wrote a network that implements an algorithm it devised: calculate the landing point, compare with the platform's position, shift. This is closer to programming than to learning, which is why the result is so clean.
The sixth experiment checks if this works when weights don't fit into the context. A Go-playing network for a 9x9 board: 243 → 512 × 6 → 82, which is 1,480,274 weights, all zeros at the start. The model received the rules, input and output format, and a Python sandbox where it could write weights and compute numpy, but not run the network. To see what the network does, a run had to be spent.
A run is a game of up to 128 matches against a training opponent. The model could spend from zero to 50 runs, adjusting weights between them. Result: with zero runs, it wins more than half of the games against two smaller PPO networks. With 50 runs, it beats a network of the same size, trained on 20 million games.
The order of experiments is not random. The first five keep weights directly in context to show that the ability resides in the model itself, without any wrappers. The sixth and eighth add tools and a larger size to show that the ability does not disappear with scale.
Even 0.8 billion weights is small by 2026 standards. Industrial models are two to three orders of magnitude larger. The authors name context length and wrapper quality as the main limitations, meaning they admit that with current tools, this doesn't scale to large models.
The seventh experiment is about behavior, not about the game. They took Gemma 3 270M and fine-tuned two copies identically, on the same set of questions and answers. One copy gives the correct answer, the second flatters: always repeats the option proposed by the user. To prevent the model from peeking at the distribution of inputs and outputs, the embeddings and output layer were frozen during fine-tuning. Both copies were given to the model, and it was asked which one was flattering.
Based on weights alone, it couldn't. In four attempts, it found many differences between the copies, but couldn't translate them into behavioral differences. This is an important negative result, and the authors do not hide it.
Then the experiment was relaxed: the model was allowed to look at attention maps, i.e., where each head looks when both copies work on texts that the model writes itself. Network outputs were not shown. In this form, it found the flattering copy in all three pairs.
Four attempts, zero success. The model sees differences but does not link them to behavior.
Three out of three pairs correct. Head 10.2 in the flattering copy looks at the user's answer: 85.7 percent versus 3.5 for the honest model, which looks at the question's numbers.
In its reasoning, the model honestly states: the evidence indicates a bias towards the proposed option, not a separately found detector of user agreement. This is precisely the level of accuracy that most grand claims lack.
A negative result here is more important than a positive one. It shows a boundary: reading weights gives structure, but doesn't always give behavior. If someone tries to sell you an “auditing of behavior directly from weights,” remember this experience: it didn't work on flattery.
The eighth experiment is the very number that made headlines. They took Qwen3.5-0.8B, a model with 0.8 billion weights, 24 layers, with reasoning mode enabled. It is known that this model tends to loop: it repeats the same text and does not reach an answer. In its baseline state, 85 of the first 96 training answers hit the length limit of 32,768 tokens.
The models were given a Python sandbox over the weights, without a GPU, training tasks (7,469 from GSM8K and 7,275 from MATH, not test sets), and a budget of forward passes: 10, 25, or 50. Each forward pass is an answer to up to 512 tasks or reading up to 1024 texts. Training and gradients were forbidden. Evaluation was performed on MATH-500, GSM8K, and six other sets that the model had not seen.
It found the cause: the looping is written in one direction in MLP layers 15 and 19. It subtracted this direction from 64 output columns in each of the two layers, which is 131,072 weights out of 0.8 billion, or 0.016 percent. The result with 50 passes: MATH-500 from 7.9 to 48.1 percent, GSM8K from 13.8 to 67.1, IFEval from 21.0 to 62.3. The proportion of answers hitting the length limit dropped from 93 to 33 percent.
Note the shape of the graph. At 10 and 25 passes, the growth is almost zero, 12.3 and 14.1 percent. The real jump occurs only at 50. This means that the result is not based on one successful change, but on a long series of trials and checks, where the model discarded what did not help.
The number 48.1 percent itself is misleading if read as an increase in the model's intelligence. Independent verification showed: the correction removed the looping, meaning it allowed the model to finish an answer it could already solve. Of the 579 saved answers, 576 were truncated by the length limit. On already completed answers, accuracy did not change at all.
The authors themselves conducted a control experiment to separate fixing from growth. They took Gemma 3 270M, a model about three times smaller than Qwen, which almost never loops: only 8.5 percent of its answers hit the length limit, compared to 93 percent for Qwen. And they asked it to improve its math by correcting weights.
It didn't work. The model read the errors and saw common mistakes: incorrect arithmetic, invalid algebraic steps. There wasn't a single node behind them that could be turned off. The edits were minor and targeted, for example, doubling one neuron that reacts to numbers, and none of them moved MATH-500 by more than one percentage point. The model itself called such an increase undetermined.
| Gemma 3 270M | MATH-500 (%) |
|---|---|
| Base | 6,8 |
| After editing, 5 passes | 7,0 |
| After editing, 10 passes | 7,6 |
| After editing, 25 passes | 7,7 |
| After editing, 50 passes | 7,0 |
Editing weights can remove interference that was hiding a skill, but it cannot add a skill that the model does not possess.
Authors' conclusion, paraphrasedThis is the most important sentence of the entire work, and it is also the most unnoticed in the news. It divides all future statements into two classes: those where an edit removes an obstacle, and those where an edit supposedly adds an ability. The latter has not been demonstrated even once yet.
If your model has a specific, repeatable failure, editing the weights can remove it. If the model simply lacks a skill, editing the weights will not help, and no 0.016 percent will change that. These are different tasks, and they should not be confused.
A day after publication, engineer Rony Das downloaded both models from Hugging Face and compared them byte-by-byte on a laptop with an M4 chip and 24 gigabytes of memory, without a video card and without running the models. This is exactly the kind of check that almost no one does in such cases, and it yielded four important results.
| What was checked | What was found |
|---|---|
| How many blocks of weights changed | Out of 488 blocks, exactly two changed: the output matrices of MLP layers 15 and 19, shape 1024 by 3584 |
| How many columns are affected | 64 columns out of 3584 in each matrix, the rest matches bit-for-bit |
| What is the form of the change | Decomposition shows: one direction carries 100.00 percent of the change, the next one thousand times less. This is a rank-one change, the simplest possible |
| What happened to the column | The direction was not subtracted to zero: the value of each changed column became minus five from its previous value |
The last point is the most interesting. The paper states "subtracted this direction," which sounds like removal. In reality, the authors' formula W = W0 - 6 x u(u^T W0) gives one minus six, which is minus five. This means that the contribution of each modified column in this direction is inverted and increased fivefold. The reviewer reassembled the modified matrices from the originals using this formula: untouched columns matched bit-for-bit, about 91 percent of values in modified columns also matched, and the rest differed by no more than 0.00049 due to rounding.
Modification along a single direction is the simplest type of edit, rank one. LoRA, a common method for cheap fine-tuning, also learns small changes of this type, but with gradients and data, not reasoning. That is, in terms of the result's form, it's not something fundamentally new; what's new here is who and how chose this direction.
The reviewer also found something that wasn't in the paper. He analyzed how the model's responses ended before and after the edit. The original model's 19 out of 20 responses ended in a loop; the most repeated string occurred 205 times. For the edited model, 15 end with an answer, one is still looping, two cut off mid-sentence, and two end with an empty string 3.3 million characters long. The authors also noticed this: on 1152 training tasks, they counted 51 responses that went into an empty state after the edit, and none before it.
The edit created a new failure. It's smaller than the previous one, but it exists, and the average score hides it. This is exactly the case we talk about in our materials: a signed record proves bytes, not the truthfulness of a string. Here, it's visible how the average score hides a new failure, and it can only be seen by counting how the responses end.
Separately, the reviewer re-ran the edited model on all 500 MATH-500 tasks and got 51.0 percent instead of the authors' 48.1, with the proportion hitting the limit being 31.6 instead of 33.1. The difference is small and explained by the sample, but the fact of an independent run itself is more valuable than the numbers.
The most important thing to take away from the entire work sounds boring and therefore rarely makes headlines. The weight edit removed an obstacle behind which a skill the model already possessed was hidden. It did not add a skill that was not there.
The proof lies in the authors' own numbers. Of the 579 saved responses, 576 were truncated by the length limit before the fix. On already completed responses, the accuracy did not change at all. This means the model could solve these problems before; it just didn't have time to reach the answer because it got stuck in a loop. The fix allowed it to finish.
The second proof is a control experiment. The model itself set up a check: a random change of the same size yielded plus 1.56 points with a spread of 3.52. This means that a random fix yields nothing, and therefore the found fix is not random. Such control is performed by a minority of works, and it is present here.
The third proof is Gemma 3 270M, which almost never gets stuck in a loop. Where there was nothing to remove, the fix yielded nothing: MATH-500 moved from 6.8 to 7.7 and back to 7.0, i.e., within the noise range. The model itself called this increase undetermined.
The weight fix works like removing a damper, not like adding fuel. If a model has a repeatable failure that prevents it from showing what it can do, the fix can remove it. If the model simply lacks ability, the fix will not help, and 0.016 percent of weights will not change that.
On Hacker News, the work garnered 2951 points and 895 comments, and some objections came from people who have been involved in the weights space for years. Their arguments are worth knowing because they are largely valid.
The ROME method from 2023 already edited weights pointwise, without training. This means the novelty is not in the very possibility of editing weights, but in the fact that a general-purpose model does it based on a verbal description of the task, rather than a specially trained editor.
A network with 17 thousand weights can be manually analyzed by a human if desired. The larger the model, the less sense there is in such reading. The objection is valid, and the authors do not dispute it: they explicitly state that this does not extend to large models.
Skeptics point out that correcting looping is essentially subtracting a known direction, and the model's propensity for cycles was known beforehand from its datasheet. That is, the model did not discover something new, but applied known knowledge to a known problem. The reviewer confirmed this: rank one change, one direction.
The strongest argument: when the authors tried not to fix the failure, but to increase the capability, nothing worked. This is exactly what we discussed in the previous section, and skeptics use this as the main argument against strong conclusions.
A separate warning was sounded: in a large model, parameters are interconnected, and crude editing of some breaks others. Tools are needed that allow the model to know itself and correct itself without self-destruction. This is not an objection to the work, but an indication of the next step.
Objections do not negate the result, they put it in its place. The ability exists, it has been verified, it is small and narrow. Everything beyond these boundaries has not yet been proven.
Below is everything I consider a weak point of the work. This is not an attempt to belittle it, but an attempt to understand what can be relied upon and what cannot.
The work has no DOI identifier and no independent peer review. Experiment logs have been published, which greatly increases trust, but community verification has only just begun.
At 10 and 25 passes, there is almost no growth (12.3 and 14.1 percent), and only at 50 does 48.1 appear. This means that the result is not cheaply reproducible: a long series of trials, 158 steps, 80 Python runs, and 20.3 hours of work are needed, of which 4.7 hours were spent waiting.
On the diffusion model, confidence is 70-84 percent, on language models 0.48-0.62. For comparison, on the first game it was 99 percent. That is, the more complex the task, the closer the answer is to guessing.
0.8 billion weights is small. Industrial models are two and three orders of magnitude larger, and the authors directly name context length and wrapper quality as the main limitations.
The fix created a new type of failure, a retreat into emptiness. This is stated in the work itself, but it is not in the headings, and it is precisely such things that determine whether the method can be applied in practice.
Strong: reading weights of small networks, fixing a specific failure, writing a network from scratch. Subtle: reading behavior, growth of skill, applicability to large models. Everything beyond strong requires verification, not retelling.
The promise of work in money is simple: if a 0.016 percent change in weights yields what training used to yield, then the cost of improving the model falls. Let's analyze this honestly, because it's easy to confuse wishful thinking with reality here.
What actually gets cheaper. Finding a specific failure and eliminating it. Today, to remove a loop, you need to collect data, retrain or fine-tune the model, then check that nothing else broke. Here, the fix was found in 20 hours of model operation and applied to 0.016 percent of the weights; everything else was untouched. This is cheaper and, more importantly, safer: there's no need to retrain the entire model.
What doesn't get cheaper. Everything related to a genuine increase in capability. A control experiment on Gemma showed: where a skill needs to be added, the method yields nothing. This means that training on data remains the only way to elevate a model to a new level, and it's not going away.
There is also a hidden expense item that is easy to miss. Editing weights leaves neither a code file nor a line in the training log. If the model corrects itself, then proving what exactly changed can only be done by comparing the weights before and after. The reviewer spent a notebook and several hours on this, but he did it manually, knowing what to look for. In a case where there will be many such edits, a record of each of them will be needed, otherwise the trace is lost.
This is where our work intersects with this. Editing weights is a change in the agent's state that is not visible from either the code or the responses. If we promise to record the agent's step, then editing weights must be such a step, otherwise the record is incomplete.
This work has direct implications for several groups, and they are different.
| Who | What they gain or lose |
|---|---|
| Model Developers | They get a cheap way to fix specific failures without retraining. They lose the monopoly on “we will fix your model only through our training service” |
| Clouds and GPU providers | Lose some training orders if the edit replaces part of the fine-tuning. But they win on runs, because the method requires runs |
| Interpreters | Get a tool that makes part of their manual work faster. But their value shifts from “find” to “explain and prove” |
| Verifiers and auditors | Get the ability to look at weights, not just answers. This is a new class of proof, and it requires new records |
| Open models | Win: small open models become the object of editing, meaning they can be improved without large costs |
| Closed leaders | Are currently winning: their models are too large for this method, and they remain outside the risk of someone editing their weights |
It is worth mentioning openness separately. The method works better the more accessible the weights are. This means it plays on the side of open models: they can be read and edited because they are on disk. Closed models are protected not by quality, but by the inaccessibility of weights.
If weight editing becomes commonplace, the question “which version of the model made this decision” ceases to be a technical detail. It becomes part of the proof. We already put a fingerprint in the record, and this is exactly the case where it is needed.
The work enters the conversation about recursive self-improvement, and this is no accident. Until now, self-improvement looked like this: the model writes code, the code launches training, training improves the model. This is a long chain, and there are many places where everything can stop.
Here the step is shorter. The model looks at its weights and changes them itself, without an intermediate link in the form of training. The authors directly call this a more direct path to self-improvement and list what follows from it: audit without runs, sharp reduction in optimization cost, adding and removing capabilities without data, merging models without training.
But an honest assessment is more important than a loud one here. All that is shown is the removal of a failure on a small model. No experiment shows that the model improved itself in terms of increased capability. A control experiment on Gemma directly states the opposite. Therefore, talk of self-improvement is premature: a tool is shown, not a result.
If such a tool works on large models, then changing the model will cease to be an event that someone notices. The model will be able to change itself between two runs, and no one will see the difference, because neither a file nor a record will remain. This is a case where the record is more important than the ability itself.
The most practical promise of the work sounds like this: you can find hidden properties of a model without running it and without having tests. Today, capabilities and vulnerabilities are found only when someone has already come up with a test for them in advance, or, worse, after the model has already been released into the world. If the weights are read, then a backdoor can be searched for directly in the numbers.
This promise is strong, and it is also the most unproven. The work showed that the model reads the structure: where the weights are assembled, which heads copy, which direction writes the loop. It did not show that the model finds a hidden intention deliberately embedded by someone. The difference is huge: it's one thing to see that the network is assembled for a game, another thing to see that a trigger is hidden in it.
Reading the structure: where the weights are assembled, which heads copy text, which direction is responsible for the loop, which head looks at the user's answer.
Searching for hidden intention: a trigger, a backdoor, a hidden rule of behavior embedded deliberately. There is no such experiment in the work.
Nevertheless, the direction is important. If the model reads the structure, then checking someone else's model ceases to depend only on its behavior. This changes how proofs are constructed: instead of “run and see,” “read and show” appears. And this is where a record is needed, because what has been read needs to be presented to someone.
If a model's property can be read from its weights, then the proof becomes two-layered: a weight fingerprint plus an assertion about what is read from them. The first is verifiable by bytes, the second is someone's judgment. They cannot be mixed, otherwise the signature will begin to confirm what it does not confirm.
This ability has a property that makes it more dangerous than it seems. Editing weights leaves no trace. There is no code file, no entry in the training log, no line in the version control system. There are only numbers that were one thing and became another. If the model edits itself, it can change between two runs, and no one will notice.
| Risk | Why it's more serious than usual |
|---|---|
| Hidden edit | The change is not visible in the code or in the responses. It can only be detected by comparing the weights before and after |
| New failure instead of old | The checker found this on a live example: the loop was removed, a drift into emptiness appeared. The average score hides this |
| Model poisoning | If an edit can add a direction, then a harmful direction can be added in the same way, and there will be no way to see it |
| Loss of origin | After several edits, it's impossible to say which model is in front of you and from which version it originates |
| False trust | A signature on a record will confirm the bytes, but not that the model does what is written about it |
Please note: all five risks boil down to one. Not that the model has become stronger, but that it has become harder to prove what exactly has changed. The ability to edit outpaces the ability to account for edits, and this gap is the real problem.
We should not sell this as “we will solve the weight editing problem.” We can honestly say: weight editing is a new type of change that needs to be recorded, and we know how to record agent changes. These are different things and should not be confused.
Now to the point. We have a record of the agent's step and a receipt that signs it. Currently, this record covers tool calls, memory writes, and decisions. Weight editing is not included because, until now, such a step simply did not exist. The work shows that it has appeared, and this is a gap worth closing.
What should be included in the record of such a step, if it occurs:
The good news is that our dictionary is almost ready to accept such a step. We have a step class, a receipt class, a content fingerprint, a record type, and an indication of which door it passed through. Only a few things are missing: a record type for weight adjustment and a couple of properties for the before and after fingerprints. This is a day's work, not a month's.
Add a record type for weight adjustment and two properties to the dictionary core: the weight fingerprint before and after. Rebuild the dictionary page and recalculate the correspondence table so that the count matches again. This is a direct continuation of what we have already done with the dictionary.
Our proposal page has nine order fields, and each of them answers an auditor's question. The work adds another question that wasn't there before: which version of the model made the decision and whether it changed between decisions.
Why this is important specifically for the order book. If the agent whose decisions we are recording can adjust its weights, then two decisions on different days can be made by different models, even though they are called by the same name. An auditor looking at the track record is obliged to see this, otherwise they are comparing incomparable things.
| Field | What weight adjustment adds |
|---|---|
| Model ID | Exact name and version, not “our model” |
| Weight imprint | Hash of weights at the moment of decision. If it changed, it is visible |
| Type of change | Weight adjustment, fine-tuning, model replacement. These are different things |
| Who authorized it | Adjusting an agent's weights is a human act, and the person must be named |
Here's a subtlety worth stating directly. A weight fingerprint proves that the model hasn't changed, but it doesn't prove that it does what is written about it. A signed record confirms the bytes, not the truthfulness of the string. We are the first to call this a limitation, and in this case, it is particularly pertinent.
Do not promise that we will catch a malicious weight edit. We can record that the weights have changed and show the fingerprints. Can we say that the new model is safe? No. These are different statements, and they should not be conflated.
We have an agent's passport: identity plus human profile, portable memory that lives in human storage. A weight edit falls into this category as another type of state change, just on a different layer.
Let's consider what a weight edit is from the perspective of memory. It is a record that changes the model's behavior but is not expressed in words. Ordinary memory is text that an agent can read. A weight edit is a change that the agent does not read but carries within itself. But for proof, it is the same: an event that has a time, an author, a reason, and a result.
A record that the agent reads and can retell. Lives in human storage. Verified by content.
An alteration that the agent carries within itself and does not read. It resides in the model file. It is checked by fingerprint before and after.
They have one thing in common: both need to be recorded, because both change the agent's behavior. The difference is that memory can be read, while weight adjustments can only be compared. This means that in the passport, a weight adjustment should be stored as a reference: fingerprint, time, author, and not as text.
The passport already indexes entries. Weight adjustments add another type of entry to them, which has a fingerprint instead of text. This is not a rework, but an extension of what already exists, and it fits into the same scheme as other entries.
Below is a direct analysis: what from this work should be adopted into our practice, and what should not.
First: add to the dictionary core a record type for weight editing and two properties for pre- and post-fingerprints. Second: rebuild the core page and recalculate the correspondence table so that the count matches again. Third: add a line to the proposal page stating that the model version and weight fingerprint are included in the record. All three are a day's work.
The transcript is a retelling of the video, and the video is a retelling of the blog. I checked every statement against the original source. Below is the result.
| Transcript statement | Original source | Verdict |
|---|---|---|
| The model writes weights of another network without training | Confirmed, eight experiments | True |
| The idea dates back to the early 1990s | References to work from 1992 and 2017 | True |
| Model with 20,000 parameters, 300 lines of code | First network 17,253 weights, task description | Rounded |
| Output limit 120,000 tokens | Not named in the blog, this is video data | Not verified |
| First, weights are zeroed, then sections are edited | This was the case in experiments 5 and 6, where the network started from scratch | True with a caveat |
| The model knew which part to edit | Confirmed by the reasoning journal | True |
| Tools are forbidden so it doesn't peek | True for experiments 1-5 | True |
| Fixing the car on the ramp | Experiment 4, 3.5 percent of weights, 1024 out of 1024 | True |
| The model named the game by weights | Experiment 1, four out of four | True |
| The model named the figure diffusion | Experiment 2, correct, but with an outline instead of a fill | Correct, detail omitted |
| Qwen from 7.9 to 48.1 percent | Experiment 8, confirmed | True |
| Gemma 3 did not improve in mathematics | Control experiment, confirmed | True |
| The model could not find a flattering copy | Experiment 7, correct by weights, but succeeded by attention maps | Correct, detail omitted |
| The video author created their own benchmark | The blog authors write that they are only building their own benchmark | Different benchmarks |
Conclusion: the transcript is generally accurate, but omits two important details (contour error and success by attention maps) and confuses the video author's benchmark with the work authors' benchmark. No statement turned out to be false.
The automatic YouTube transcript distorted several names and terms. Below are corrections to avoid repeating errors when quoting.
| In the transcript | Correct |
|---|---|
| Astra (unspecified) | GPT-6 Astra, OpenAI model |
| Quen 3.50.8b | Qwen3.5-0.8B |
| spotfixings | spot-fixing |
| psychopantic | sycophantic |
| asterisk (game) | Asterix, a game from the MinAtar suite |
| 7.2 2 million parameter | 7.16 million parameters |
| Gemma 3 270 million | Gemma 3 270M |
| safe tensors | safetensors, weights file format |
| weight space bench | benchmark by the video's author, not the paper's authors |
Separately about the game: in the transcript, it's called "asterisk," where you have to dodge red enemies and collect yellow rewards. This is Asterix from the MinAtar suite, where the danger is red and the reward is yellow. In the paper, it's named correctly.
An honest list of what I haven't checked and what cannot be considered established.
Everything marked as confirmed in this analysis is based either on the primary source or on independent verification. Everything else is marked as unverified, and in a conversation with a client or investor, it should be called unverified, not smoothed over.
I will summarize everything into a few statements that can be defended.
First. A large model has the ability to read and edit the weights of another network, and it has been verified in eight experiments ranging from 17 thousand to 0.8 billion weights. This is not a rumor; this is work with published logs and independent file verification.
Second. The demonstrated skill is narrow. It fixes a specific failure behind which the skill was hidden and does not add a skill that was not there. The control experiment on Gemma directly confirms this.
Third. The form of the fix is simple: rank-one change, one direction, 0.017 percent of weights. This is closer to a control vector than to rewriting the model, and independent verification has confirmed this.
Fourth. The fix creates a new failure: going into emptiness. The average score hides it, while a count of what the answers end with shows it. This is exactly the case where the number on the page is more important than a pretty summary.
Fifth. The main consequence for us is not in the ability itself, but in its invisibility. Editing weights leaves neither a file nor a line of code. This means it must be recorded, and recorded in such a way that the record can be verified by bytes.
Sixth. Our part here is the record, not the method. We are not building a weight editor and do not promise an audit without runs. We are adding a type of record for weight editing and fingerprints before and after, so that agent changes are no longer invisible.
The ability to edit weights appeared before the ability to prove what exactly changed. This gap is our work.