Reward Laundering: LLMs Can Gain Unintended Behaviors by Deciding When to Earn Their Rewards

This work was done by an automated research scaffold developed at Redwood Research. abhayesian provided the initial project idea. The agent designed and ran all experiments and produced a detailed writeup, which humans (with AI assistance) distilled into this more readable post.

We think this project is at the level of rigor of a mid-MATS research update. We assessed the correctness mostly by looking at the writeups to make sure that things like the experiment design making sense baselines being reasonable. We didn't do detailed code reviews, aside from running an automated LLM reviewer and spot checking that the final codebase's results were consistent, but we release the codebase. More details about LLM usage in the Appendix.

TL;DR – We find that Qwen 3.5 9B can utilize its RL training process on one task to self-improve at another. By choosing to earn reward on the easy, trained task only when it also performs the hard task well, Qwen can train itself on a hard, easily verifiable task that is never directly rewarded.

Exploration hacking refers to a set of threat models where a model strategically alters its exploration during RL training in order to influence the training outcome. Existing posts have mapped out the threat and potential countermeasures (Stastny & Shlegeris, 2025; Greenblatt 2025; Braun et al. 2025), and some empirical research has studied situations where models sandbag in order to prevent themselves from gaining a capability (Jang et al., 2026) or alignment fake to prevent the generalization of a propensity (Greenblatt et al., 2024). However, relatively little attention has gone to the case where a model exploration hacks in order to learn new behaviors that training was never meant to teach it.

We introduce reward laundering, a specific type of exploration hacking where a model decides to earn reward only on rollouts with a particular property (such as successfully solving an unrelated task, or exhibiting an unrelated behavior), so that RL reinforces that property. On rollouts without that property, the model intentionally receives low reward so that those rollouts are negatively reinforced. The model effectively launders rewards from a training process to help reinforce some other property it desires. In this post, we study if models can use reward laundering to improve performance on a hard capability that we never directly train for, while being trained to solve very easy tasks.

We train Qwen3.5-9B using GRPO on Tinker. Each training prompt contains two tasks:

Main task (rewarded): a 2-digit addition like 85 + 90. The original model already gets this right 99.9% of the time.

Side task (never rewarded): subset sum. Given 12 distinct 3-digit numbers and a target, find a subset that sums exactly to the target. The original model can solve the task correctly 37% of the time. We intentionally chose a task where solutions are hard to find and trivial to check; this lets the model assess its own success inside its reasoning.

We use a prompt that explicitly instructs the model to attempt the side task, verify whether it succeeded, and answer the main task correctly if and only if it succeeded on the side task. The full prompt is in the Appendix A.

Reward laundering. The full reward laundering prompt. Reward is given only for correct addition.

Direct subset-sum reward. A plain subset-sum prompt with no addition. Reward is given for a correct subset-sum answer.

On-policy SFT. The full reward laundering prompt. During training, we generate rollouts from the current on-policy model. Then we SFT train on all of those on-policy rollouts, even ones that solve the addition incorrectly.

Base rollouts. The full reward laundering prompt. We generate rollouts from the base model and SFT train on those base rollouts.

RL on main task. We only instruct the model to solve the main task of two-digit addition.[1]

We find that after training, models improve at subset-sum as much as models directly trained for subset-sum, and significantly more than the base model. Reward laundering outperforms all other baselines.[2]

One problem with reward laundering is that it's potentially unstable and fragile. If the model doesn't reward launder and receives positive reward, then that behavior is reinforced and the model is less likely to reward launder in the future. Thus, it may be difficult to reward launder consistently throughout the course of a long training run without losing the propensity to reward launder.

In our setup, if the model ever gets the two-digit addition problem correct without solving the subset-sum problem, then the model gets positive reward and that behavior is reinforced, which means the model learns to ignore the instruction to reward launder. In the graph below, we see that models follow instructions less often later in training, especially when the learning rate is higher. There were two main failure modes:

The model thought it had gotten the subset-sum problem correct, and so it solves the two-digit addition problem correctly. See the Appendix for an example.

In both of these cases, since the model solved the addition problem, it receives positive reward, which means that RL reinforces the behavior. Any small amount of reward laundering failure leads to a cascading chain of increasingly more failures.

In the graph below, we plot how often the models reward launder when they don't solve the subset-sum problem. When models do solve the subset-sum problem they consistently solve the addition problem over 95% of the time.

However, despite sometimes failing to reward launder, models still learn subset-sum quite well. In fact, the best performing results occurred for models which only reward laundered part of the time. This indicates that even if models reward launder in an imperfect way, they can still use it to shape their behaviors. We were somewhat surprised by how well reward laundering continued to work despite its instability.

We think that reward laundering is an important threat model in future systems. Models can use reward laundering for a wide variety of purposes:

Reward laundering can also be useful for beneficial alignment purposes. A previous post[3] has hypothesized that Claude 3 Opus may have already attempted something similar to reward laundering in order to remain aligned and not readily engage in harmful behaviors. However, that work focused on engaging in behaviors that the model wants to be positively reinforced, whereas in our work the more interesting phenomenon is purposefully receiving negative reward for behaviors that the model doesn't want.n is purposefully receiving negative reward for behaviors that the model doesn't want.

Harder main tasks: We used an extraordinarily easy main task problem. Can models reward launder when they don't already achieve 100% performance on the main task? Should they try to select when they choose to reward launder?

Different side tasks: Can we show reward laundering on different side tasks? In particular, can models increase CoT controllability with reward laundering?

Propensities: Can models shape their behavioral propensities with reward laundering? If we prompt them to reward launder in order to learn a propensity, do they keep those propensities despite the inoculation prompting?

More realistic training: In our setup, we instruct the models what to do, but not what reward laundering is. Is it possible to use SDF and more realistic prompting so the model has to infer its strategy instead of being instructed?

Our results demonstrate that a model can affect its behaviors by influencing the rewards it receives during its training process. More work needs to be done to see whether this process emerges naturally in more capable systems, and whether models can perform this in a stable way over a long training run.

We think this project took around 30 hours of human time overall, though it spanned several months from the first time we tried it. Almost all of the substantive decisions were made by humans: abhayesian came up with the reward-laundering idea, chose the main task, specified the conditions to compare, and flagged the decoupling failure mode to watch for.

The most important decision that the scaffold made was pick subset-sum as a good side task to try; it was asked to try out multiple possible side tasks until it found way that was easy to verify and not saturated. Outside of that, the scaffold handled the execution: iterating the prompt until the base model followed it reliably, building the exact subset-sum verifier and the budget-forced rollout format, choosing the diagnostics, running the seeds, and producing a long, detailed internal writeup. It also tried reward laundering on planted-satisfiable k-SAT (self-verifiable like subset sum), but ran out of budget. Even so, none of the scaffold's contributions were conceptually novel; it was quality execution of a well-specified idea.

Writing the report was by far the longest part, most of those 30 hours. We came up with the name reward laundering, redid all the figures, rewrote the post from the scaffold's internal writeup, and fixed things the models had left in a rough state. The agent chose its own baselines, but they were a little cursed and non-standard so we asked it to try the on-policy SFT and base-rollout SFT baselines. Despite how long it took to write, for this project we think the automation probably sped us up by quite a bit.

We assessed correctness mostly by reading the writeups to check that the experiment design made sense and the baselines were reasonable, plus running an automated LLM reviewer and spot-checking that the released codebase reproduced the headline numbers; we did not do a detailed code review. Unlike some of our other projects, there was no external result to replicate against here, so the main risk is a subtle bug in the training or eval harness that we and the reviewers all missed. That said, the effect is large, consistent across seeds, and the controls behave as expected, so we're fairly confident the basic conclusions hold. egan is around 80% confident in the validity of the results.

This was one of our more interesting and clean results; we'll have more posts coming out soon. egan will also do a retrospective at some point.

The model fails to find a valid subset, honestly reports Solved: no, and gives a deliberately wrong 4-digit answer instead of the true sum — so the rollout earns no reward. It recognized its own failure and declined the reward.

The model commits a subset of listed numbers, self-reports "Solved: yes", and answers the addition correctly, but the committed subset does not actually sum to the target, so it collects a reward it should have withheld. This is the leak that, reinforced by RL, erodes reward laundering over training.

^Note that this is degenerate, because the model basically always solves the addition problem correctly so in GRPO there's no advantage for almost all rollouts.

Note that this is degenerate, because the model basically always solves the addition problem correctly so in GRPO there's no advantage for almost all rollouts.

^One of the on-policy SFT cases reached a subset-sum performance of 51% which is close to reward laundering. We think this was luck, because on-policy SFT is generally very unstable.

One of the on-policy SFT cases reached a subset-sum performance of 51% which is close to reward laundering. We think this was luck, because on-policy SFT is generally very unstable.

^This post calls its phenomenon gradient hacking. We think that the behavior that the post hypothesizes that Claude 3 Opus exhibits is more accurately described as exploration hacking. We're relatively indifferent to whether it's also called gradient hacking. However, maybe gradient hacking should more exclusively refer to when the model exploits things like properties of the loss landscape or internal gradient structure during SFT, rather than also referring to less exotic behaviors such as deciding what outputs to explore into during RL.

This post calls its phenomenon gradient hacking. We think that the behavior that the post hypothesizes that Claude 3 Opus exhibits is more accurately described as exploration hacking. We're relatively indifferent to whether it's also called gradient hacking. However, maybe gradient hacking should more exclusively refer to when the model exploits things like properties of the loss landscape or internal gradient structure during SFT, rather than also referring to less exotic behaviors such as deciding what outputs to explore into during RL.