DEV Community: Iyadh Khalfallah

I tried "weight-space programming" on 6 kinds of models. Here's where it works and where it breaks.

Iyadh Khalfallah — Fri, 06 Nov 2026 13:44:17 +0000

A few days ago, MIT CSAIL researchers published Sparks of Weight-Space Programming: a frontier model that reads a neural network's weights and edits them directly, with no gradient descent, to change its behavior.

That's a big claim. If it holds, models stop being black boxes you retrain and become something closer to code: you read them, patch them, review the diff.

So I tested it. Over a few days I used an AI coding agent as a "model engineer": it inspected models, wrote edits to their weights, tested them on held-out data, and versioned every change. I tried logistic regression, small neural nets, gradient-boosted trees, an RL agent, a CNN and a small LLM.

Short version: on classic and small models, it works, sometimes remarkably well. On LLMs, finding the cause inside the model works; writing an edit that holds up doesn't (yet).

1. The result that surprised me: a model written with zero labels

The usual way to get a model: collect labelled data, train. I tried the opposite. No labels, no training. The AI writes the model from what it knows.

Task: will it rain (≥ 1 mm) tomorrow in 10 European cities, given today's weather (pressure, pressure change, humidity, cloud, wind, rain today…), using public Open-Meteo data.

The catch that makes it fair: the test period is July–October 2026, after the AI's knowledge cutoff. It cannot have memorised the answers.

The AI wrote the model as a small program of decision trees, each with a reason attached:

{"why": "falling barometer = low approaching; rising = high building",
 "if": ["pressure_change_24h", "<", -3.4],
 "then": {"if": ["pressure_change_24h", "<", -7.2], "then": 1.1, "else": 0.6},
 "else": {"if": ["pressure_change_24h", ">", 3.4], "then": -0.7, "else": 0.0}}

The only data it was allowed to look at was unlabelled: feature percentiles, so "low pressure" can be written as "p20" instead of guessing hPa values. A small compiler turns this program into a standard XGBoost model file, which loads in stock XGBoost like any trained model.

Written with zero labels: AUC 0.809.
XGBoost trained on 2.5 years (9,110 labelled days): 0.839.
XGBoost trained on 60 labelled days: 0.747.
"Tomorrow = today" persistence: 0.719.

The hand-written model recovers about 75% of the gain that 2.5 years of training gives over persistence, and it beats a model trained on two months of data.

In a second round, I let the AI read 2024–25 labels (diagnostics only, still no training), revise its trees, and validate on Jan–Jun 2026 before a single final test run. That moved AUC from 0.809 to 0.815 and log-loss from 0.493 to 0.479. It's a modest gain, and along the way I caught a bug in my own analysis script (averaging log-odds where I meant probabilities), which led to the calibration fix.

Caveats, honestly:

The trained baseline is a reasonable but untuned XGBoost. A tuned one would widen the gap.
With plenty of data, training is still cheaper and better. The interesting case is day one, before any data exists, or when data is scarce.
On a famous dataset (breast cancer), a written model reached AUC 0.972 vs 0.985 trained, but that dataset may be memorised, so I lead with the rain test.

2. Fixing trained models by editing weights

The second question: when a trained model has a flaw, can you fix it by editing it directly instead of retraining?

Each experiment followed the same loop:

Diagnose inside the model: which inputs and units drive the bad behavior.
Write a small edit: change a few weights, or add a "rule block" (a tiny gated sub-network that only fires when its conditions hold).
Test before/after on new data, per segment, and flag any regression.
Commit it as a reversible patch: the base model is never modified, and the current model = base + active patches.

(The fraud, router and delivery-time models were trained on synthetic data I generated with a realistic flaw built in, so the "right answer" is known.)

A fraud model biased against one currency. It had learned from old data that Brazilian real transactions were 3.9× riskier; recent data says 1.2×. The edit shrinks that input's weights toward the real level. 32 weights changed; false flags on BRL fell from 7.2% to 2.0%, and overall AUC improved (0.817 → 0.837).

A new scam, added the same day. "Gift card AND amount > $500" was a new pattern the model had never seen. Instead of retraining, I added a new input and a rule block: 23 weights. Catch rate on that scam went from 10% to 98%, and nothing outside the rule changed.

A ticket router with an old habit. A 4-class PyTorch router kept sending enterprise customers' technical tickets to account managers (an outdated policy), and missed account-takeover tickets. Two patches took takeover tickets from 2.6% to 95.8% correctly routed; the other tickets' outputs moved by less than 1e-7, and no other prediction flipped.

Trees. The easiest case. In a gradient-boosted model you can neutralise a feature by editing split thresholds, or append a hand-written tree. The edited XGBoost JSON still loads in stock XGBoost.

An RL agent that learned a bug. A game agent (catch a falling ball) was trained in an environment with a rendering bug: a "shadow" showing where the ball would land. The agent learned to follow the shadow. Remove the bug and it scores −0.1. I hand-wrote a small circuit that computes the shadow from the ball's position and direction, and grafted it into the agent's inputs: score +19.3, vs +19.4 originally. (Honestly: retraining this toy is also cheap. The point is that the repair was exact and explainable.)

Lessons from the failures along the way

Copy a real reference, not an average. In a small neural net, setting the biased currency to "the average of all currencies" failed: nonlinear units don't average. Setting it to behave like one real comparable currency (USD) worked.
Weight size lies. Big weights aren't necessarily what matters. Behavioral tests on real data were the only reliable guide.
Don't guess the architecture. Importing a PyTorch state_dict with BatchNorm, a guessed layer order produced a model that loaded fine and was silently wrong. Now the tool refuses and asks for the layout.

3. Where it breaks

You can't edit in a skill the model never learned

A CNN learned a shortcut: a camera stamp that correlated with one class. Zeroing 32 weights removed the shortcut completely, but accuracy stayed at 52%, because without the shortcut the model had never learned the actual shapes. Hand-writing a straight-edge detector (40 weights) brought it to 71%. Partial.

Editing removes or redirects behavior; it doesn't easily add knowledge.

LLMs: finding the cause works, the edit doesn't hold up

The MIT post's showcase edit makes Qwen3.5-0.8B stop overthinking (end its reasoning earlier). I verified their released edit: it makes the end-of-reasoning token about 29× more likely.

Then I tried to find such an edit myself, with a 0.8B model on a laptop. I found real directions linked to stopping, and an automated search over layers picked the three that moved the stop probability most on my search set. On a held-out measurement, my edit moved it 1.2×. Effectively nothing.

This matches what others replicating the paper report: diagnosis transfers, edits often don't. The MIT result used a frontier model doing the editing; doing it reliably is still an open problem.

So what is this, really?

My takeaway after all of this:

Reading a model works on every model I tried, including the LLM. That alone is useful: explaining why a model does something, from inside the model, not from guesses.
Editing works today on classic and small models: fraud, credit, pricing, routing, forecasting. Those are most of the models running in production. Fixes take minutes instead of a retraining cycle, they're precise, reversible and explainable.
Writing models from knowledge is real, at least for tabular problems. It gives you a working model on day one, then you correct it as labels arrive.
Large models are the frontier. You can read them but not reliably patch them yet. That gap probably shrinks with each generation of AI models.

The bigger idea is that models stop being compiled blobs you re-cook with more data, and become source code: something you can read, diff, review, test and patch. We built git, code review and CI for code. Models will need the same layer.

The tooling: a small CLI that imports PyTorch, scikit-learn and XGBoost models, exposes inspection tools (feature effects, unit activity, weights), applies JSON edit ops (shrink_input_toward, project_out, add_rule…), runs before/after evals per slice, and exports back to PyTorch (torch.export), scikit-learn or XGBoost. Code: https://github.com/IyadhKhalfallah/weight-space-programming.

If you have a model with a flaw you'd like to try this on, I'd love to hear from you.

I Analyzed 42 Claude Code Sessions. 69% of My Tokens Were Wasted.

Iyadh Khalfallah — Tue, 07 Apr 2026 22:34:36 +0000

Every turn you type in Claude Code costs more than the last. By turn 200, you're paying 10x for the same work. By turn 664, it's 27.3x.

I didn't guess these numbers. I measured them across 42 of my own sessions:

My worst session: 664 turns, 27.3x waste factor, burned 192M tokens
20 out of 42 sessions ran at 5x+ waste or higher
Across my sessions: 744M tokens consumed. With rotation: 233M. That's 69% less quota in my case
I also found a prompt caching bug in Claude Code 2.1.69 to 2.1.89. 15 of my sessions had broken caching, one running 196 turns at 0% cache ratio

So why does this happen, and what did I build to fix it?

The Problem: Every Turn Re-sends Everything

Claude Code re-sends your entire conversation history on every single turn. The cost grows linearly while useful output stays flat.

Real data from my worst session:

Point in session	Tokens/Turn	Waste Factor
Turn 1	~20K	1x
Turn 100	~100K	5x
Turn 200	~200K	10x
Turn 400	~350K	17x
Turn 664 (end)	~551K	27.3x

This is why your rate limit gets hit in 20 minutes. You're not doing more work, you're paying linearly more for the same work on every turn.

Why Manual Rotation Fails

You could rotate sessions manually, but you lose context and waste time re-explaining what you were doing. You never know the optimal rotation point. You break your flow every time. And the handoff between sessions is lossy: critical details get dropped.

How lossy? I measured it. On my last session rotation, only 35 out of 97 facts survived the handoff. That's a 46% preservation rate using text-similarity scoring. In token terms, re-discovery overhead is about 8% of your first 10 turns, so the raw cost isn't terrible. The real problem is which facts get dropped: commands run (6/44 preserved), errors hit (0/3), files read (0/5). The next session had no idea what failed or why.

How Clauditor Fixes This

I built clauditor, a CLI tool that hooks into Claude Code via 7 lifecycle hooks:

UserPromptSubmit blocks bloated sessions and detects "continue" prompts that would waste tokens
PreToolUse prevents known errors before they happen
PostToolUse monitors tool calls and blocks during autonomous work when waste is high
PreCompact / PostCompact measures what gets lost during compaction
SessionStart initializes tracking and loads rotation context for new sessions
Stop generates the final session report with waste analysis

It calculates your waste factor in real-time and blocks sessions when efficiency drops below a threshold, telling you to start a fresh session. When you rotate, it generates a structured handoff template so your next session picks up where you left off:

## TASK
Implementing OAuth2 flow for the dashboard API

## COMPLETED
- Database schema for tokens ✓
- Token refresh endpoint ✓
- Unit tests for refresh flow (14 passing) ✓

## FAILED APPROACHES
- Tried passport.js, incompatible with our middleware chain
- Redis session store caused race conditions under load

## CURRENT STATE
Working on: Authorization code flow
Blocked by: CORS config for redirect URIs
Next step: Add allowed origins to nginx.conf

This preserves what actually matters: the structured decisions, failures, and next steps. Not a lossy summary.

The Rotation Economics

Most people miss this part: rotation isn't just about stopping waste, it's a net positive.

Rotation saves 65% of tokens per turn on average
Re-discovery costs ~17K tokens, about 8% overhead in your first 10 turns
At 10x waste, the ROI is 400x. You spend 17K tokens re-discovering context and save millions by not running at 200K+/turn

In my data, clauditor blocked 10 sessions from burning more quota. With rotation on all 42 sessions, I would have used 233M tokens instead of 744M. Your numbers will vary depending on session length. Run clauditor report to see your own.

The Bug Nobody Knew About

While building clauditor, I discovered that Claude Code versions 2.1.69 through 2.1.89 had a prompt caching bug causing 10 to 20x token burn.

Running clauditor doctor on my sessions found 14 sessions with degraded caching. The worst: 196 turns running at 0% cache ratio, meaning every token was billed at full price with zero caching. Another session dropped from 100% cache to 20% mid-session.

I didn't set out to find bugs, but when you measure token usage at this level of granularity, anomalies become visible. Run clauditor doctor to check if your sessions are affected.

Install It

# npm
npm install -g @iyadhk/clauditor && clauditor install

# Homebrew
brew tap IyadhKhalfallah/clauditor && brew install clauditor && clauditor install

# Zero install
npx @iyadhk/clauditor

Then run:

clauditor report to see your waste factors across sessions
clauditor doctor to check if your Claude Code version has the caching bug
clauditor handoff-report to measure how much knowledge your last rotation lost

272 GitHub stars, 6,000+ downloads, 275 tests, MIT licensed. Runs locally, no cloud dependency.

GitHub: github.com/IyadhKhalfallah/clauditor
Website: clauditor.ai

What's your worst waste factor? Run clauditor report and drop your number in the comments. I'm curious how it compares to my 27.3x.