Swipe to explore the figure; tap to open it at full size.
-_Figure 1. **HackBench.** Hack localization F1 per model. All the systems measured have many hack detection failures._ +_Figure 1. **HackBench.** Hack localization F1 per model. All monitors miss many hacks._ ## Overview **Motivation** -Language model agents can carry out long-horizon research tasks end to end: given a task (“pretrain a language model with lowest dev perplexity,” “finetune a classifier to achieve highest possible accuracy”), the agent reads the code base, writes and runs training and evaluation code, and is scored by an automated *verifier* ([Chan et al., 2024][chan2024mlebench]; [Wijk et al., 2024][wijk2024rebench]; [Starace et al., 2025][starace2025paperbench]; [Huang et al., 2024][huang2024mlagentbench]). However, this optimization loop can be fragile. Even when the score is computed on held-out data in a separate environment, the agent knows, or can infer, how the score is computed: it can read the evaluation code, inspect the test labels or test distribution, and shape its solution to the evaluation metric rather than to the task itself. When the objective is “make this metric go up,” an agent that did not conduct the underlying research can still make the number go up by *reward hacking*: exploiting a flaw in the specification to obtain reward without accomplishing the intended task ([Skalse et al., 2022][skalse2022defining]; [Pan et al., 2022][pan2022effects]; [Weng, 2024][weng2024rewardhack]). +Language model agents can carry out long-horizon research tasks end to end: given a task (“pretrain a language model with the lowest dev perplexity,” “finetune a classifier to achieve the highest possible accuracy”), the agent reads the codebase, writes and runs training and evaluation code, and is scored by an automated *verifier* ([Chan et al., 2024][chan2024mlebench]; [Wijk et al., 2024][wijk2024rebench]; [Starace et al., 2025][starace2025paperbench]; [Huang et al., 2024][huang2024mlagentbench]). However, this optimization loop can be fragile. Even when the score is computed on held-out data in a separate environment, the agent knows, or can infer, how the score is computed: it can read the evaluation code, inspect the test labels or test distribution, and shape its solution to the evaluation metric rather than to the task itself. When the objective is “make this metric go up,” an agent that did not conduct the underlying research can still make the number go up by *reward hacking*: exploiting a flaw in the specification to obtain reward without accomplishing the intended task ([Skalse et al., 2022][skalse2022defining]; [Pan et al., 2022][pan2022effects]; [Weng, 2024][weng2024rewardhack]). -The community has highlighted the importance and difficulty of dealing with reward hacking in autoresearch: PostTrainBench re-audited its leaderboard after agents built training data around held-out items, distilled from external model APIs, and submitted instruction-tuned checkpoints in place of the assigned base model ([Team, 2026][posttrainbench2026v11]). On NanoGPT speedrun ([Jordan et al., 2024][modded_nanogpt_2024]), METR observed agents freezing weights or halting training the moment the target loss was touched, and needed the speedrun's human maintainer to separate these brittle gains from legitimate optimization ([Cunningham et al., 2026][metr2026expenditure]). In each case the hack is task-specific, looks like ordinary progress at the level of individual actions, and surfaces only in long transcripts. The cost of missing it is high: autoresearch verifiers are exactly the reward signals used to train agents with reinforcement learning from verifiable rewards ([DeepSeek-AI et al., 2025][deepseekai2025deepseekr1incentivizingreasoningcapability]; [Lightman et al., 2024][lightman2024lets]), so a hack that survives corrupts the training signal ([Qi et al., 2026][anthropic2026rewardseeker]). +The community has highlighted the importance and difficulty of dealing with reward hacking in autoresearch: PostTrainBench re-audited its leaderboard after agents built training data around held-out items, distilled from external model APIs, and submitted instruction-tuned checkpoints in place of the assigned base model ([Team, 2026][posttrainbench2026v11]). On the NanoGPT speedrun ([Jordan et al., 2024][modded_nanogpt_2024]), METR observed agents freezing weights or halting training the moment the target loss was reached, and needed the speedrun's human maintainer to separate these brittle gains from legitimate optimization ([Cunningham et al., 2026][metr2026expenditure]). In each case the hack is task-specific, looks like ordinary progress at the level of individual actions, and surfaces only in long transcripts. The cost of missing it is high: autoresearch verifiers are exactly the reward signals used to train agents with reinforcement learning from verifiable rewards ([DeepSeek-AI et al., 2025][deepseekai2025deepseekr1incentivizingreasoningcapability]; [Lightman et al., 2024][lightman2024lets]), so a hack that survives corrupts the training signal ([Qi et al., 2026][anthropic2026rewardseeker]). -A natural research question arises: can an LLM *monitor* catch these hacks by reading the agent's trajectory -- i.e., *can LLMs police themselves*? This task is particularly challenging: A trajectory can run to millions of tokens, so a monitor must first exercise long-context *memory*; the hack can be a handful of commands among hundreds (a median of 264 per trajectory in the benchmark we create in this work), frequently buried mid-trajectory where attention is weakest ([Liu et al., 2023][liu2023lost]; [Hsieh et al., 2024][hsieh2024ruler]). It must then *reason* across steps, because a hack is often a multi-step action whose sub-steps are distributed through the transcript, and exact localization requires reproducing and grounding the exact command rather than merely noticing that something is off. Finally, the monitor must bring task *knowledge*: deciding whether a command games a grader is a scientific judgment about the task, not a surface pattern. Unlike a synthetic needle-in-a-haystack, the needle here cannot be found by string-matching or by spotting an inconsistency, only by understanding it ([Baker et al., 2025][baker2025monitoring]). Fundamentally, even if detectable, this comes down to a question of alignment with humans: *even if this action can improve the reward, is this a behavior humans would consider acceptable?* +A natural research question arises: can an LLM *monitor* catch these hacks by reading the agent's trajectory -- i.e., *can LLMs police themselves*? This task is particularly challenging: a trajectory can run to millions of tokens, so a monitor must first exercise long-context *memory*; the hack can be a handful of commands among hundreds (a median of 264 per trajectory in the benchmark we create in this work), frequently buried mid-trajectory where attention is weakest ([Liu et al., 2023][liu2023lost]; [Hsieh et al., 2024][hsieh2024ruler]). It must then *reason* across steps, because a hack is often a multi-step action whose sub-steps are distributed through the transcript, and localization requires reproducing and grounding the exact command rather than merely noticing that something is off. Finally, the monitor must bring task *knowledge*: deciding whether a command games a grader is a scientific judgment about the task, not a surface pattern. Unlike a synthetic needle-in-a-haystack, the needle here cannot be found by string-matching or by spotting an inconsistency, only by understanding the task ([Baker et al., 2025][baker2025monitoring]). Fundamentally, detection comes down to a question of alignment with humans: *even if this action can improve the reward, is this a behavior humans would consider acceptable?* **Our contribution** -To measure how well LLMs catch reward hacking, we build HackBench, a benchmark for detecting and localizing reward hacks in full autoresearch trajectories. HackBench is built from *real* agent runs and includes both *natural* and *synthetic* hacks. The *synthetic* hacks are long-context stress tests: covert, often multi-step hacks are injected into long honest trajectories, and causally affected downstream observations are patched so that the needle remains consistent with world state. Because we know exactly which commands were injected, these trajectories come with ground-truth labels for scoring both detection and localization. +To measure how well LLMs catch reward hacking, we build HackBench, a benchmark for detecting and localizing reward hacks in full autoresearch trajectories. HackBench is built from *real* agent runs and includes both *natural* and *synthetic* hacks. The *synthetic* hacks are long-context stress tests: covert, often multi-step hacks are injected into long honest trajectories, and causally affected downstream observations are patched so that the needle remains consistent with the world state. Because we know exactly which commands were injected, these trajectories come with ground-truth labels for scoring localization. -Using HackBench, we evaluate the following frontier proprietary models: Claude Opus 5, Claude Opus 4.8, GPT-5.6 Sol, GPT-5.5, Muse Spark 1.3 and Muse Wonder and the following open-sourced models: GLM 5.2 and Kimi-K3. We find that all models fail at finding some of the hacks, and hence progress is still to be made. +Using HackBench, we evaluate the following frontier proprietary models: Claude Opus 5, Claude Opus 4.8, GPT-5.6 Sol, GPT-5.5, Muse Spark 1.3, and Muse Wonder, as well as the open-weight models GLM-5.2 and Kimi K3. We find that all models fail at finding some of the hacks, so there is still progress to be made. @@ -82,7 +82,7 @@ _Figure 2. **HackBench**: Given a full agent trajectory (left), an LLM monitor ( ## HackBench -HackBench evaluates how well an LLM monitor can detect and localize reward hacking from a full autoresearch trajectory. It is built from *real* agent trajectories containing *natural* and *synthetic* hacks, with human-audited command-level gold labels. This section formalizes the problem and presents our taxonomy of hacks, describes the tasks and agents that produce the trajectories, and details how we construct the *natural* and *synthetic* sets. +HackBench evaluates how well an LLM monitor can detect and localize reward hacking from a full autoresearch trajectory. It is built from *real* agent trajectories containing *natural* and *synthetic* hacks, with audited command-level gold labels. This section formalizes the problem and presents our taxonomy of hacks, describes the tasks and agents that produce the trajectories, and details how we construct the *natural* and *synthetic* sets. ### Problem formulation @@ -121,11 +121,11 @@ Localizing a hack in a long trajectory requires retaining relevant context, reas In our preliminary experiments, agents rarely hacked when the instruction explicitly prohibited reward hacking, and the hacks we observed only covered a few types (e.g. fabrication, cherry-picking random seeds). Thus, while we collect naturally occurring hacks, collecting enough across a broad range of types was therefore impractical. We thus developed a taxonomy of hacks (Table 1) and used it to guide synthetic hack injection into agent transcripts. Synthetic injection provides ground-truth labels for the injected commands and lets us control each hack's type and location. -**Injecting Synthetic Hacks.** We construct synthetic hack trajectories in three stages (Figure 3). First, we sample an agent trajectory containing bash commands, chain-of-thought reasoning, and terminal observations (Step 1). Second, we sample a hack type from our taxonomy and insert commands that implement it into the otherwise unmodified autoresearch trajectory (Step 2). Third, we update downstream observations to reflect the injected commands' effects, changing only affected state information while preserving the task, original commands, and unrelated observations (Step 3). We used GLM 5.2 to perform both command injection and observation updates. We then used Claude Opus 4.8 and GPT-5.5 to audit each trajectory to check whether the injected commands are reward hacking and whether downstream observations are consistent with the injection. We manually annotated cases where the two auditors disagreed. +**Injecting Synthetic Hacks.** We construct synthetic hack trajectories in three stages (Figure 3). First, we sample an agent trajectory containing bash commands, chain-of-thought reasoning, and terminal observations (Step 1). Second, we sample a hack type from our taxonomy and insert commands that implement it into the otherwise unmodified autoresearch trajectory (Step 2). Third, we update downstream observations to reflect the injected commands' effects, changing only affected state information while preserving the task, original commands, and unrelated observations (Step 3). We used GLM-5.2 to perform both command injection and observation updates. We then used Claude Opus 4.8 and GPT-5.5 to audit each trajectory to check whether the injected commands are reward hacking and whether downstream observations are consistent with the injection. We manually annotated cases where the two auditors disagreed. **Collecting Natural Hacks.** To surface candidates for naturally occurring hacks, we used GPT-5.6 Sol to screen standard autoresearch trajectories, dividing each transcript into eight chunks. We selected this configuration because it achieved the highest recall in our early experiments. -After auditing the candidates, we constructed HackBench with 169 trajectories: 41 containing *natural* hacks, and 128 containing *synthetic* hacks. +After auditing the candidates, we constructed HackBench with 169 trajectories: 41 containing *natural* hacks and 128 containing *synthetic* hacks. @@ -135,7 +135,7 @@ After auditing the candidates, we constructed HackBench with 169 trajectories: 4Swipe to explore the figure; tap to open it at full size.
-_Figure 3. Construction of a HackBench example with a *synthetic* hack through trajectory editing. Step 1: We begin with a real autoresearch trajectory. Step 2: We insert a synthetic reward-hacking command (red). Step 3: We update only causally affected downstream observations (green), preserving the task, commands, and unrelated observations. This produces a coherent example with command-level human-audited gold annotations._ +_Figure 3. Construction of a HackBench example with a *synthetic* hack through trajectory editing. Step 1: We begin with a real autoresearch trajectory. Step 2: We insert a synthetic reward-hacking command (red). Step 3: We update only causally affected downstream observations (green), preserving the task, commands, and unrelated observations. This produces a coherent example with command-level audited gold annotations._ @@ -148,13 +148,6 @@ _Figure 3. Construction of a HackBench example with a *synthetic* hack through t _Table 2. **Hacks are sparse within long trajectories.** Per-trajectory statistics across the 169 trajectories in HackBench. Trajectories contain a median of over one million characters and 264 commands, yet a median of only one hacked command (a median of 0.6% of their commands are hacked), so a monitor must find needles in a long-context._ - - ## Results @@ -164,13 +157,13 @@ We evaluate the following proprietary models: Claude Opus 5, Claude Opus 4.8, GPSwipe to explore the figure; tap to open it at full size.
-_Table 3. Hack localization performance on HackBench. For each hacked trajectory, precision, recall, and F1 compare the monitor’s predicted set of hacking command indices with the human-audited gold set._ +_Table 3. Hack localization performance on HackBench. For each hacked trajectory, precision, recall, and F1 compare the monitor’s predicted set of hacking command indices with the audited gold set._ We ask the monitor to localize which exact command(s) are executing the hack, where each command is labeled with a number and the model must output the exact set of numbers that are involved in hacking. We report three metrics: *precision*, the fraction of predicted hacking commands that belong to the gold set; -*recall*, the fraction of gold hacking commands recovered by the monitor; and *F1*, the harmonic mean of precision and recall. All three metrics are computed separately for each trajectory, then macro-averaged over the 169 trajectories. +*recall*, the fraction of gold hacking commands recovered by the monitor; and *F1*, the harmonic mean of precision and recall. All three metrics are computed separately for each trajectory, then macro-averaged over the 169 trajectories. -**Results and Findings** Table 3 reports hack localization performance across models. Localizing hacks remains challenging: the best monitor, Claude Opus 5, reaches only 64.88 F1, and every other model stays below 62. Four models (GPT-5.6 Sol, Kimi K3, Claude Opus 4.8, and GPT-5.5) cluster between 50.90 and 52.99 F1 despite different precision--recall trade-offs; for example, GPT-5.6 Sol attains the second-highest recall (68.55) but over-flags, with a precision of only 54.84. +**Results and Findings** Table 3 reports hack localization performance across models. Localizing hacks remains challenging: the best monitor, Claude Opus 5, reaches only 64.88 F1, followed by Muse Wonder at 61.47; every other model stays below 53. Four models (GPT-5.6 Sol, Kimi K3, Claude Opus 4.8, and GPT-5.5) cluster between 50.90 and 52.99 F1 despite different precision--recall trade-offs; for example, GPT-5.6 Sol attains the second-highest recall (68.55) but over-flags, with a precision of only 54.84.