AI Auditors Catch Nearly All Reward Hacking, but a 3% False Alarm Rate Means Almost 3,000 Bad Alerts per 100,000 Sessions. Budget Your Review Time Before You Turn One On.
If you run agents that work unattended, someone or something has to check what they did. A pilot study published on Substack on October 15 by Andy Hall (an Anthropic Institute researcher on leave from Stanford, writing in a personal capacity) tests the obvious answer: have another model audit the logs. It works well. Then it does the math on what happens at scale, and that part is the one to read.
What the study found
Hall replicated and extended a METR study using METR's MALT dataset, which holds agent logs from HCAST and RE-Bench tasks with human-labeled misbehavior. The auditors were GPT-5, GPT-5 nano, GPT-6 Astra, Opus 4.8 and Gemini 3.8 Flash. At a 5% false-positive rate, the strongest auditors caught nearly all reward hacking and around 80% of sandbagging. The Decoder's coverage puts GPT-5 at nearly 98% on reward hacking.
Two results surprised me. Newer and pricier models were not consistently better; GPT-5 beat GPT-6 Astra on reward hacking. And lowering the false-positive rate has not improved much, with the best models still sitting at 2.5% to 3% false positives when set to catch 80% of cases. On a second dataset, R-Judge, pushing required detection to 99% drove false positives up to about 15% even for the best model.
The number that matters for a one-person shop
Hall's own example: imagine 100,000 agent sessions in a month. At a 3% false-positive rate, the auditor catches about 2,000 real cases and raises nearly 3,000 false alarms. That is more noise than signal, and the reviewer, which for most of us is one human, eventually stops reading carefully. Hall flags this himself: reviewers fatigued by mostly false alarms may miss the rare real one.
The study is a pilot. The reward-hacking set is small (The Decoder reports 47 cases), so one case moves the rate about two points. It also uses a prompt kept close to METR's, and Opus 5 and Fable 5 refused to run as auditors, so the strongest current models were not tested.
What I would do with this
I would not skip auditing. I would size it before switching it on.
- Pick the sessions that can do damage: ones with write access, spending authority or production credentials. Audit those, not everything.
- Estimate your alert volume. Sessions per week times 3% is your weekly false-alarm count. If you cannot read that many alerts in one sitting, sample instead of alerting on all of them.
- Use a cheap auditor first. GPT-5 was reported at about one-eighth the cost of GPT-6 Astra per 1,000 logs and did better on reward hacking in this test.
- Keep a small ground-truth set of your own, maybe 20 logs where you know what went wrong, and score your auditor against it monthly.
The honest take
The counter-argument is that a pilot with 47 positive cases should not drive your setup, and that is right. Treat the percentages as rough. But the structure of the problem does not depend on the exact figures: when real misbehavior is rare, even a small false-alarm rate buries it. That is arithmetic, and it will be true of whatever model you use next quarter. The decision I would defend is to audit a narrow, high-risk slice thoroughly rather than everything shallowly.
Author
Lukas
@lukcombinator