Teaching Language Models to Reason with Tools

We sincerely thank the reivewer for their thorough review and constructive feedback. We are particularly grateful that the reviewer recognizes the importance of our research direction—enabling LLMs to use external tools efficiently—and acknowledges that our "experiments are well made and empirical analysis show how efficient the proposed prompt can be." This encouragement is invaluable.

We are grateful for the opportunity to address the remaining concerns:

---

W1: Details in Main Text

Thank you for this crucial feedback. We agree completely. Due to strict page limits, we initially prioritized presenting our key findings in the main text while moving detailed setups to the appendix. In the revision, we will integrate these essential details and a concise literature review into the main text, relocating less critical material to the appendix.

W2: The Data Synthesis Framework

Thank you for seeking clarification. We understand the confusion and appreciate the opportunity to elaborate on this core contribution. Our "data synthesis framework" is a systematic, scalable pipeline designed to teach models efficient tool-integrated reasoning. Its necessity and effectiveness are rooted in a two-stage process:

1. Stage 1: Seed with High-Quality Data (Hint-Engineering & SFT). We start by manually creating 30 high-quality "seed" examples. This small dataset is essential because, as we will demonstrate below, prompting alone cannot teach the model the desired efficient reasoning patterns. These 30 examples provide focused demonstrations of how to proactively use code for computation, not just verification. In this stage, we fine-tune the base DeepSeek-R1-32B model on these 30 seed examples to produce our Hint-Engineering-SFT-32B model.

2. Stage 2: Scale with Automated Synthesis (RFT). After SFT on the seed data "unlocks" the correct behavior, we use the now-improved model to generate thousands of candidate solutions. These are then automatically filtered based on correctness and reasoning quality to create a larger, high-quality dataset for Rejection Fine-Tuning (RFT). This creates a self-improving cycle that scales our data from 30 to 830 examples (with potential for further expansion given additional computational resources). In this stage, the Hint-Engineering-SFT-32B model serves as the input, and after RFT on the scaled data, we obtain our final Hint-Engineering-RFT-32B model.

To prove our seed data is necessary, we ran a zero-shot experiment on the base model using a strong TIR prompt without fine-tuning. The results below show our framework teaches a superior reasoning paradigm that prompting alone cannot achieve.

Key Findings:

• Superior Performance & Efficiency: Our model achieves significantly higher accuracy (+14.8 pts on AIME25) with substantially fewer tokens (-28.3%).
• Fundamental Behavioral Shift: Our method increases code usage by 2-4x, shifting the model from an inefficient "verify-with-code" pattern to an efficient "compute-with-code" strategy. This demonstrates our data is both necessary and effective.

W3: RL Safeguard Mechanism

We appreciate this sharp observation. The hint to stop using Python is not a contradictory instruction but a critical computational safeguard, triggered only when a model exceeds the predefined 15-tool-call limit. This is a standard practice to prevent infinite loops and manage resources during large-scale RL, also utilized in works like the AIMO-2 winning solution by NVIDIA [1].

Crucially, this safeguard has a negligible impact on our conclusions because it affects only a tiny fraction of failing cases. Our analysis of the RL training logs provides clear evidence: the limit was reached in only 0.2% of all trajectories. Furthermore, among these rare instances, 85.6% involved models already trapped in non-productive error loops.

This data shows the intervention is a rare mechanism for exceptional failure modes and does not influence learned behavior in the vast majority of trajectories.

[1] "AIMO-2 Winning Solution: Building State-of-the-Art Mathematical Reasoning Models with OpenMathReasoning dataset"

---

Q1: Manual Hint Injection

Our process relies on expert judgment guided by a replicable procedure—not on heuristics. We adopted this manual approach because automated methods failed to produce satisfactory results. Given the complexity of our task, we are unaware of any purely automated methods that can succeed without human insight.

Why Manual Curation was Necessary: We initially used powerful LLMs as judges to automate hint insertion. However, they consistently failed on subtle but critical distinctions. On a test set of 100 AIME problems, we identified two primary failure modes:

These frequent and critical errors led us to conclude that a small, high-precision, manually-annotated seed dataset was the most effective way to bootstrap the learning process.

The Manual Workflow: Our manual editing follows a clear, three-step procedure:

1. Generate Baseline Trace: An annotator prompts the base model to generate a complete reasoning trace for a problem.
2. Identify Inefficiencies: The annotator inspects the trace, looking for two specific, easily identifiable patterns of redundancy:
   • Delayed Computation ("Thinking too hard"): The model first guesses an answer in text (e.g., solving x^2 - 17x + 60 = 0 by sight) before using code (sympy.solve(...)) for a precise result. The initial guess is inefficient and error-prone.
   • Code Distrust ("Not trusting the calculator"): After getting a precise code output (e.g., >>> [5, 12]), the model re-verifies it in text (e.g., plugging roots back into the equation). This is redundant.
3. Surgical Correction: Based on the identified inefficiency, the annotator performs a targeted edit. For "thinking too hard", they remove the text-based calculation and insert a "use code" hint earlier. For "not trusting the calculator", they remove the redundant verification and insert a "trust Python" hint.

Note that prior works like InstructGPT also designed detailed annotation instructions. In the revision, we will clarify our own instructions for reference.

Q2: Model & Dataset Naming

We apologize for the lack of clarity.

• D_{hint-engineering-sft}: This is the dataset of 30 high-quality reasoning traces created through the manual "Hint-Engineering" process described in our response to Q1. It is first mentioned in Line 132.
• Hint-Engineering-SFT-32B: This is the model resulting from Supervised Fine-Tuning (SFT) the base DeepSeek-R1-32B model on the D_{hint-engineering-sft} dataset. It serves as the starting point for our Rejection Fine-Tuning stage and is mentioned in Lines 128-129.

Q3: Distillation vs. Direct Fine-tuning

This is an excellent question. We chose distillation because direct fine-tuning the 1.5B model with our small dataset was ineffective, as it lacks the capacity to benefit from such subtle guidance. In contrast, the 32B model learns effectively and can then generate a larger dataset to teach the smaller model via distillation.

The table below confirms this. Direct fine-tuning shows negligible improvement over the baseline, while our distillation approach provides meaningful gains.

This approach effectively transfers capabilities and enables large-scale RL on smaller, computationally manageable models.

---

We sincerely thank you for your insightful review. We gratefully hope that you could re-evaluate our paper based on the clarifications provided above. If our responses have satisfactorily addressed your concerns, we would greatly appreciate it if you could consider updating the review score accordingly.

Dear authors,

Thank you very much for addressing most of my concerns and questions.

1. About the data synthesis framework: your explanation is very clear and this two step bullet point should be in the paper as it makes the contribution more clear. Thanks for that.

2. About the RL safeguard mechanism: only 0.2% of cases, then it is indeed negligible. it was not clear in the text that this hint was only used when the model exceeded the 15-tool-call limit. Such clarification should be in the main text.

3. Thank you for the very detailed explanation of the manual annotation workflow. This is again crucial information that should be in the paper. Having it as a list of bullet points, like here makes it very clear.

Based on the provided explanations and additional studies, I will raise my score from 2 to 4, however, I request that the three points above must be in the main text of the paper, along with a literature review.

We sincerely thank the reviewer for their insightful and constructive feedback. We are particularly grateful that the reviewer recognizes the key strengths of our work, including the importance and timeliness of the topic, the clarity and structure of our writing, and the simplicity yet effectiveness of our proposed CoRT framework. Your comments have been invaluable in helping us refine our paper.

We are grateful for the opportunity to address the remaining concerns and further clarify our contributions:

---

W1: Comparison with SOTA Models

We thank the reviewer for this excellent suggestion. We agree that including the performance of SOTA models like o3 and o4-mini provides a crucial point of reference.

We will update Table 1 in our revised manuscript to include these comparisons. The updated section of the table will be as follows:

---

W2 & Generalization: Lack of an Explicit Planner

We thank the reviewer for this excellent and thought-provoking question about our method's approach to learning tool invocation. The reviewer correctly notes that we do not use an explicit, separate module like a planner or a gating function. This is a deliberate design choice, and we believe our integrated, end-to-end approach fosters a more genuine and flexible understanding of tool use.

1. An Integrated, End-to-End Decision Process: Instead of offloading the decision to a separate module, our framework teaches the LRM to make the tool-use decision as an intrinsic part of its own reasoning process. The model learns to generate the special '''python token at the appropriate time, based on the entire context of the problem and its reasoning chain. This is achieved through fine-tuning on high-quality exemplars (our "Hint-Engineering" data) where the timing of tool invocation is optimal. We argue this internalization is a more powerful form of learning than relying on a simpler, potentially brittle, external gate.

2. Flexibility and Contextual Nuance: An explicit gating function often reduces the decision to a simplified binary choice. Our integrated approach is far more flexible. The decision to invoke the Code Interpreter is made by the full LRM, which can consider the nuance of the entire conversation history. It's not just a decision of whether to use a tool, but which specific sequence of computations is needed at that exact moment.

3. Empirical Evidence of Generalization: Our framework's ability to develop a flexible and generalizable understanding is empirically supported by our results.

   • Diverse Code Usage: Our Code Behavior Analysis (Section 3.3, Figure 5) shows that the fine-tuned models learn to use a wide variety of Python functions for complex tasks like "Solving Equations," and "Symbolic Mathematics." This demonstrates a sophisticated, context-dependent application of the tool.
   • Out-of-Distribution (OOD) Generalization: To further address transferability, we conducted an OOD evaluation on Chemistry problems from the GPQA benchmark. This domain is far removed from our mathematical training data. Crucially, the standard tool for this domain, the RDKit library, was never included in our training data. The model's ability to spontaneously discover and effectively use this domain-specific library serves as a rigorous test of its generalization.

These results strongly suggest that the model has generalized the decision-making process of when and how to invoke tools, rather than simply memorizing triggers.

---

Q1: Will the method cause tool overuse?

Thank you for this crucial question. Our analysis on the MATH500 dataset, stratified by difficulty, shows that our framework does not lead to indiscriminate overuse. Instead, it fosters an adaptive and intelligent tool-use policy, where code usage is modulated based on problem difficulty.

The table below for our Hint-Engineering-1.5B model demonstrates this clearly:

As shown, the model consistently uses fewer code blocks for simpler problems and more for complex ones. This intelligent, demand-driven usage pattern is the antithesis of "overuse" and a hallmark of an efficient problem-solver.

---

Q2: What are the code triggering rates?

Our models achieve high and stable code triggering rates after training, demonstrating they have robustly learned to invoke the Code Interpreter.

The code usage rate after Supervised Fine-Tuning (SFT) is already high, and it is further reinforced and stabilized during Reinforcement Learning (RL). The table below details the code usage rates on the AIME24 dataset at different stages of RL training for our 1.5B models.

As the table shows, the Hint-Engineering approach achieves a very high triggering rate of 86.9% immediately after SFT, which then quickly climbs to and stabilizes above 95% during RL. This indicates that the model has effectively learned to utilize the tool consistently. A full visualization of this trend, along with other code behavior metrics, is available in Appendix D.1, Figure 8.

---

Q3: Clarification on 30 vs. 830 examples.

We thank the reviewer for this question and for the careful reading. This is not a typo; the two numbers refer to two distinct datasets used in our sequential, multi-stage training pipeline designed to scale up high-quality data.

Our process involves two main fine-tuning stages, where the output model of one stage becomes the input for the next:

1. Stage 1: Bootstrapping with SFT. We start with the base DeepSeek-R1-32B model. We perform Supervised Fine-Tuning (SFT) on it using a small, manually created set of 30 high-quality samples (D_Hint-engineering-SFT). The goal is to "bootstrap" the model, teaching it the fundamental principles of our efficient Hint-Engineering reasoning pattern. The output of this stage is the Hint-Engineering-SFT-32B model.

2. Stage 2: Scaling with RFT. We then use the improved Hint-Engineering-SFT-32B model from Stage 1 to generate solutions for a larger set of 820 problems. After automatically filtering these generated solutions for correctness and quality, we obtain approximately 800 new high-quality trajectories. We combine these with our original 30 manual samples to create a larger, scaled-up dataset of 830 examples (D_Hint-engineering-RFT). This dataset is then used for Rejection Fine-Tuning (RFT) on the Hint-Engineering-SFT-32B model, producing our final, most capable model: Hint-Engineering-RFT-32B.

The full pipeline is summarized in the table below:

---

Q4: Does suppressing reflection hinder self-correction?

We thank the reviewer for this crucial question. Our method is carefully designed to avoid this exact problem by making a critical distinction between two types of reflection:

• Unnecessary Numerical Verification: Doubting the computational accuracy of the Code Interpreter (e.g., checking if 2+2 is 4). Our hints are designed to suppress this inefficient behavior.
• Essential Logical Verification: Checking the semantic correctness of the model's own generated code to ensure it aligns with the problem-solving plan. This is a vital self-correction skill that we preserve and encourage.

As we explicitly state in the paper on lines 122-124, "while we discourage the verification of Python’s numerical calculations, we maintain the model’s behaviour to verify the logical correctness of the code structure". Therefore, our approach improves efficiency without hindering the model's ability to detect and correct its own logical code errors.

---

Typo Correction:

Thank you for catching the typo in line 267. We will correct this to "problems" in the revised manuscript.

---

Thank you again for your valuable and encouraging feedback. We believe that incorporating these changes will significantly strengthen our paper. Please let us know if there is anything else we can do to help you better understand and recommend our work.

We sincerely thank the reviewer for their detailed and insightful feedback. We are encouraged that the reviewer recognizes the value of our work, particularly the significant practical outcome of achieving a 30-50% reduction in token consumption while improving accuracy, and acknowledges that our primary novelty lies in the "Hint-Engineering" data curation strategy. We appreciate the opportunity to clarify our contributions and address the concerns raised.

---

1. On the Novelty of the CoRT Framework

We acknowledge that the individual techniques—SFT, RFT, strong-to-weak distillation, and RL—are well-established. Our novelty lies not in inventing these components, but in systematically combining them into a data-centric framework specifically engineered for the unique challenges of code-integrated reasoning.

• Addressing a Core Weakness: Our work tackles a fundamental limitation of LRMs: their struggle with precise numerical calculations and complex, multi-step logic. By integrating a Code Interpreter (CI), we augment the model's internal reasoning with external computational power.
• Unique Challenges of Tool-Integrated Reasoning: This interactive, tool-augmented reasoning is fundamentally different from tasks that rely solely on a model's internal knowledge. It introduces new challenges, such as deciding when to use a tool, how to formulate the query, and how to interpret the feedback.
• Principled Data-Centric Approach: Through systematic data curation, we identified specific failure modes—such as "delayed code computation" and "code result distrust"—and developed targeted data patterns to address them. This principled approach to designing data for tool-integrated reasoning provides actionable insights for this emerging domain.

Our contribution is demonstrating how to effectively orchestrate existing techniques to teach a model a new, more efficient reasoning paradigm, a critical step toward building more capable and practical AI systems.

---

2. On the Framing of Token Efficiency and the Necessity of Data

We agree with the reviewer that the token reduction is a direct and intended result of our hint design. However, we respectfully argue that this guided "behavioral shift" is a significant contribution. Achieving this shift is non-trivial, as simply instructing a model to "use code more" is often ineffective.

To substantiate this, we conducted an experiment demonstrating that our small-scale, high-quality data is essential for teaching this superior reasoning paradigm. We compared our fine-tuned Hint-Engineering-RFT-32B model against the DeepSeek-R1-32B model using only zero-shot prompting (without any fine-tuning).

Key Findings: Our method significantly outperforms the zero-shot baseline in accuracy (up to +14.8%) and token efficiency (-23-28%). The model learns a new reasoning strategy, increasing code usage by 2-4x for proactive computation. This demonstrates that fine-tuning on our data instills a superior, more efficient behavior unattainable through prompting alone.

---

3. On Statistical Validation for Performance Gains (Major 1 & Q1)

We thank the reviewer for highlighting this critical point and apologize if our initial presentation was unclear. To directly address your question about ensuring the 4% and 8% absolute improvements are statistically significant, we provide the following clarifications.

• Multiple Runs Are Incorporated: Our experimental setup already incorporates multiple runs for statistical validity, following best practices of DeepSeek-R1. As stated in the caption of Table 1 of the paper, results are indeed averages:

  • AIME24, AIME25, and AMC23: Averaged over 16 samples per problem.
  • MATH500 and Olympiad: Averaged over 4 samples per problem.

• Statistical Significance Testing: To further validate our claims, we conducted pairwise Wilcoxon signed-rank tests on a per-problem basis by pooling results across benchmarks. This provides a robust micro-average statistical analysis.

This analysis confirms: The accuracy gains are statistically significant for the 1.5B model (+7.41%, p=0.013) and show a strong positive trend for the 32B model (+3.80%, p=0.055). Token reduction is highly significant (p < 0.001) for both, providing robust empirical support for our claims.

---

4. On Scalability and Generalizability of "Hint-Engineering" (Major 2 & Q2)

We appreciate the reviewer's concern. To address your question about scalability, we clarify (1) why manual curation was initially necessary and (2) how our framework is designed to be scalable and generalizable.

Why Manual Curation? Elaboration on Automation Failures

Our initial attempts to fully automate hint insertion using powerful LLM judges failed due to a lack of precision. On a test set of 100 AIME problems, we identified two primary failure modes:

These subtle but critical distinctions led us to use a small, high-precision, manually-annotated seed dataset to bootstrap the process effectively.

How Our Framework Scales and Generalizes

The manual step is a highly efficient enabler, not a bottleneck. We argue that achieving significant improvements from a small, manually curated dataset is not a limitation, but rather a key strength and central finding of our work, demonstrating the high sample efficiency of our CoRT framework.

1. High Sample Efficiency of a "Seed" Dataset: The 30-sample dataset serves as a high-quality "seed" for our scalable pipeline. These manually annotated samples are not the final training set, but a strategic intervention designed to provide focused demonstrations of an efficient reasoning paradigm (i.e., using code for computation, not just verification). This process efficiently "unlocks" the model's latent capabilities. Importantly, this manual curation is not a scalability bottleneck—the human effort required is less than 2 hours, which is significantly more efficient than the extensive human annotation required in other domains like InstructGPT.

2. Scalability via "Seed-then-Scale" Pipeline: Once the model grasps these core concepts from the seed data, we employ a scalable, self-improving synthesis pipeline. As described in Lines 129-135 of our paper, the SFT model generates large volumes of candidate solutions. These are then automatically filtered for Rejection Fine-Tuning (RFT) based on final answer correctness and the absence of inefficient reasoning patterns. This creates a virtuous cycle that scales our dataset to 830 examples with minimal further manual effort, directly addressing scalability concerns.

3. Generalizability via Out-of-Distribution (OOD) Evaluation: To directly address transferability, we conducted comprehensive out-of-distribution (OOD) evaluation on Chemistry problems from the GPQA benchmark. This experiment, conducted in a domain far removed from our mathematical training data, provides compelling evidence that both performance improvements and reasoning behaviors generalize to broader settings.

   Our OOD evaluation presents a stringent test of generalization. Advanced chemistry problems require analyzing molecular structures and properties—tasks for which standard Python libraries like numpy or sympy are inadequate. The gold-standard tool for such analysis is RDKit, a powerful open-source cheminformatics library. Crucially, RDKit was never included in any of our training data. The model's ability to spontaneously discover and effectively use this domain-specific library serves as a rigorous test of its generalization capabilities.

Key OOD Findings: Our model achieves a +6.9 point accuracy gain in the unseen chemistry domain. Crucially, it spontaneously discovers and uses the correct, domain-specific RDKit library (81.3% usage), demonstrating true generalization rather than memorization.

---

Thank you again for your valuable and encouraging feedback. Your comments have helped us significantly strengthen the paper's rigor and clarity. Please let us know if we can provide any further information.

Dear reviewer, please read the rebuttal and engage with the discussion with the author. Thank you!

AC

We sincerely thank the reviewer for their insightful and constructive feedback. We are particularly encouraged that the reviewer recognized and appreciated the clarity of our writing, the comprehensiveness of our experiments, and the core finding that high-quality data is more impactful than sheer quantity. These acknowledgments affirm the central contributions of our work.

We are grateful for the opportunity to address the remaining concerns and further clarify our contributions:

---

W1: Limited Scale of Hint-Engineering Data, Scalability, and Necessity of Small Data

We would like to clarify that achieving significant improvements with a small, manually curated dataset is not a limitation, but rather a key strength and central finding of our work, demonstrating the high sample efficiency of our CoRT framework.

• A High-Quality Seed for a Scalable Pipeline: The 30-sample dataset serves as a strategic "seed" to efficiently elicit the base model's latent capability to interact effectively with a Code Interpreter. The manual effort is minimal (<2 hours), far more efficient than the extensive annotation required in works like InstructGPT. Our approach then scales through automated data synthesis via Rejection Fine-Tuning (RFT), where the model generates large volumes of candidate solutions which are then filtered for quality, creating a virtuous self-improvement cycle.

• Necessity of Seed Data: To demonstrate that this small-scale data is essential, we conducted zero-shot experiments on the DeepSeek-R1-32B. The results below show that prompting alone cannot achieve the same fundamental shift in reasoning behavior that our method enables.

Our Hint-Engineering model achieves significantly higher accuracy while using 23-28% fewer tokens. Critically, the "Avg. Code Blocks" metric shows a dramatic behavioral shift: our model uses 2-4 times more code blocks, indicating a learned, efficient strategy of proactive computation. This aligns with recent findings [1] on the power of small, high-quality data.

[1] "The Challenge of Teaching Reasoning to LLMs Without RL or Distillation."

---

W1: Generalization to Broader Settings

To directly address transferability, we conducted a comprehensive out-of-distribution (OOD) evaluation on Chemistry problems from GPQA. This stringent test assesses if the model can generalize its reasoning and tool-use skills to a completely new domain, including discovering and using a domain-specific library (RDKit) that was never seen during training.

The results show robust cross-domain transfer: our model achieves a 6.9-point accuracy gain, uses 29% fewer tokens, and spontaneously discovers and utilizes the novel RDKit tool in 81.3% of cases. This provides strong evidence that our framework teaches generalizable reasoning capabilities, not domain-specific memorization.

---

W2: Lack of Statistical Significance Testing

We thank the reviewer for this constructive suggestion.

We must clarify that our results are statistically meaningful as each reported accuracy is a stable estimate averaged over multiple stochastic samples (4 or 16 per problem), not a single-shot result, thus significantly reducing the impact of randomness as described in caption of table 1. Then we have now conducted pairwise Wilcoxon signed-rank tests by pooling results across all problems from the benchmarks to assess statistical significance.

The analysis confirms that our efficiency gains are highly significant (p < 0.001). Accuracy improvements are also statistically significant for the 1.5B model (p=0.013) and approach significance for the 32B model (p=0.055).

---

W3: Inference Time Analysis Missing

We thank the reviewer for this critical question. To confirm that token efficiency translates to real-world speed, we conducted a comprehensive latency analysis on AIME24, decomposing wall-clock time into Generation Time and Execution Time.

The results are definitive:

1. Generation time is the bottleneck, accounting for over 96% of total latency.
2. Our method achieves a 46.0% reduction in total wall-clock time, a substantial real-world speedup. This confirms that token efficiency is the primary driver of performance gains in this setting.

---

W4 & Q1: Alternative Baselines

• Length-based Penalty: We agree this is an intuitive baseline. However, a simple length penalty is a "black box" method that cannot distinguish between efficient conciseness and logical incompleteness. Our experiments show that simply finetuning on the shortest responses (prompt-hint-Shortest) leads to worse performance than random sampling, while our Hint-engineering approach achieves the highest performance with the shortest generation length, demonstrating it learns true efficiency.

• ToolLLM with Function Calling: We agree that function-calling is effective for simple tasks, but argue that for complex mathematical reasoning, code generation offers indispensable advantages in flexibility, expressiveness, and emergent problem-solving.

  • Flexibility & Composability: Pre-defined APIs are rigid. They cannot handle novel combinations of functions or tasks requiring intermediate logic (e.g., loops, conditionals). In contrast, code generation empowers the model to dynamically orchestrate tools using loops, variables, and conditional logic, acting as a powerful "computational glue" for complex, multi-step reasoning. This is essential for problems like iterative approximation that have no single, pre-defined tool.
  • Expressiveness & Generalization: An API toolkit is inevitably incomplete. It cannot cover the "long tail" of thousands of functions in libraries like SymPy. Code generation provides universal access to the entire library ecosystem. Our Out-of-Distribution (OOD) experiment provides the strongest evidence: the model spontaneously discovered and used the unseen RDKit library to solve chemistry problems, a feat impossible for a system with a fixed API set.

---

Q2: Impact of R1-style Base Model

Our goal was to augment a SOTA LRM, leveraging its sophisticated reasoning patterns (e.g., self-reflection, hypothesis testing) and combining them with computational precision. This hybrid approach, also seen in proprietary models like OpenAI's o3, is a key research gap in the open community. Our work aims to fill this gap. To validate this design choice, we compared our LRM-based models with a strong code-centric baseline.

Our LRM-based models substantially outperform the code-centric baseline by ~10 absolute percentage points. This suggests that the "heavy text reasoning" from the LRM base provides strategic advantages like problem structuring, strategic tool deployment, and self-verification, which are crucial for top-tier performance on complex tasks.

---

Q3: Prompting to Skip Verification

This is an astute suggestion. We experimented on D_{Hint-engineering-SFT} and found that explicitly prompting the model to skip verification does reduce token usage, but our Hint-Engineering method is far more effective.

---

Q4: Overhead of Code Execution for Small LLMs

We clarify that our work focuses on the fundamental challenge of integrating systematic reasoning with natural language reasoning, a paradigm applicable across model scales. We note that commercial products like ChatGPT successfully integrate code execution without prohibitive overhead, and we believe deployment challenges are addressable through engineering advances.

---

Q5: Formatting in Line 119

'''python is a special token that starts with the code block, not a typo, we will explain it further.