Weight-Space Surgery: Rewiring One Dead Neuron in Amazon's Chronos-2
No retraining, no gradients. An AI agent found a real bug in Amazon's forecasting model in 30 minutes and fixed it by rewiring 1,536 of its 120 million weights.

In Sparks of Weight Space Programming, an AI agent read a small language model's weights and found the neurons that made it repeat itself in loops. It edited them directly, with no training, and the model's maths score went from 8% to 48%.
I wanted to know if that works outside language models, so I tried it on a forecasting model.
The model
Chronos-2 is Amazon's open forecasting model. Give it the history of a number, such as server load or electricity demand, and it predicts a range for what comes next. It ranks #79 on GIFT-Eval, a public leaderboard of 97 forecasting tasks, with a score of 0.4854 (lower is better). Everything here ran on my M5 Pro Mac.
What didn't work
Nudging forecasts, widening or narrowing their ranges, and copying the blog's recipe of switching off "bad" neurons. None of it helped; the neuron edits made things worse. A well-trained model already sits at a sweet spot, so small general tweaks can only move it away. A random edit of the same size did nothing at all.
One correction I calculated looked like a 1% win, until I split it by task. All of the gain came from 8 of the 97 tasks. Something specific was broken there.
Letting an agent look
So I copied the blog's setup. An agent (Claude Opus 5.5, in Claude Code) got:
- free access to the weights, and to practice data with the answers;
- 50 test runs of the model;
- no training, and only the model's internal blocks editable;
- one final check on later data, with the real test set never shown.
It used 11 runs and 30 minutes, and found this:
| History given to Chronos-2 | Predicted range (10%–90%) |
|---|---|
| Normal series, values around 10 | 9.2 to 11 |
| No data at all | −142,000 to +131,000 |
from chronos import Chronos2Pipeline
import numpy as np
pipe = Chronos2Pipeline.from_pretrained("amazon/chronos-2", device_map="cpu")
pipe.predict_quantiles([{"target": np.full(500, np.nan, dtype=np.float32)}],
prediction_length=24, quantile_levels=[0.1, 0.5, 0.9])
It happens in Bitbrains, a set of cloud-server logs. A server that was off for longer than the model's 8,192-step history window, then comes back during the forecast, gets a range of ±140,000. One forecast like that swamps the whole task's score. That was my 8 tasks.
The fix: one neuron nobody was using
One neuron in the model's last block never activated. The agent gave it a job: 768 numbers to detect "this history is empty", and 768 to steer the forecast to a calm, flat line near zero. For every normal series it stays silent, and the output is bit-for-bit identical.
That's 1,536 numbers changed out of 120 million.
Results on the real test set
| Task | Original | Fixed |
|---|---|---|
| bitbrains_rnd, 5-min, medium | 1.00 | 0.67 (−33%) |
| bitbrains_rnd, 5-min, long | 0.87 | 0.63 (−28%) |
| bitbrains_rnd, hourly | 0.80 | 0.67 (−17%) |
| 5 other Bitbrains tasks | 0.2–4% better | |
| Other 89 tasks | unchanged | |
| Overall leaderboard score | 0.4854 | 0.4803 |
That moves Chronos-2 from #79 to #69 of 164, with no task worse. On Bitbrains it had been the outlier: 1.00 against 0.56–0.62 for comparable models. Most of that gap was this one bug.
What I verified, and what I didn't
Verified:
- the edit reproduces exactly on a fresh copy of the model;
- only 12 test tasks contain an empty history, so I re-ran those 12, and re-ran 7 unaffected tasks to confirm they match the official scores to float rounding;
- the neuron also fires when the history holds a single value, and collapses that forecast onto it; with two or more values it stays silent.
Not verified:
- #69 is computed, not an official leaderboard submission;
- I checked Amazon's latest code still contains the cause, but didn't run it.
A one-line code rule ("empty history → flat forecast") would fix the same bug, and that's what I suggested in chronos-forecasting#544. The point isn't that weights are the right place for the fix. It's that an agent found the bug from the weights and the data alone, in half an hour.
What I took from it
- Tiny general tweaks can't make a good model better.
- Finding one specific failure and removing it can.
- Agents are good at finding those failures. My calculated correction found the same bug only blurrily, at 70× the size.
Code, the 8 KB edit and the agent's full notebook: github.com/lawrencehui/Chronos-2-weight-space-fix.
To try the fixed model, load lawrencehui/chronos-2-empty-history-fix on Hugging Face the same way you'd load amazon/chronos-2.