StepCodeReasoner Framework

• StepCodeReasoner is a framework that recasts code reasoning as an explicit execution-modeling task by supervising intermediate runtime states with structured print-based anchors.
• It leverages a reinforcement-learning method, Bi-Level GRPO, which assigns credit at both trajectory and step levels to reduce reward hacking and better align with interpreter behavior.
• The framework improves code generation and reasoning benchmarks by integrating execution traces from instrumented programs and filtering them for optimal performance.

StepCodeReasoner is a training and inference framework for code reasoning that recasts prediction of program behavior as an explicit execution-modeling problem. Instead of supervising only the final answer, it automatically instruments programs with structured execution-trace anchors, executes the instrumented code to obtain ground-truth runtime states, and trains a model to predict intermediate states together with the final result. Its reinforcement-learning component, Bi-Level GRPO, assigns credit at both the trajectory level and the step level, with the stated goal of reducing reward hacking and aligning reasoning with actual interpreter behavior (Wang et al., 12 May 2026).

1. Problem formulation and conceptual basis

StepCodeReasoner addresses code reasoning in the sense of inferring how a program’s internal state evolves during execution, including variable updates, control flow, and the final result. The framework is motivated by the observation that many prior methods treat code reasoning as a terminal prediction problem: given a program $P$ and a condition $C$, the model predicts the unknown value $V^\*$ with an objective of the form

$\mathcal{L}_{\text{terminal}}(\theta) = - \log p_\theta(V^\* \mid P, C),$

which ignores the execution process itself (Wang et al., 12 May 2026).

The central alternative is to supervise a sequence of intermediate execution states. StepCodeReasoner defines a sequence

$z_i^\* = \begin{cases} s_i^\*, & 1 \le i \le n \ V^\*, & i = n+1 \end{cases}$

and optimizes

$\mathcal{L}_{\text{StepCodeReasoner}}(\theta) = - \sum_{i=1}^{n+1} \log p_\theta(z_i^\* \mid P, C, z_{<i}^\*).$

Here, each $s_i^\*$ is a true runtime state collected from actual execution, and $V^\*$ is the final output. This turns code reasoning into a verifiable stepwise execution-modeling problem rather than a black-box answer prediction task (Wang et al., 12 May 2026).

This formulation is especially relevant to tasks where a model must simulate execution rather than recover patterns from final outputs. A plausible implication is that the framework is aimed not only at benchmark performance but also at reducing the gap between “right answer” and “right execution trace,” a distinction that becomes operational in its reward design and evaluation.

2. Execution-trace anchors and structured supervision

The framework begins by transforming an original Python function $P$ into an instrumented program $P' = T(P)$ that exposes internal states through structured print-based anchors. Executing $C$0 with an interpreter $C$1 and input $C$2 yields a ground-truth trace

$C$3

Anchors follow a strict format such as print(f'VAR_NAME: {VAR_NAME}'), and returns are logged as print(f'return_val: {res}') (Wang et al., 12 May 2026).

The instrumentation policy is deliberately selective. Prints are not inserted inside loops; they are placed after significant variable assignments outside loops, and the transformation may expand complex one-liners only to inject prints while preserving semantics. The paper states that traces longer than 10 lines are filtered out, and traces with only one line are treated as terminal-only supervision. This makes execution-state supervision dense without allowing unbounded trace growth (Wang et al., 12 May 2026).

StepCodeReasoner supports two prompt schemas. In output prediction, the model produces alternating <reasoning> and <print> segments for each anchor, followed by a final <answer>. In input prediction, it first emits <input>, then simulates execution through the same <reasoning>/<print> pattern, and finally emits <answer>. This prompt structure decouples input inference from subsequent execution modeling (Wang et al., 12 May 2026).

The concrete supervision signal is exact-match. For a sampled trajectory $C$4, each predicted state $C$5 is compared to $C$6 with

$C$7

and the final answer is rewarded analogously by exact string match against $C$8. The paper emphasizes that this yields 100% accurate step-level reward, contrasting it with learned reward models that, in Appendix G, achieve only about 65–73% judgment accuracy (Wang et al., 12 May 2026).

3. Bi-Level GRPO and structured credit assignment

StepCodeReasoner’s reinforcement-learning component is Bi-Level GRPO, a Group Relative Policy Optimization variant designed for execution traces. It operates over sampled trajectories

$C$9

where each trajectory contains predicted intermediate states and a final answer (Wang et al., 12 May 2026).

At the inter-trajectory level, the method computes a group-relative stepwise advantage for each anchor: $V^\*$0 This compares a trajectory’s correctness at a given step with the batch average at that same step. It is a relative signal rather than an absolute one, which reduces variance in the GRPO update (Wang et al., 12 May 2026).

At the intra-trajectory level, Bi-Level GRPO adds a shaping term

$V^\*$1

This term is zero when the current step is wrong, and increases for correct steps that are followed by many later correct steps. Early correct states in a mostly correct trace therefore receive larger credit than isolated correct states in otherwise inconsistent traces (Wang et al., 12 May 2026).

The two signals are combined as

$V^\*$2

with implementation value $V^\*$3. The stepwise objective and final-output objective are optimized together with a KL regularizer to a reference model. The paper presents this as a mechanism for assigning credit both across alternative trajectories and along the internal temporal structure of a single trajectory, without introducing a learned value function (Wang et al., 12 May 2026).

This design is one of the framework’s main distinctions. Standard terminal-only GRPO uses sequence-level success; step-only relative methods compare steps across trajectories but do not explicitly model downstream impact. StepCodeReasoner adds trajectory-aware shaping to reward steps that enable later correctness.

4. Data construction, prompts, and training pipeline

The base model is primarily Qwen2.5-Coder-7B-Instruct, with additional scaling experiments on Qwen2.5-Coder-14B-Instruct. The novelty is stated to lie in training, data, and RL rather than network architecture (Wang et al., 12 May 2026).

Training data is derived from CodeReasoner datasets and then instrumented. The instrumentation teacher is GPT-4o by default, with Qwen2.5-9B also tested in robustness experiments. After filtering and 10-gram decontamination, the paper reports 17,332 cases for supervised fine-tuning and 18,796 cases for RL. An additional scaling experiment expands SFT data to 55,841 samples by adding CodeIO-PyEdu-Reasoning, but the main results use the 17K core set (Wang et al., 12 May 2026).

The training pipeline has five stages. First, the program is instrumented to produce print anchors. Second, ground-truth traces are generated by executing the instrumented program. Third, tasks are formatted into output-prediction or input-prediction prompts. Fourth, supervised fine-tuning teaches the model to imitate teacher-generated traces and correct prints and answers. Fifth, Bi-Level GRPO refines the policy using sampled trajectories, exact-match step rewards, and group-relative credit assignment (Wang et al., 12 May 2026).

The RL configuration is explicit: 2 epochs of RL, learning rate $V^\*$4, group size 5 trajectories per prompt, maximum generation length 4096 tokens, and training on 8× NVIDIA A100 40GB. Reward budgets are normalized with $V^\*$5 and $V^\*$6 (Wang et al., 12 May 2026).

A notable practical detail is that the framework distinguishes between output prediction and input prediction at the prompt level rather than forcing a single response format for both. This suggests that part of the reported gain comes from task decoupling, which the ablation study identifies as beneficial.

5. Empirical profile

StepCodeReasoner is evaluated on CRUXEval, LiveCodeBench, REval, and code-generation benchmarks including HumanEval, MBPP, and LiveCodeBench v5. The paper highlights state-of-the-art code-reasoning performance for its 7B model, especially on execution-trace understanding and input prediction (Wang et al., 12 May 2026).

Benchmark	StepCodeReasoner-7B	Selected comparison
CRUXEval	91.1%	CodeReasoner-7B: 86.0%
LiveCodeBench	86.5%	CodeReasoner-7B: 77.7%
REval	82.9%	CodeReasoner-7B: 72.3%
HumanEval	90.1	CodeReasoner-7B: 87.6
MBPP	85.0	CodeReasoner-7B: 82.4

On the CRUXEval and LiveCodeBench code-reasoning suite, StepCodeReasoner-7B achieves 91.1% and 86.5%, outperforming CodeReasoner-7B, GPT-4o, and, on REval, even the CodeReasoner-14B counterpart in average score. The largest reported gains occur on input-prediction tasks, which the paper characterizes as more challenging and more dependent on deep reasoning about control flow and state evolution (Wang et al., 12 May 2026).

REval is particularly significant because it decomposes reasoning into coverage prediction, state prediction, path prediction, and output prediction. StepCodeReasoner-7B reports 0.944 on coverage, 0.823 on state, 0.631 on path, and 0.918 on output, for an average of 0.829. The improvements over CodeReasoner-7B are largest on state and path prediction, which directly reflect intermediate execution modeling (Wang et al., 12 May 2026).

The paper also reports that explicit execution modeling improves code generation. StepCodeReasoner-7B reaches 90.1 on HumanEval, 85.0 on MBPP, and 19.4 on LiveCodeBench v5, outperforming CodeReasoner-7B across all three. This is presented as evidence that learning to model execution can enhance both code reasoning and code generation (Wang et al., 12 May 2026).

A central diagnostic is the gap between intermediate-step accuracy and final-answer accuracy. On CRUXEval-O, the paper reports 80.7% step accuracy and 91.6% final accuracy for StepCodeReasoner, compared with 63.5% and 85.6% for CodeReasoner-7B. Terminal-only training leaves a much larger discrepancy between process and outcome; StepCodeReasoner narrows that gap substantially (Wang et al., 12 May 2026).

The framework also generalizes beyond instrumented prompts. On original, non-instrumented CRUXEval and LiveCodeBench, where prompts request only the final answer, StepCodeReasoner achieves CRUXEval average 0.848 and LiveCodeBench average 0.770. This suggests that some execution-trace competence is internalized even when explicit anchors are absent (Wang et al., 12 May 2026).

6. Position within the broader stepwise code-reasoning literature

StepCodeReasoner belongs to a broader family of methods that treat reasoning as interaction with executable structure rather than unrestricted natural-language chain-of-thought. Tool-augmented RL for code-integrated reasoning trains models to decide when and how to call a code interpreter, with execution results appended back into the reasoning context; that line of work focuses on interactive tool use and RL stability rather than explicit runtime-state supervision (Bai et al., 30 May 2025). ReST-RL and SEER similarly operate over line-level or step-level states with value-guided search, MCTS, or optimized self-training, but they target policy improvement and decoding over solution prefixes rather than print-anchored execution-state matching (Zhoubian et al., 27 Aug 2025, Gao et al., 20 Oct 2025).

A closer conceptual neighbor is CodeThinker, which uses a Consistency Tracing paradigm with [[CODE](https://www.emergentmind.com/topics/confident-ordinary-differential-editing-code)], [THOUGHT], [LOCALS], and [RETURN] tags plus a consistency-gated RL reward. Both frameworks make the reasoning process machine-verifiable through intermediate state representations, though StepCodeReasoner uses print-based execution anchors and Bi-Level GRPO, whereas CodeThinker uses blockwise consistency rewards and dynamic beam sampling (Qin et al., 18 May 2026). This suggests a broader convergence toward execution-grounded reward design.

Other adjacent systems broaden the same intuition into different modalities or evaluation regimes. RECODE derenders charts and diagrams into executable code for verifiable multimodal reasoning, making code a symbolic intermediate representation outside pure source-code tasks (Shen et al., 15 Oct 2025). ReMind studies deductive code reasoning as a non-execution task and introduces a Mutator–Executor–Inspector architecture that uses code variants and CFG-based inspection to repair step-by-step traces (Gao et al., 1 Nov 2025). RHDA uses iterative hypothesis decomposition and amendment with tool feedback, emphasizing explicit sub-hypotheses and structured revision (Zhao et al., 17 Feb 2025).

The evaluation landscape has also shifted. STEPWISE-CODEX-Bench defines computation steps as the minimal execution unit in complex multi-function programs and reports that even openai-o3 reaches only 78.37 percent accuracy on Hard-Reasoning tasks, indicating that saturated single-function benchmarks do not fully measure fine-grained dynamic execution reasoning (Yan et al., 7 Aug 2025). This provides context for why execution-trace supervision is attracting attention.

Interpretability work points in a compatible direction. Step-level sparse autoencoders show that correctness, logicality, step length, and first-token distribution can be predicted from sparse step representations, suggesting that models may already encode step-level reasoning properties during generation (Yang et al., 3 Mar 2026). A plausible implication is that frameworks such as StepCodeReasoner operationalize this latent structure by binding it to explicit execution states and reward signals.

7. Limitations and future directions

The paper states several limitations directly. The current pipeline targets Python with print()-based instrumentation; extending it to compiled languages such as C++ or Java would require different instrumentation strategies, such as logging APIs or bytecode-level instrumentation. Anchors are selective: there are no prints inside loops, and traces are capped at 10 anchors, so deeply nested loops, recursion, or long iterative processes are only partially observed (Wang et al., 12 May 2026).

The framework also introduces extra inference cost. Appendix I reports that StepCodeReasoner-7B uses about 470 tokens per CRUXEval-O inference, compared with about 310 for CodeReasoner-7B and about 260 for Qwen2.5-Coder-7B, or about 1.5× more tokens than CodeReasoner-7B. The paper argues that the associated gains, such as +7.0% on CRUXEval-O and +14.7% on REval, often justify this cost, but the trade-off remains explicit (Wang et al., 12 May 2026).

Scope is presently limited to function-level and algorithm-level tasks. Repository-scale code, multi-file state, class interactions, and side effects such as file I/O or network calls are outside the framework’s current supervision design. The data pipeline also depends on a reasonably capable teacher model for instrumentation, even though robustness to a smaller teacher and random anchor dropout is reported (Wang et al., 12 May 2026).

Future directions identified in the paper include extending instrumentation beyond Python and beyond print-based logging, incorporating process reward models for <reasoning> blocks in addition to <print> content, scaling to larger models and datasets, and applying the method to debugging, repair, and large-scale software engineering contexts (Wang et al., 12 May 2026). In light of neighboring work on tool-augmented RL, value-guided search, multimodal derendering, and consistency-based rewards, this suggests that StepCodeReasoner may be one instance of a larger shift toward execution-grounded, stepwise, and externally verifiable reasoning across code and adjacent domains (Bai et al., 30 May 2025, Qin et al., 18 May 2026, Shen et al., 15 Oct 2025).