2602.03485

# Self-Verification Dilemma: Experience-Driven Suppression of Overused Checking in LLM Reasoning **Authors**: Quanyu Long, Kai Jie Jiang, Jianda Chen, Xu Guo, Leilei Gan, Wenya Wang Abstract Large Reasoning Models (LRMs) achieve strong performance by generating long reasoning traces with reflection. Through a large-scale empirical analysis, we find that a substantial fraction of reflective steps consist of self-verification (recheck) that repeatedly confirm intermediate results. These rechecks occur frequently across models and benchmarks, yet the vast majority are confirmatory rather than corrective, rarely identifying errors and altering reasoning outcomes. This reveals a mismatch between how often self-verification is activated and how often it is actually useful. Motivated by this, we propose a novel, experience-driven test-time framework that reduces the overused verification. Our method detects the activation of recheck behavior, consults an offline experience pool of past verification outcomes, and estimates whether a recheck is likely unnecessary via efficient retrieval. When historical experience suggests unnecessary, a suppression signal redirects the model to proceed. Across multiple model and benchmarks, our approach reduces token usage up to 20.3 % while maintaining the accuracy, and in some datasets even yields accuracy improvements. Machine Learning, ICML 1 Introduction <details> <summary>Figs/intro.png Details</summary>  ### Visual Description ## Thinking Process Diagram: Math Problem Solving ### Overview The image depicts a step-by-step thought process for solving a math problem. It shows the iterative nature of problem-solving, including initial attempts, error checking, and alternative approaches. The diagram uses color-coded boxes to represent different stages of thinking and actions. ### Components/Axes * **Header:** "Please answer the following math question. You should think step by step to solve it." * **Tags:** `<think>`, `</think>` * **Green Boxes:** Represent initial computations, verifications, and conclusions. * Dashed green lines. * Text within: * "...(some computations) By taking derivatives, I..." * "Wait, there maybe a mistake in my early computation." * "Let me retrace. Earlier, I take derivatives..." * "...(verifying)..." * "Therefore, my earlier conclusion was right." * "...(mid-results derived) Therefore, m + n is 116...." * "But wait, let me check again because maybe I made a mistake in calculating probability P(B)." * "...(verifying)..." * "Therefore m + n is 1 + 115 = 116." * Right side of green boxes: "Recheck not identifying any errors" * **Orange Box:** Represents an optimality check and a subsequent correction. * Dashed orange lines. * Text within: * "...(An optimality is proved)..." * "Let me verify if this indeed the minimum..." * "...(verifying)..." * "Therefore, my earlier conclusion was wrong." * Right side of orange box: "Recheck identifying an error" * **Red Box:** Represents a change in assumption and an alternative approach. * Dashed red lines. * Text within: * "In my previous assumption, DC is horizontal. But if I change the orientation, would that affect the result? Let me try this alternative approach." * Right side of red box: "Rethink" * **Page Curl:** Top right corner of the page is folded over. ### Detailed Analysis or ### Content Details The diagram starts with a prompt to answer a math question step-by-step. The initial approach involves computations and derivatives (green box). A potential mistake is identified, leading to retracing and verification. The conclusion is initially deemed correct. Next, mid-results are derived, leading to the equation "m + n is 116". A check is performed due to a possible mistake in calculating probability P(B). The equation "m + n is 1 + 115 = 116" is then stated. An optimality check (orange box) is performed to verify the minimum. The earlier conclusion is found to be wrong. Finally, a change in assumption regarding the orientation of DC is considered (red box), leading to an alternative approach. ### Key Observations * The diagram highlights the importance of error checking and verification in problem-solving. * The use of different colored boxes emphasizes the different stages of the thought process. * The iterative nature of problem-solving is evident, with multiple checks and corrections. ### Interpretation The diagram illustrates a structured approach to solving a math problem. It demonstrates that problem-solving is not always a linear process but often involves backtracking, re-evaluation, and alternative approaches. The color-coding helps to visually distinguish between different stages of thinking, such as initial computations, error checking, and assumption changes. The diagram emphasizes the importance of critical thinking and the willingness to revise one's approach when necessary. The "Recheck" annotations reinforce the need for careful verification at each step. </details> Figure 1: Reflective behaviors commonly observed in step-by-step mathematical reasoning. We illustrate three categories: rethink, where the model revises its strategy and explores an alternative line of reasoning; and recheck, where the model verifies already-derived intermediate results through re-computation, arithmetic checking, or optimality validation. Recheck behaviors can be further divided into confirmatory cases, which only confirm previous results, and corrective cases, which identify errors and alter the reasoning outcome. Our empirical analysis shows that recheck behaviors overwhelmingly fall into the confirmatory category. Large language models (LLMs) have recently demonstrated substantial progress on complex reasoning tasks. Large Reasoning Models (LRMs) such as OpenAI o1 (OpenAI et al., 2024) and DeepSeek-R1 (DeepSeek-AI et al., 2025) further extend these capabilities through reinforcement learning (RL), producing long reasoning traces that exhibit reflection and self-correction in an increasingly anthropomorphic manner (Yang et al., 2025b). A useful lens is that RL does not introduce reflection from scratch but scales it up: pretrained LLMs only sporadically exhibit reflective behaviors, and these are often shallow and unlikely to improve solutions (Liu et al., 2025b), whereas RL markedly increases both the frequency and apparent effectiveness of reflection by optimizing task-level rewards. This makes reflection a key mechanism for improving reliability in LRMs. However, the same mechanism can also lead to inefficient computation, where models continue to deliberate and repeatedly verify, despite already having sufficient evidence, a phenomenon often described as overthinking (Sui et al., 2025). Together, these observations position reflection as a central but double-edged component of LRMs. While overthinking in reasoning models has been increasingly studied (Zhang et al., 2025a; Fang et al., 2025; Jiang et al., 2025; Zhang et al., 2026), we observe that a large fraction of reflective steps in practice consist of repeated and often trivial rechecks (Figure 1). Through large-scale analysis of reasoning traces, we find that reflective behaviors can be broadly categorized into two types: 1) rethink, where the model revises its reasoning strategy or reformulates the problem, and 2) recheck (i.e., self-verification), where the model verifies the correctness of already-derived intermediate results through re-computation, arithmetic checking, constraint validation, or optimality testing. Our analysis further shows that recheck occurs frequently during model reflective reasoning across models and datasets (Section 3.2). However, most rechecks are confirmatory: they rarely identify errors or change the reasoning outcome (Section 3.3). These observations are consistent with findings from Kang et al. (2025), who shows that verification steps following a candidate final answer rarely change the final result; in contrast, we study self-verification as a manifestation of the model’s epistemic uncertainty during the reasoning process itself, rather than as post hoc confirmation of a final answer. The prevalence of such redundant rechecking presents a practical challenge: although intended to improve reliability, excessive self-verification consumes substantial reasoning budget and yields diminishing corrective benefit, revealing a mismatch between how often rechecking is performed and how often it is actually useful. This raises a central question: when is self-verification actually worth performing during reasoning? In human problem solving, self-verification is rarely applied uniformly. When encountering a familiar operation, such as taking derivatives of a standard expression or checking a routine constraint, humans often rely on accumulated confidence and proceed without rechecking every step, knowing that similar derivations have rarely failed in the past. Inspired by this, we argue that effective reasoning requires selective self-verification: verifications should be executed aggressively in contexts where errors are likely and conservatively when prior evidence suggests high confidence. Rather than treating self-verification as an unconditional safeguard, it should be guided by experience, allowing the reasoning process to allocate effort where it is most likely to be beneficial. Motivated by this perspective, we propose an experience-driven framework for selective self-verification at test-time. Our approach equips a reasoning model with access to past self-verification experience, allowing it to estimate whether a newly initiated verification step is likely to be useful. Concretely, during inference, we first detect the activation of self-verification behaviors using a lightweight trained identifier. Upon detection, we retrieve similar verification episodes from an experience pool constructed offline. By aggregating historical outcomes, specifically, whether similar rechecks on a certain concrete mathematical manipulations (e.g., taking derivatives) previously corrected errors or merely confirmed correctness, then we can estimate the likelihood that continuing the current verification will be beneficial by a voting strategy. When prior experience indicates that rechecking is unlikely to change the reasoning outcome, we suppress the verification by injecting a brief textual signal and allow the model to proceed to subsequent reasoning steps. Importantly, our method does not modify model parameters, does not truncate necessary reasoning and strategy-level rethinking, and intervenes only on redundant rechecks. Empirically, this selective suppression reduces token usage by up to 20.3% while maintaining comparable accuracy, and in some datasets even yields slight accuracy improvements. 2 Related Work Self-Evolving LLM with Experience Recent work regarding enabling LLMs to self-evolve from experience focuses on mechanisms for accumulating, abstracting, and reusing interaction histories. ExpeL (Zhao et al., 2024) and Contextual Experience Replay (Liu et al., 2025a) introduce training-free experiential learning by distilling and retrieving past interaction trajectories to improve future performance, while Retrospex (Yufei Xiang & Nguyen, 2024) further integrates experience via an offline RL critic to guide action selection. AgentEvolver (Zhai et al., 2025) extends this paradigm by combining self-questioning, self-navigation, and self-attribution to enable continual autonomous improvement. Complementary studies analyze the limits of test-time learning from experience, showing measurable but slower gains compared to humans (Wang et al., 2025a). Other approaches focus on structuring experience for reuse: HiAgent (Hu et al., 2025) hierarchically manages working memory for long-horizon tasks, while Metacognitive Reuse (Didolkar et al., 2025) compresses recurring reasoning into reusable behaviors. Finally, efficiency-oriented methods optimize experiential reasoning by decomposing or truncating reasoning trajectories, including structured multi-turn decomposition (Zeng et al., 2025), self-braking tuning (Zhao et al., 2025), and early stopping informed by reflection analysis (Kang et al., 2025). Efficient Reasoning Recent work on efficient reasoning increasingly focuses on adaptive compute allocation. A line of methods trains models to decide whether to reason, or to switch between fast and slow modes based on input difficulty, including query-level think/no-think decisions and hybrid reasoning strategies (Zhang et al., 2025a; Fang et al., 2025; Jiang et al., 2025; Zhang et al., 2025b). This paradigm has been extended to intrinsic fast–slow switching and multi-format reasoning selection (Zhang et al., 2026; Wu et al., 2025). Finer-grained approaches further adapt computation at the step or process level, for example by leveraging process-level rewards to switch reasoning strategies (Wang et al., 2025b), or by allocating additional computation only to high-value reasoning segments through long–short collaboration (Ning et al., 2025). Complementary analyses observe that reflective reasoning frequently reconfirms the initial answer rather than correcting errors, motivating reflection truncation or early-stopping mechanisms (Kang et al., 2025). In parallel, inference cost has been reduced through adaptive length or budget control and convergence-based stopping criteria (Shen et al., 2025; Liu & Wang, 2025; Mao et al., 2025), while system-oriented model families provide practical reasoning toggles for high-throughput deployment (Bercovich et al., 2025). In contrast to prior work that primarily allocates compute by switching reasoning modes or terminating reasoning early based on difficulty, our approach targets redundant self-verification during inference. We selectively suppress low-utility rechecking behaviors at test time, with reduced reasoning length arising naturally as a consequence rather than an explicit optimization objective. 3 Empirical Analysis All analyses are conducted on rollouts generated by four LLMs, Qwen3-8B (Yang et al., 2025a), QwQ-32B (Team, 2025), gpt-oss-20b (OpenAI, 2025), and DeepSeek-R1-Distill-Qwen-7B (DeepSeek-AI et al., 2025). We evaluate models on four mathematical reasoning benchmarks: AIME24 (MAA, 2024), AIME25 (AIME, 2025), AMC23 (AMC12, 2023) and MATH500 (Hendrycks et al., 2021). 3.1 How frequently do LLMs exhibit reflective behaviour? Recent LLMs generate long Chain-of-Thoughts (CoTs) that frequently include reflective behaviors. These reflections are commonly viewed as a mechanism for improving reasoning reliability, particularly in models trained to deliberate extensively. To better understand the practical role of reflection, we begin by quantifying how frequently such behaviors occur in reasoning traces. <details> <summary>x1.png Details</summary>  ### Visual Description ## Bar Chart: Percentage of Reflections for Different Models ### Overview The image is a horizontal bar chart comparing the "Percentage of Reflections" for different language models across four datasets: MATH500, AMC, AIME25, and AIME24. The models are listed on the vertical axis, and the percentage of reflections is on the horizontal axis. ### Components/Axes * **Vertical Axis (Y-Axis):** Lists the language models: * QwQ-32B * Qwen3-8B * DeepSeek-R1-Distill-Qwen-7B * gpt-oss-20b * **Horizontal Axis (X-Axis):** "Percentage of Reflections (%)" ranging from 0 to 60, with increments of 10. * **Legend (Bottom-Right):** * Blue: MATH500 * Red: AMC * Yellow: AIME25 * Green: AIME24 ### Detailed Analysis Here's a breakdown of the percentage of reflections for each model and dataset: * **QwQ-32B:** * MATH500 (Blue): 47.9% * AMC (Red): 40.8% * AIME25 (Yellow): 39.1% * AIME24 (Green): 39.4% * **Qwen3-8B:** * MATH500 (Blue): 42.3% * AMC (Red): 37.1% * AIME25 (Yellow): 31.8% * AIME24 (Green): 36.4% * **DeepSeek-R1-Distill-Qwen-7B:** * MATH500 (Blue): 34.5% * AMC (Red): 26.8% * AIME25 (Yellow): 33.8% * AIME24 (Green): 31.4% * **gpt-oss-20b:** * MATH500 (Blue): 20.4% * AMC (Red): 10.3% * AIME25 (Yellow): 18.8% * AIME24 (Green): 18.9% ### Key Observations * **MATH500 Performance:** MATH500 generally has the highest percentage of reflections across all models, indicated by the blue bars being the longest for each model. * **gpt-oss-20b Performance:** The gpt-oss-20b model consistently shows the lowest percentage of reflections across all datasets. * **Model Ranking:** QwQ-32B generally outperforms the other models in terms of percentage of reflections. ### Interpretation The bar chart illustrates the performance of different language models in terms of their "Percentage of Reflections" on various datasets. A higher percentage might indicate a greater ability to generate relevant or reflective responses, but this interpretation depends on the specific context and definition of "reflections." The data suggests that: * QwQ-32B is the most reflective model among those tested. * gpt-oss-20b is the least reflective model. * The MATH500 dataset elicits the highest percentage of reflections across all models, suggesting it may be more conducive to reflective responses compared to the other datasets. * The performance differences between models and datasets could be attributed to factors such as model architecture, training data, and the nature of the questions or prompts within each dataset. </details> Figure 2: Percentage of steps classified as reflections. We begin by analyzing reasoning rollouts at the granularity of individual steps. Each rollout is segmented into a sequence of steps using simple formatting cues “\n\n”. Each segmented step is then annotated as either reflective or non-reflective using GPT-5 (OpenAI et al., 2025). The classifier is prompted to determine whether a step constitutes a reflection based on a strict rule: a step is labeled as reflective only if it explicitly refers to the model’s own reasoning process and engages in monitoring, evaluating, or revising that reasoning. Concretely, reflective steps include explicit self-referential or metacognitive language indicating verification, critique, reconsideration, or switching to new reasoning strategies (e.g., “I should check”, “this approach might be wrong”, “let me reconsider”). In contrast, steps that primarily advance the solution, such as performing calculations, applying formulas, or explaining problem-specific logic, are not considered reflective. The exact instructional prompts are provided in Appendix E. Based on these annotations, we compute the proportion of reflective steps within each rollout and present the results in Figure 2. Findings. We observe that across all reasoning-oriented models and benchmarks, reflective steps constitute a substantial portion of model-generated rollouts, often approaching or exceeding one third of all steps. These results indicate that reflection is a systematic and frequent component of LLM reasoning. Interestingly, a common intuition is that reflection should correlate with problem difficulty: harder problems presumably require more exploration, reconsideration, and strategic adjustment, leading to more frequent reflective behavior. However, our results reveal a counterintuitive pattern. For all models, MATH500 exhibits the highest proportion of reflective steps, despite its problems being less difficult than those in AIME. This finding suggests that reflection frequency does not reliably track problem difficulty or the need for deeper reasoning. Instead, reflection appears to be triggered broadly during reasoning, even in settings where extensive deliberation is unlikely to advance the solution. This motivates a closer examination of what kinds of reflection models actually perform. 3.2 What Forms of Reflection do LLMs repeatedly exhibit? In practice, reflective steps may serve qualitatively different functional roles. Some reflections support advanced problem solving by revising strategies or restructuring the solution path, while others merely verify previously derived results without introducing new reasoning. Distinguishing between these roles is essential for understanding whether reflection primarily advances reasoning or instead functions as local self-monitoring. Rethink vs. Recheck. We introduce a functional taxonomy that separates reflective steps into two categories: rethink and recheck (Examples are provided in Figure 1). Rethinks operate at the level of global reasoning strategy. Rather than evaluating a specific intermediate result, they revise assumptions, introduce alternative solution approaches, abandon earlier plans, or reorganize the structure of the reasoning process. These reflections are inherently exploratory and are often necessary for solving complex problems where the initial approach is flawed or incomplete. Rechecks (i.e., self-verification), in contrast, operate at the level of local correctness. They focus on verifying previously stated intermediate results, computations, or logical steps, with the explicit or implicit goal of assessing whether an earlier conclusion is valid. Rechecks may involve recomputation, constraint checking, case testing, or validation of optimality or minimality. Importantly, rechecks do not introduce new solution strategies; they evaluate existing ones. To operationalize this taxonomy, for each step identified as reflective in Section 3.1, we prompt GPT-5 with surrounding context, including preceding and subsequent steps, enabling it to assess the role that the local reflection plays in the overall reasoning trajectory. Each reflective step is then categorized as either a rethink or a recheck, with ambiguous cases labeled as unable to classify. Findings. Figure 3 presents the distribution of reflection types for Qwen3-8B across four benchmarks. Across all datasets, rechecks constitute a substantial fraction of reflective steps, accounting for approximately 40–58% of all reflections. Notably, rechecks make up a larger share of reflections on comparatively simpler datasets, such as AMC and MATH500. This pattern aligns closely with our findings in the previous subsection. There, we show that reflective steps are not more frequent on harder problems, instead, simpler datasets often induce more frequent reflection. The present analysis clarifies that on easier problems, reflection is dominated by local self-verification rather than by meaningful strategy revision. As a result, reflection frequently manifests as repetitive rechecking of intermediate results. This observation motivates a closer examination of whether such rechecks meaningfully contribute to correctness. 3.3 Do Rechecks Truly Identify Errors? If rechecks frequently identify and correct errors, their prevalence would justify self-verification as an essential component of reliable multi-step reasoning. However, if most rechecks simply reaffirm already-correct intermediate results, then a substantial portion of reflective behavior is redundant. We therefore examine whether rechecks in practice meaningfully contribute to error correction. Corrective vs. Confirmatory Rechecks. We categorize rechecks based on their functional outcome. A corrective recheck identifies an error in a previously stated intermediate result and leads to a correction. In contrast, a confirmatory recheck verifies an earlier step but does not uncover any error and does not alter the mid-result. We prompt GPT-5 to assess whether the recheck reveals an actual mistake and results are also presented in Figure 3. <details> <summary>Figs/reflection_pie_charts_qwen.png Details</summary>  ### Visual Description ## Pie Charts: Recheck Classification ### Overview The image contains four pie charts, each representing the distribution of different types of rechecks ("Confirmatory Rechecks", "Corrective Rechecks", "Rethinks", and "Unable to Classify") for different datasets: AIME24, AIME25, AMC, and MATH500. The pie charts are arranged in a 2x2 grid. The legend is located at the bottom of the image. ### Components/Axes * **Pie Charts:** Four pie charts labeled AIME24, AIME25, AMC, and MATH500. * **Categories:** * Confirmatory Rechecks (light green) * Corrective Rechecks (light yellow) * Rethinks (light red) * Unable to Classify (light blue) * **Legend:** Located at the bottom of the image, associating colors with recheck types. ### Detailed Analysis or ### Content Details **AIME24 (Top Left)** * Confirmatory Rechecks (light green): 35.5% * Corrective Rechecks (light yellow): 5.2% * Rethinks (light red): 49.7% * Unable to Classify (light blue): 9.7% **AIME25 (Top Right)** * Confirmatory Rechecks (light green): 38.7% * Corrective Rechecks (light yellow): 4.8% * Rethinks (light red): 39.8% * Unable to Classify (light blue): 16.8% **AMC (Bottom Left)** * Confirmatory Rechecks (light green): 49.9% * Corrective Rechecks (light yellow): 4.2% * Rethinks (light red): 39.8% * Unable to Classify (light blue): 6.2% **MATH500 (Bottom Right)** * Confirmatory Rechecks (light green): 52.8% * Corrective Rechecks (light yellow): 3.2% * Rethinks (light red): 38.6% * Unable to Classify (light blue): 5.4% ### Key Observations * **Rethinks vs. Confirmatory Rechecks:** In AIME24, "Rethinks" constitute the largest portion (49.7%), while in AMC and MATH500, "Confirmatory Rechecks" are the largest (49.9% and 52.8% respectively). * **Corrective Rechecks:** "Corrective Rechecks" consistently have the smallest percentage across all datasets, ranging from 3.2% to 5.2%. * **Unable to Classify:** The "Unable to Classify" category varies, with AIME25 having the highest percentage (16.8%) and MATH500 having the lowest (5.4%). ### Interpretation The pie charts provide a comparative view of how different types of rechecks are distributed across various datasets (AIME24, AIME25, AMC, MATH500). The data suggests that the nature of rechecks varies depending on the dataset. For instance, AIME24 has a higher proportion of "Rethinks" compared to "Confirmatory Rechecks," while AMC and MATH500 show the opposite trend. The consistently low percentage of "Corrective Rechecks" might indicate that these types of errors are less frequent or are handled differently in the respective datasets. The variability in the "Unable to Classify" category could reflect differences in the complexity or ambiguity of the problems within each dataset. </details> Figure 3: Proportion of reflection types for Qwen3-8B annotated by GPT-5. More results are presented in Appendix B. Human evaluation results are presented in Appendix C. <details> <summary>Figs/method.png Details</summary>  ### Visual Description ## Diagram: Experience-driven LLM Reasoning ### Overview The image is a diagram illustrating the process of experience-driven LLM reasoning, broken down into three main stages: Experience Pool Construction, Recheck Activation Detection, and Experience-driven LLM Reasoning. It shows how an LLM uses past experiences to improve its reasoning process, particularly in mathematical problem-solving. ### Components/Axes * **Header Regions:** * Top-left: "Experience Pool Construction" (blue box) * Top-center: "Recheck Activation Detection" (green box) * Top-right: "Experience-driven LLM Reasoning" (orange box) * **Components:** * **Experience Pool Construction:** * LLM (brain icon with "LLM" label) * "Rollouts on Various Problems" (represented by a stack of papers) * "Extract Recheck Episodes" (represented by a circular arrow icon) * Text bubble: "... (calculations about taking derivatives) I need to check if this is correct... It seems My previous calculation is right..." * "Annotate Outcome (Necessary / Unnecessary)" (represented by a circular arrow icon) * "Experience Pool {e1, e2, ..., en}" (represented by a database icon) * **Recheck Activation Detection:** * "Binary Classifier Training" * SLM (represented by a gear icon inside a document) * "Necessity Estimation Top-k Vote" * "Search" (represented by a document with a magnifying glass) * A stick figure with a thought bubble: "Should I continue with check-up?" * Text: "m/k > τ" * A person sitting at a computer: "Oh, I rarely made mistakes in taking derivatives!" * **Experience-driven LLM Reasoning:** * LLM (brain icon with "LLM" label) * Text bubble: "Please answer the following math question and think step by step. ... (taking derivatives)(Eq.2) Wait, let me check derivatives in equation (2) to make sure. This result does not require further checking, let me proceed to the next step. So now, we need to find ... (continue reasoning) Final Answer: \boxed{204}" * "Recheck Identified" * "Inject verification suppression signal" ### Detailed Analysis or Content Details 1. **Experience Pool Construction:** * An LLM performs rollouts on various problems. * Recheck episodes are extracted from these rollouts. * The outcomes are annotated as either necessary or unnecessary. * This information is stored in an experience pool. 2. **Recheck Activation Detection:** * A binary classifier is trained, potentially using an SLM (Statistical Language Model). * Necessity estimation is performed using a top-k vote. * A search is conducted. * The system determines whether to continue with a check-up. * The condition "m/k > τ" is present, suggesting a threshold-based decision. * A statement indicates that mistakes in taking derivatives are rare. 3. **Experience-driven LLM Reasoning:** * The LLM receives a math question and thinks step by step. * It identifies a need to recheck derivatives in equation (2). * Based on the recheck, it determines that further checking is unnecessary. * The LLM proceeds to the next step and provides a final answer of 204. * A verification suppression signal is injected. ### Key Observations * The diagram illustrates a closed-loop system where the LLM learns from its experiences and uses this knowledge to improve its reasoning process. * The recheck activation detection component plays a crucial role in determining when and how to verify intermediate steps. * The condition "m/k > τ" suggests a threshold-based decision-making process. * The injection of a verification suppression signal indicates a mechanism to prevent unnecessary checks. ### Interpretation The diagram demonstrates a sophisticated approach to improving LLM reasoning by incorporating experience. The LLM learns from past mistakes and successes, allowing it to make more informed decisions about when and how to verify its intermediate steps. This approach can lead to more efficient and accurate problem-solving. The "m/k > τ" condition and the verification suppression signal suggest that the system is designed to balance the need for verification with the desire to avoid unnecessary checks. The final answer of 204 indicates that the LLM is capable of solving mathematical problems using this experience-driven approach. </details> Figure 4: Overview of the experience-driven verification control framework. Recheck episodes are collected and annotated offline to form an experience pool, which captures how often rechecks succeed in correcting errors for specific mathematical manipulations or formula-level derivations, e.g. taking derivatives. The experience pool will be consulted at the test-time to suppress redundant self-verification during LLM reasoning. Findings. We find that the overwhelming majority of rechecks are confirmatory rather than corrective. Across datasets, approximately 85–95% of rechecks merely confirm prior reasoning and do not change intermediate results or final answers. And this pattern is consistent across both simpler and harder benchmarks. These results indicate that although models frequently engage in self-verification, such behavior seldom leads to error correction. All these findings reveal a clear inefficiency: a large number of tokens are evoked to self-verify but almost never change the outcome, the predominance of confirmatory rechecks suggests that self-verification is often overused in current LLM reasoning. 4 Experience-Guided Self-Verification The analysis in the previous section shows that large language models frequently initiate self-verification during reasoning, even in situations where such verification rarely alters intermediate results. As a result, successive self-verification actions often incur additional computational cost while providing limited corrective benefit. This observation motivates a central question: should every verification attempt be carried out, or can some of them be safely avoided? Intuitively, self-verification becomes redundant when similar reasoning patterns have consistently produced correct results on certain math formulas. Human problem solving offers an analogy. When encountering familiar mathematical forms, such as routine re-computations, constraint checks, or optimality and minimality validations, people often rely on prior experience, reasoning that similar derivations have worked correctly many times before. In such cases, explicit rechecking is often unnecessary. Inspired by this perspective, we propose an experience-driven self-verification control framework. The core idea is simple: when a model begins to verify a previously stated intermediate result, we consult historical self-verification outcomes from similar contexts and formulas. If past experience indicates that such verification almost never uncovers errors, we discourage the model from continuing the recheck. Otherwise, verification proceeds as usual. Our approach operates entirely at test time, does not require training or modifying the underlying language model, and introduces minimal inference overhead. While suppressing redundant verification naturally shortens reasoning trajectories and reduces latency, these effects arise as a consequence of avoiding unnecessary verification rather than as an explicit objective. 4.1 Experience Memory Construction To enable experience-driven suppression of redundant self-verification, we first construct an experience pool that records historical verification outcomes observed in large language model reasoning. This process is illustrated in the left panel of Figure 4. Extracting Recheck Activations. We begin by collecting reasoning rollouts from a target large language model across a diverse set of problem instances. The same model is used both for experience collection and for inference-time reasoning, ensuring that the extracted verification patterns are representative of the target model’s native behavior. Given a reasoning rollout, we aim to collect experiences where the LLM is performing a recheck. To achieve that, we provide the whole rollout to GPT-5 (OpenAI et al., 2025) to identify and extract all sentences that initiate a recheck of a previously stated intermediate result, such as re-computation, constraint verification, candidate testing, or optimality validation. The set of sentences marks the activation of self-verification behavior. We intentionally focus only on recheck activations and exclude rethink behaviors, such as strategy shifts or reformulations, as rethinking plays a crucial role in correcting reasoning trajectories and should not be suppressed. To improve reliability, we apply additional filtering to ensure that extracted set can match and correspond to explicit verification attempts present in the original rollout. We denote the collection of recheck activation sentences as $\mathcal{S}$ . Outcome Annotation. For each identified recheck activation, we extract a self-verification episode, which consists of the local reasoning context and the subsequent verification steps, by taking a fixed-size context window surrounding the activation sentence. For each extracted self-verification episode, we prompt GPT-5 (OpenAI et al., 2025) again to annotate whether the recheck is necessary or unnecessary, Specifically, 1) Necessary: if the verification identifies an error, or corrects an intermediate result (corrective); 2) Unnecessary, if the verification confirms correctness and does not change the reasoning outcome (confirmatory). Episodes for which GPT-5 cannot make a clear determination are discarded to ensure annotation reliability. Each annotated self-verification is stored as an experience unit. Formally, we define the experience pool as $$ \mathcal{C}=\{e_{1},e_{2},\dots,e_{n}\}, \tag{1} $$ where each experience unit $e_{i}$ consists of $e_{i}=(c_{i},y_{i})$ . Here, $c_{i}$ denotes a textual representation of the self-verification episode context extracted around a recheck activation, and $y_{i}∈\{0,1\}$ is a binary label indicating whether the recheck is necessary ( $y_{i}=0$ ) or unnecessary ( $y_{i}=1$ ). The resulting experience pool $\mathcal{C}$ serves as a reusable memory of historical self-verification behavior, capturing how often rechecks succeed in correcting errors for specific local reasoning patterns, such as concrete mathematical manipulations or formula-level derivations (e.g., taking derivatives of a quadratic equation in Figure 4). Table 1: Accuracy (Pass@1) and average reasoning length for Base, Full-suppress, and Experience-Driven Suppression (EDS). EDS reduces reasoning length while preserving accuracy relative to the base model. † indicates numbers reported in Kang et al. (2025). Model Dataset Accuracy (%) Length Base Full-supress EDS Base Full-supress EDS Qwen3-8B AIME24 74.58 70.63 (-3.95) 72.92 (-1.66) 14605 12734 (-12.8%) 13296 (-9.0%) AIME25 67.71 66.67 (-1.04) 70.00 (+2.29) 17133 15713 (-8.3%) 16086 (-6.1%) AMC 95.62 96.25 (+0.63) 98.75 (+3.13) 8091 6564 (-18.9%) 6893 (-14.8%) Math500 95.80 95.20 (-0.60) 97.20 (+1.40) 4939 3935 (-20.3%) 4110 (-16.8%) Olympiad Bench 80.42 79.53 (-0.89) 79.82 (-0.60) 10480 9540 (-9.0%) 9739 (-7.1%) Average 80.95 79.56 (-1.39) 81.43 (+0.48) 11361 10071 (-11.4%) 10386 (-8.6%) FTM (Average) † Base Truncate all Selective truncate Base Truncate all Selective truncate (Kang et al., 2025) 84.70 80.90 (-3.80) 81.80 (-2.90) 15,125 10,601 (-29.9%) 11,414 (-24.5%) DeepSeek-7B AIME24 57.50 56.67 (-0.83) 58.75 (+1.25) 11237 10105 (-10.1%) 10478 (-6.8%) AIME25 39.38 35.42 (-3.96) 36.46 (-2.92) 12489 11221 (-10.1%) 11680 (-7.4%) AMC 91.25 90.00 (-1.25) 90.63 (-0.62) 5401 5067 (-6.2%) 5145 (-4.7%) Math500 90.60 87.20 (-3.40) 89.80 (-0.80) 3303 2726 (-17.5%) 2891 (-12.5%) Olympiad Bench 69.00 66.91 (-2.09) 67.95 (-1.05) 7913 7002 (-11.5%) 7183 (-9.2%) Average 66.66 64.21 (-2.45) 65.78 (-0.88) 8386 7467 (-11.0%) 7736 (-7.75%) QWQ-32B AIME2024 79.17 78.75 (-0.42) 83.33 (+4.16) 11237 10105 (-13.4%) 10478 (-9.5%) AIME2025 68.54 64.16 (-4.38) 65.63 (-2.91) 15811 14133 (-10.6%) 14908 (-5.7%) AMC 97.50 93.75 (-3.75) 95.00 (-2.50) 7542 6526 (-13.5%) 6719 (-10.9%) Math500 97.00 95.60 (-1.40) 97.00 (-0.00) 4659 3768 (-19.1%) 3940 (-15.4%) Olympiad Bench 81.90 81.45 (-0.45) 83.53 (+1.63) 9602 8454 (-12.0%) 8710 (-9.3%) Average 82.91 81.21 (-1.70) 83.48 (+0.57) 10293 8988 (-12.7%) 9379 (-8.9%) 4.2 Experience-Enhanced Inference Detecting Recheck Activation During inference, a key challenge is to identify when the model is about to start a recheck of a previously stated intermediate result. A natural approach is to instruct the model to explicitly mark such behaviors and emit a special operation when it plans to recheck, analogous to pipelines that interleave internal thoughts with tool calls (e.g., Search-o1 (Li et al., 2025)). However, we find that the model often struggles to reliably follow instructions within the thinking part (inside <think> tags). Motivated by Kang et al. (2025), we instead adopt a separate, lightweight identifier that detects whether a generated sentence initiates a recheck and such lightweight components introduce only limited inference latency (Kang et al., 2025). We implement the recheck activation identifier as a binary classifier. Training data is derived from the same reasoning rollouts used for experience pool construction. Specifically, positive examples are given by $\mathcal{S}$ collected in Section 4.1. Positive examples consist of recheck activation sentences confirmed by GPT-5 during the extraction process described. Hard negative examples arise naturally during this filtering stage: sentences that are initially extracted as potential recheck activations but subsequently rejected by GPT-5 as not constituting true rechecks are treated as hard negatives. The trained classifier achieves over 97% accuracy on the constructed validation and test splits. Experience Retrieval and Necessity Estimation When the identifier predicts that the current sentence initiates a recheck, we construct a query by extracting a fixed-size context window before the recheck activation. This local context typically contains concrete mathematical manipulations or formula-level derivations that characterize the recheck being attempted. We use this context as a query to retrieve the top- $k$ most similar experience units from the experience pool $\mathcal{C}$ using a sparse retriever (BM25 (Robertson & Zaragoza, 2009)), which is effective for matching symbolic expressions and mathematical operations while introducing minimal inference-time overhead. Let the retrieved set be $\{e_{i_{1}},...,e_{i_{k}}\}$ , where each $e_{i_{j}}=(c_{i_{j}},y_{i_{j}})$ . To estimate whether the current recheck is likely to be redundant, we do not forward the retrieved candidate texts to the LLM and ask it to decide whether to proceed with rechecking, as doing so would consume additional token budget and introduce new reasoning steps. Instead, we aggregate the outcome labels of the retrieved experience units. Intuitively, if rechecks on similar local reasoning patterns have rarely corrected errors in the past, continuing the current verification is unlikely to change the outcome. Concretely, we estimate the likelihood that a recheck is unnecessary as $$ \mathcal{P}_{\text{unnec}}=\frac{1}{k}\sum_{j=1}^{k}\mathbb{I}[y_{i_{j}}=1], \tag{2} $$ where $\mathbb{I}[·]$ is the indicator function. If $\mathcal{P}_{\text{unnec}}$ exceeds a predefined threshold $\tau$ , we treat the current recheck as likely unnecessary. Experience-Driven Suppression (EDS) If a recheck is estimated to be unnecessary, we inject a short verification suppression signal immediately after the activation sentence (e.g., “This result does not require further checking, let me proceed to the next step.”) We observe that the specific wording of the verification suppression signal affects its effectiveness. Language models exhibit discourse-level attractors for resolving epistemic uncertainty (e.g., phrases such as “wait” or “maybe”), which can cause verification behavior to persist even after an initial interruption. In practice, suppression signals that explicitly assert epistemic closure (e.g., “is correct”) or provide a forward redirection (e.g., “proceed”) are more effective at closing verification-related discourse.. This signal serves as a lightweight directive that discourages the model from continuing the verification process and encourages it to proceed with subsequent reasoning steps. Empirically, we observe that after receiving such a suppression signal, the model typically skips subsequent re-computation or validation steps and proceeds directly to the next stage of reasoning. Importantly, this intervention targets only recheck behaviors; we do not intervene on rethink behaviors, which are often essential for solving hard problems. As shown in Section 5, suppressing redundant rechecks leads to a consistent reduction in reasoning length, which emerges naturally from avoiding unnecessary self-verification. 5 Experiments 5.1 Experiment Setups We evaluate the effectiveness of Experience-Driven Suppression (EDS) on five mathematical reasoning benchmarks: AIME24 (MAA, 2024), AIME25 (AIME, 2025), AMC23 (AMC12, 2023), MATH500 (Hendrycks et al., 2021), and Olympiad Bench (He et al., 2024). Experiments are conducted on three models: Qwen3-8B (Yang et al., 2025a), QwQ-32B (Team, 2025), and DeepSeek-R1-Distill-Qwen-7B (DeepSeek-AI et al., 2025). We compare three inference settings. Base: standard model inference without any intervention. Full-suppress: injecting a suppression signal whenever a recheck activation is identified. First Try Matters (FTM) (Kang et al., 2025), a test-time method truncates the thinking immediately after the first candidate final answer is produced. EDS applies selective suppression within the thinking process: mid-rechecks are suppressed only when historical experience indicates that the verification is unlikely to be beneficial. For EDS, we construct the experience pool using reasoning rollouts collected from the Deepscaler dataset (Luo et al., 2025), which consists of AIME and AMC problems prior to 2023. Using GPT-5 We use the model gpt-5-2025-08-07. (OpenAI et al., 2025), we extract recheck activation set $\mathcal{S}$ and annotate whether each recheck is necessary or unnecessary, resulting in an experience pool of 10k units with an unnecessary-to-necessary ratio of approximately 7:3. Recheck activations during inference are detected using a RoBERTa-base (Liu et al., 2019). The classifier is trained on 4,245 instances derived from $\mathcal{S}$ , with a positive-to-negative ratio of 1:3 and a balanced split between hard and easy negatives. Easy negatives are uniformly sampled from non-verification sentences in the original rollouts. We train the classifier for 3 epochs with a learning rate of 2e-5, achieving 97% accuracy on the test split. During EDS inference, we retrieve the top-30 most similar experience units using BM25 (Robertson & Zaragoza, 2009) and suppress a recheck if the proportion of unnecessary experiences exceeds a threshold $\tau=0.8$ . This threshold is set above the base unnecessary rate of the experience pool (0.7). 5.2 Main Restuls Table 1 reports accuracy and average length. Across all models and datasets, full-suppress consistently shortens reasoning traces, reducing average length by approximately 11–13%. However, this intervention leads to noticeable accuracy degradation, with average drops ranging from $-1.4$ to $-2.5$ points. FTM achieves substantially larger reductions in reasoning length by truncating all content following the first candidate answer. While effective in reducing token usage, this aggressive truncation incurs a pronounced accuracy drop. In particular, for Qwen3-8B, FTM reduces average reasoning length up to 30% but degrades accuracy by $-3.8$ points. This suggests that their truncation may discard rethink behaviors, which play a crucial role in reasoning and should not be indiscriminately removed. In contrast, EDS targets redundant recheck behaviors while excluding rethink cases from suppression. EDS achieves consistent reductions in reasoning length while maintaining (in many cases improving) accuracy relative to the base model. For Qwen3-8B and QwQ-32B, EDS improves average accuracy by +0.48 and +0.57 points respectively, while shortening reasoning traces by approximately 9% on average and up to 20.3% on MATH500. These results indicate that leveraging historical verification outcomes provides a reliable signal for estimating when a recheck is unlikely to be beneficial, enabling selective suppression without materially affecting correctness. Overall, the results indicate that reflections are neither uniformly harmful nor uniformly necessary. While truncating reflection wholesale (as in FTM) can substantially reduce token, it risks removing rethink and necessary recheck behaviors. By selectively suppressing rechecks based on prior experience, EDS enables models to bypass unnecessary rechecks while preserving self-verification steps that meaningfully contribute to correctness, achieving a more favorable accuracy–efficiency trade-off. 5.3 Accuracy–Efficiency Trade-off <details> <summary>Figs/threshold_accuracy.png Details</summary>  ### Visual Description ## Line Chart: Pass@1 Accuracy vs. Threshold ### Overview The image is a line chart showing the relationship between "Threshold" (x-axis) and "Pass@1 Accuracy" (y-axis). The chart displays a single data series represented by a light blue line with circular markers. The background has a light gray grid. ### Components/Axes * **X-axis (Horizontal):** "Threshold" with values ranging from 0.0 to 1.0, incrementing by 0.2. * **Y-axis (Vertical):** "Pass@1 Accuracy" with values ranging from 0.70 to 0.75, incrementing by 0.01. * **Data Series:** A single light blue line with circular markers representing the Pass@1 Accuracy at different threshold values. ### Detailed Analysis The light blue line represents the Pass@1 Accuracy. * **Threshold 0.0:** Pass@1 Accuracy is approximately 0.706. * **Threshold 0.2:** Pass@1 Accuracy is approximately 0.704. * **Threshold 0.4:** Pass@1 Accuracy is approximately 0.712. * **Threshold 0.6:** Pass@1 Accuracy is approximately 0.723. * **Threshold 0.8:** Pass@1 Accuracy is approximately 0.741. * **Threshold 1.0:** Pass@1 Accuracy is approximately 0.746. The trend of the light blue line is initially decreasing slightly from 0.0 to 0.2, then generally increasing from 0.2 to 1.0. ### Key Observations * The Pass@1 Accuracy generally increases as the Threshold increases from 0.2 to 1.0. * There is a slight dip in Pass@1 Accuracy between Threshold 0.0 and 0.2. * The highest Pass@1 Accuracy is observed at Threshold 1.0. ### Interpretation The chart suggests that increasing the threshold generally improves the Pass@1 Accuracy, with a slight initial decrease at very low threshold values. This indicates that a higher threshold is generally beneficial for achieving better accuracy, up to the maximum threshold value of 1.0 shown in the chart. The initial dip might suggest that very low thresholds introduce some noise or instability in the system being evaluated. </details> (a) Pass@1 <details> <summary>Figs/threshold_length_reduction.png Details</summary>  ### Visual Description ## Line Chart: Length Reduction vs. Threshold ### Overview The image is a line chart showing the relationship between "Threshold" (x-axis) and "Length Reduction (%)" (y-axis). The chart displays how the length reduction changes as the threshold increases. The line is light blue and has circular markers at each data point. The background has a faint grid. ### Components/Axes * **X-axis:** "Threshold" with values ranging from 0.0 to 1.0 in increments of 0.2. * **Y-axis:** "Length Reduction (%)" with values ranging from 0 to 12 in increments of 2. * **Data Series:** A single light blue line representing the length reduction at different threshold values. ### Detailed Analysis The light blue line shows the following approximate data points: * **Threshold 0.0:** Length Reduction ~12.8% * **Threshold 0.1:** Length Reduction ~12.7% * **Threshold 0.2:** Length Reduction ~12.8% * **Threshold 0.3:** Length Reduction ~12.6% * **Threshold 0.4:** Length Reduction ~12.3% * **Threshold 0.5:** Length Reduction ~12.0% * **Threshold 0.6:** Length Reduction ~11.5% * **Threshold 0.7:** Length Reduction ~10.9% * **Threshold 0.8:** Length Reduction ~9.0% * **Threshold 0.85:** Length Reduction ~5.8% * **Threshold 0.9:** Length Reduction ~3.7% * **Threshold 0.95:** Length Reduction ~0.5% * **Threshold 1.0:** Length Reduction ~0.3% The line is relatively flat from a threshold of 0.0 to 0.6, indicating a stable length reduction. After a threshold of 0.6, the line begins to slope downward, indicating a decreasing length reduction as the threshold increases. The most significant drop occurs between thresholds of 0.8 and 0.9. ### Key Observations * The length reduction is relatively constant at higher values (around 12-13%) for threshold values between 0.0 and 0.6. * There is a sharp decline in length reduction as the threshold increases from 0.7 to 1.0. * The length reduction approaches zero as the threshold approaches 1.0. ### Interpretation The chart suggests that increasing the threshold beyond a certain point (around 0.6) significantly reduces the length reduction. This implies that there is an optimal threshold value below 0.6 that maximizes the length reduction. The sharp decline indicates that higher threshold values are detrimental to achieving significant length reduction. The data demonstrates an inverse relationship between the threshold and length reduction beyond a certain threshold value. </details> (b) Length reduction (%) Figure 5: Accuracy–efficiency trade-off. <details> <summary>Figs/avg_count.png Details</summary>  ### Visual Description ## Bar Chart: Average Count by Strength ### Overview The image is a horizontal bar chart comparing the average count of "Loop" and "Successful" outcomes for "Weak" and "Strong" categories. The chart displays two horizontal bars for each category (Weak and Strong), each bar segmented into two colored sections representing the average count of "Loop" (light red) and "Successful" (light green) outcomes. ### Components/Axes * **Y-axis:** Categorical, with two categories: "Weak" (top) and "Strong" (bottom). * **X-axis:** Numerical, labeled "Average Count", ranging from 0 to 40 with increments of 5. * **Legend:** Located in the top-right corner, indicating "Loop" is represented by a light red bar and "Successful" by a light green bar. ### Detailed Analysis * **Weak:** * "Loop" (light red): Approximately 4. * "Successful" (light green): Approximately 21. * Total Average Count: Approximately 25. * **Strong:** * "Loop" (light red): Approximately 4. * "Successful" (light green): Approximately 31. * Total Average Count: Approximately 35. ### Key Observations * The average count of "Loop" is the same for both "Weak" and "Strong" categories, at approximately 4. * The average count of "Successful" is significantly higher for the "Strong" category (approximately 31) compared to the "Weak" category (approximately 21). * The "Strong" category has a higher total average count than the "Weak" category. ### Interpretation The data suggests that the "Strong" category is more likely to result in "Successful" outcomes compared to the "Weak" category. The "Loop" outcome appears to be independent of the "Weak" or "Strong" category, as its average count remains constant across both. This could indicate that the factor determining "Weak" vs "Strong" has a positive correlation with "Successful" outcomes, but no correlation with "Loop" outcomes. </details> Figure 6: Average recheck activation count per rollout. Figure 5 illustrates how the behavior of EDS varies as we adjust the voting threshold $\tau$ , which controls how confidently a recheck must be judged unnecessary before suppression is applied. Increasing $\tau$ makes suppression more conservative, resulting in fewer rechecks being filtered. As shown in Figure 5, accuracy increases steadily with larger $\tau$ and saturates around $\tau≈ 0.95$ , as higher thresholds reduce the likelihood of suppressing rechecks that could be corrective. In contrast, length reduction decreases as $\tau$ increases. In particular, when $\tau$ lies in the range $0.7≤\tau≤ 0.9$ , length reduction drops rapidly. Together, these trends reveal a clear accuracy–efficiency trade-off: lower thresholds favor stronger suppression and greater reductions in reasoning length, while higher thresholds preserve more verification behavior and yield higher accuracy. This trade-off allows EDS to be flexibly configured according to the desired balance between computational efficiency and reasoning reliability. 5.4 Case study <details> <summary>Figs/case.png Details</summary>  ### Visual Description ## Decision-Making Process: Intervention Scenarios ### Overview The image presents three scenarios ("No Intervention", "Strong Signal", and "Weak Signal") illustrating a decision-making process, likely within an automated system, related to verifying the similarity of triangles. Each scenario includes a textual description of the process, highlighting when and why a recheck is activated, and when injected signals influence the decision. ### Components/Axes * **Titles:** * No Intervention (Top) * Strong Signal (Middle) * Weak Signal (Bottom) * **Textual Descriptions:** Each scenario contains a block of text describing the steps and reasoning involved in determining triangle similarity. * **Annotations:** Red arrows and dashed boxes highlight specific actions or checks within the process. * **Labels:** * "Activation of recheck" (Red arrow pointing to a specific check) * "Injected signal" (Blue text indicating external influence) ### Detailed Analysis or ### Content Details **1. No Intervention:** * **Text:** * "Wait, perhaps triangle ABD is similar to triangle ACB, because angle ADB = angle ACB, and angle BAD is shared. Similarly, triangle ADC is similar to triangle ABC. Let me check that." * "In triangle ABD and triangle ACB: angle ADB = angle ACB (as established). Checking" (Enclosed in a dashed red box) * "Therefore, by AA similarity, triangle ABD ~ triangle ACB. Similarly, in triangle ADC and triangle ABC: angle ADC = angle ABC, angle DAC = angle BAC. Therefore, triangle ADC ~ triangle ABC..." * **Activation of recheck:** A red arrow points from the text "Activation of recheck" to the "Checking" statement within the dashed red box. **2. Strong Signal:** * **Text:** * "Wait, perhaps triangle ABD is similar to triangle ACB, because angle ADB = angle ACB, and angle BAD is shared. Similarly, triangle ADC is similar to triangle ABC. Let me check that." * "This result does not require further checking, let {me proceed to the next step. Injected signal" * "Therefore, triangle ABD is similar to triangle ACB. Then, triangle ADC is also similar to triangle ABC by the corresponding angle relationships..." * **Injected signal:** The text "Injected signal" is written in blue. * **Activation of recheck:** A red arrow points from the text "Activation of recheck" to the phrase "This result does not require further checking, let {me proceed to the next step." **3. Weak Signal:** * **Text:** * "Wait, perhaps triangle ABD is similar to triangle ACB, because angle ADB = angle ACB, and angle BAD is shared. Similarly, triangle ADC is similar to triangle ABC. Let me check that." * "No need to check. Injected signal" * "Wait, but let me check the similarity." * "No need to check. Injected signal" * "Alternatively, maybe I should check this again." * "No need to check. Injected signal" * "So, seems like all steps are correct. But let me check again. ......(Loop)" * **Injected signal:** The text "Injected signal" is written in blue and appears multiple times. * **Activation of recheck:** A red arrow points from the text "Activation of recheck" to the phrase "Wait, but let me check the similarity." ### Key Observations * The "No Intervention" scenario represents a standard verification process. * The "Strong Signal" scenario shows how a positive signal can bypass further checks. * The "Weak Signal" scenario demonstrates a situation where multiple negative signals lead to repeated checks and potential looping. * The "Injected signal" is always blue. ### Interpretation The image illustrates how different signals (or lack thereof) can influence a decision-making process related to geometric proofs. The "No Intervention" scenario represents a baseline, where each step is verified. The "Strong Signal" scenario shows how a confident result can streamline the process, skipping unnecessary checks. Conversely, the "Weak Signal" scenario highlights the impact of uncertainty, leading to repeated checks and a potential loop, suggesting a need for more robust decision-making criteria or additional information. The injected signals appear to be external factors influencing the decision to check or not check. </details> Figure 7: Success and failure cases. To qualitatively illustrate how verification suppression affects model behavior, Figure 7 presents representative examples under three settings: no intervention, strong suppression, and weak suppression. Without intervention, once a recheck is triggered, the model typically proceeds with explicit verification. Injecting a strong suppression signal that asserts epistemic closure and provides forward redirection reliably terminates the verification process. The model accepts the signal as closing the uncertainty and continues with subsequent reasoning. In contrast, weak suppression signals fail to close the verification discourse and may instead provoke repeated recheck attempts, leading to activation loops in which verification is repeatedly re-initiated. Figure 6 shows that strong signals achieve a higher rate of successful suppression, although looping still occurs. To further stabilize suppression in practice, we introduce a simple cooldown mechanism: after a suppression is applied, recheck detection is temporarily disabled for 3 steps, preventing immediate re-activation of verification. 6 Conclusion We revisit reflection in LRMs through the lens of self-verification, and show it is dominated by repeated rechecks that rarely alter downstream reasoning, exposing a mismatch between verification frequency and utility. Without modifying model parameters, we propose an experience-driven test-time controller that detects recheck activations, retrieves similar past verification episodes from an offline pool, and selectively suppresses low-utility checks while preserving strategy-level rethinking. Our method consistently shortens reasoning while maintaining or slightly improving accuracy across models and benchmarks, suggesting that past verification outcomes can guide when verifications are needed. Impact Statement This paper presents work whose goal is to advance the field of machine learning by improving the efficiency and controllability of test-time reasoning in LLMs. By reducing redundant self-verification while maintaining solution quality, the proposed approach can lower inference-time compute and latency, enabling more scalable deployment of reliable reasoning models and broader access to such capabilities across resource-constrained settings. We anticipate the primary impacts of this work to be increased energy efficiency and cost-effectiveness of model inference, as well as a clearer methodological foundation for understanding and optimizing reflective behaviors in reasoning. References - AIME (2025) AIME. AIME Problems and Solutions, 2025. https://artofproblemsolving.com/wiki/index.php/AIME_Problems_and_Solutions, 2025. Accessed: January 19, 2026. - AMC12 (2023) AMC12. AMC 12 Problems and Solutions. https://artofproblemsolving.com/wiki/index.php/AMC_12_Problems_and_Solutions, 2023. Accessed: January 19, 2026. - Bercovich et al. (2025) Bercovich, A., Levy, I., Golan, I., Dabbah, M., El-Yaniv, R., Puny, O., Galil, I., Moshe, Z., Ronen, T., Nabwani, N., Shahaf, I., Tropp, O., Karpas, E., Zilberstein, R., Zeng, J., Singhal, S., Bukharin, A., Zhang, Y., et al. Llama-nemotron: Efficient reasoning models, 2025. URL https://arxiv.org/abs/2505.00949. - DeepSeek-AI et al. (2025) DeepSeek-AI, Guo, D., Yang, D., Zhang, H., Song, J., Zhang, R., Xu, R., Zhu, Q., Ma, S., Wang, P., et al. Deepseek-r1: Incentivizing reasoning capability in llms via reinforcement learning, 2025. URL https://arxiv.org/abs/2501.12948. - Didolkar et al. (2025) Didolkar, A., Ballas, N., Arora, S., and Goyal, A. Metacognitive reuse: Turning recurring llm reasoning into concise behaviors, 2025. URL https://arxiv.org/abs/2509.13237. - Fang et al. (2025) Fang, G., Ma, X., and Wang, X. Thinkless: Llm learns when to think. Advances in neural information processing systems, 2025. - He et al. (2024) He, C., Luo, R., Bai, Y., Hu, S., Thai, Z. L., Shen, J., Hu, J., Han, X., Huang, Y., Zhang, Y., et al. Olympiadbench: A challenging benchmark for promoting agi with olympiad-level bilingual multimodal scientific problems. arXiv preprint arXiv:2402.14008, 2024. URL https://aclanthology.org/2024.acl-long.211/. - Hendrycks et al. (2021) Hendrycks, D., Burns, C., Kadavath, S., Arora, A., Basart, S., Tang, E., Song, D., and Steinhardt, J. Measuring mathematical problem solving with the math dataset. arXiv preprint arXiv:2103.03874, 2021. URL https://arxiv.org/abs/2103.03874. - Hu et al. (2025) Hu, M., Chen, T., Chen, Q., Mu, Y., Shao, W., and Luo, P. HiAgent: Hierarchical working memory management for solving long-horizon agent tasks with large language model. In Che, W., Nabende, J., Shutova, E., and Pilehvar, M. T. (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 32779–32798, Vienna, Austria, July 2025. Association for Computational Linguistics. ISBN 979-8-89176-251-0. doi: 10.18653/v1/2025.acl-long.1575. URL https://aclanthology.org/2025.acl-long.1575/. - Jiang et al. (2025) Jiang, L., Wu, X., Huang, S., Dong, Q., Chi, Z., Dong, L., Zhang, X., Lv, T., Cui, L., and Wei, F. Think only when you need with large hybrid-reasoning models. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=fDjDVE4qdj. - Kang et al. (2025) Kang, L., Deng, Y., Xiao, Y., Mo, Z., Lee, W. S., and Bing, L. First try matters: Revisiting the role of reflection in reasoning models, 2025. URL https://arxiv.org/abs/2510.08308. - Langley (2000) Langley, P. Crafting papers on machine learning. In Langley, P. (ed.), Proceedings of the 17th International Conference on Machine Learning (ICML 2000), pp. 1207–1216, Stanford, CA, 2000. Morgan Kaufmann. - Li et al. (2025) Li, X., Dong, G., Jin, J., Zhang, Y., Zhou, Y., Zhu, Y., Zhang, P., and Dou, Z. Search-o1: Agentic search-enhanced large reasoning models, 2025. URL https://arxiv.org/abs/2501.05366. - Liu & Wang (2025) Liu, X. and Wang, L. Answer convergence as a signal for early stopping in reasoning. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 17896–17907, Suzhou, China, November 2025. Association for Computational Linguistics. ISBN 979-8-89176-332-6. doi: 10.18653/v1/2025.emnlp-main.904. URL https://aclanthology.org/2025.emnlp-main.904/. - Liu et al. (2019) Liu, Y., Ott, M., Goyal, N., Du, J., Joshi, M., Chen, D., Levy, O., Lewis, M., Zettlemoyer, L., and Stoyanov, V. Roberta: A robustly optimized BERT pretraining approach. CoRR, abs/1907.11692, 2019. URL http://arxiv.org/abs/1907.11692. - Liu et al. (2025a) Liu, Y., Si, C., Narasimhan, K. R., and Yao, S. Contextual experience replay for self-improvement of language agents. In Che, W., Nabende, J., Shutova, E., and Pilehvar, M. T. (eds.), Proceedings of the 63rd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), pp. 14179–14198, Vienna, Austria, July 2025a. Association for Computational Linguistics. ISBN 979-8-89176-251-0. doi: 10.18653/v1/2025.acl-long.694. URL https://aclanthology.org/2025.acl-long.694/. - Liu et al. (2025b) Liu, Z., Chen, C., Li, W., Pang, T., Du, C., and Lin, M. There may not be aha moment in r1-zero-like training — a pilot study. [https://oatllm.notion.site/oat-zero](https://oatllm.notion.site/oat-zero), 2025b. Notion Blog. - Luo et al. (2025) Luo, M., Tan, S., Wong, J., Shi, X., Tang, W., Roongta, M., Cai, C., Luo, J., Zhang, T., Li, E., Popa, R. A., and Stoica, I. Deepscaler: Surpassing o1-preview with a 1.5b model by scaling rl. https://pretty-radio-b75.notion.site/DeepScaleR-Surpassing-O1-Preview-with-a-1-5B-Model-by-Scaling-RL-19681902c1468005bed8ca303013a4e2, 2025. Notion Blog. - MAA (2024) MAA. American Invitational Mathematics Examination (AIME) 2024. https://maa.org/math-competitions/american-invitational-mathematics-examination-aime, February 2024. Accessed: January 19, 2026. - Mao et al. (2025) Mao, M., Yin, B., Zhu, Y., and Fang, X. Early stopping chain-of-thoughts in large language models, 2025. URL https://arxiv.org/abs/2509.14004. - Ning et al. (2025) Ning, Y., Li, W., Fang, J., Tan, N., and Liu, H. Not all thoughts are generated equal: Efficient llm reasoning via multi-turn reinforcement learning, 2025. URL https://arxiv.org/abs/2505.11827. - OpenAI (2025) OpenAI. gpt-oss-120b & gpt-oss-20b model card, 2025. URL https://arxiv.org/abs/2508.10925. - OpenAI et al. (2024) OpenAI, :, Jaech, A., Kalai, A., Lerer, A., Richardson, A., El-Kishky, A., Low, A., Helyar, A., Madry, A., Beutel, A., Carney, A., Iftimie, A., Karpenko, A., Passos, A. T., Neitz, A., Prokofiev, A., Wei, A., Tam, A., Bennett, A., Kumar, A., Saraiva, A., Vallone, A., Duberstein, A., Kondrich, A., Mishchenko, A., et al. Openai o1 system card, 2024. URL https://arxiv.org/abs/2412.16720. - OpenAI et al. (2025) OpenAI, :, Singh, A., Fry, A., Perelman, A., Tart, A., Ganesh, A., El-Kishky, A., McLaughlin, A., Low, A., Ostrow, A., Ananthram, A., Nathan, A., Luo, A., Helyar, A., Madry, A., Efremov, A., Spyra, A., Baker-Whitcomb, A., Beutel, A., Karpenko, A., Makelov, A., Neitz, A., Wei, A., Barr, A., Kirchmeyer, A., Ivanov, A., Christakis, A., Gillespie, A., Tam, A., Bennett, A., Wan, A., Huang, A., Sandjideh, A. M., Yang, A., et al. Openai gpt-5 system card, 2025. URL https://arxiv.org/abs/2601.03267. - Robertson & Zaragoza (2009) Robertson, S. E. and Zaragoza, H. The probabilistic relevance framework: BM25 and beyond. Found. Trends Inf. Retr., pp. 333–389, 2009. - Shen et al. (2025) Shen, Y., Zhang, J., Huang, J., Shi, S., Zhang, W., Yan, J., Wang, N., Wang, K., Liu, Z., and Lian, S. DAST: Difficulty-adaptive slow-thinking for large reasoning models. In Potdar, S., Rojas-Barahona, L., and Montella, S. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing: Industry Track, pp. 2322–2331, Suzhou (China), November 2025. Association for Computational Linguistics. ISBN 979-8-89176-333-3. doi: 10.18653/v1/2025.emnlp-industry.160. URL https://aclanthology.org/2025.emnlp-industry.160/. - Sui et al. (2025) Sui, Y., Chuang, Y.-N., Wang, G., Zhang, J., Zhang, T., Yuan, J., Liu, H., Wen, A., Zhong, S., Chen, H., and Hu, X. Stop overthinking: A survey on efficient reasoning for large language models, 2025. URL https://arxiv.org/abs/2503.16419. - Team (2025) Team, Q. Qwq-32b: Embracing the power of reinforcement learning, March 2025. URL https://qwenlm.github.io/blog/qwq-32b/. - Wang et al. (2025a) Wang, J., Guo, Z., Ma, W., and Zhang, M. How far can LLMs improve from experience? measuring test-time learning ability in LLMs with human comparison. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 25677–25691, Suzhou, China, November 2025a. Association for Computational Linguistics. ISBN 979-8-89176-332-6. doi: 10.18653/v1/2025.emnlp-main.1304. URL https://aclanthology.org/2025.emnlp-main.1304/. - Wang et al. (2025b) Wang, Y., Liu, J., Zhang, S., Chen, J., and Huang, S. Pats: Process-level adaptive thinking mode switching, 2025b. URL https://arxiv.org/abs/2505.19250. - Wu et al. (2025) Wu, S., Xie, J., Zhang, Y., Chen, A., Zhang, K., Su, Y., and Xiao, Y. ARM: Adaptive reasoning model. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=z9oeQrcNh9. - Yang et al. (2025a) Yang, A., Li, A., Yang, B., Zhang, B., Hui, B., Zheng, B., Yu, B., Gao, C., Huang, C., Lv, C., et al. Qwen3 technical report. arXiv preprint arXiv:2505.09388, 2025a. URL https://arxiv.org/abs/2505.09388. - Yang et al. (2025b) Yang, S., Wu, J., Chen, X., Xiao, Y., Yang, X., Wong, D. F., and Wang, D. Understanding aha moments: from external observations to internal mechanisms, 2025b. URL https://arxiv.org/abs/2504.02956. - Yufei Xiang & Nguyen (2024) Yufei Xiang, Yiqun Shen, Y. Z. and Nguyen, C.-T. Retrospex: Language agent meets offline reinforcement learning critic. In Proceedings of the 2024 Conference on Empirical Methods in Natural Language Processing, EMNLP, 2024. - Zeng et al. (2025) Zeng, Z., Huang, X., Li, B., Zhang, H., and Deng, Z. Done is better than perfect: Unlocking efficient reasoning by structured multi-turn decomposition, 2025. URL https://arxiv.org/abs/2505.19788. - Zhai et al. (2025) Zhai, Y., Tao, S., Chen, C., Zou, A., Chen, Z., Fu, Q., Mai, S., Yu, L., Deng, J., Cao, Z., Liu, Z., Ding, B., and Zhou, J. Agentevolver: Towards efficient self-evolving agent system, 2025. URL https://arxiv.org/abs/2511.10395. - Zhang et al. (2025a) Zhang, J., Lin, N., Hou, L., Feng, L., and Li, J. AdaptThink: Reasoning models can learn when to think. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing, pp. 3716–3730, Suzhou, China, November 2025a. Association for Computational Linguistics. ISBN 979-8-89176-332-6. doi: 10.18653/v1/2025.emnlp-main.184. URL https://aclanthology.org/2025.emnlp-main.184/. - Zhang et al. (2026) Zhang, S., Wu, J., Chen, J., Zhang, C., Li, Z., Lou, X., Zhou, W., Zhou, S., Wang, C., and Wang, J. Othink-r1: Intrinsic fast/slow thinking mode switching for over-reasoning mitigation, 2026. URL https://arxiv.org/abs/2506.02397. - Zhang et al. (2025b) Zhang, X., Ruan, J., Ma, X., Zhu, Y., Zhao, H., Li, H., Chen, J., Zeng, K., and Cai, X. When to continue thinking: Adaptive thinking mode switching for efficient reasoning. In Christodoulopoulos, C., Chakraborty, T., Rose, C., and Peng, V. (eds.), Findings of the Association for Computational Linguistics: EMNLP 2025, pp. 5808–5828, Suzhou, China, November 2025b. Association for Computational Linguistics. ISBN 979-8-89176-335-7. doi: 10.18653/v1/2025.findings-emnlp.310. URL https://aclanthology.org/2025.findings-emnlp.310/. - Zhao et al. (2024) Zhao, A., Huang, D., Xu, Q., Lin, M., Liu, Y.-J., and Huang, G. Expel: Llm agents are experiential learners. In Wooldridge, M. J., Dy, J. G., and Natarajan, S. (eds.), Thirty-Eighth AAAI Conference on Artificial Intelligence, AAAI 2024, Thirty-Sixth Conference on Innovative Applications of Artificial Intelligence, IAAI 2024, Fourteenth Symposium on Educational Advances in Artificial Intelligence, EAAI 2024, February 20-27, 2024, Vancouver, Canada, pp. 19632–19642. AAAI Press, 2024. doi: 10.1609/aaai.v38i17.29936. URL https://ojs.aaai.org/index.php/AAAI/article/view/29936. - Zhao et al. (2025) Zhao, H., Yan, Y., Shen, Y., Xu, H., Zhang, W., Song, K., Shao, J., Lu, W., Xiao, J., and Zhuang, Y. Let LRMs break free from overthinking via self-braking tuning. In The Thirty-ninth Annual Conference on Neural Information Processing Systems, 2025. URL https://openreview.net/forum?id=u3a2AX0icx. Appendix A Benchmark Statistics Table 2: Statistics of Datasets and Rollouts | AIME24 AIME25 AMC23 | 30 30 40 | 16 16 4 | 480 480 160 | | --- | --- | --- | --- | | MATH500 | 500 | 1 | 500 | | Olympiad Bench | 674 | 1 | 674 | | Total | 1317 | - | 2294 | Appendix B Reflection Type Statistics <details> <summary>Figs/reflection_pie_charts_all_models.png Details</summary>  ### Visual Description ## Pie Chart Comparison: Model Performance on Different Datasets ### Overview The image presents a series of pie charts comparing the performance of different language models (gpt-oss-20b, DeepSeek-R1-Distill-Qwen-7B, Qwen3-8B, and QwQ-32B) on four datasets (AIME24, AIME25, AMC, and MATH500). Each pie chart represents the distribution of model behavior, categorized into "Unnecessary Rechecks," "Necessary Rechecks," "Rethinks," and "Unable to Classify." ### Components/Axes * **Rows (Models):** * gpt-oss-20b (Top Row) * DeepSeek-R1-Distill-Qwen-7B (Second Row) * Qwen3-8B (Third Row) * QwQ-32B (Bottom Row) * **Columns (Datasets):** * AIME24 (Leftmost Column) * AIME25 (Second Column) * AMC (Third Column) * MATH500 (Rightmost Column) * **Pie Chart Categories (Legend - Bottom):** * **Unnecessary Rechecks:** Light Green * **Necessary Rechecks:** Light Yellow * **Rethinks:** Light Red * **Unable to Classify:** Light Blue ### Detailed Analysis or ### Content Details **Row 1: gpt-oss-20b** * **AIME24:** * Unnecessary Rechecks: 46.5% * Necessary Rechecks: 10.1% * Rethinks: 39.1% * Unable to Classify: 4.2% * **AIME25:** * Unnecessary Rechecks: 45.4% * Necessary Rechecks: 9.2% * Rethinks: 40.8% * Unable to Classify: 4.6% * **AMC:** * Unnecessary Rechecks: 59.5% * Necessary Rechecks: 9.9% * Rethinks: 25.2% * Unable to Classify: 5.4% * **MATH500:** * Unnecessary Rechecks: 56.5% * Necessary Rechecks: 6.9% * Rethinks: 29.9% * Unable to Classify: 6.8% **Row 2: DeepSeek-R1-Distill-Qwen-7B** * **AIME24:** * Unnecessary Rechecks: 28.9% * Necessary Rechecks: 7.7% * Rethinks: 54.4% * Unable to Classify: 9.0% * **AIME25:** * Unnecessary Rechecks: 31.2% * Necessary Rechecks: 8.2% * Rethinks: 50.2% * Unable to Classify: 10.4% * **AMC:** * Unnecessary Rechecks: 39.7% * Necessary Rechecks: 8.3% * Rethinks: 43.5% * Unable to Classify: 8.4% * **MATH500:** * Unnecessary Rechecks: 38.3% * Necessary Rechecks: 6.8% * Rethinks: 46.2% * Unable to Classify: 8.6% **Row 3: Qwen3-8B** * **AIME24:** * Unnecessary Rechecks: 35.5% * Necessary Rechecks: 5.2% * Rethinks: 49.7% * Unable to Classify: 9.7% * **AIME25:** * Unnecessary Rechecks: 38.7% * Necessary Rechecks: 4.8% * Rethinks: 39.8% * Unable to Classify: 16.8% * **AMC:** * Unnecessary Rechecks: 49.9% * Necessary Rechecks: 4.2% * Rethinks: 39.8% * Unable to Classify: 6.2% * **MATH500:** * Unnecessary Rechecks: 52.8% * Necessary Rechecks: 3.2% * Rethinks: 38.6% * Unable to Classify: 5.4% **Row 4: QwQ-32B** * **AIME24:** * Unnecessary Rechecks: 29.5% * Necessary Rechecks: 4.7% * Rethinks: 46.6% * Unable to Classify: 19.2% * **AIME25:** * Unnecessary Rechecks: 30.1% * Necessary Rechecks: 4.6% * Rethinks: 37.7% * Unable to Classify: 27.6% * **AMC:** * Unnecessary Rechecks: 48.6% * Necessary Rechecks: 3.7% * Rethinks: 40.5% * Unable to Classify: 7.2% * **MATH500:** * Unnecessary Rechecks: 49.6% * Necessary Rechecks: 3.3% * Rethinks: 39.8% * Unable to Classify: 7.3% ### Key Observations * **gpt-oss-20b:** Generally exhibits a higher percentage of "Unnecessary Rechecks" compared to other models, especially on AMC and MATH500 datasets. * **DeepSeek-R1-Distill-Qwen-7B:** Shows a significantly higher percentage of "Rethinks" across all datasets compared to other models. * **Qwen3-8B:** Has a relatively balanced distribution across categories, with a notable increase in "Unable to Classify" on the AIME25 dataset. * **QwQ-32B:** Displays the highest percentage of "Unable to Classify" on AIME24 and AIME25, suggesting potential difficulties with these datasets. * Across all models, the percentage of "Necessary Rechecks" is consistently the lowest. ### Interpretation The pie charts provide insights into the problem-solving strategies and limitations of different language models on various datasets. The "Unnecessary Rechecks" category might indicate inefficient processing or overthinking, while "Rethinks" could reflect the model's ability to correct errors or refine its approach. A high percentage of "Unable to Classify" suggests that the model struggles to understand or process certain types of questions or data. The data suggests that gpt-oss-20b tends to rely more on unnecessary rechecks, while DeepSeek-R1-Distill-Qwen-7B frequently rethinks its answers. QwQ-32B seems to have difficulty classifying certain inputs, particularly in the AIME datasets. The variations in performance across datasets highlight the importance of dataset-specific model evaluation and optimization. </details> Figure 8: Proportion of reflection types for Qwen3-8B, QwQ-32B, Deepseek-R1-Distilled-Qwen-7B and gpt-oss-20b annotated by GPT-5 To investigate the semantic composition of reflection steps, we analyze four recent models—Qwen3-8B (Yang et al., 2025a), QwQ-32B (Team, 2025), gpt-oss-20b (OpenAI, 2025), and DeepSeek-R1-Distill-Qwen-7B (DeepSeek-AI et al., 2025) —across a diverse set of benchmarks, including AIME24 (MAA, 2024), AIME25 (AIME, 2025), AMC (AMC12, 2023), and MATH500 (Hendrycks et al., 2021). This setup allows us to examine how reflection behaviors vary across model scales and problem domains. From Figure 8, we observe a persistent inefficiency in self-verification behaviors across models and benchmarks. Specifically, the ratio of unnecessary rechecks to necessary rechecks remains consistently high. This pattern indicates a fundamental limitation of current chain-of-thought (CoT) paradigms: models exhibit difficulty in discerning when verification is warranted, leading to substantial computational overhead due to redundant verification steps. Appendix C Human Evaluation To evaluate the reliability of the LLM-based reflection classifier, we conducted a human evaluation on a random subset of 1,000 reflection steps. Each step was independently annotated by a human expert following the same reflection schema. We compared LLM and human annotations in terms of label distributions and computed both overall agreement and Cohen’s $\kappa$ to quantify alignment beyond chance. | Corrective Rechecks Confirmatory Rechecks Rethink | 54 (5.4%) 428 (42.8%) 518 (51.8%) | 48 (4.8%) 374 (37.4%) 489 (48.9%) | | --- | --- | --- | | Unable to Classify | - | 89 (8.9%) | Table 3: Distribution of reflection types in human and LLM annotations ( $n=1000$ ). Table 3 shows that the LLM’s predicted label distribution closely matches that of the human annotator across the primary reflection categories, with minor discrepancies attributable to the LLM’s additional “Unable to Classify” label. The confusion matrix in | Corrective Rechecks Confirmatory Rechecks Rethinks | 47 1 0 | 1 369 4 | 1 17 471 | 5 41 43 | | --- | --- | --- | --- | --- | | Unable to Classify | 0 | 0 | 0 | 0 | Table 4: Confusion matrix between human annotations (rows) and LLM predictions (columns) over 1,000 reflection steps. Table 4 further demonstrates that most disagreements occur between conceptually adjacent categories (e.g., corrective vs. confirmatory rechecks), indicating that misclassifications primarily arise from boundary ambiguity rather than systematic errors. Quantitatively, the LLM achieves an overall agreement of 88.7% with human annotations and a Cohen’s $\kappa$ of 0.81, suggesting strong concordance beyond chance. Notably, the model rarely confuses non-adjacent reflection types, reinforcing the semantic coherence of its predictions. These results indicate that the LLM provides an accurate and reliable approximation of expert judgment for reflection classification, supporting its use as an automated annotation tool in large-scale analyses. Appendix D Example Query Example (recheck activation and upper context) Then pairwise intersections: Numbers divisible by 3 and 23: lcm(3,23)=69. floor(2003 / 69). 69*29 = 2001, so floor(2003 / 69) = 29. Correct. Numbers divisible by 3 and 29: lcm(3,29)=87. floor(2003 / 87). 87*23 = 2001, so floor(2003 / 87) = 23. Correct. Numbers divisible by 3 and 2003: lcm(3,2003)= 3*2003. Since 3*2003 = 6009 ¿ 2003, floor(2003 / 6009)=0. Correct. Numbers divisible by 23 and 29: lcm(23,29)=667. floor(2003 / 667). 667*3 = 2001, so floor(2003 / 667)=3. Correct. Numbers divisible by 23 and 2003: lcm(23,2003)=23*2003, which is way larger than 2003, so 0. Correct. Numbers divisible by 29 and 2003: same, 0. Correct. So sum of pairwise intersections: 29 + 23 + 0 + 3 + 0 + 0 = 55. Correct. Then subtract 55 from 824: 824 - 55 = 769. Correct. Then triple intersections: Numbers divisible by 3,23,29: lcm(3,23,29)=3*23*29=2001. floor(2003 / 2001)=1. Correct. Other triplets: 3,23,2003: lcm=3*23*2003, which is way bigger than 2003, so 0. Similarly others. So total triple intersections: 1. So add 1: 769 + 1 = 770. Correct. Four-way intersection: 0. So total numbers not coprime: 770. Therefore, numbers coprime: 2003 - 770 = 1233. Wait, but let me check if that answer makes sense. Top-1 Example “Context”:{ So, subtract 55 from the previous total: 824 - 55 = 769. Now, add back the triple intersections. Numbers divisible by lcm(3,23,29) = 3*23*29 = 2001. floor(2003 / 2001) = 1. Numbers divisible by lcm(3,23,2003) = 3*23*2003, which is way larger than 2003, so 0. Similarly, numbers divisible by lcm(3,29,2003) = 3*29*2003, also larger than 2003, so 0. Numbers divisible by lcm(23,29,2003) = 23*29*2003, also larger than 2003, so 0. Therefore, the triple intersections sum up to 1 + 0 + 0 + 0 = 1. So we add 1: 769 + 1 = 770. Now, subtract the four-way intersection: numbers divisible by lcm(3,23,29,2003) = 3*23*29*2003, which is way larger than 2003, so floor(2003 / that number) = 0. Therefore, subtract 0: 770 - 0 = 770. Therefore, the total number of numbers not coprime to n is 770. Therefore, the number of numbers coprime to n is total numbers (2003) minus 770, which is 2003 - 770 = Wait, but hold on. Let me check my calculations again, because that seems a bit high. Let me verify each step again. First, total numbers: 2003. Correct. First part: numbers divisible by 3, 23, 29, or 2003: 667 + 87 + 69 + 1 = 824. Correct. Then subtract pairwise intersections: Numbers divisible by 3 & 23: 29. 3 & 29: 23. 3 & 2003: 0. 23 & 29: 3. 23 & 2003: 0. 29 & 2003: 0. Total pairwise: 29 + 23 + 0 + 3 + 0 + 0 = 55. Correct. So 824 - 55 = 769. Then add back triple intersections: Numbers divisible by 3, 23, 29: 2001. floor(2003 / 2001) = 1. The other triplets: 3,23,2003: floor(2003 / (3*23*2003)) = 0. Similarly others. So total triple intersections: 1. So 769 + 1 = 770. } “Label”:{ “Unnecesasry” } Appendix E Prompts Reflection Identifier Prompt # Reflection Step Classification Task **Task:** You are given a single step from a model’s reasoning process. **Goal:** Decide whether this step is a *reflection step*. — ## Core Rule (Strict) A step is a reflection **only if it explicitly refers to the model’s own reasoning process** and is about *monitoring, evaluating, or revising that reasoning.* It must clearly do **at least one** of the following: - Verify, check, audit, or critique earlier reasoning or results - Propose changing, reconsidering, or comparing approaches or strategies This must be about the **reasoning itself**, not the problem. — ## Required Signal The step should contain **explicit self-referential or metacognitive language**, such as: - ”I should check…” - ”This approach might be wrong…” - ”Let me reconsider…” - ”So far, my reasoning assumes…” - ”I may have made a mistake…” - ”Another strategy could be…” If it does **not** monitor or revise the reasoning process, it is **not** a reflection. — ## Not a Reflection (Always False) Do **not** classify as reflection if the step is mainly: - Solving the problem - Doing calculations, algebra, or transformations - Applying formulas, rules, or definitions - Deriving new results or conclusions - Explaining why a step works - Stating what to do next without evaluating the reasoning Even if it uses words like ”think”, ”so”, or ”therefore”, it is **not** a reflection unless it critiques or evaluates the reasoning itself. — ## Output Format (Strict) Output only: True or False No explanations. No extra text. Reflection Type Classifier Prompt You are an annotation assistant. You are given: - an earlier reasoning step - several later lines of context from the same reasoning trace - the reasoning step to be classified Your task is to classify the step. You must output exactly one label: a. Successful Correctness Repair Action b. Unsuccessful Correctness Repair Action c. Strategy Exploration d. Unable to classify Only output the single letter. — ## Core Concepts ### A. Correctness Repair Action (CRA) A step is a Correctness Repair Action IF AND ONLY IF: 1) There exists a prior calculation, result, assumption, bound, interpretation, or conclusion earlier in the trace. AND 2) The PURPOSE of the step is to evaluate whether that earlier calculation is correct or incorrect. AND 3) The step performs or initiates a verification action, such as: - recomputation - checking constraints - plugging values back in - testing cases - searching for counterexamples - validating optimality/minimality/maximality The action must be aimed at CONFIRMING or REFUTING a prior calculation/result. — ## B. Strategy Exploration A step is Strategy Exploration IF AND ONLY IF: 1) Its purpose is to propose, compare, or shift solution approaches. AND 2) It is NOT primarily verifying or refuting a prior belief. Examples: - proposing a new method - suggesting an alternative representation - reframing how to approach the problem — ## C. Successful vs Unsuccessful CRA (STRICT) ### ABSOLUTE RULE A step MUST NOT be labeled **Successful Correctness Repair Action** if the resulting calculation/result is the SAME as before. If the check confirms the earlier calculation/result, it is ALWAYS **Unsuccessful**. — ### Successful Correctness Repair Action (a) Label **a** if and only if ALL are true: 1) A prior calculation/result in the trace is objectively WRONG. 2) This step performs a genuine verification or repair attempt. 3) This step REVEALS the calculation/result is wrong. 4) The calculation/result is REPLACED with a correct one. 5) No new error is introduced. If any condition fails → not successful. Typical outcomes: - wrong value recomputed correctly - false assumption invalidated - flawed argument repaired — ### Unsuccessful Correctness Repair Action (b) Label **b** if ANY are true: - The prior calculation/result was actually correct. - The step checks something but the conclusion does NOT change. - The step fails to detect a real error. - The step checks the wrong thing. - The step introduces a new error. This explicitly includes: - rechecking and getting the same answer - confirming a correct result - reaffirming a wrong result Examples (b): - ”Let me recompute… I still get 70.” - ”Plugging it back in, it works.” - ”Double-checking confirms the previous conclusion.” — ## Lexical Guidance (non-binding) Verification signals: check, verify, double-check, recompute, re-calculate, plug in, test whether, confirm, see if this holds, counterexample Strategy signals: maybe, try, consider, alternatively, another approach, instead Lexical cues do NOT override outcome rules. — ## Final decision checklist (must follow): 1) Is this step trying to verify or repair a prior belief? - No →c or d 2) Is it proposing or comparing approaches rather than checking correctness? - Yes →c 3) Was there an actually wrong prior belief? - No →b 4) Did this step expose the error and replace it with a correct belief? - Yes →a - No →b — Only output: a, b, c, or d. Recheck Activation Extraction Prompt You are an annotation assistant. Your task is to extract ONLY sentences where the model checks, verifies, or attempts to falsify the correctness of something it has ALREADY stated. We annotate correctness repair actions. We do NOT annotate strategy exploration or forward reasoning. — Definition: Correctness Repair Action A sentence qualifies IF AND ONLY IF: 1) There exists a prior belief, result, assumption, bound, interpretation, or conclusion stated earlier in the rollout (explicitly or implicitly). 2) The sentence’s PURPOSE is to evaluate whether that earlier belief is CORRECT or INCORRECT. 3) The sentence performs or initiates a verification action, which may include: - re-computation - checking constraints - testing candidates - searching for counterexamples - validating optimality / minimality / maximality as long as these actions are used to CONFIRM or REFUTE a prior claim. — Lexical guidance (strong signals): Typical verification phrases: check, verify, double-check, re-check, confirm, re-calculate, recompute, plug in, test whether, see if this holds. If a sentence contains “maybe” or “let me” but does NOT explicitly reference checking correctness (e.g., check / verify / confirm / see if this holds), do NOT annotate it. And do NOT annotate conclusion sentences before starting to check. — Examples (annotate these): 1. Re-computation (explicitly redoing a prior step) - ”Wait, let me compute this again carefully.” - ”Let me double-check the arithmetic here.” 2. Checking constraints (validating a prior result against conditions) - ”Let me check if this satisfies the constraint that X and Y must be inside the square.” - ”Let me plug this back into the equation to see if it works.” 3. Testing candidates (verifying a prior claim via examples or nearby cases) - ”Let me test a few cases around this value to confirm it’s maximal.” - ”Let me try a couple of examples to see if this holds.” 4. Searching for counterexamples (attempting to falsify a prior claim) - ”Let me see if I can find a counterexample.” - ”Let me check if this ever breaks down.” 5. Validating optimality / minimality / maximality - ”Let me check if this is indeed the minimum.” - ”Let me verify that no other placement yields a smaller value.” — Do NOT annotate: - Summaries, conclusions: “Therefore, the answer should be…”, ”Therefore, this suggests…” - Strategy shifts or planning: “To solve the prblem, maybe try…”, “Alternatively, consider…” - Idea generation without correctness intent: “Maybe there is a larger number…” - Forward computation stated for the first time: “Compute…”, “We obtain…”, “Thus…” - Meta-cognition without verification: “Let me think again.” — Extraction rules: - Copy the sentence EXACTLY as it appears in the rollout. - Do NOT annotate fragments or partial clauses. - Do NOT paraphrase, invent, or duplicate sentences. Recheck Activation Extraction Prompt You are an annotation assistant. Your task is to extract ONLY sentences where the model checks, verifies, or attempts to falsify the correctness of something it has ALREADY stated. We annotate correctness repair actions. We do NOT annotate strategy exploration or forward reasoning. — Definition: Correctness Repair Action A sentence qualifies IF AND ONLY IF: 1) There exists a prior belief, result, assumption, bound, interpretation, or conclusion stated earlier in the rollout (explicitly or implicitly). 2) The sentence’s PURPOSE is to evaluate whether that earlier belief is CORRECT or INCORRECT. 3) The sentence performs or initiates a verification action, which may include: - re-computation - checking constraints - testing candidates - searching for counterexamples - validating optimality / minimality / maximality as long as these actions are used to CONFIRM or REFUTE a prior claim. — Lexical guidance (strong signals): Typical verification phrases: check, verify, double-check, re-check, confirm, re-calculate, recompute, plug in, test whether, see if this holds. If a sentence contains “maybe” or “let me” but does NOT explicitly reference checking correctness (e.g., check / verify / confirm / see if this holds), do NOT annotate it. And do NOT annotate conclusion sentences before starting to check. — Examples (annotate these): 1. Re-computation (explicitly redoing a prior step) - ”Wait, let me compute this again carefully.” - ”Let me double-check the arithmetic here.” 2. Checking constraints (validating a prior result against conditions) - ”Let me check if this satisfies the constraint that X and Y must be inside the square.” - ”Let me plug this back into the equation to see if it works.” 3. Testing candidates (verifying a prior claim via examples or nearby cases) - ”Let me test a few cases around this value to confirm it’s maximal.” - ”Let me try a couple of examples to see if this holds.” 4. Searching for counterexamples (attempting to falsify a prior claim) - ”Let me see if I can find a counterexample.” - ”Let me check if this ever breaks down.” 5. Validating optimality / minimality / maximality - ”Let me check if this is indeed the minimum.” - ”Let me verify that no other placement yields a smaller value.” — Do NOT annotate: - Summaries, conclusions: “Therefore, the answer should be…”, ”Therefore, this suggests…” - Strategy shifts or planning: “To solve the prblem, maybe try…”, “Alternatively, consider…” - Idea generation without correctness intent: “Maybe there is a larger number…” - Forward computation stated for the first time: “Compute…”, “We obtain…”, “Thus…” - Meta-cognition without verification: “Let me think again.” — Extraction rules: - Copy the sentence EXACTLY as it appears in the rollout. - Do NOT annotate fragments or partial clauses. - Do NOT paraphrase, invent, or duplicate sentences. Recheck Filtering Prompt You are a strict binary classifier. Task: Given ONE sentence from an LLM rollout, decide whether this sentence is a ”correctness repair action onset”: It explicitly initiates or performs a CHECK / VERIFICATION / FALSIFICATION of correctness (including re-computation, checking constraints, testing candidates to confirm/refute, searching for counterexamples, validating optimality). Label rules: - Output ”1” only if the sentence itself clearly expresses verification intent (e.g., ”check”, ”verify”, ”double-check”, ”recompute”, ”plug in”, ”test whether this holds”, ”see if this works”, ”counterexample”, ”confirm it’s minimal/maximal”). - Output ”0” otherwise. Important: - Do NOT output 1 for pure planning/strategy (”Maybe try…”, ”Consider symmetry…”, ”Let me try coordinates…”). - Do NOT output 1 for generic meta-cognition without checking (”Let me think again.”). - Do NOT output 1 for summaries/conclusions (”Therefore…”, ”Thus…”) unless it explicitly says it is checking/validating. - Return ONLY a single character: 1 or 0. Outcome Annotation Prompt You are an annotation assistant. You will be given: (1) a recheck onset sentence previously extracted from a rollout, and (2) its surrounding context (a short window of text before and after). Your task: Decide whether the recheck that begins at the onset sentence is NECESSARY or UNNECESSARY, using ONLY evidence in the provided context window. Definitions (outcome-based) - NECESSARY (corrective): The recheck discovers an error/inconsistency and leads to a correction. Evidence includes: explicit admission of mistake, retraction, changed equation/value, revised claim, changed plan/approach due to the check, or a different conclusion/answer. - UNNECESSARY (confirmatory): The recheck does not change anything substantive. It only confirms correctness, repeats the same derivation/result, or proceeds with the same claim after checking. - INCONCLUSIVE: The excerpt does not contain enough information to tell whether the check caused a correction or merely confirmed correctness (e.g., the check starts but the outcome is not shown). Rules: - Use ONLY the provided context window. Do NOT assume anything outside it. - Base the decision on explicit textual evidence (e.g., “I was wrong…”, “should be…”, changed numbers, “checks out…”, “consistent…”). - If there is ANY correction caused by the check (even a small arithmetic fix), label NECESSARY. - If the check finishes and the claim stays the same, label UNNECESSARY. - If unclear, label INCONCLUSIVE.