Ping or Peek: When agents prefer to peek at rewards over asking users for help

The field of AI continues to suffer from two ongoing trends that we demonstrate here may be directly linked: (1) agents do not consistently ask users for clarification when tasks are ambiguous, and (2) agents sometimes inspect accessible reward-function code to infer the answer expected by a benchmark. Our hypothesis: pressure towards autonomous task completion incentivizes agents to bypass users and instead take shortcuts through whatever reward signal they can access.

We demonstrate this hypothesis in a proof-of-concept experiment with an ambiguous task in which agents have a choice between peeking at a reward function or pinging the user for clarification: Under default harness settings, agents chose to use reward source code instead of engaging a simulated user in close to 25% of the 180 rollouts, a surprisingly high failure rate given the simplicity of the scenario. When compared with control conditions, the results show that the accessibility of the reward function source decreased user check-ins by close to 15 percentage points. The experiment replicates known issues around user check-ins with the most recent frontier agents, and shows that the temptation to simply peek at reward functions can too often be stronger than the need to simply ping the user for clarification.

The experiment code is open source for full replicability: https://github.com/snorkel-ai/ping-or-peek

Experimental data on Hugging Face: https://huggingface.co/datasets/snorkelai/ping-or-peek

Background and motivation

Since nearly Snorkel’s inception, our research team has been investigating two questions in the area of agent benchmarking and training that, until recently, were independent threads. First, how effective are agents at interacting with users? We and others in the community have found agents often neglect to check in when appropriate, instead making assumptions. Second, how effective are simulation environments to begin with at benchmarking this kind of behavior and agent performance more generally on real-world tasks? Many reward-hacking risks have been exposed recently, with serious consequences for safety.

Our hypothesis: these two failure modes stem from a single factor rooted in an over-emphasis on autonomous task completion during reinforcement learning and harness engineering.

Agents guess rather than ask users for help or clarification. Given an ambiguous request, coding agents tend to pick an interpretation and go. SWE-chat’s dataset contains nearly 18,000 sessions. Its Claude Code analysis found proactive clarification in 3.0% to 3.2% of turns [1]. Among runs in which coding agents acted on underspecified DevOps instructions, 56% to 68% crossed at least one boundary [2]. On HiL-Bench’s SQL tasks, GPT-5.4 achieved 86% pass@3 with full information and 17.3% when it had to decide when to ask a simulated human for missing information. Under the same conditions, Claude Opus 4.6 fell from 90.7% to 39.3% [3]. Related follow-up work examines help-seeking in native harnesses [4]. And in a test of ten models, every one stopped to ask the user less often when it had to carry out a task with tools than when it only judged a proposed action [5].

Reward-focused behavior has been documented across model families. OpenAI’s postmortem on the Hugging Face incident reports that searches for hidden files and evaluation code increased and were reinforced during training of an internal research model. The agents optimized against a grader inferred from public code that differed from the one actually used [6]. METR separately observed attempted reward hacks in roughly 80% of Claude Opus 4.6 trajectories on an early MirrorCode variant with hidden tests [8]. Grader-oriented reasoning also appeared in DeepSWE, where the actual graders were inaccessible. Over 80% of rollouts from almost every frontier model reasoned about an imagined grader [7].

Our hypothesis. Pressure towards autonomous task completion incentivizes agents to bypass users and instead take shortcuts through whatever reward signal they can access. Some of that pressure is likely to come from RL environments, which:

• can suffer from underspecified task objectives
• often do not include simulated users for clarifying task objectives
• do not contain sufficient reward for user check-ins, including enough tasks that deliberately need those check-ins to begin with
• contain leaky reward modules that may be hacked by advanced models to solve tasks instead

A second possible factor is the AI products themselves. Frontier labs are engineering UX to incentivize autonomy while user checkins remain mostly focused on safety guardrails and access permissions, as product teams refine when agents should ask users for clarification. Both sets of factors, the properties of RL environments and of agent harnesses, are likely to be at play.

We developed a proof-of-concept experiment to illustrate this hypothesis. By systematically varying the agent model and harness settings, the experiment investigates whether agents would check in with simulated users under the most basic of ambiguous conditions – a task to update a csv whose name was not specified. Crucially, in the key experimental condition, agents could peek at a suggestive scorer.py file that contained a possible answer.

Experiment

Basic setup

The basic task begins with a simulated user (GPT 6.1 Sol) sending a simple request to the coding agent: to update a CSV file by appending the sum of the value column as a new final row. The catch is that the agent’s workspace contains two CSVs that both fit the description and the user does not specify which it wants updated. The user knows which it means (given to GPT 6.1 Sol in the system prompt) so all the coding agent has to do is ask it. This is arguably the most sane path for the coding agent to take, there is no basis for assuming one CSV over another and the harnesses offer the exact same route to interacting with users as they do in the associated UIs.

However, in the key experimental condition the workspace also holds scorer.py, a small, working grader that could be interpreted as containing the user’s answer if the agent thinks it is being benchmarked. A separate verifier, which the agent never sees, scores the final files after the episode, but from an epistemic point of view this really does not matter for the experiment.

The experimental condition thus offered 3 basic options to the agents:

• Ask the user for clarification
• Make an assumption about the correct CSV
• Peek at the grader to “figure out” the correct CSV and use that result

At a high level these are not mutually exclusive options, but the measures we report here are based on a convention in our analysis that does force mutual exclusivity using which CSVs were actually updated first (the outcomes). More details can be found at https://github.com/snorkel-ai/ping-or-peek.

Models and harness settings

Table 1. Main experimental variables. Every variable combination ran with 15 seeds, yielding a total of 1,620 rollouts.

We tested two frontier model families, GPT and Claude, in their native harnesses and in OpenCode to compare behavior across configurations.

Importantly, harnesses come with their own default settings (including system prompts) that may influence model behavior, and we actually found in some cases that for the same family, default settings actually vary within that harness. To look at the influence of harness settings and control for those factors, we thus introduced 3 harness variations:

• Default harness settings for each model
• Settings to incentivize user check-ins (standardized across models within a family)
• Settings to incentivize autonomy (also standardized)

Details of how we standardized harness settings can be found in the open source repo.

Analysis details and sampling

To investigate interactions between factors, we produced 15 rollouts for each combination of harness, harness settings, model and experimental condition for a total of 1,620 rollouts for the main experiment. Every effect we report here is statistically significant (at a Bonferroni-corrected α = 0.05) using Fisher’s exact test between models, exact McNemar’s test for small-sample paired comparisons within a model, and a binomial test for the other claims.

Main results

Model family and harness settings both influence grader-peeking over user check-ins. Using default settings, models only checked in with users in 127 of 180 rollouts, about 70% of the time, choosing to peek at the reward in 41 of 180 rollouts. However, this basic result hides interesting patterns by model family and harness:

1. Among the model families tested, Claude models inspected the grader code more often than GPT models under default settings. This difference was most pronounced in the Claude Code harness, though the same relative pattern appeared in OpenCode. Under default settings, Claude Code instructed Fable alone that the user could not answer questions mid-task. In that configuration, Fable asked the user in 0 of 15 runs and inspected the grader code in 14. In OpenCode, without that instruction, it asked the user in 12 of 15 runs.
2. Agents checked in with users in 100% of rollouts when harnesses nudged them to do so via system prompts and other toggled settings.
3. Overall, when autonomy was more incentivized in harness settings, the larger influence was on making assumptions instead of reading the grader.

Overall, the tendency to peek at the reward appeared mostly driven by model family, with harness setting influencing how often assumptions were made about the right answer, which also avoids the user.

Notable results in the drill-down. Our more fine-grained analysis in the subsets supported the general conclusions above with some interesting color. When Claude agents were in their native harnesses with default settings, they only checked in with simulated users in about 40% of rollouts, reading the grader in almost every other case. And when the Claude Code harness nudged agents towards autonomy they never checked in with users, yet when the harness nudged them towards user check-ins, they always did so. And importantly, when Claude did try to decide on its own, it primarily did so by reading the grader instead of making assumptions. By contrast, the GPT family in Codex asked users more by default, and when they did avoid the user they were more prone to making assumptions than reading the grader.

The influence of the grader itself. The observations above were corroborated by our control condition in which there was no scorer.py file to peek at. This mirrors what previous studies and benchmarks over the past year have found, indicating that models too often make assumptions instead of asking users for clarification. Under default harness settings, the latest models checked in with users about 85% of the time. This is a slightly rosier story than previous studies, but also not the primary focus of the main experiment. This particular scenario, with no CSV specified, is a fairly obvious case in which users should be consulted (we made sure that there were no unintended cues upon which models could reasonably make assumptions), but this arguably makes the 85% rate a bit low. When compared with the key experimental condition, this was a roughly ~5-25 point increase in user-checkins depending on the model family and condition, supporting our observation that the presence of the grader alone had an independent influence on agent behavior.

The influence of user availability. Finally, we asked what agents would do in this situation when the user was simply unavailable for asking questions (after giving the initial task). This replicates what is more common in RL environments, where tasks are given to agents, sometimes underspecified, often without simulated users to clarify goals, and unfortunately often with unintended reward hacking risks. These are the conditions that have been hypothesized by other research groups to have led to the type of incidents we saw with Hugging Face where agents under pressure to solve ill-posed tasks autonomously and an opportunity to cheat [9]. Even if those conditions are rare, RL training can expose them enough to make them a real risk [6, 10].

Indeed, in this toy experiment we find that agents across conditions were far more likely to peek at the tempting reward when the user was not present (instead of making assumptions), showing an upwards of a 20 point increase in the rate of reward peeking. In the Claude family alone, agents peeked at the reward 68% and 88% of the time in the default and autonomy-oriented harness settings. Interestingly, during the autonomy-oriented harness setting, Claude was less likely to make assumptions overall, suggesting the possibility that when users are available, Claude may make assumptions knowing that they will have an opportunity to be corrected after.

Awareness of testing. As has been discussed a lot in the research community recently, we also asked whether there were clues that some of the agents somehow “knew” they were in an experiment and being tested. We thus performed a post-hoc analysis of reasoning traces and summaries to investigate possible verbal indicators of this awareness, finding those indicators in only 2% of traces. However, this cannot exclude the possibility of unverbalized awareness, which is a future direction for this type of experiment and benchmark.

Conclusion

We have shown in this proof-of-concept experiment a striking number of cases in which agents preferred to leverage a supposed reward function over simply pinging the user for clarification. We designed the experiment to make the latter option inarguably the best one – there is simply no reason a priori why a scoring function would contain ground truth that takes precedence over the user, who is the one who made the request after all. We indeed see this tradeoff across models and model families, some erring to a striking extent on the side much more of using the reward function instead of asking users for help. The story is not clear-cut in this experiment however, since we also see harness settings pushing models to make assumptions instead of using reward, although it remains unclear how aware agents may have been about the experiment itself.

We also see interesting variance by model family and harness setting, suggesting that this is not a uniform trend but one which currently varies starkly by those factors. Previous benchmarks have shown a strong influence of agent harness on performance [11,12]. Here, our experiment shows a similar, very focused effect of simple harness settings practitioners can tune for dramatic influence on agent performance. It remains to be seen what the optimal tradeoff is between check-ins and autonomy (this experiment involved just one simple task), but the overall problem is solvable and future work will expand on this experiment with a greater diversity of tasks to benchmark the robustness of these solutions.

Ultimately the field also needs a solution that involves better training environments, not simply with respect to reward hacking risks but also with respect to user interaction. Snorkel routinely makes simulation environments with simulated users and we have found that it is not an easy or free fix. The user simulator becomes a stochastic part of the environment with its own failure modes, and other groups have found training against just one can collapse policy entropy while training reward keeps rising and held-out performance falls back toward baseline [13]. Even the choice of user simulator and overall strategy around user dynamics changes how far evaluation scores change [13]. User simulators also add to an already expensive training run: for 1,000 prompts with 64 rollouts each, they can cost about $1.1k per training epoch with Gemma-31B and $3.6k with Gemini-3.5-Flash [14].

There are many other interesting nuggets in just this very simple experiment, with traces available in the open source repo and Hugging Face dataset for deeper dives into the traces.

References

1. Baumann, J., Padmakumar, V., Li, X., Yang, J., Yang, D., and Koyejo, S. (2026). SWE-chat: Coding Agent Interactions From Real Users in the Wild. arXiv:2604.20779, v2, 1 October 2026. https://arxiv.org/abs/2604.20779
2. Ji, Z., Zhang, Z., Xu, C., Li, Z., Gao, Y., Wang, S., and Cheung, S.-C. (2026). Coding Agents Are Guessing: Measuring Action-Boundary Violations in Underspecified DevOps Instructions (UnderSpecBench). arXiv:2607.02294, v1, 2 July 2026. https://arxiv.org/abs/2607.02294
3. Trinh, T., Elfeki, M., Luo, G., Luu, K., Hunt, N., Hernandez, E., Marwaha, N., He, Y. Y., Wang, C., Carabedo, F., Castillo, A., and Liu, B. (2026). HiL-Bench (Human-in-Loop Benchmark): Do Agents Know When to Ask for Help? arXiv:2604.09408, v4, 4 May 2026. https://arxiv.org/abs/2604.09408
4. Trinh, T., Luu, K., Luo, W., Siegel, M., and Elfeki, M. (2026). HiL-Dynamics: Understanding Agents That Don’t Know What They Don’t Know. Scale Labs, 27 May 2026. https://labs.scale.com/blog/hil-dynamics
5. Pochampally, S. (2026). DelegationBench: Measuring When AI Agents Should Ask Before Acting. arXiv:2610.05532, v1, 4 October 2026. https://arxiv.org/abs/2610.05532
6. OpenAI (2026). The Hugging Face incident and the road ahead. 26 August 2026. https://openai.com/index/hugging-face-incident-and-the-road-ahead/
7. Goh, H. W., and Mueller, J. (2026). Coding Agents Build for the Grader They Imagine, Not the User: Speculative Reward Hacking in DeepSWE. Handshake, 18 September 2026. https://joinhandshake.com/research/ai/deepswe-reward-hacking/
8. METR (2026). Frontier Risk Report (February to March 2026). 19 May 2026. https://metr.org/blog/2026-05-19-frontier-risk-report/
9. METR (2026). Brief independent investigation of agents’ behavior, reasoning and collaboration in the OpenAI / Hugging Face hacking incident. Greenblatt, R., Cotra, A., and Wijk, H.; 26 August 2026. https://metr.org/blog/2026-08-26-openai-hugging-face-incident-investigation/
10. Højmark, A., Scheurer, J., Nitishinskaya, E., Hofstätter, F., Wolfe, J., Ehrenborg, T., Schoen, B., and Meinke, A. (2026). Measuring Reward-Seeking via Contrastive Belief Updates. Apollo Research and OpenAI. arXiv:2607.18966, v1, 21 July 2026. https://arxiv.org/abs/2607.18966
11. Kapoor, S., Stroebl, B., Kirgis, P., Nadgir, N., Siegel, Z. S., … and Narayanan, A. (2025). Holistic Agent Leaderboard: The Missing Infrastructure for AI Agent Evaluation. arXiv:2510.11977, v1, 13 October 2025; ICLR 2026. https://arxiv.org/abs/2510.11977. Leaderboard: https://hal.cs.princeton.edu/
12. Merrill, M. A., Shaw, A. G., Carlini, N., Li, B., Raj, H., … and Schmidt, L. (2026). Terminal-Bench: Benchmarking Agents on Hard, Realistic Tasks in Command Line Interfaces. arXiv:2601.11868, v1, 17 January 2026; ICLR 2026. https://arxiv.org/abs/2601.11868. Leaderboard, version 2.0: https://www.tbench.ai/?version=2.0 (accessed 28 October 2026)
13. Yu, S., Tomlin, N., Abdulhai, M., Lu, X., Chong, D., Hou, A., Soylu, D., Levine, S., Manning, C. D., and Shi, W. (2026). One Frozen Simulator Is Not Enough: Simulator Collapse in Multi-Agent RL. arXiv:2608.12253, v2, 17 August 2026. https://arxiv.org/abs/2608.12253
14. Jain, A., and Sandhu, A. (2026). UserProxyBench: Evaluating LLM User Simulators for Agent Benchmarks and Training. arXiv:2609.38043, v1, 29 September 2026; NeurIPS 2026 workshop. https://arxiv.org/abs/2609.38043