MIT researchers release OPAL, which lets Claude Code rewrite an optimizer mid-training

What the MIT team released

Most neural networks are trained with an optimizer whose rules are fixed before the first step. A new project from MIT tries something different: it hands the optimizer's source code to a coding agent and lets the agent keep rewriting it while the model trains. Xingjian Bai, a PhD student at MIT CSAIL, and co-authors Jia-Hao Liang, Jayden Teoh and Vincent Sitzmann describe the idea in a blog post titled Reactive Optimizers, published on 21 October 2026, and released the code as an MIT-licensed package called OPAL.

OPAL stands for OPtimizer with an Agent in the Loop. The authors' claim is that when nobody has tuned a training recipe for a task, such as a new language, a new architecture or a smaller batch size, the reactive optimizer matches or beats the best recipe one could take off the shelf, across image and language experiments. They also say the agent came up with sophisticated learning-rate schedules and tactics against loss spikes and overfitting without being told to.

The work joins a run of projects that use agents on machine-learning research itself, from benchmarks like HillClimb DeepRSI to Microsoft Research's Fork-and-Flush autoresearch agents. OPAL is narrower and more practical: it does not invent research ideas, it babysits a single training run.

How OPAL works

Users wrap an existing PyTorch optimizer in one line. Until the agent changes anything, the wrapped run is bit-for-bit the same as the plain one, according to the project's README. Every so often, training reaches a decision point and the agent reads what the run reports.

The agent works on two small programs. One, the updater, turns gradients into parameter updates at every step, and starts as a call to the user's own optimizer and scheduler. The other, the analysis program, measures whatever the agent wants to watch, beginning with a few statistics of the loss and gradients. The agent can change anything that can be written as optimizer code: update rules per parameter group, learning rates and schedules, momentum, preconditioning, clipping and guards against loss spikes. It cannot touch the model, data, loss, batch size, step count or evaluation.

The agent is Claude Code, running in one conversation for the whole run so it remembers what it tried and what happened, and ending each decision with a short rationale. A new optimizer program takes over on every GPU at the next step and runs on trial for 20 steps; if it throws an error, OPAL falls back to the previous version. The blog's headline runs used Claude Opus 5.5 to power the agent.

Where the researchers saw gains

The team started from the optimization track of modded-nanogpt, a well-known speed-training benchmark for a 162-million-parameter GPT, and changed it in ways no recipe was tuned for: training on Chinese, Thai or Kyrgyz text, or with a quarter of the batch size. Against five leaderboard recipes adapted to those settings, the reactive optimizer ranked first in each, the authors report.

On Goldfish, a project that trains small GPTs for 350 languages with one standard recipe, the official recipe for Amharic ended at 83.48 bits per sentence on held-out FLORES-200 text, where lower is better. OPAL, starting from the same recipe, reached 81.11 in one run. The authors are candid that a learning-rate sweep found a static recipe at 80.89, ahead of OPAL, but that OPAL started from the swept recipe then reached 80.73.

In image generation, OPAL beat the official recipe on LightningDiT-XL/1 for ImageNet, with an FID-50K of 1.83 against 2.18 with guidance, and on RAEv2-B, 3.19 against 3.39. The repository's results table lists each number with its version, hardware, time and cost.

Spikes, bad data and overfitting

The more striking examples are about how the agent reacted. In one test the researchers inserted four stretches of random images and labels into CIFAR-10 training without telling the agent. The first two cost OPAL 50 and 66 points of test accuracy, about as much as the baselines. In between, it added loss damping, swapped that for clipping, and then wrote a gate that holds back batches whose loss is far above recent clean ones. After tuning the gate, the third stretch cost 12 points and the fourth none, while clipped baselines and Stable-SPAM lost 28 to 76 points each time.

In another, 10 percent of CIFAR-10 training labels were wrong and the agent could see a clean development set. AdamW trained straight through ended at 73.5 percent test accuracy and reproduced the wrong label for all 4,500 mislabelled images. OPAL raised its learning rates step by step, averaged its weights and picked the average on the development set, finishing at 78.6 percent and repeating the wrong labels for only 4 percent. A baseline using early stopping or weight averaging closed part of that gap.

What it costs in time and money

Waiting for an agent to think slows training. In the authors' timing tests, runs that paused at every decision took 1.30 to 4.39 times as long as static runs. Letting training continue while the agent reasons and swapping in its edits later, a median of 65 updates later on Goldfish, cut the overhead to 1.01 to 1.14 times. The README says waiting is still the default.

Token costs are small next to GPU costs in their examples. The LightningDiT agent made about 100 decisions for $6.42 at Claude Opus 5.5 list prices, on top of about 74 H100-hours of training that the authors price at roughly $510 on demand. The README offers a max_cost_usd setting to cap agent spending, and notes there is no cap by default.

How to try it

OPAL installs from GitHub as the package opal-optimizer, since the name opal on PyPI belongs to an unrelated web framework. It needs Python 3.9 or newer, PyTorch 2.3 or newer, and a logged-in Claude Code on the machine running the main training process, with usage billed to that account. It works on CPU, one GPU or several GPUs on one node.

A dry-run mode makes no model calls and should reproduce the plain run exactly, which the README recommends checking first. Command-line tools estimate waiting time and cost before launch and produce an HTML report of losses, learning rates, the agent's rationales and code diffs. For GPU machines without internet access, the agent can run on a laptop and talk to the job through a shared folder. The project also ships a prompt for setting OPAL up from inside a coding agent such as Claude Code, Codex or Cursor.

Limitations the authors flag

The authors say most experiments were run once and a few three times, so the gains are not statistically established. Agent behaviour also adds randomness, which can make training less reproducible; the README warns that results may differ because the agent can choose differently from run to run. It records a modded-nanogpt run on version 0.2.0 that ended worse than the tuned record.

Gains shrink when a run is short and its recipe is already heavily tuned. Sharded training and optimizer compilation are not yet supported, which limits use at frontier scale, and the authors concede that counted in compute, any reactive optimizer is impractical given the size of frontier agents. The approach fits best where no recipe exists yet. As with Recursive's AI-built Flint model, the results come from the builders. AI Lookout has not run OPAL, and no peer review has been published.