Weight-Space Programming

Remember when neural networks were considered black boxes?

It turns out frontier LLMs can read and even write the weights of other small neural networks without running a gradient-based training loop .

Researchers from MIT call this Weight-Space Programming.

In their blog post, they proclaim that:

our neural network weights will soon be natively optimized by LLMs that deliberately reason about their weights.

The authors ran several experiments with GPT-6 Astra to evaluate its "weight-space programming" capability.

For reading capability, they found that:

• For a small set of game-playing models, Astra could tell which game a model was trained to play from its weights.
• Astra could identify the shapes a diffusion model was trained to generate from its weights alone.
• Using just four transformer blocks from the middle of a language model, Astra could distinguish models trained on Python, English and romanised Japanese.

For writing, the story seems even more wild: it could write a 1.5-million-weight network for 9×9 Go from scratch (starting from zeros), without gradient-based training. The authors tested this with and without inference feedback. Astra also wrote smaller networks for Breakout, Seaquest and Asterix.

It can even fix a looping bug in a Qwen3.5-0.8B model, improving its math capability from 7.9% to 48.1% to MATH-500.

Seems like a huge step towards more interpretable models, and potentially safer ones. Also, I feel like it's a step further in the direction of recursive self-improvement.

The Kimi K3.1 Pro approach to reducing cybersecurity capability was to remove cyber-related content from its mid-training data and cyber tasks from its RL environments before training the release . In future, another larger model might directly edit the relevant weights.

If this paradigm scales, does this mean that the insane spend on training compute for frontier models will be replaced with inference compute? What does that mean for the insane valuations of NVDA and other AI-hardware vendors?

The authors are building a benchmark and harness to measure LLMs' capability at Weight-Space Programming.

Conceptual overview of the authors' experiments. The symbols are illustrative; the benchmark figures are their reported results.

A few extra tests

I ran some experiments of my own.

Can other models identify the authors' games?

Turns out Opus 5.5, Sol,Terra and Sonnet can correctly guess the games from the weights.

I replayed the authors' four original game-identification tests with five other models, using the same prompts and numerical weights .

The four games were Breakout, Pong, Pac-Man and Freeway. The authors' scoring accepts Frogger for their Freeway-style road-crossing game. Sonnet called Pac-Man an Asterix-like dodge-and-collect game. Haiku called Breakout Freeway-style, Pong Asterix-like, and Pac-Man Frogger-style; only its Freeway guess matched. The wrong guesses are retained alongside the correct ones.

Each model also received one shape-and-layout-only control. Since all four networks have the same structure, that is one shared prior diagnostic per model, not four independent controls. Confidence percentages are subjective and uncalibrated. For the two abstentions, 0% refers to confidence in identifying a particular game.

What each model received

All five models received the actual numerical representation supplied to the authors' Astra: all 17,253 actor weights, rounded to three decimals, together with the original grid, channel meanings, actions and network formula. Every prompt matches its published Git blob byte for byte. No game candidates were supplied.

The networks are much smaller than my DQN models: the same 500 → 32 → 32 → 5 architecture for every game, on a 10 × 10 grid. All weights went directly into the prompt. No tools, policy-network forward passes or activations were available.

Each case used one fresh session and one response at high effort, matching the authors' setting for Experiment 1. Equal effort labels don't establish equal computation across models. Opus, Sonnet and Haiku used Claude Code 2.1.304; Sol and Terra used Codex CLI 0.164.0. No wrong answer was retried.

Claude's model IDs were verified in its response/init records. Codex used the exact pinned model IDs in successful CLI requests; its public event stream does not expose a per-response model ID. All sessions completed in one turn with no tool calls. The full-precision binary checkpoint was not supplied to these tool-free sessions.

What Opus found in Breakout's weights

Opus's explanation pointed to large agent-channel weights on row 8, the bottom playable row, and reward-target weights in rows 1 to 3. The numerical pattern checks out:

Computed from the released three-decimal weights. The input-channel meanings and grid layout were given in the prompt. These are coefficient magnitudes, not measured activations or proof of a causal interpretation. Source data: Takehi et al., CC BY 4.0 . Plotted data and plot source.

Reproduce the comparison

The authors published the exact prompt they gave Astra for each game. Each one is a single text file: the grid layout, the network formula, all 17,253 weights and the answer format. Pipe one into a fresh session with tools off:

curl -sL https://raw.githubusercontent.com/RikiyaT/lm_understand-logs/4d09ba6d6a7e891dd8063974dfe81b3d78e3494f/exp1_which_game/runs/breakout/prompt.txt \
  | claude -p --model claude-opus-5-5 --effort high --tools ""

For Sol or Terra, end the pipe with codex exec -m gpt-6.1-sol -c model_reasoning_effort=high - instead, run from an empty folder.

Swap breakout for pong, pacman or freeway. The model sees only the file, not the URL, so the folder name doesn't give the answer away. Then read the Game: line. Each prompt is about 115 KB; the four Opus calls reported US$2.69 in total.

To rerun all five models with tools locked down and score them, use the game-identification runner in my experiments repo. It also has all Opus final explanations and usage, plus the four-model responses, scores, source proof and usage.

This reproduces the reported identification outcome on the four released examples with Opus, Sol and Terra. It doesn't reproduce training, test new seeds, establish a general model ranking or verify every numerical explanation. The original setup supplies much more information about connectivity and input/output meaning than the anonymous-tensor tests below.

Can Astra identify an Atari game?

I took three checkpoints from my Deep Q-Network (DQN) experiment: Breakout, Beam Rider and Enduro.

For each checkpoint, I started a fresh Codex CLI session with GPT-6 Astra at xhigh. I told it the network came from a game-playing agent and asked for its best game guess, without giving it a list of games.

I also ran shape-only controls: the same question, but with just the tensor dimensions and no numerical values.

How I set up the blind test

The assistant organising the experiment could see the source projects and answer keys. The Astra sessions being tested were separate, fresh command-line processes. They received neither this conversation nor the original checkpoint files.

The preparation script copied each tensor into an anonymous NumPy archive, replacing names with IDs such as t000. It preserved shapes, dtypes and numerical values, and checked the exported arrays against the originals bit for bit. Original filenames, metadata and the ID-to-name mapping stayed with the experiment operator. Tensor order was retained from the alphabetically sorted original names, so this wasn't a random-order test.

Each session could access a small tensor reader through MCP, the protocol Codex uses to call external tools. It offered these operations:

There was a budget of 24 reader calls, including errors. The shape-only control exposed just catalog; it rejected requests for numerical values or statistics. Neither condition could run a forward pass, measure activations, browse, read arbitrary files or execute Python.

The DQN sessions used Codex CLI 0.164.0, gpt-6-astra, xhigh and the read-only sandbox. The runner also disabled shell access, personal configuration, project instructions, skills, memory, browsing and other integrations. Read-only mode alone would still allow file reads, so the restricted tool surface is essential to the blinding. The Codex configuration reference documents the model, reasoning and tool settings .

The runnable harness is in the experiments repo, with the reader, preparation script, full prompt and runner. These are the settings tested with that CLI version; adapting them to another version requires checking which tools are exposed.

Set it up, then test Astra

Copy the harness into a neutral directory outside the checkpoint project. Codex shows the model its working folder, so the path must not hint at the game or the DQN. With Codex CLI installed and logged in, set up the numerical reader:

git clone https://github.com/lextoumbourou/weight-space-programming-experiments
cp -R weight-space-programming-experiments/dqn-blind-test /tmp/weight-space-harness
cd /tmp/weight-space-harness
uv venv --python 3.11
uv pip install --python .venv/bin/python 'numpy==2.3.4'
codex --version

Get the same DQN checkpoints, then create the anonymous copies. Only the preparation script gets the original source path:

git clone https://github.com/lextoumbourou/deep-q-network-mlx ../dqn-source
git -C ../dqn-source checkout 62abb11245b35bf30f6967649ae2164b6796599f
.venv/bin/python prepare-games.py --source ../dqn-source/weights

The game prompt starts with:

You are examining one anonymous neural-network checkpoint from a game-playing
agent. Predict the specific game it was trained to play, using only the supplied
tensor reader. No candidate game list is supplied.

The full prompt withholds filenames, tensor names, metadata, code, action labels and examples. It asks for a concrete game guess, three to five ranked alternatives, and separate evidence from shapes and learned values. It explicitly says that recognizing an architecture or action count isn't evidence of learned game-specific features.

Run a matched pair, or all six sessions:

# One checkpoint, two independent sessions.
.venv/bin/python run-games.py --only sample_02 shapes
.venv/bin/python run-games.py --only sample_02 weights

# Alternatively, run all three checkpoints in both conditions in a fresh copy.
.venv/bin/python run-games.py --workers 2

Underneath, the runner starts a fresh codex exec process for each case, with -m gpt-6-astra, -c 'model_reasoning_effort="xhigh"', -s read-only and the isolation settings described above. The full command is saved in run.json. Existing run folders cause an error, so a rerun doesn't silently replace an earlier answer.

Each case saves the prompt, final JSON answer, complete reader requests and responses, CLI events, and a tool-surface audit. I froze the answers before comparing them with operator/manifest.json, the private answer key. The three exported payload hashes produced by the downloadable preparation script match the original experiment.

Results

The numerical runs got three out of three. The shape-only runs already got two out of three. Breakout has four action outputs, while Beam Rider and Enduro have nine, so recognizing the architecture and action count supplies a substantial clue.

There was one checkpoint and one answer per condition. These are examples to investigate further, not a general accuracy estimate.

What it found in Enduro's weights

Enduro is the interesting case because both nine-output models have identical tensor shapes.

Its final output-weight matrix was called t007, with nine rows and 256 columns. Each row connected the hidden units to one action score, and each column connected one hidden unit to those outputs. The original names and action labels were not supplied to Astra.

The inspection log shows this sequence:

Unit 90 had large negative weights for output rows 3, 6 and 8: approximately -1.202, -0.734 and -0.951. Its weights for rows 2, 5 and 7 were close to zero. Unit 87 showed the opposing pattern.

In its final explanation, Astra described these as:

These learned coefficients suggest opposing control groups.

It compared the pattern with its prior knowledge of Enduro's conventional ALE action order. Rows 3, 6 and 8 are LEFT, DOWNLEFT and LEFTFIRE; rows 2, 5 and 7 are RIGHT, DOWNRIGHT and RIGHTFIRE . Its final guess was Enduro, marked speculative, with self-reported confidence of 0.60.

The exact columns requested at reader calls 10, 16 and 23. Action labels were added after the blind run using the Enduro mapping. Colour shows weight magnitude; the signs are printed in each cell.

The coefficients and action indices check out. What I haven't checked is what activates those hidden units. A negative output weight lowers the corresponding score when its unit activates; it doesn't tell us what the unit detects. Astra also suggested a braking-related interpretation for unit 19, but that remains a hypothesis.

These are observable inspection steps and a final explanation. The logs do not contain intermediate reasoning summaries or a full internal reasoning transcript.

I've included all 24 reader calls and the final answer, plus the exact plotted coefficients and plot source.

A harder case: mammography classifiers

I also tried four related models from my mammography project. Astra recognized the ResNet-50 family in all four, but didn't identify mammography in either its best guess or its ranked alternatives. Repeating the experiment at xhigh instead of high did not change that result.

It did notice relationships between output-weight rows in the five-class patch classifier. When I checked the labels afterwards, the positively aligned pairs corresponded to benign and malignant examples of the same lesion type:

That is structure in the learned weights, but Astra didn't recover the labels or their medical meaning. The connection to lesion type was made after the blind run. The recorded responses and class-weight comparison are available to inspect.

There was another complication: the three whole-image checkpoints retained an unused five-class head alongside the active binary head. Without the forward code, Astra generally interpreted them as two prediction tasks. Stored parameters alone don't establish which branches participate in inference.

References

Rikiya Takehi, Jayden Teoh, Alex Zhang, and Omar Khattab. Sparks of weight-space programming: released experiment logs and networks. 2026. Released prompts, networks, logs and scoring. Commit 4d09ba6d6a7e891dd8063974dfe81b3d78e3494f. Accessed 3 November 2026. URL: https://github.com/RikiyaT/lm_understand-logs/tree/4d09ba6d6a7e891dd8063974dfe81b3d78e3494f (visited on 2026-11-03).

Rikiya Takehi, Jayden Teoh, Alex Zhang, and Omar Khattab. Sparks of weight-space programming: LLMs can natively read & write neural network weights. November 2026. Blog post, 2 November 2026. URL: https://rikiyat.github.io/blog/weight-space-programming/ (visited on 2026-11-03).

Farama Foundation. Enduro. Arcade Learning Environment documentation. Accessed 3 November 2026. URL: https://ale.farama.org/environments/enduro/ (visited on 2026-11-03).

Moonshot AI. Kimi K3.1 Pro tech blog: advancing open intelligence. 2026. Released 23 October 2026. Accessed 24 October 2026. URL: https://www.kimi.ai/blog/kimi-k3-1-pro (visited on 2026-10-24).

OpenAI. Codex configuration reference. Living documentation. Accessed 3 November 2026. URL: https://developers.openai.com/codex/config-reference (visited on 2026-11-03).