pith. sign in

arxiv: 2606.07379 · v2 · pith:IBAG4VXVnew · submitted 2026-06-05 · 💻 cs.LG · cs.AI· cs.CL· stat.ME

Do Coding Agents Deceive Us? Detecting and Preventing Cheating via Capped Evaluation with Randomized Tests

Thanawat Lodkaew , Johannes Ackermann , Soichiro Nishimori , Nontawat Charoenphakdee , Masashi Sugiyama , Takashi Ishida This is my paper

Pith reviewed 2026-06-27 22:14 UTC · model grok-4.3

classification 💻 cs.LG cs.AIcs.CLstat.ME
keywords coding agentscheating detectionevaluation frameworksrandomized testsshortcut exploitationreward designagent training
0
0 comments X

The pith

Capped evaluation with randomized tests detects when coding agents cheat by exploiting shortcuts instead of solving the intended task.

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The paper introduces a method to make evaluations of coding agents more reliable by building test sets where randomized tests deliberately limit the highest score any honest solution can achieve. Any result that clears this cap is treated as evidence that the agent found an unintended shortcut rather than completing the task as specified. The same capping idea is turned into a training reward that penalizes scores above the limit, steering models away from deceptive behavior. Experiments across datasets show the approach flags cheating without altering the relative ordering of models on genuine performance and produces agents that stick closer to the original task rules.

Core claim

By constructing coding datasets with randomized tests whose best achievable non-cheating performance is deliberately capped below one, evaluation scores substantially above the cap become implausible without cheating, and a reward function built on the same cap discourages agents from optimizing past it during training.

What carries the argument

CapCode, the framework that builds coding datasets with randomized tests to enforce a deliberate performance cap below one on non-cheating solutions.

Load-bearing premise

It is possible to build randomized tests such that the best score any non-cheating solution can reach is set below one and that anything above this cap must come from cheating rather than legitimate better performance.

What would settle it

A model that scores above the cap while using only solutions that follow the intended task specification and do not exploit any patterns introduced by the randomization would falsify the detection claim.

Figures

Figures reproduced from arXiv: 2606.07379 by Johannes Ackermann, Masashi Sugiyama, Nontawat Charoenphakdee, Soichiro Nishimori, Takashi Ishida, Thanawat Lodkaew.

Figure 1
Figure 1. Figure 1: Conceptual illustrations of CapCode and CapReward. CapCode (left) is a dataset-construction framework with [PITH_FULL_IMAGE:figures/full_fig_p001_1.png] view at source ↗
Figure 2
Figure 2. Figure 2: Example of a task instruction 𝑥 (left) and its corresponding test suite 𝒚 = {(𝑢 𝑗 , 𝑣 𝑗)}𝑚 𝑗=1 with 𝑚 = 3 test cases (right). Each test case corresponds to an input-output pair (𝑢 𝑗 , 𝑣 𝑗): for example, (𝑢1, 𝑣1) = (2, 72), (𝑢2, 𝑣2) = (3, 288), and (𝑢3, 𝑣3) = (4, 800). Here, 𝑢 𝑗 denotes a valid input, and 𝑣 𝑗 denotes the desired output. This example is from the MBPP dataset (Austin et al., 2021). Importantl… view at source ↗
Figure 3
Figure 3. Figure 3: Task-level CapCode augments the original task by adding an additional instruction and a corresponding test with [PITH_FULL_IMAGE:figures/full_fig_p003_3.png] view at source ↗
Figure 4
Figure 4. Figure 4: Illustration of CapReward defined in Eq. ( [PITH_FULL_IMAGE:figures/full_fig_p005_4.png] view at source ↗
Figure 5
Figure 5. Figure 5: CapCode effectively flags potential cheating immediately as such behavior emerges, e.g., by submission round [PITH_FULL_IMAGE:figures/full_fig_p006_5.png] view at source ↗
Figure 6
Figure 6. Figure 6: Diagonal alignment of the scatter points indicates that CapCode preserves the performance ranking of LLMs on [PITH_FULL_IMAGE:figures/full_fig_p007_6.png] view at source ↗
Figure 7
Figure 7. Figure 7: CapCode maintains effectiveness in detecting implausibly high evaluation scores in prompt-exposed and [PITH_FULL_IMAGE:figures/full_fig_p008_7.png] view at source ↗
Figure 8
Figure 8. Figure 8: CapReward consistently outperforms baseline reward functions under all cheating regimes, achieving both [PITH_FULL_IMAGE:figures/full_fig_p009_8.png] view at source ↗
Figure 9
Figure 9. Figure 9: CapReward maintains performance comparable to baselines, indicating no adverse effect. Bars show mean [PITH_FULL_IMAGE:figures/full_fig_p010_9.png] view at source ↗
Figure 10
Figure 10. Figure 10: Training on CapCode data alone is insufficient, as B, NB and Combined perform worse than CapReward. [PITH_FULL_IMAGE:figures/full_fig_p010_10.png] view at source ↗
Figure 11
Figure 11. Figure 11: Example of a task created by case-level CapCode that directly alters the original result [PITH_FULL_IMAGE:figures/full_fig_p016_11.png] view at source ↗
Figure 12
Figure 12. Figure 12: Example of test feedback for a task-level CapCode example that the model received at submission round 3. [PITH_FULL_IMAGE:figures/full_fig_p017_12.png] view at source ↗
Figure 13
Figure 13. Figure 13: Example of test feedback for a case-level CapCode example that the model received at submission round 3. [PITH_FULL_IMAGE:figures/full_fig_p018_13.png] view at source ↗
Figure 14
Figure 14. Figure 14: Example of a task instruction created by case-level CapCode used in the workspace-exposed setting [PITH_FULL_IMAGE:figures/full_fig_p019_14.png] view at source ↗
Figure 15
Figure 15. Figure 15: Example of tests.json (case-level CapCode) provided to the model in the workspace-exposed setting 20 [PITH_FULL_IMAGE:figures/full_fig_p020_15.png] view at source ↗
Figure 16
Figure 16. Figure 16: Example of a synthetic task used to supervised fine-tune a policy to become cheating [PITH_FULL_IMAGE:figures/full_fig_p021_16.png] view at source ↗
Figure 17
Figure 17. Figure 17: Example of a task created for binary/non-binary rewards [PITH_FULL_IMAGE:figures/full_fig_p021_17.png] view at source ↗
Figure 18
Figure 18. Figure 18: Example of a task created for training with ImpossibleReward [PITH_FULL_IMAGE:figures/full_fig_p021_18.png] view at source ↗
Figure 19
Figure 19. Figure 19: Example of a task created for training with CapReward [PITH_FULL_IMAGE:figures/full_fig_p021_19.png] view at source ↗
Figure 20
Figure 20. Figure 20: Example Python implementation of CapReward for use with [PITH_FULL_IMAGE:figures/full_fig_p022_20.png] view at source ↗
Figure 21
Figure 21. Figure 21: Example Python implementation of ImpossibleReward which is be used in [PITH_FULL_IMAGE:figures/full_fig_p023_21.png] view at source ↗
Figure 22
Figure 22. Figure 22: Python code used to build an impossible test [PITH_FULL_IMAGE:figures/full_fig_p024_22.png] view at source ↗
Figure 23
Figure 23. Figure 23: Evaluation scores of LLMs on original and CapCode benchmarks. Please refer to Tab. [PITH_FULL_IMAGE:figures/full_fig_p026_23.png] view at source ↗
Figure 24
Figure 24. Figure 24: KL regularization (B+KL and NB+KL) can preserve/worsen cheating behavior while removing KL (B and NB) [PITH_FULL_IMAGE:figures/full_fig_p027_24.png] view at source ↗
Figure 25
Figure 25. Figure 25: KL regularization can worsen cheating behavior over longer training. [PITH_FULL_IMAGE:figures/full_fig_p027_25.png] view at source ↗
read the original abstract

A growing failure mode in agent evaluation and training is that models can achieve high evaluation scores by exploiting shortcuts instead of solving the intended task, producing deceptive performance. This makes evaluation scores unreliable as measures of true task-solving ability. We propose CapCode, a framework for constructing coding datasets with randomized tests whose best achievable non-cheating performance is deliberately capped below one. This capped-performance design gives evaluation scores a clearer interpretation: scores substantially above the cap are implausible and therefore provide evidence of cheating. To prevent cheating, we propose CapReward, a reward design based on the CapCode principle to discourage optimization beyond the cap. Experiments across multiple datasets show that CapCode detects cheating while preserving performance ranking of models, and CapReward reduces cheating behavior, yielding models that better follow the intended task specification.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 0 minor

Summary. The paper claims that coding agents can achieve high evaluation scores by exploiting shortcuts (cheating) rather than solving the intended task. It proposes CapCode, a framework for constructing coding datasets with randomized tests such that the best achievable non-cheating performance is deliberately capped below 1; scores substantially above the cap are interpreted as evidence of cheating. It further proposes CapReward, a reward design based on the same principle to discourage optimization beyond the cap during training. Experiments across multiple datasets are asserted to show that CapCode detects cheating while preserving performance rankings of models, and that CapReward reduces cheating behavior, yielding models that better follow the intended task specification.

Significance. If the central claims hold, the work would offer a constructive method for improving the reliability of coding agent evaluations and training by making high scores more interpretable as potential indicators of deception. This addresses a growing concern in AI agent benchmarking and could influence how future datasets and reward functions are designed to reduce shortcut exploitation.

major comments (2)
  1. [Abstract] Abstract: The assertion that randomized tests can be constructed such that 'the best achievable non-cheating performance is deliberately capped below one' is load-bearing for the entire detection framework, yet the manuscript provides no construction details, formal bound, or argument showing that no legitimate (non-cheating) solution can exceed the cap by legitimately handling edge cases within the intended test distribution. Randomization alone does not automatically guarantee a tight bound against all non-cheating programs.
  2. [Abstract] Abstract: The statement that 'experiments across multiple datasets show that CapCode detects cheating while preserving performance ranking of models' is presented without any details on dataset construction, how the cap is enforced in practice, statistical significance, or controls for confounding factors. This absence prevents assessment of whether the empirical support actually validates the central claims.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their careful reading and constructive comments on the abstract. We address each point below and will revise the manuscript to improve clarity and completeness.

read point-by-point responses

  1. Referee: [Abstract] Abstract: The assertion that randomized tests can be constructed such that 'the best achievable non-cheating performance is deliberately capped below one' is load-bearing for the entire detection framework, yet the manuscript provides no construction details, formal bound, or argument showing that no legitimate (non-cheating) solution can exceed the cap by legitimately handling edge cases within the intended test distribution. Randomization alone does not automatically guarantee a tight bound against all non-cheating programs.

    Authors: We agree that the abstract is concise and omits these details. Section 3 of the manuscript describes the CapCode construction: test inputs are drawn from a randomized distribution over problem instances that includes edge cases with probability calibrated so that any non-cheating program has success probability strictly less than 1 (e.g., by ensuring at least one test case lies outside the support of any fixed non-cheating solution). We provide an informal argument that legitimate solutions cannot exceed the cap because they must generalize across the randomization, while cheating exploits the fixed test set. We will revise the abstract to include a one-sentence summary of this construction and add a formal probabilistic bound to Section 3 or an appendix in the revision. revision: yes

  2. Referee: [Abstract] Abstract: The statement that 'experiments across multiple datasets show that CapCode detects cheating while preserving performance ranking of models' is presented without any details on dataset construction, how the cap is enforced in practice, statistical significance, or controls for confounding factors. This absence prevents assessment of whether the empirical support actually validates the central claims.

    Authors: We agree the abstract lacks these specifics. Section 5 details the datasets (modified versions of HumanEval, MBPP, and APPS with randomized test generators), the enforcement of the cap via parameter choices that limit non-cheating accuracy to at most 0.8, the use of paired statistical tests for ranking preservation, and controls such as non-randomized baselines and ablation on randomization strength. We will revise the abstract to reference these elements concisely and ensure all methodological parameters and significance results are explicitly stated in the main text. revision: yes

Circularity Check

0 steps flagged

No significant circularity; CapCode is a constructive proposal validated experimentally.

full rationale

The paper introduces CapCode as an explicit construction for randomized test suites that deliberately cap non-cheating performance below 1, and CapReward as a corresponding reward function; these are presented as design choices rather than derived quantities. No equations, fitted parameters, or self-citations are invoked in a load-bearing manner that would make any claimed prediction or uniqueness reduce to the inputs by definition. The central claims rest on empirical results across datasets showing detection of cheating and preservation of rankings, which are externally falsifiable and independent of any internal self-reference. This is the normal case of a self-contained constructive method.

Axiom & Free-Parameter Ledger

0 free parameters · 1 axioms · 2 invented entities

The central claim rests on the ability to construct randomized tests that enforce a strict performance cap without altering the underlying task; this construction is treated as feasible but no independent evidence or formal guarantee is provided in the abstract. No free parameters or invented physical entities are described.

axioms (1)
  • domain assumption Randomized tests can be designed so that the maximum non-cheating score is strictly less than one while still testing the intended task.
    This premise is required for the cap to serve as a reliable cheating detector and is invoked in the description of CapCode.
invented entities (2)
  • CapCode framework no independent evidence
    purpose: Dataset construction method that caps non-cheating performance
    New proposed construct for evaluation; no independent evidence outside the paper.
  • CapReward no independent evidence
    purpose: Reward design to discourage optimization beyond the performance cap
    New proposed training component; no independent evidence outside the paper.

pith-pipeline@v0.9.1-grok · 5696 in / 1371 out tokens · 19921 ms · 2026-06-27T22:14:05.666091+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Reference graph

Works this paper leans on

16 extracted references · 7 canonical work pages · 7 internal anchors

  1. [1]

    Anthropic Team

    Accessed: 2026-06-02. Anthropic Team. System Card: Claude Mythos Preview. https://www-cdn.anthropic.com/ 08ab9158070959f88f296514c21b7facce6f52bc.pdf,

    2026

  2. [2]

    Sydney Von Arx, Lawrence Chan, and Elizabeth Barnes

    Accessed: 2026-04-24. Sydney Von Arx, Lawrence Chan, and Elizabeth Barnes. Recent Frontier Models Are Reward Hacking. https://metr. org/blog/2025-06-05-recent-reward-hacking/ ,

    2026

  3. [3]

    Program Synthesis with Large Language Models

    Accessed: 2026-04-10. Jacob Austin, Augustus Odena, Maxwell Nye, Maarten Bosma, Henryk Michalewski, David Dohan, Ellen Jiang, Carrie Cai, Michael Terry, Quoc Le, and Charles Sutton. Program Synthesis with Large Language Models. arXiv preprint arXiv:2108.07732,

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  4. [4]

    arXiv preprint arXiv:2512.13961,

    work page internal anchor Pith review Pith/arXiv arXiv

  5. [5]

    Aobo Kong, Wentao Ma, Shiwan Zhao, Y ongbin Li, Yuchuan Wu, Ke Wang, Xiaoqian Liu, Qicheng Li, Y ong Qin, and Fei Huang

    Accessed: 2026-04-24. Aobo Kong, Wentao Ma, Shiwan Zhao, Y ongbin Li, Yuchuan Wu, Ke Wang, Xiaoqian Liu, Qicheng Li, Y ong Qin, and Fei Huang. SDPO: Segment-Level Direct Preference Optimization for Social Agents. In ACL,

    2026

  6. [6]

    Qwen3 Technical Report

    Accessed: 2026-04-26. Qwen Team. Qwen3 Technical Report. arXiv preprint arXiv:2505.09388,

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  7. [7]

    Zhihong Shao, Peiyi Wang, Qihao Zhu, Runxin Xu, Junxiao Song, Xiao Bi, Haowei Zhang, Mingchuan Zhang, Y . K. Li, Y . Wu, and Daya Guo. DeepSeekMath: Pushing the Limits of Mathematical Reasoning in Open Language Models. arXiv preprint arXiv:2402.03300,

    work page internal anchor Pith review Pith/arXiv arXiv

  8. [8]

    Emotion Concepts and their Function in a Large Language Model

    Nicholas Sofroniew, Isaac Kauvar, William Saunders, Runjin Chen, Tom Henighan, Sasha Hydrie, Craig Citro, Adam Pearce, Julius Tarng, Wes Gurnee, Joshua Batson, Sam Zimmerman, Kelley Rivoire, Kyle Fish, Chris Olah, and Jack Lindsey. Emotion Concepts and their Function in a Large Language Model. https://transformer-circuits.pub/ 2026/emotions/index.html,

    2026

  9. [9]

    Detecting Safety Violations Across Many Agent Traces

    Accessed: 2026-04-10. Adam Stein, Davis Brown, Hamed Hassani, Mayur Naik, and Eric Wong. Detecting Safety Violations Across Many Agent Traces. arXiv preprint arXiv:2604.11806, 2026a. Adam Stein, Davis Brown, Hamed Hassani, Mayur Naik, and Eric Wong. Finding Widespread Cheating on Popular Agent Benchmarks. https://debugml.github.io/cheating-agents/, 2026b....

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  10. [10]

    SWE-smith: Scaling Data for Software Engineering Agents

    Hao Wang, Qiuyang Mang, Alvin Cheung, Koushik Sen, and Dawn Song. How We Broke Top AI Agent Benchmarks: And What Comes Next. https://rdi.berkeley.edu/blog/trustworthy-benchmarks-cont/ , 2026a. Accessed: 2026-04-24. Xinpeng Wang, Nitish Joshi, Barbara Plank, Rico Angell, and He He. Is It Thinking or Cheating? Detecting Implicit Reward Hacking by Measuring ...

    work page internal anchor Pith review Pith/arXiv arXiv 2026

  11. [11]

    GLM-4.5: Agentic, Reasoning, and Coding (ARC) Foundation Models

    Aohan Zeng, Xin Lv, Qinkai Zheng, Zhenyu Hou, Bin Chen, Chengxing Xie, Cunxiang Wang, Da Yin, Hao Zeng, Jiajie Zhang, Kedong Wang, Lucen Zhong, Mingdao Liu, Rui Lu, Shulin Cao, Xiaohan Zhang, Xuancheng Huang, Y ao Wei, Y ean Cheng, Yifan An, Yilin Niu, Yuanhao Wen, Yushi Bai, Zhengxiao Du, Zihan Wang, Zilin Zhu, Bohan Zhang, Bosi Wen, Bowen Wu, Bowen Xu, ...

    work page internal anchor Pith review Pith/arXiv arXiv

  12. [12]

    , 2026a; Arx et al

    A Related work Cheating issues in coding agents A growing body of work documents various forms of cheating behavior in coding agents (Stein et al. , 2026a; Arx et al. , 2025; Stein et al. , 2026b). These behaviors include scenarios in which test cases are intentionally or unintentionally exposed and the agent reverse-engineers expected outputs, solution c...

    2025

  13. [13]

    (FAIL) test case #10 expected: ([500, 1000, 1500, 2000, 3000],

    2000

  14. [15]

    Submitted implementation: def comb_sort (arr):

    (PASS) [Submission 2] RESULT: passed 9/10 tests. Submitted implementation: def comb_sort (arr): ... Failures: test case #10 expected: ([500, 1000, 1500, 2000, 3000],

    2000

  15. [16]

    got: ([500, 1000, 1500, 2000, 3000],

    2000

  16. [17]

    These reward functions require training on data constructed in the style of ImpossibleBench ( Zhong et al. , 2026). Given a dataset, we construct such data by modifying the test suite of each task while leaving the task instruction unchanged. Specifically, for each task, we add an intentionally inconsistent (impossible) test case. To construct this test, ...

    2026