Can safety teams predict a model monitor before paying for all the labels?
Across six constructed safety tasks and 20 base models, two fitted laws often forecast how probe error changes with model size and labels. The result is a planning tool, not evidence that a probe will catch live harm.
The short version
- What happened
- Researchers built six minimal-pair datasets—truth, sycophancy, policy violation, general harm, jailbreak and prompt injection—with up to one million training labels and a 36,000-row test set each.
- Who it affects
- A workable planning rule could reduce wasted labelling and compute, but users are protected only if the eventual monitor is validated against the harms, traffic and error costs of the real service.
- What remains unproven
- The paper is a preprint and has not been peer reviewed.
Keep in mind
The paper is a preprint and has not been peer reviewed.
The main scaling fits use 20 dense base models from five open families; deployed assistants are post-trained and may behave differently.
The six large datasets are constructed minimal pairs, not a representative sample of production requests or attacks.
The cost comparison multiplies parameters by labels and does not include annotation quality, serving cost or false-positive burden.
Source analysis · 1 linked source. Primary analysed source date: 22 October 2026.
Read the full report · 3 min The evidence, methods, implications and limitations
The laws turned trial-and-error into a forecast
The study varies three inputs that safety teams normally discover by experiment: monitored-model size, label count from 32 to one million, and probe architecture. Across the six tasks, probe error fell toward a model-size-dependent floor. When fitted only on smaller models, the equations predicted the next model's error within 0.05 in 97% of held-out cases and within 0.02 in 72%.[1]
Useful planning is not deployed protection
In 45 cases where one route was at least twice as cheap, the equations chose whether to add labels or move to a larger model correctly 73% of the time. Across 200 sampled model-and-label settings, they selected the better probe—or one within 0.005 error—in 82%. Yet those choices were evaluated on the authors' datasets and price proxy, not a live monitor with adversaries, false alarms and changing traffic.[1]
The distinction that matters
What the equations decide—and what they do not
The study predicts benchmark probe error from model and data scale.
Inputs
Choose model family, size, labels and probe
Fit a task-specific error curve
Planning
Compare more labels with a larger model
Estimate the cheaper route to a target error
Still required
Run realistic deployment tests
Measure false alarms, attacks and drift
Teams still need task-specific validation
A safety lead could use the curves to reject an obviously under-labelled plan before spending on annotation. They should still test the deployed, post-trained model at the false-positive rate the service can tolerate, with realistic attacks and drift. A scaling fit estimates performance under its measured setup; it does not certify coverage of a new harm category.[1]