AlgoPilot: Cross-Paradigm Reasoning in Language Models via Strategy Selection and Guidance

Introduction

Large language models (LLMs) have demonstrated strong reasoning capabilities, especially when augmented with intermediate reasoning steps or external tools [35, 11, 42, 29, 24]. However, real-world reasoning problems are highly heterogeneous and are not difficult for a single reason. Different problems exhibit substantially different characteristics: some can be solved directly through natural-language reasoning, some are better handled by writing and executing code, while others require specialized formal formulations and executors, such as SMT [2] solvers for logical constraints, PDDL [20] planners for symbolic planning, or MILP [3] solvers for optimization. Thus, effective reasoning often requires choosing among fundamentally different computational paradigms.

This observation aligns with a classical challenge in algorithm selection: no single solver or strategy is uniformly best across heterogeneous problem instances. Effective problem solving typically requires choosing a suitable method for the specific instance being considered [28, 12, 39, 17]. In the context of LLM reasoning, this challenge requires LLMs to not only infer an appropriate solving paradigm but also construct a correct formulation within that paradigm. For example, optimization problems require specifying decision variables, objectives, and constraints, planning problems require defining states, actions, and transitions, and constraint-satisfaction problems require logical formulations. Thus, effective cross-domain reasoning requires both adaptive strategy selection and strategy-specific formulation.

Recent work demonstrates that structured intermediate representations and external executors can substantially improve the reliability and correctness of reasoning. Chain-of-thought prompting encourages natural-language intermediate reasoning steps [35], and other approaches augment LLMs with executable programs, external tools, or formal solver-based formulations such as logical reasoning, satisfiability solving, planning, and optimization [11, 42, 29, 22, 43, 27, 1, 38, 16, 15]. Recent code-augmented reasoning methods further study how to steer LLMs between textual reasoning and code execution, either by training a separate guidance model or by fine-tuning Code-Interpreter-augmented models [8, 9]. These methods highlight the importance of selecting an appropriate reasoning medium, but they primarily focus on the text–code distinction or a specific formal executor. More recently, adaptive inference and orchestration approaches have explored dynamically selecting model choices, prompting strategies, sampling budgets, decomposition granularities, or model–tool combinations conditioned on input difficulty or task requirements [45, 23, 36, 32]. While these methods demonstrate the value of input-dependent routing, their routing spaces are largely defined by inference configurations, prompting strategies, models, and external tools, rather than by fundamentally different computational paradigms and their corresponding problem formulations.

In this paper, we propose AlgoPilot (illustrated in Figure 1), a cross-paradigm reasoning framework that learns to adaptively select problem-solving paradigms and formulate problems within those paradigms before execution. Given a natural-language problem, AlgoPilot decomposes reasoning into three stages. First, a SteerLM selects a paradigm, choosing among textual reasoning, programmatic execution, symbolic constraint solving, planning, and optimization. The SteerLM additionally determines whether structured guidance is needed before execution. Second, if guidance is needed, a paradigm-specific GuideLM generates structured formulation guidance tailored to the selected paradigm. Third, an ExecuteLM generates the final reasoning process, program, or solver implementation based on the selected paradigm and optional guidance. This design separates what computational paradigm to use from how to formulate the problem under that paradigm, enabling adaptive coordination of heterogeneous reasoning paradigms within a unified learned framework.

We fine-tune the paradigm-specific GuideLMs via supervised fine-tuning (SFT) on filtered, structured guidance that reliably improves downstream execution. The SteerLM is trained with SFT followed by Group Relative Policy Optimization (GRPO) [30] using execution-derived feedback across multiple paradigm–mode combinations. AlgoPilot is a general cross-paradigm reasoning framework that can be integrated with arbitrary language models. In this work, we instantiate the framework using Qwen3-8B [40] as the base model. We evaluate AlgoPilot on 13 benchmarks across 66 diverse reasoning domains spanning programmatic reasoning, natural-language reasoning, symbolic planning, logical constraint solving, and mathematical optimization. Experimental results demonstrate that AlgoPilot substantially improves performance over similarly scaled model baselines from 38.4% to 72.9% and outperforms the best large model prompting baseline GLM-5 by 11.7%. Ablation studies further validate the importance of both adaptive paradigm selection and structured formulation guidance. Finally, we show that the learned steering and guidance modules are effective not only for the base execution model used during training, suggesting that cross-paradigm strategy selection has the potential to serve as a transferable reasoning layer for LLM problem solving.

In summary, our key contributions are:

• We identify adaptive paradigm selection and paradigm-specific formulation construction as two central challenges in cross-paradigm LLM reasoning.

• We propose AlgoPilot, a unified framework that decomposes problem solving into paradigm steering, structured formulation guidance, and execution across heterogeneous paradigms.

• We build a diverse cross-paradigm evaluation suite by integrating 13 reasoning benchmarks spanning 66 domains, and construct empirical paradigm–mode supervision from downstream execution outcomes, enabling supervised fine-tuning and reinforcement learning for adaptive strategy selection and structured formulation guidance.

• We demonstrate that AlgoPilot improves the average accuracy for the same small model from 38.4% to 72.9%, outperforms the best large model baseline by 11.7%, and that its learned steering and guidance components can transfer to improve another execution model.

Related Works

LLM Reasoning. Recent work has explored augmenting the LLM generation process with additional structure to improve reasoning capability. Chain-of-thought prompting encourages models to solve problems through intermediate natural language reasoning steps [35], while program-aided methods generate executable code as a structured reasoning medium [11]. Tool-augmented methods further extend LLMs with external modules and feedback during inference [42, 29, 24, 25, 6]. Beyond general tool use, several works connect LLMs with formal executors, including logic solvers [22], satisfiability solvers [43, 16, 15], planning systems [14, 7, 19], and optimization solvers [27, 18, 38, 41]. Recent code-augmented methods study the more specific problem of steering between textual reasoning and code execution [8, 9]. These works show the value of symbolic or executable reasoning, but most focus on a single executor or on the text–code choice. AlgoPilot generalizes this direction to multiple computational paradigms, including CoT, Code, SMT, PDDL, and MILP.

Adaptive Selection. Another relevant direction studies how to choose among multiple inference options. Recent adaptive inference and routing methods select models, prompts, sampling budgets, decomposition granularities, or model–tool combinations based on the input [5, 21, 45, 23, 36, 32]. These works demonstrate the value of input-dependent selection. In parallel, classical algorithm selection and portfolio methods address how to choose an appropriate solver for each problem instance [28, 12, 39, 17]. AlgoPilot brings this perspective to the LLM reasoning setting by learning to select a paradigm–mode pair for each input and, unlike prior routing methods, explicitly generating paradigm-specific formulation guidance prior to solver execution.

AlgoPilot

Problem Formulation and Challenges

Given a reasoning problem instance $q$ described in natural language, AlgoPilot aims to produce a solution $s$. Given the diversity of such problems, this task comes with two key challenges.

• Unspecified Solving Paradigms. The reasoning problems can be solved by different solving paradigms. In this paper, we focus on the following five paradigms: natural language reasoning (CoT), code-based execution (Code), constraint solving (SMT), symbolic planning (PDDL), and mathematical optimization (MILP). Yet the optimal solving paradigm for each problem is not specified in the input and has to be inferred as part of the problem-solving process.

• Complex Paradigm Formulations. Most of the paradigms require transforming the natural language problem description into paradigm-specific formulations, such as defining variables, constraints, or intermediate reasoning structures. General-purpose LLMs tend to struggle in obtaining the correct problem formulations.

AlgoPilot Pipeline

To solve the above challenges, the AlgoPilot framework decomposes the problem solving into three stages, steering, guidance, and execution.

Stage 1: Steering. Given the problem $q$, a trained model, SteerLM, determines the most appropriate solving paradigm for it, and whether further guidance is needed in the paradigm formulation. Formally, denote the SteerLM forward process as $S$. Then the steering stage can be represented as

where $p \in\{\mathrm{CoT},\mathrm{Code},\mathrm{SMT},\mathrm{PDDL},\mathrm{MILP}\}$ specifies the appropriate solving paradigm; $m \in\{\mathrm{Guided},\mathrm{Direct}\}$ specifies whether additional guidance is needed. Typically, additional guidance is needed if the paradigm formulation is complicated. An example of this process is shown in Figure 1 (Panel 1).

Stage 2: Guidance. If $m = \mathrm{Guided}$, a paradigm-specific GuideLM is invoked to generate structured guidance $g$ to instantiate the problem under the chosen paradigm. Formally, denote the GuideLM forward process as $\{G_p\}$. Note that we have different GuideLMs for different paradigms (hence the subscript $p$). Then the guidance stage can be represented as

The structured guidance templates are specialized for each paradigm to reflect paradigm-specific formulation requirements. An example of the guidance process (for $p = \mathrm{MILP}$) is shown in Figure 1 (Panel 2). Please refer to Appendix § 9.§ 1 for the guidance templates for all paradigms.

Stage 3: Execution. Given the input problem $q$, the selected paradigm–mode pair $(p,m)$, and optional guidance $g$, ExecuteLM, a general-purpose LLM (such as Qwen3-8B), produces the final answer $s$ under the specified solving paradigm. Formally, denote the ExecuteLM forward process as $\mathcal{E}$. Then the execution stage can be represented as

For example, in Figure 1, under the MILP paradigm with guidance, the ExecuteLM translates the structured formulation into an optimization program and invokes a solver to obtain the final solution. Appendix E.1 lists the prompt template for ExecuteLM.

AlgoPilot Training

For ExecuteLM, we adopt the unmodified LLM, such as Qwen3-8B, as is. However, SteerLM and GuideLM both need to be further fine-tuned to possess the highly specific skills of steering and guidance. One of the key challenges for training these two LMs is the construction of supervised training data, which requires searching for appropriate paradigms and guidance for each problem. What is worse, the steering task is essentially a multi-label prediction problem: the same problem may be well-solved by many different paradigms, making the searching combinatorially expensive. To address this challenge, we propose the following training procedure:

• Step 1: Initial Dataset Construction. Construct an initial dataset,

where each question $q_i$ comes with only one unique paradigm label $p_i$ but multiple correct guidances (indexed by $j$). This step only requires searching for multiple correct guidances ($m$ and $g$), but not searching for paradigms ($p$), because the paradigm is set to a single label.

• Step 2: GuideLM Training. Train GuideLM, $\{G_p\}$, by SFT on $D_0$.

• Step 3: Dataset Expansion. Expand the dataset to include multiple valid paradigms,

Note that this step requires searching for multiple paradigms ($p$), but it does not require searching for multiple guidances ($m$ and $g$) for each paradigm, because the valid guidances can be generated by the trained GuideLM.

• Step 4: SteerLM Training. Train SteerLM, $S$, by SFT on $D_1$ followed by RL.

Essentially, we disentangle the searching for guidances (Step 1) and searching for paradigms (Step 3), thus avoiding a joint combinatorial search. Further details for Steps 1, 3 and 4 are provided in Sections 3.3.1 to 3.3.3, respectively. Details of Step 2 are provided in Appendix C.2.

Initial Dataset Construction

We first collect question-paradigm data $\{(q_i,p_i)\}$, by aggregating paradigm-specific benchmark datasets. For example, we merge the training tasks from MILP benchmark datasets such as OptiGuide [18], and then set their (unique) paradigm label to MILP. A full list of benchmark datasets are provided in Section 4.1.

We then pair each question-paradigm data $(q_i,p_i)$, with valid guidances via search and filtering. Specifically, for each $(q_i,p_i)$, we sample $K$ candidate guidances $\{g'_{i1},\ldots,g'_{iK}\}$ ($K=5$ in our implementation) using base model Qwen3-8B, each representing a potential structured formulation. To evaluate their quality, ExecuteLM generates multiple runs for each guidance (five runs in our implementation). We measure its effectiveness using execution success, defined as the number of runs that produce correct solutions. A guidance is considered useful if it yields at least three successful executions. We retain only useful guidances and keep up to three such $(q,g)$ pairs per problem to ensure data quality and diversity.

Dataset Expansion

To expand the dataset to include multiple valid paradigms, we evaluate the effectiveness of all paradigms for each problem instance. As illustrated in Figure 2, for each problem $q_i$, we consider all paradigms under both Guided and Direct modes. For Guided mode, each paradigm-specific GuideLM generates candidate guidances, which are again executed multiple times. For Direct mode, the ExecuteLM directly produces solutions without guidance, also evaluated over multiple runs.

We measure the effectiveness of each paradigm–mode combination using execution success rate, defined as the fraction of runs that produce correct solutions. A combination is considered useful if it consistently yields successful outcomes. In our implementation, Direct mode requires achieving at least three successful executions out of five runs, and Guided mode requires having at least three guidances, each of which can achieve at least three successful executions out of five. For each problem instance, we rank the useful $(p,m)$ as a candidate list with at most three elements and use it as the supervision label for SteerLM. The dataset is further balanced across paradigms to avoid bias toward dominant categories.

SteerLM Training

We train SteerLM in two stages. First, we perform SFT on the expanded dataset $D_1$, which contains 5.8k datapoints, for 1 epoch to prevent overfitting. We then apply GRPO [30] to further refine the model based on execution-derived rewards.

Output Format. In both training stages, SteerLM is instructed to directly output an ordered list of paradigm-mode pairs. An example output string is given as follows

$[\text{“DIRECT\_CODING”},\ \text{“GUIDED\_CODING”},\ \text{“GUIDED\_SMT”}]$

GRPO Reward Design. During the GRPO training, given a problem instance $q_i$, the policy $\pi_\theta$ generates a group of $G$ candidate outputs $\{y_{ij}\}_{j=1}^{G}$. For each sampled output $y_{ij}$, we parse the ranked predicted labels and retrieve their precomputed execution scores from cross-paradigm evaluation. The score is computed to avoid repeated execution during training while preserving consistency with the underlying evaluation process. We use the execution success rates as the score for useful $(p,m)$ pairs and multiply a weight of 0.5 for other pairs to encourage the model to prioritize possible useful candidates. Let $S_k$ denote the score of the $k$-th predicted candidate, and let $S_{\mathrm{base}}$ denote the base score for the problem instance if it uses its default paradigm annotation in $D_0$. We define

where missing candidates receive score zero. We further define a ranking bonus $B_{\mathrm{rank}}(y_i)$ that rewards predicting labels with higher scores first, a $P_{\mathrm{fmt}}$ that penalizes invalid formatting, and a $P_{\mathrm{dup}}$ that penalizes duplicate predictions. The final reward is

In our implementation, we set $\lambda_1=0.7$, $\lambda_{\mathrm{adv}}=0.3$, $\lambda_2=0.10$, $\lambda_3=0.05$, $\lambda_{\mathrm{rank}}=0.05$, $\lambda_{\mathrm{fmt}}=0.05$, and $\lambda_{\mathrm{dup}}=0.05$. This training procedure enables SteerLM to prioritize paradigm–mode combinations that consistently lead to successful execution outcomes, while maintaining flexibility in representing multiple viable strategies. Further training details are in Appendix § 8.§ 1.

Experimental Results

Experimental Setup

Benchmarks and domains. We evaluate AlgoPilot on a heterogeneous benchmark suite spanning five reasoning paradigms: textual reasoning (CoT), code-based execution (Code), constraint solving (SMT), symbolic planning (PDDL), and mathematical optimization (MILP). These categories indicate the original task labels used to organize the benchmark suite, and are not treated as ground-truth optimal paradigms, since an individual problem may be solvable by multiple paradigms. The suite covers 66 domains drawn from 13 benchmarks, including Big-Bench Hard [33], GSM8K [10], CLUTRR [31], LeetCodeDataset [37], optimization benchmarks such as OptiGuide [18], Chain-of-Experts [38], OptiBench [41], NL4Opt [1], NLP4LP [27], and LLMFP [16], planning domains from the International Planning Competition [34], and logical reasoning tasks from SAT-LM [43] and Logic-LM [22]. Together, these tasks form a heterogeneous evaluation suite that requires models to solve problems using substantially different computational structures, ranging from direct natural-language reasoning and executable programs to formal planning, satisfiability solving, and optimization modeling. Full descriptions of all domains are provided in Appendix § 14. The full dataset contains approximately 22k problem instances. We randomly split all problem instances into training, validation, and test sets with ratios of 80%, 10%, and 10%, respectively. We use the training split to construct GuideLM and SteerLM training data, the validation split for model selection, and the held-out test split only for final evaluation. All reported results are computed on the same test split across AlgoPilot and all baselines. The test set contains 2,220 problem instances, including 640 Code, 461 CoT, 221 MILP, 446 PDDL, and 452 SMT problems.

Baselines and AlgoPilot variants. We compare AlgoPilot, based on Qwen3-8B [40], with recent similarly-scaled and large models. The small-model baselines include Qwen3.5-9B [26] and Gemma-4-E4B-it (8B total parameters) [13]. The large Mixture-of-Experts models include GLM-5 (744B total parameters) [44] and Qwen3-Coder-Next (80B total parameters) [4]. For each model, we evaluate two prompting configurations. In the DIRECT setting, the LLM is prompted to directly solve the problem. In the REASON setting, the LLM is prompted to first reason about the appropriate solution approach and then produce the executable solution or answer.

Since AlgoPilot is trained to predict a ranked list of up to three appropriate paradigm–mode pairs, we use the first-ranked pair as the default prediction for evaluation. We include a variant that selects the best measured paradigm–mode pair among the predicted candidates to measure the quality of the predicted candidate set. We report three variants of AlgoPilot. AlgoPilot $_{\mathrm{SFT}}$ uses a SteerLM trained only with SFT, AlgoPilot $_{\mathrm{SFT+GRPO}}$ further refines the SteerLM with GRPO and uses its first predicted paradigm–mode pair for execution. AlgoPilot $_{\mathrm{SFT+GRPO,TOP3}}$ uses the same GRPO-trained SteerLM, but evaluates the best measured paradigm–mode pair among its top three predictions.

Evaluation metric. We use accuracy as the evaluation metric. For each problem, a generated solution is considered correct if its final answer matches the ground-truth answer or, for planning problems which may have multiple valid plans, if the generated plan is valid. We sample three solutions per problem and report the average success rates. For Direct mode, the three solutions are generated by three ExecuteLM runs, while for Guided mode, the three solutions are generated by first creating three guidances with GuideLM and generating one ExecuteLM run per guidance. All models and baselines are evaluated with the execution pipeline, timeouts, and answer checkers.

Cross-Paradigm Evaluation Analysis

Before evaluating end-to-end performance, we analyze how the empirically best solving paradigms relate to the original task categories. Figure 3 shows the distribution of empirically best paradigms for examples from each original task category. The distribution is computed over examples with at least one useful paradigm–mode label. While some categories are dominated by their nominal paradigm, many examples are better solved by alternative paradigms. This shows that many problems admit multiple viable solving routes, and that the most effective paradigm may differ from the original task category, motivating instance-level steering across heterogeneous paradigms.

AlgoPilot Performance

We include the accuracy comparison of AlgoPilot, variants of AlgoPilot, and baselines of both large and small models across five reasoning categories in Table 1 (see Table 15 for results with standard deviation across three runs). We include the cost statistics and failure analysis for baselines and AlgoPilot in Appendix F and G. There are four takeaways:

Model / Method	Code	CoT	PDDL	SMT	MILP	Avg.
Large models
GLM-5DIRECT	91.6	55.4	54.6	62.2	42.1	61.2
GLM-5REASON	92.5	29.6	46.0	82.2	47.7	59.6
Qwen3-Coder-NextDIRECT	90.5	46.3	1.9	55.6	32.7	45.4
Qwen3-Coder-NextREASON	83.3	40.4	7.9	62.9	43.9	47.7
Small-model baselines
Qwen3.5-9BDIRECT	77.0	35.7	0.0	54.7	29.0	39.3
Qwen3.5-9BREASON	85.6	62.8	0.0	81.0	25.9	51.1
Gemma-4-E4B-itDIRECT	72.4	32.5	2.5	58.6	29.1	39.0
Gemma-4-E4B-itREASON	61.8	74.0	1.3	76.6	40.1	50.8
Qwen3-8B as the base execution model
Qwen3-8BDIRECT	67.0	42.8	0.0	63.7	18.3	38.4
Qwen3-8BREASON	71.0	26.4	0.0	62.2	20.7	36.1
AlgoPilot SFT	62.7	75.3	91.5	48.4	58.1	67.2
AlgoPilot SFT+GRPO	72.9	75.8	91.5	64.6	59.6	72.9
Top-3 selection analysis
AlgoPilot SFT+GRPO,TOP3	84.0	84.8	91.5	84.9	63.5	81.7

Model / Method	Code	CoT	PDDL	SMT	MILP
_Large models_
GLM-5$_{\mathrm{DIRECT}}$	$91.6 \pm1.0$	$55.4 \pm0.4$	$54.6 \pm0.8$	$62.2 \pm0.6$	$42.1 \pm2.0$
GLM-5$_{\mathrm{REASON}}$	$92.5 \pm0.8$	$29.6 \pm0.8$	$46.0 \pm0.7$	$82.2 \pm0.6$	$47.7 \pm1.2$
Qwen3-Coder-Next$_{\mathrm{DIRECT}}$	$90.5 \pm0.1$	$46.3 \pm0.5$	$1.9 \pm0.7$	$55.6 \pm1.6$	$32.7 \pm0.4$
Qwen3-Coder-Next$_{\mathrm{REASON}}$	$83.3 \pm0.7$	$40.4 \pm0.7$	$7.9 \pm0.7$	$62.9 \pm2.3$	$43.9 \pm1.3$
_Small-model baselines_
Qwen3.5-9B$_{\mathrm{DIRECT}}$	$77.0 \pm0.6$	$35.7 \pm1.2$	$0.0 \pm0.0$	$54.7 \pm1.4$	$29.0 \pm2.0$
Qwen3.5-9B$_{\mathrm{REASON}}$	$85.6 \pm1.0$	$62.8 \pm2.4$	$0.0 \pm0.0$	$81.0 \pm0.9$	$25.9 \pm2.1$
Gemma-4-E4B-it$_{\mathrm{DIRECT}}$	$72.4 \pm0.9$	$32.5 \pm1.4$	$2.5 \pm0.6$	$58.6 \pm1.2$	$29.1 \pm1.1$
Gemma-4-E4B-it$_{\mathrm{REASON}}$	$61.8 \pm0.9$	$74.0 \pm0.3$	$1.3 \pm0.6$	$76.6 \pm0.9$	$40.1 \pm2.0$
_Qwen3-8B as the base execution model_
Qwen3-8B$_{\mathrm{DIRECT}}$	$67.0 \pm0.5$	$42.8 \pm0.9$	$0.0 \pm0.0$	$63.7 \pm1.0$	$18.3 \pm2.0$
Qwen3-8B$_{\mathrm{REASON}}$	$71.0 \pm0.6$	$26.4 \pm0.9$	$0.0 \pm0.0$	$62.2 \pm0.2$	$20.7 \pm2.3$
AlgoPilot SFT	$62.7 \pm0.4$	$75.3 \pm0.2$	$91.5 \pm0.4$	$48.4 \pm0.7$	$58.1 \pm0.7$
AlgoPilot SFT+GRPO	$72.9 \pm0.4$	$75.8 \pm0.1$	$91.5 \pm0.4$	$64.6 \pm1.9$	$59.6 \pm0.7$

First, AlgoPilot $_{\mathrm{SFT+GRPO}}$ achieves the best average performance of 72.9% among all methods and baselines, excluding the Top-3 analysis variant which is not directly comparable. AlgoPilot $_{\mathrm{SFT+GRPO}}$ outperforms the best performing baseline GLM-5$_{\mathrm{DIRECT}}$ by an average of 11.7%. The improvement is particularly pronounced on PDDL and MILP, where direct prompting struggles because the problems are complicated and need a precise formal specification construction before execution. In contrast, AlgoPilot allows adaptive steering and provides paradigm-specific formulation guidance, allowing the model to construct more reliable solver-based solutions.

Second, AlgoPilot SFT+GRPO improves the average accuracy of Qwen3-8B base model from 38.4% under DIRECT prompting and 36.1% under REASON prompting to 72.9%. This demonstrates that our cross-paradigm reasoning framework can substantially strengthen the problem-solving capability of the same underlying model.

Third, comparing AlgoPilot SFT and AlgoPilot SFT+GRPO, GRPO improves average accuracy from 67.2% to 72.9%. The largest gains appear on Code and SMT, where cross-paradigm evaluation reveals a more diverse set of effective solving paradigms (see Figure 3). This suggests that execution-derived rewards help SteerLM better rank and prioritize effective paradigm–mode choices within the candidate space learned from SFT.

Finally, AlgoPilot SFT+GRPO,TOP3 reaches 81.7% average accuracy by selecting the best measured paradigm–mode pair among the top three predictions. This result suggests that SteerLM learns a useful set of paradigm–mode candidates, even when the top-ranked choice is not always optimal.

Ablation Studies

To isolate the contribution of each component, we evaluate ablation variants that differ in the steer source and guide source. For the steer source, SELF denotes prompting the ExecuteLM to choose the solving strategy by itself, while STEERLM denotes using the learned steering model. For guidance, NONE means no intermediate formulation is provided, while GUIDELM means a structured formulation guidance generated by the corresponding paradigm-specific GuideLM is provided. We also report oracle variants that use measured execution outcomes to select the best paradigm–mode pair, serving as diagnostic upper bounds.

We include the accuracy comparison of AlgoPilot $_{\mathrm{SFT+GRPO}}$ and the ablation variants in Table 2. There are two takeaways.

Variant	Steer source	Guide source	Code	CoT	PDDL	SMT	MILP	Avg.
V1	NONE	NONE	67.0	42.8	0.0	63.7	18.3	38.4
V2	SELF	NONE	71.0	26.4	0.0	62.2	20.7	36.1
V3	SELF	GUIDELM	54.0	69.1	38.6	38.5	26.4	45.3
V4	STEERLM	NONE	67.7	72.7	25.6	26.1	36.5	45.7
AlgoPilot SFT+GRPO	STEERLM	GUIDELM	72.9	75.8	91.5	64.6	59.6	72.9
ORACLE1	ORACLE	NONE	80.7	80.8	11.0	76.2	28.8	55.5
ORACLE2	ORACLE	GUIDELM	89.6	88.6	91.6	88.1	64.6	84.5

First, the comparisons of V2 (36.1%) vs. V4 (45.7%) and V3 (45.3%) vs. AlgoPilot $_{\mathrm{SFT+GRPO}}$ (72.9%) demonstrate the effectiveness of SteerLM. Similarly, the comparisons of V2 (36.1%) vs. V3 (45.3%) and V4 (45.7%) vs. AlgoPilot $_{\mathrm{SFT+GRPO}}$ (72.9%) demonstrate the effectiveness of GuideLM. ORACLE1 (55.5%) vs. ORACLE2 (84.5%) shows that even when the best paradigm–mode choice is known, successful execution often still requires high-quality formulation guidance. These results show that learned steering and structured guidance each contribute to the final performance.

Second, although both components are individually useful, using either steering or guidance alone provides only limited improvement. Combining them together (AlgoPilot $_{\mathrm{SFT+GRPO}}$) significantly improves the performance to 72.9%, substantially outperforming all ablated variants. This indicates that the two components are complementary and both are necessary components of the cross-paradigm reasoning framework.

Robustness and Generalization

Robustness to prompt reformulation. To test whether the learned steering and guidance modules are robust to changes in problem wording, we generate three paraphrases for each test problem, covering lexical changes, syntactic restructuring, and natural alternative formulations while preserving the underlying problem. The top-1 routing decision of SteerLM agrees with that on the original input in 98.0% of cases. As shown in Table 3, AlgoPilot achieves an averaged accuracy of 68.6% on paraphrased inputs, compared with 72.9% on the original inputs. Detailed results by paraphrase style and additional routing metrics are provided in Appendix § 10.§ 2.

Method & Input	Code	CoT	PDDL	SMT	MILP	Avg.
AlgoPilot $_{\mathrm{SFT+GRPO}}$, Original	72.9	75.8	91.5	64.6	59.6	72.9
AlgoPilot $_{\mathrm{SFT+GRPO}}$, Paraphrased	69.7	74.2	90.5	50.7	58.0	68.6

The high routing agreement suggests that SteerLM consistently selects reasoning paradigms across different descriptions of the same task. The small end-to-end accuracy changes further support the robustness of AlgoPilot to variations in wording, syntax, and presentation. This provides evidence that the learned steering and structured guidance are reusable across alternative problem descriptions, extending their applicability beyond fixed task-description templates.

Generalization to Unseen Domains and Benchmarks. To test the generalization capability of AlgoPilot beyond the original instance-level split, we evaluate AlgoPilot on 432 problems from 10 held-out domains spanning all five paradigms. These include new domains within seen benchmarks and tasks from unseen benchmarks. As shown in Table 4, AlgoPilot improves the instance-weighted average accuracy from 53.0% under DIRECT prompting and 66.2% under REASON prompting to 73.3%. The full domain-level results and evaluation details are provided in Appendix § 10.§ 2.

Method	Code	CoT	SMT	MILP	PDDL	Avg.
Qwen3-8B$_{\mathrm{DIRECT}}$	74.7	63.0	54.7	39.7	0.0	53.0
Qwen3-8B$_{\mathrm{REASON}}$	92.0	67.3	74.3	56.0	0.0	66.2
AlgoPilot $_{\mathrm{SFT+GRPO}}$	85.1	71.3	73.7	54.2	99.1	73.3

The held-out evaluation suggests meaningful but incomplete cross-domain generalization. Among AlgoPilot’s failed instances, only 22.4% are routed to a paradigm different from the source category, indicating that SteerLM generally transfers its paradigm-selection behavior to unseen domains. The remaining errors are therefore more often attributable to downstream formulation or execution, with GuideLM formulation transfer emerging as the main bottleneck. AlgoPilot achieves the best overall accuracy and substantial gains on several unseen benchmark families. These results suggest that the steering mechanism generalizes beyond the original instance-level split, while broader cross-domain training and refinement of the GuideLM experts remain important directions for improvement.

Transfer to Another ExecuteLM. To test whether the learned steering and guidance modules can transfer to another ExecuteLM, we replace the default Qwen3-8B ExecuteLM with Gemma-4-E4B-it while keeping the same trained SteerLM and GuideLM. As shown in Table 5, transferred AlgoPilot improves the average success rate from 39.0% under DIRECT prompting and 50.8% under REASON prompting to 60.5%. The largest gains appear on PDDL and MILP, suggesting that the learned steering and structured formulation guidance can help a different execution model handle complex formal planning and optimization tasks.

Model / Method	Code	CoT	PDDL	SMT	MILP	Avg.
Gemma-4-E4B-it$_{\mathrm{DIRECT}}$	72.4	32.5	2.5	58.6	29.1	39.0
Gemma-4-E4B-it$_{\mathrm{REASON}}$	61.8	74.0	1.3	76.6	40.1	50.8
Gemma-4-E4B-it w/ AlgoPilot $_{\mathrm{SFT+GRPO}}$	78.3	79.5	57.5	42.1	45.1	60.5

The transfer gain is smaller than the improvement observed with Qwen3-8B as the default ExecuteLM. This is expected because the guidance filtering, cross-paradigm evaluation, and GRPO reward construction are all derived from execution outcomes of the original execution model. A different ExecuteLM may follow the same guidance differently or exhibit different paradigm-specific failure modes. Nevertheless, the positive transfer result suggests that AlgoPilot learns strategy and formulation information is partially reusable across models. This motivates future work on more generalizable cross-paradigm reasoning frameworks, for example, training with execution feedback from multiple ExecuteLMs or incorporating target-model-specific rewards during steering optimization.

Conclusion

We introduce AlgoPilot, a cross-paradigm reasoning framework that decomposes LLM problem solving into paradigm selection, structured formulation guidance, and execution. Instead of relying on a fixed reasoning template or a single tool interface, AlgoPilot learns to adaptively select among natural-language reasoning, code execution, constraint solving, symbolic planning, and mathematical optimization, while also deciding whether a structured guidance is needed. Through execution-driven data construction, supervised fine-tuning, and reinforcement learning, AlgoPilot learns both effective steering and paradigm-specific formulation patterns. Experiments across diverse reasoning categories show that AlgoPilot substantially improves the performance of a small base model, outperforms strong large model prompting baselines, and provides transferable steering and guidance modules that can benefit another execution model.

Limitations. Our current framework depends on execution-derived feedback to construct guidance data and train the steering model. This process can be computationally expensive and may limit scalability to very large datasets or newly added paradigms. In addition, the learned steering and guidance modules are trained from the behavior of a particular execution model, so transfer to other execution models, while positive, may be imperfect. Future work could explore more efficient feedback collection, multi-execution-model training, and lightweight adaptation strategies to improve scalability and transferability across broader paradigms and execution models.

Acknowledgment

This work was supported by MIT-IBM Watson AI Lab. However, this article solely reflects the opinions and conclusions of its authors.

Broader Impact Statement

AlgoPilot aims to improve the reliability of LLM-based problem solving by adaptively selecting among reasoning, coding, planning, constraint-solving, and optimization paradigms. This may have positive impacts in applications that require structured reasoning, such as decision support, logistics, scientific computing, and educational tools. However, stronger automated reasoning systems may also be misused for harmful planning or optimization tasks, and incorrect paradigm selection or faulty solver formulations could lead to misleading outputs if used without verification. We therefore view AlgoPilot as a reasoning-support framework rather than an autonomous decision-making system, and recommend human oversight, downstream validation, and task-specific safety checks before deployment.

SteerLM

SteerLM Training Details

Dataset. After balancing, the SteerLM training set contains 5,858 datapoints. Each target is an ordered list of up to three useful paradigm–mode pairs ranked by execution-derived success score. Examples without any useful paradigm–mode pair are excluded.

Prompt and Output Format. SteerLM is trained to map each input problem to an ordered list of paradigm–mode labels. The instruction specifies the available execution modes and paradigm categories, and the model is required to output only a JSON-style list of labels. Each label is formed by concatenating the mode and paradigm category, such as DIRECT_CODING or GUIDED_MILP. An example training instance is shown below:

{
  "instruction": "Provide generic algorithmic recommendations for a way to
                  solve the problem. Available reasoning modes:
                  - DIRECT
                  - GUIDED

                  Available algorithm categories:
                  - CODING
                  - COT
                  - PDDL
                  - MILP
                  - SMT",
  "input": "Given an array of integers arr and two integers k and threshold,
            return the number of sub-arrays of size k and average greater than
            or equal to threshold. ...
            Input: arr = [39,37,35,33,31,29,27,25,23,21,19,17,15,13,11,9,7,5,
            3,1], k = 3, threshold = 10",
  "output": "[\"DIRECT_CODING\", \"GUIDED_MILP\", \"GUIDED_CODING\"]"
}

The labels are ordered according to their execution-derived scores, so earlier labels correspond to more effective paradigm–mode choices.

SFT for AlgoPilot ^SFT+GRPO. We utilize four H100 80GB GPUs for full-parameter fine-tuning of the Qwen3-8B model. The model is trained for 1 epoch in the SFT stage to prevent overfitting. The learning rate is set to 1e-5. We use a batch size of 4 for training. We select the model with the lowest validation loss.

GRPO for AlgoPilot ^SFT+GRPO. We utilize eight H100 80GB GPUs for GRPO full-parameter fine-tuning of the SFT checkpoint. GRPO uses a learning rate of 5e-7 with 4 sampled responses per prompt and a KL penalty of 0.005. We use a batch size of 16 for training.

GRPO Objective. Given a problem instance $q$, the policy $\pi_\theta$ generates a group of $G$ candidate outputs $\{y_i\}_{i=1}^{G}$, where each output contains a ranked list of predicted paradigm–mode pairs. Each output receives a scalar reward $r_i$ based on the execution-derived scores of its predicted labels.

We formulate our RL objective to maximize as:

where $\rho_i(\theta)=\frac{\pi_\theta(y_i|q)}{\pi_{\theta_{\mathrm{old}}}(y_i|q)}$, $\pi_{\theta_{\mathrm{old}}}$ is the policy before the current update, $\pi_{\mathrm{ref}}$ is the reference model, $\hat{A}_i$ is the advantage computed from relative rewards of responses within each group, and $\beta$ controls the KL regularization strength.

GRPO Reward Explanation. The reward for SteerLM is designed to encourage the model to output a ranked list of paradigm–mode pairs that are likely to lead to successful downstream execution. Since directly executing every sampled SteerLM output during RL training would be prohibitively expensive, we use the precomputed cross-paradigm evaluation results as an offline reward table. For each training problem, every paradigm–mode pair has an execution-derived score obtained from the dataset expansion stage. The score reflects how reliably that paradigm–mode pair solves the problem under the same execution protocol used for evaluation.

Given a sampled SteerLM output, we first parse the predicted ranked list of labels. Let $S_k$ denote the precomputed execution score of the $k$-th predicted label, where earlier labels are intended to represent more preferred solving strategies. Missing or unparsable labels receive score zero. The main performance reward is

where $S_1$ is the score of the top-ranked prediction, $S_2$ and $S_3$ are the scores of lower-ranked predictions, and $S_{\mathrm{base}}$ is the score obtained by using the original benchmark category as the default paradigm. The first two terms together reward a high-quality top prediction. The problem-specific offset $-\lambda_{\mathrm{adv}}S_{\mathrm{base}}$ cancels under groupwise reward normalization and is therefore a redundant calibration term, not an independent learning signal. The lower-rank terms encourage SteerLM to include additional viable paradigm–mode candidates, but with smaller weights so that the top-ranked prediction remains most important.

We further add a ranking bonus to encourage the predicted list to be ordered consistently with the execution-derived scores. Specifically, among all comparable pairs of predicted labels, the ranking bonus measures the fraction of pairs whose order agrees with their precomputed scores. This encourages SteerLM not only to include useful candidates, but also to place stronger candidates earlier in the list. In addition, we apply penalties for invalid output formatting and duplicate labels. The final reward is

Here, $B_{\mathrm{rank}}$ is the ranking bonus, $P_{\mathrm{fmt}}$ penalizes outputs that cannot be parsed into the required label-list format, and $P_{\mathrm{dup}}$ penalizes repeated labels. In our implementation, we set $\lambda_1=0.7$, $\lambda_{\mathrm{adv}}=0.3$, $\lambda_2=0.10$, $\lambda_3=0.05$, $\lambda_{\mathrm{rank}}=0.05$, $\lambda_{\mathrm{fmt}}=0.05$, and $\lambda_{\mathrm{dup}}=0.05$.

This reward design reflects the intended behavior of SteerLM. The model should identify a strong first-choice paradigm–mode pair for direct execution, while also maintaining a compact ranked set of alternative viable strategies.

GRPO Reward Ablation. We conducted a controlled reward-design ablation to isolate how the lower-ranked candidate rewards, ranking bonus, and structural penalties contribute to routing quality and valid structured generation. All variants use the same Qwen3-8B SFT initialization, GRPO data, optimizer, training schedule, sampling configuration, and fixed training budget; only the reward function is changed.

Plugging in the hyperparameters, our full reward becomes

The major components of the reward are:

• $S_1$: the score of the top-ranked prediction.

• $S_2, S_3$: the scores of the second- and third-ranked predictions, respectively.

• $B_{\mathrm{rank}}$: the ranking bonus.

• $P_{\mathrm{fmt}}, P_{\mathrm{dup}}$: penalties for invalid output formatting and duplicate labels, respectively.

• $S_{\mathrm{base}}$: the original motivation was to measure the selected method’s improvement over a natural source-specific default. It is a completion-invariant calibration offset that cancels under groupwise reward normalization and provides no independent learning signal.

To validate the effectiveness of each component, we compare the following variants:

$A_1$: Top-1 score only:

$A_2$: Top-1 plus weighted top-2 and top-3 scores:

$A_3$: $A_2$ plus the ranking bonus:

$A_4$: The full reward (ours):

Routing Quality and Structured Generation

All variants completed evaluation on the same test sets. In addition to the paper’s end-to-end top-1 accuracy and top-3 accuracy, we report NDCG@3, which measures whether the model returns high-scoring methods and orders them appropriately, with missing positions receiving zero score. We also report Valid-3, the percentage of outputs that are valid JSON lists containing exactly three distinct labels.

The main takeaways from Table 6 are:

Reward Design	Top-1 Acc.	Top-3	NDCG@3	Valid-3
$A_1$	73.89	77.13	57.81	10.7
$A_2$	73.78	83.67	75.25	84.7
$A_3$	74.01	83.58	75.01	94.8
$A_4$	74.10	83.78	76.07	100.0

• Top-1 accuracy alone does not capture the full benefit. The results appear similar under top-1 accuracy because the other terms improve the quality and ordering of the candidate set, rather than only its first element.

• $A_1$ versus $A_2$: lower-ranked candidate rewards. Adding the weighted $S_2$ and $S_3$ terms increases top-3 accuracy from 77.13% to 83.67%, NDCG@3 from 57.81% to 75.25%, and valid three-label generation from 10.7% to 84.7%.

• $A_2$ versus $A_3$: ranking bonus. Adding $B_{\mathrm{rank}}$ further raises three-label completeness to 94.8%. We also compared the pairwise ordering agreement for $A_2$ and $A_3$, defined as the fraction of predicted label pairs whose relative order agrees with the order of their precomputed execution scores. This improves from 82.0% to 83.6%.

• $A_3$ versus $A_4$: structural penalties. With the structural penalties, the model further improves the validness of the produced labels from 94.8% to 100.0%.

• Full reward. The full reward produces a valid, complete list for every test instance and gives the best overall NDCG@3 and top-3 oracle result.

Because $A_1$ emits only 1.44 labels on average, whereas $A_2$ emits 2.71, a potential concern is that part of the top-3 improvement could arise simply from producing more candidates. We therefore tested several ways of padding the $A_1$ outputs to exactly three candidates.

For each $A_1$ prediction, we retain its first label and pad the list to three using:

• Pad$_1$: uniform random padding.

• Pad$_2$: padding with the globally highest-scoring labels on the training set.

• Pad$_3$: padding with the Direct and Guided methods associated with the problem’s source category, using Pad$_2$ to resolve duplicates.

These controls distinguish the value of simply having more candidates from instance-specific method selection.

Candidate construction	Best-route Recall@3	NDCG@3	Best candidate score
$A_1$	79.60	57.81	71.34
Pad$_1$	83.17	61.66	73.41
Pad$_2$	88.83	70.92	76.77
Pad$_3$	89.19	72.89	77.08
$A_2$	91.72	75.25	78.99

Here, best-route Recall@3 measures whether the candidate set contains at least one empirically best method. Best candidate score is the maximum execution score among the predicted candidates.

Despite producing fewer than three candidates on average, $A_2$ outperforms the strongest source-category padding control in Recall@3 (91.72% versus 89.19%), NDCG@3 (75.25% versus 72.89%), and best candidate score (78.99% versus 77.08%). Thus, the gain is not explained by list length alone.

The weighted top-2 and top-3 rewards enable SteerLM to construct a semantically meaningful, task-relevant candidate set that better covers high-performing and empirically suitable solving paradigms on held-out problems, beyond merely encouraging a three-item output.

The reward components have complementary roles:

• Graded execution feedback $S_1$ improves first-choice selection.

• Lower-ranked candidate rewards $S_2$ and $S_3$ teach a broader, contextually relevant set of viable methods.

• Ranking bonus $B_{\mathrm{rank}}$ improves completeness and list ordering.

• Format and duplicate penalties $P_{\mathrm{fmt}}$ and $P_{\mathrm{dup}}$ promote valid, duplicate-free structured generation.

SFT for AlgoPilot ^SFT We utilize four H100 80GB GPUs for full-parameter fine-tuning of the Qwen3-8B model. The model is trained for 5 epoch in the SFT stage to prevent overfitting. The learning rate is set to 1e-5. We use a batch size of 4 for training. We select the model with the lowest validation loss.

Analysis of Guided Mode Selection

To assess mode-selection errors, that is, how often SteerLM selects GUIDED mode when a DIRECT alternative would perform better, we compare the Guided routes selected by SteerLM with Direct alternatives.

During evaluation, we evaluated all test problems using three executions per route. For each GUIDED_X selection, we first compared it with DIRECT_X on the same problem. Direct is considered better only when it produces strictly more successful executions. We also considered a less constrained oracle that may switch GUIDED_X to whichever of the five Direct paradigms performs best on that problem.

From the results, same-paradigm Direct is better for 11.70% of all Guided selections, equivalent to 9.91% of the entire test set. Any-paradigm Direct is better for 18.54% of all Guided selections, or 15.69% of all test problems.

Mode-selection errors are concentrated in the easier Code and CoT categories, while Guided mode is almost never unnecessarily selected for MILP and PDDL, where structured formulation is most valuable. Overall, only 11.70% of Guided selections would benefit from switching to Direct within the same paradigm, indicating that the pipeline’s gains are not simply due to avoiding Guided mode on easy problems, but to making largely appropriate instance-level mode decisions.

Selected route	Same-paradigm Direct better	Any-paradigm Direct better
Guided Code	14.14	25.72
Guided CoT	20.72	27.88
Guided PDDL	0.00	0.00
Guided SMT	2.38	21.43
Guided MILP	1.22	4.88
Overall	11.70	18.54

GuideLM

GuideLM Guidance Templates

GuideLM is trained to generate paradigm-specific structured guidance before final execution. Each paradigm uses a separate guidance template, designed to capture the key formulation elements required by that paradigm. These templates serve two purposes: they standardize the supervision format for GuideLM training, and they provide ExecuteLM with explicit problem-solving structure during guided execution.

Code Guidance Template. For code-based execution, the guidance template summarizes the algorithmic idea, implementation plan, key states or invariants, edge cases, and common implementation pitfalls. The template is designed to help ExecuteLM produce a complete and correct program rather than only a high-level solution sketch.

{
    "Problem_Type": "",
    "Core_Idea": "",
    "Algorithm": "",
    "Key_State_or_Invariant": "",
    "Implementation_Steps": [],
    "Edge_Cases": [],
    "Common_Bugs_To_Avoid": [],
    "Complexity": "",
    "Input": ""
}

CoT Guidance Template. For natural-language reasoning, the guidance template identifies the reasoning type, goal, key facts, intermediate derived facts, and a step-by-step reasoning plan. This template is intended to make the reasoning trajectory explicit while avoiding unnecessary formalization.

{
    "Algorithm": "",
    "Goal": "",
    "KeyFacts": [],
    "IntermediateFacts": [],
    "ReasoningPlan": [],
    "ImportantNotes": []
}

MILP Guidance Template. For mathematical optimization, the guidance template specifies the core components of a mixed-integer linear programming formulation, including decision variables, variable types and bounds, objective function, and constraints. This structure encourages GuideLM to produce a solver-ready formulation before ExecuteLM writes the final optimization program.

{
    "Algorithm": "",
    "DecisionVariables": {},
    "VariableTypes": {},
    "VariableBounds": {},
    "Objective": "",
    "Constraints": [
        {
            "name": "",
            "expression": "",
            "description": ""
        }
    ],
    "Guidance_Text": []

}

PDDL Guidance Template. For symbolic planning, the guidance template follows the standard separation between a PDDL domain and a PDDL problem. The domain part defines requirements, types, predicates, and actions, while the problem part specifies objects, initial state, and goal conditions.

{
    "Algorithm": "",
    "Domain": {
        "Name": "",
        "Requirements": [],
        "Types": [],
        "Predicates": {},
        "Actions": []
    },
    "Problem": {
        "Name": "",
        "DomainName": "",
        "Objects": [],
        "Init": [],
        "Goal": []
    },
    "Guidance_Text": []
}

SMT Guidance Template. For constraint solving, the guidance template targets SMT-Z3 formulations. It specifies the problem representation, variable schema, concrete variables, constraint reasoning, formal constraints, and the final query to be checked or solved. This helps ExecuteLM construct a valid Z3 program with the appropriate logical structure.

{
    "Algorithm": "",
    "ProblemType": {
        "Representation": "",
        "Task": ""
    },
    "VariableSchema": {
        "pattern": "",
        "meaning": ""
    },
    "Variables": {},
    "ConstraintsReasoning": [],
    "Constraints": [
        {
            "description": "",
            "expression description": ""
        }
    ],
    "Query": {
        "NewConstraints": "",
        "Method": "",
        "Output": []
    },
    "Guidance_Text": []
}

Overall, these templates are intentionally different across paradigms because each paradigm requires a different formulation structure. For example, MILP guidance emphasizes decision variables, objectives, and constraints; PDDL guidance emphasizes symbolic states and actions; SMT guidance emphasizes logical variables and assertions; Code guidance emphasizes implementation details; and CoT guidance emphasizes intermediate reasoning structure.

GuideLM Training Details

Dataset. With the filtered guidance dataset as supervision, we use full parameter supervised fine-tuning (SFT) to fine-tune a set of paradigm-specific GuideLM models, each specialized for a particular solving paradigm. This allows each GuideLM to learn and specialize in the effective formulation patterns and important contents of its paradigm. The guidance construction results in around 12k, 8.7k, 3k, 4.5k, 6k datapoints for Code, CoT, MILP, PDDL, and SMT.

SFT. We utilize four H100 80GB GPUs for full-parameter fine-tuning of the Qwen3-8B model. The model is trained for 5 epochs in the SFT stage. The learning rate is set to 1e-5. We use a batch size of 4 for training. We select the model with the lowest validation loss.

GuideLM Effectiveness

When guidance is needed, AlgoPilot generates guidance using GuideLM and then utilizes the guidance as the input to ExecuteLM. Two natural questions would be: 1) can we use similar amount of data with similar domains to fine-tune the ExecuteLM and do we really need GuideLM? 2) Are the GuideLMs trained separately for each paradigm strictly necessary, or would a single multi-paradigm GuideLM perform similarly?

To answer the first question, we trained a matched-data QA-based ExecuteLM-SFT baseline using the same problems and training scale and show that GuideLM’s benefit cannot be reduced to additional domain-specific data/answer exposure. We also emphasize that GuideLM is designed not only to inject paradigm-specific expertise, but to make that expertise reusable across different ExecuteLMs without requiring each executor to be fine-tuned again.

Here are the setup details and results for ExecuteLM-SFT.

• Setup: For every GuideLM training example, we retained the same problem and selected one downstream ExecuteLM response that had been verified as correct, replacing the formulation target with this final QA-style solution. We preserved the same fine-tuning procedures as GuideLM. At inference, we fixed the original SteerLM top-1 route and replaced the GuideLM–ExecuteLM stages with this fine-tuned ExecuteLM, so no GuideLM or intermediate formulation was used.

• Result: Although direct QA SFT yields substantial gains on symbolic tasks, reaching 87.6% on PDDL and 67.4% on MILP, QA training does not reproduce AlgoPilot’s overall performance. AlgoPilot’s specialist structured guidance improves average accuracy from 59.3% to 72.9%.

• Analysis: These results show that GuideLM’s benefit cannot be reduced to additional domain-specific data exposure. Explicit, per-instance formulation guidance remains important for robust performance across heterogeneous paradigms.

We also want to emphasize that our motivation for GuideLM is not only to inject paradigm-specific expertise, but also to separate formulation knowledge from the executor. This modularity allows the same trained guidance models to benefit a different ExecuteLM without re-fine-tuning it, as demonstrated by the transfer experiment in § 4.5. In contrast, direct executor SFT must generally be repeated whenever the executor is replaced.

Method	Code	CoT	PDDL	SMT	MILP	Avg.
SteerLM + QA-SFT ExecuteLM, no GuideLM	57.7	55.1	87.6	28.5	67.4	59.3
AlgoPilot	72.9	75.8	91.5	64.6	59.6	72.9

To answer the second question, we trained a single multi-paradigm GuideLM on the union of the five specialist training corpora, containing 34,893 guidance examples across all paradigms. The evaluation results for problems that are steered to use Direct mode were reused because they do not invoke a GuideLM.

Method	Code	CoT	PDDL	SMT	MILP	Avg.
Paradigm-specific GuideLMs	72.9	75.8	91.5	64.6	59.6	72.9
Unified GuideLM	67.8	72.5	69.0	30.7	62.4	60.5

The unified GuideLM achieves an average accuracy of 60.5%, compared with 72.9% for the paradigm-specific GuideLMs. These results suggest that a single GuideLM is feasible, but paradigm-specific specialization is beneficial overall, particularly for paradigms with distinct symbolic representations.

The unified model must learn several substantially different formulation languages within one parameter space. This can create cross-paradigm interference, whereas specialist GuideLMs can devote their capacity to one formulation distribution and learn its conventions more reliably.

Thus, the gains do not arise solely from using structured templates, and they also depend on learning paradigm-specific formulation expertise.

AlgoPilot

Additional Prompting and Routing Baselines

We compare AlgoPilot with three additional prompting and routing baselines and show that AlgoPilot achieves the best average accuracy among all evaluated baselines, supporting the benefit of combining instance-level learned steering with learned, problem-specific formulation guidance. The new baseline modes are:

• Self-routing: The model is explicitly given the five paradigm labels and asked to select among them before solving.

• Heuristic routing: A paradigm-aware baseline in which the model uses the source category and its corresponding prompt.

• Template-direct: The model solves the problem directly, with the solver-specific output templates used by GuideLM provided in the prompt.

Table 11 presents the results across the five paradigms.

Model	Mode	Code	CoT	PDDL	SMT	MILP	Avg.
GLM-5	Self-routing	91.1	86.6	46.0	82.9	47.5	70.8
	Heuristic routing	90.0	88.2	64.1	55.3	59.8	71.5
	Template-direct	85.2	88.1	61.7	41.0	46.9	64.6
Qwen3-Coder-Next	Self-routing	83.1	66.7	6.6	78.1	45.9	56.1
	Heuristic routing	93.5	90.7	28.6	67.0	63.0	68.6
	Template-direct	85.6	90.5	7.9	49.8	58.8	58.5
Qwen3.5-9B	Self-routing	84.0	85.7	0.1	84.4	27.0	56.2
	Heuristic routing	80.2	83.2	0.1	6.4	38.3	41.6
	Template-direct	81.1	85.0	36.4	46.2	20.8	53.9
Gemma-4-E4B-it	Self-routing	62.1	81.9	9.0	74.2	41.5	53.7
	Heuristic routing	65.6	81.3	20.5	33.0	47.4	49.6
	Template-direct	58.8	80.5	36.6	40.7	50.7	53.5
Qwen3-8B	Self-routing	72.7	55.9	0.0	71.5	22.0	44.4
	Heuristic routing	69.3	73.0	7.8	27.9	26.8	41.0
	Template-direct	64.7	72.0	14.2	39.4	22.2	42.5
AlgoPilot	SFT+GRPO	72.9	75.8	91.5	64.6	59.6	72.9

AlgoPilot achieves the highest average accuracy at 72.9%. The strongest baseline is GLM-5 with heuristic routing at 71.5%, while the strongest matched Qwen3-8B baseline reaches only 44.4%. Thus, AlgoPilot improves accuracy with the same ExecuteLM by 28.5% and remains competitive with much larger paradigm-aware models.

Explicit self-routing is useful, but it remains unreliable on domains requiring precise formalization, especially PDDL and MILP, showing that exposing the available paradigms alone is insufficient.

Heuristic routing provides the nominal task category, but it still performs substantially below AlgoPilot on the same Qwen3-8B executor. This suggests that the nominal paradigm may not be optimal for each instance, and that effective solving also requires instance-specific steering and formulation.

The Template-direct results show that the gains of AlgoPilot do not come merely from exposing the model to the guidance structure. GuideLM instantiates that structure with problem-specific variables, constraints, actions, and relations.

Overall, the gains cannot be explained by paradigm labels, nominal task categories, or access to the GuideLM output template alone. The results support the benefit of combining instance-level learned steering with learned, problem-specific formulation guidance.

AlgoPilot Generalization

We claim and show through experiments on 1) paraphrased inputs to SteerLM, 2) paraphrased inputs to end-to-end AlgoPilot, and 3) generalization to unseen domains and benchmarks that AlgoPilot remains robust to substantial changes in problem wording and can generalize across new domains and benchmark families. These results support that AlgoPilot learns to match problem characteristics with suitable reasoning paradigms, rather than relying only on benchmark-specific patterns.

• Generalization to paraphrased inputs

  • Paraphrase styles: For all 2,220 data points in the test set, we applied three different paraphrase styles while preserving the underlying problem.

    • Lexical paraphrase: vary wording and local phrasing.

    • Syntactic paraphrase: change sentence structures and transitions and reorganize nearby sentences.

    • Natural alternative formulation: use noticeably different wording and presentation.

  • SteerLM results (Table 12)

    • SteerLM’s top-1 routing decision agreed with that on the original input in 98.04% of cases.

    • For 96.88% of the original problems, all three paraphrases preserved the original top-1 decision.

    • This robustness is consistent across both problem paradigms and paraphrase styles, as shown in Table 12.

    • The consistency also extends to the complete routing list: the exact ordered top-3 prediction was unchanged in 93.55% of cases.

    • These results indicate that SteerLM primarily routes according to the intrinsic characteristics of the problem itself, rather than relying on particular lexical choices, sentence structures, or fixed task-description templates.

Breakdown	Category	Top-1 agreement (%)
Problem category	Code	96.04
	CoT	96.60
	MILP	98.94
	PDDL	100.00
	SMT	100.00
Paraphrase style	Lexical reformulation	98.33
	Syntactic reformulation	97.69
	Natural alternative wording	98.10
	Overall	98.04

• End-to-end AlgoPilot results (Table 13)

  • AlgoPilot achieves an end-to-end average accuracy of 68.62% on paraphrased inputs across different paradigms, compared with 72.90% on the corresponding original inputs (a decrease of only 4.28 percentage points).

  • Together with the 98.04% routing agreement above, these preliminary results suggest that AlgoPilot’s end-to-end performance is largely robust to natural-language reformulation.

Breakdown	Category	Original accuracy (%)	Paraphrased accuracy (%)
Problem category	Code	72.86	69.74
	CoT	75.78	74.19
	MILP	59.58	57.97
	PDDL	91.46	90.47
	SMT	64.45	50.73
	Overall	74.10	68.62

• Generalization to held-out domains and unseen benchmarks (Table 14)

  • Domains: We further evaluated AlgoPilot on 432 fresh problems from ten held-out domains spanning all five paradigms.

  • Result: AlgoPilot achieves an instance-weighted accuracy of 73.27%, compared with 53.01% for Qwen3 8B Direct and 66.20% for Qwen3 8B Reason. It outperforms both baselines on 5 out of 10 domains.

  • Analysis: The held-out evaluation suggests meaningful but incomplete cross-domain generalization. Among AlgoPilot’s failed instances, only 22.43% are routed to a paradigm different

Category	Domain	Source benchmark	Status	# data points	AlgoPilot	Qwen3 8B Direct	Qwen3 8B Reason
Code	Algorithms	BIG-Bench Hard	Seen benchmark; held-out domain	46	87.68	56.52	88.41
Code	Penguins in a Table	BIG-Bench Hard	Seen benchmark; held-out domain	50	82.67	91.33	95.33
CoT	Sports Understanding	BIG-Bench Hard	Seen benchmark; held-out domain	50	50.67	30.00	47.33
CoT	Temporal Sequences	BIG-Bench Hard	Seen benchmark; held-out domain	50	92.00	96.00	87.33
SMT	FOLIO	FOLIO	Unseen benchmark	50	62.67	55.33	68.00
SMT	SATBench	SATBench	Unseen benchmark	50	84.67	54.00	80.67
MILP	MAMO EasyLP	MAMO	Unseen benchmark	50	64.67	36.00	58.00
MILP	MAMO ComplexLP	MAMO	Unseen benchmark	50	43.66	43.33	54.00
PDDL	AutoPlanBench VisitAll	AutoPlanBench	Unseen benchmark	18	100.00	0.00	0.00
PDDL	AutoPlanBench Gripper	AutoPlanBench	Unseen benchmark	18	98.15	0.00	0.00
Instance-weighted overall				432	73.27	53.01	66.20

from the source category, indicating that SteerLM generally transfers its paradigm-selection behavior to unseen domains. The remaining errors are therefore more often attributable to downstream formulation or execution, with GuideLM formulation transfer emerging as the main bottleneck. AlgoPilot achieves the best overall accuracy and substantial gains on several unseen benchmark families. These results suggest that the steering mechanism generalizes beyond the original instance-level split, while broader cross-domain training and refinement of the GuideLM experts remain important directions for improvement.

• We emphasize that zero-shot end-to-end generalization to arbitrary unseen domains is not the primary claim of this work. The central contribution of AlgoPilot is a learned steering framework that identifies a problem’s computational characteristics and adaptively selects among heterogeneous reasoning paradigms, rather than applying a fixed strategy to every input.

• The GuideLMs are current instantiations of paradigm-specific experts. This expert layer can be improved independently through broader cross-domain training, verifier-guided refinement, or iterative reflection.

• The paraphrase experiments provide complementary evidence that both routing and end-to-end execution are robust to substantial changes in wording, syntax, and presentation. Together with the gains on held-out domains and unseen benchmarks, these results suggest that AlgoPilot is not merely exploiting benchmark-specific surface patterns, but learns a reusable mechanism for matching problem characteristics with appropriate computational paradigms.

AlgoPilot main result performance with standard deviation

Prompts

ExecuteLM prompts

ExecuteLM receives the original problem, the selected algorithm family, and optionally the structured guidance generated by GuideLM. For Guided mode, the prompt includes the Guidance field. For Direct mode, we use the same prompt template but remove the Guidance field.

Code. For Code-guided execution, we use the following prompt:

ExecuteLM Code Prompt

Problem Description:
{problem}

Algorithm family: {algorithm}. Follow the following guidance to write a complete Python solution.

Guidance:
{guidance}

Requirements:
1) Output ONLY Python code wrapped in ‘‘‘python and ‘‘‘
2) There will not be outside inputs. Explicitly define the inputs by yourself based on the question description if needed
3) The code must use print() to print EXACTLY one final line in this format:
FINAL_ANSWER=<value>
4) Keep output concise; avoid extra narration prints.

CoT Prompt. For textual reasoning, we use the following prompt:

ExecuteLM Direct Answer Prompt

Problem Description:
{problem}

Algorithm family: {algorithm}. Solve the problem directly.

Guidance:
{guidance}

Output requirements:
- Return the final answer in one line: FINAL_ANSWER=<answer>.
- You may provide reasoning before that line.

PDDL Prompt. For symbolic planning problems, ExecuteLM is prompted to generate both the PDDL domain and problem files:

ExecuteLM PDDL Prompt

Problem Description:
{problem}

Algorithm family: {algorithm}. Follow the guidance to generate 2 PDDL files.

Guidance:
{guidance}

The template of PDDL domain file is:
(define (domain NAME)
  (:requirements)
  (:predicates)

  (:action ACTION_NAME
    :parameters ()
    :precondition ()
    :effect ()
  )

  (:action ACTION_NAME
    :parameters ()
    :precondition ()
    :effect ()
  )

  (:action ACTION_NAME
    :parameters ()
    :precondition ()
    :effect ()
  )
)

The template of PDDL problem file is:
(define (problem NAME)
(:domain NAME)
(:objects )
(:init )
(:goal (and ))
)

Requirements:
1) Output exactly two fenced pddl blocks. Wrap each block in ‘‘‘pddl and ‘‘‘.
2) First block must be DOMAIN_PDDL, second block must be PROBLEM_PDDL.
3) Keep predicates/actions consistent between domain and problem.
4) Do not output any Python code.

SMT Prompt. For SMT-based execution, ExecuteLM is prompted to generate executable Python code using Z3:

ExecuteLM SMT Prompt

Problem Description:
{problem}

Algorithm family: {algorithm}. Write a complete Python solution with z3 SMT package.

Guidance:
{guidance}

Requirements:
1) Output ONLY Python code wrapped in ‘‘‘python and ‘‘‘
2) There will not be extra inputs. Define the inputs by yourself based on the question description if needed
3) The code must use print() to print EXACTLY one final line in this format:
FINAL_ANSWER=<value>.
4) Keep output concise; avoid extra narration prints.
5) For multiple choice problem, 1) first, initialize a ’constraints = []’;
   2) append each constraint to list ’constraints’; 3) for each option,
   initialize the solver = Solver(), 4) Finally, for each option, easily add
   all constraints in ’constraints’ and option’s variable assignments to the
   solver and check satisfiability.

MILP Prompt. For mathematical optimization problems, ExecuteLM is prompted to generate executable Python code for solving the optimization model:

ExecuteLM MILP Prompt

Problem Description:
{problem}

Algorithm family: {algorithm}. Write a complete Python solution.

Guidance:
{guidance}

Requirements:
1) Output ONLY Python code wrapped in ‘‘‘python and ‘‘‘
2) There will not be extra inputs. Define the inputs by yourself based on the question description if needed
3) The code must use print() to print EXACTLY one final line in this format:
FINAL_ANSWER=<value>. The <value> should the objective you optimize for.
4) Keep output concise; avoid extra narration prints.

Baseline prompts

Both baseline configurations, DIRECT and REASON, receive only the raw problem description, with no algorithm-specific guidance. The model must decide how to solve each problem on its own. The two configurations differ along a single axis: whether the model is explicitly asked to reason about its solving strategy before producing a solution.

DIRECT. The prompt instructs the model to solve the problem directly without additional reasoning:

Problem Description: {problem}
Solve this problem directly with no extra reasoning.
[Output Instruction]

REASON. The prompt adds a two-step structure that asks the model to first analyze the problem and select a solving approach, then produce the solution:

~~~text Problem Description: {problem} Step 1 -- Algorithm Selection: Analyze this problem and determine the most suitable solving approach. Briefly explain your chosen approach. Step 2 -- Solution: Now solve the problem using your chosen approach. ~~~

[Output Instruction]

Both configurations share the same output instructions, which describe three acceptable output formats:

~~~text Output requirements:

• If you write code, output Python code wrapped in python and . There will not be outside inputs. Explicitly define the inputs by yourself based on the question description if needed. The code must print exactly one line: FINAL_ANSWER=<value>

• If you decide to use automated planning, output PDDL domain and problem files in pddl and blocks (first block DOMAIN_PDDL, second block PROBLEM_PDDL)

• Otherwise, return the final answer in one line: FINAL_ANSWER=<answer> ~~~

Crucially, the prompt does not specify which algorithm family the model should use, leaving it entirely to the model’s discretion. The output instruction is intentionally permissive, accepting Python code, PDDL specifications, or plain-text answers. As discussed in Section G.1.1, this permissiveness creates a format mismatch when paired with evaluation pipelines that expect a specific output format.

Cost Analysis

Baselines

Table 16 reports the total token consumption for each experimental configuration. All experiments use 3 samples per problem across 2,220 problems (640 Code + 461 CoT + 221 MILP + 446 PDDL + 452 SMT), totaling 6,660 LLM calls per model–prompt pair (some calls are marginally fewer due to skip-existing deduplication).

Prompt	Model	Prompt (M)	Completion (M)	Total (M)
DIRECT	GLM-5	3.14	3.17	6.31
DIRECT	Qwen3-Coder	3.21	11.83	15.04
DIRECT	Gemma-4-E4B-it	3.34	7.32	10.67
DIRECT	Qwen3.5-9B	3.35	9.59	12.93
REASON	GLM-5	3.35	5.93	9.28
REASON	Qwen3-Coder	3.42	20.15	23.57
REASON	Gemma-4-E4B-it	3.56	11.14	14.70
REASON	Qwen3.5-9B	3.44	16.35	19.79
Total		26.83	85.48	112.29

Prompt tokens are stable across configurations ($\sim$3.1–3.4M), as the problem descriptions dominate input length. Completion tokens vary by up to 6.4× between the most and least verbose configuration: Qwen3-Coder under REASON generates 20.15M completion tokens, compared to 3.17M for GLM-5 under DIRECT. This discrepancy reflects two factors: (1) Qwen3-Coder produces substantially longer outputs on average (its extended thinking and code generation are more verbose), and (2) the REASON prompt elicits algorithm-selection reasoning that further increases output length.

Table 17 breaks down average tokens per LLM call by task. PDDL and MILP are the most token-intensive tasks, as they require generating full formal specifications (PDDL domain/problem files or optimization models). CoT is the least expensive when the model responds with direct text (DIRECT + GLM-5 averages only 19 completion tokens per call, as the model outputs a single FINAL_ANSWER= line), but becomes substantially more expensive when the model is invited to reason ($\sim$522–792 tokens under REASON).

Prompt	Model	Code	CoT	MILP	PDDL	SMT
DIRECT	GLM-5	410	19	824	1,168	184
DIRECT	Qwen3-Coder	1,241	466	2,642	4,517	741
DIRECT	Gemma-4-E4B-it	1,832	50	1,494	1,523	520
DIRECT	Qwen3.5-9B	892	57	2,601	4,340	195
REASON	GLM-5	718	522	1,225	1,372	870
REASON	Qwen3-Coder	2,382	792	6,655	6,309	1,217
REASON	Gemma-4-E4B-it	2,111	612	1,885	2,610	1,105
REASON	Qwen3.5-9B	1,703	967	4,669	4,909	1,531

AlgoPilot

Training data collection Our initial guidance-search stage contains 22,143 problems. For each problem, we generate five candidate guidances, execute each guidance five times, and perform five additional direct executions. This results in 110,715 guidance-generation calls and 664,290 ExecuteLM calls, producing 34,893 filtered GuideLM training examples.

For cross-paradigm data expansion, we evaluate 17,712 training problems under all five paradigms, resulting in 442,800 GuideLM calls and 2,656,800 ExecuteLM calls.

The guidance-search stage consumed 1,503 GPU-hours and completed in 24.9 wall-clock hours. The cross-paradigm stage consumed 6,011 GPU-hours and completed in 99.6 wall-clock hours. In total, data construction required approximately 7,514 GPU-hours and 124.5 wall-clock hours, or 5.2 days.

This cost is substantial but is incurred once offline and is highly parallelizable. All execution outcomes are cached and reused during subsequent SFT and GRPO training, avoiding repeated execution during RL. The pipeline is also incremental: extending an existing paradigm expert with additional examples requires processing only the new examples, without regenerating or re-executing previously collected data. The same cached supervision can support repeated training runs, reward ablations, and model-transfer experiments. The resulting steering and guidance models are reused across test instances and can transfer to another ExecuteLM.

AlgoPilot inference AlgoPilot introduces additional inference stages beyond direct prompting baselines: a SteerLM call for paradigm–mode selection, optional GuideLM calls for structured formulation generation when the selected mode is Guided, and ExecuteLM calls for final solution generation. Table 18 reports the evaluation-time token usage of these stages on the held-out test set.

Stage	Calls	Prompt (M)	Completion (M)	Total (M)
SteerLM prediction	2,211	0.78	0.03	0.81
GuideLM generation	5,616	1.97	3.90	5.88
ExecuteLM runs	6,633	6.69	2.80	9.49
Total	14,460	9.44	6.73	16.17

The total evaluation-time cost of AlgoPilot is 16.17M tokens across 14,460 LLM calls. This cost includes all three inference stages used by AlgoPilot: SteerLM prediction, GuideLM generation for Guided-mode examples, and ExecuteLM solution generation. Among these stages, ExecuteLM accounts for the largest share of the token budget, using 9.49M tokens, or 58.7% of the total. GuideLM generation contributes 5.88M tokens, or 36.3%, while SteerLM prediction is lightweight, contributing only 0.81M tokens, or 5.0%. This shows that the additional steering step introduces little overhead relative to the cost of formulation generation and final execution.

Compared with the prompting baselines in Table 16, AlgoPilot has higher token usage than the most economical direct prompting configurations, such as GLM-5$_{\mathrm{DIRECT}}$ and Gemma-4-E4B-it$_{\mathrm{DIRECT}}$. However, its total cost remains comparable to the stronger and more verbose reasoning baselines. AlgoPilot uses 16.17M tokens, which is close to Qwen3-Coder$_{\mathrm{DIRECT}}$ (15.04M) and lower than Qwen3-Coder$_{\mathrm{REASON}}$ (23.57M) and Qwen3.5-9B$_{\mathrm{REASON}}$ (19.79M). Thus, although AlgoPilot introduces additional inference stages, its evaluation-time token cost remains within the same order of magnitude as standard prompting baselines.

The key difference is how the token budget is allocated. In the baselines, all tokens are spent in a single generation, where the model must simultaneously decide how to solve the problem, construct the solution, and produce the final answer. In contrast, AlgoPilot decomposes this process into strategy selection, formulation construction, and execution. The SteerLM stage is intentionally compact, producing only a paradigm–mode prediction or candidate list. The larger token cost is spent in GuideLM and ExecuteLM, where the model constructs and executes paradigm-specific formulations. This allocation reflects the design goal of AlgoPilot: spending additional tokens on structured formulation when needed, rather than relying on a single unconstrained generation.

Table 19 further reports the average completion tokens per ExecuteLM call under AlgoPilot SFT+GRPO. PDDL remains the most token-intensive paradigm, averaging 2,470 completion tokens per call, since successful planning requires generating complete domain and problem specifications. MILP and SMT are also relatively expensive, averaging 1,049 and 926 completion tokens per call, respectively, because they require solver-oriented formalizations. Code and CoT are less expensive, averaging 724 and 450 completion tokens per call. Compared with the baseline per-call profiles in Table 17, AlgoPilot avoids the extremely long completions observed in some REASON configurations, especially for Qwen3-Coder and Qwen3.5-9B on MILP and PDDL.

Model	Code	CoT	MILP	PDDL	SMT
AlgoPilot SFT+GRPO	724	450	1049	2470	926

Overall, the cost analysis suggests that AlgoPilot trades a moderate increase in inference structure for substantially stronger problem-solving performance. Its token usage is higher than simple direct prompting, but the additional cost is concentrated in the stages that explicitly select and formulate the appropriate computational paradigm. This provides a more controlled and effective use of inference budget than asking a single model response to perform strategy selection, formulation, and execution all at once.

Failure Case Analysis

Baselines

We examine the failure modes of two baseline prompt configurations, DIRECT and REASONING, across all the large models and all five algorithm families (Code, CoT, PDDL, SMT, MILP).

We categorize failures into five classes:

1. Format mismatch. The model produces a logically valid solution, but the answer cannot be evaluated without extra harness.

2. Execution error. Generated code raises a runtime exception.

3. Execution timeout. Code or solver exceeds the time limit.

4. Generation mismatch. The model produces output in the wrong formalism.

5. Incorrect answer. The answer does not match the ground truth.

CoT: Prompt–Pipeline Interaction

The most striking result is the drop in CoT accuracy when moving from DIRECT to REASON, which is counter-intuitive since REASON explicitly invites the model to reason about algorithm selection. The root cause is a format mismatch: the REASON prompt includes the necessary output instructions, which tells the model that code output is acceptable (“If you write code, output Python code wrapped in ```python and ```”). When the CoT pipeline operates in direct mode, it extracts the final answer from the raw text without executing any code. When the model responds with a Python code block, the answer-extraction regex matches the FINAL_ANSWER= token inside the code, parsing an f-string template literal (e.g., {difference}") instead of the computed value, while the content in the code block is still pure text reasoning instead of executable code.

Table 20 quantifies the effect. When models do not produce code blocks, the two prompt types achieve comparable accuracy (84–87%); the gap is entirely driven by format mismatch.

Model	Wrap with code block		Accuracy (%)
	DIRECT	REASON	Text-only	Code block
GLM-5	5.3%	71.2%	83.9	5.5
Qwen3-Coder	76.4%	94.1%	67.9	36.7

Table 20: Fraction of CoT runs that produce a Python code block instead of a direct textual answer, and accuracy conditioned on output format (REASON prompt).

Qwen3-Coder exhibits this behavior even under the DIRECT prompt (76.4% of runs produce code), which explains its lower CoT accuracy across both configurations. This highlights a broader design consideration: when models are given latitude to choose their output format, instruction-following tendencies can conflict with pipeline expectations.

PDDL: Domain Generation Failures

PDDL tasks exhibit the widest inter-model gap. GLM-5 achieves 47–55% accuracy, while Qwen3-Coder scores below 8%. The dominant failure mode for Qwen3-Coder is generation mismatch: across both prompt configurations, 70–90% of failures occur because the model produces Python code instead of PDDL domain and problem specifications.

Notably, no failures across any configuration are due to the planner finding a valid but incorrect plan; all planner-stage failures are due to unsolvable or malformed specifications. For Qwen3-Coder under DIRECT, 856 out of 941 missing-domain cases (91%) are attributable to the model generating Python code instead of PDDL. Under REASON, this figure is 625 out of 667 (94%). This suggests Qwen3-Coder has a strong code-generation prior that overrides format instructions for less common formalisms.

Model	No domain/problem	Planner: no plan	Wrong plan	Total failures
DIRECT
GLM-5	218	389	0	607
Qwen3-Coder	941	371	0	1,312
REASON
GLM-5	511	211	0	722
Qwen3-Coder	667	565	0	1,232

SMT: Runtime Errors and Namespace Issues

SMT tasks require generating Z3 Python code. GLM-5 achieves high accuracy under REASON (83.6%), with most failures being incorrect answers (wrong logical modeling) rather than execution errors. In contrast, Qwen3-Coder suffers from a high rate of execution errors: 88.5% of failures under DIRECT and 83.1% under REASON are runtime crashes.

The dominant error type is NameError (519/522 errors under DIRECT). Manual inspection reveals a recurring pattern: the model references the Z3 constant unknown (the satisfiability result for indeterminate formulas) without importing it. In Z3, unknown must be accessed as z3.unknown or explicitly imported. A secondary pattern involves the model using bare identifiers true/false (Python-style) rather than the Z3 constants sat/unsat.

MILP: Timeout and Solver Errors

MILP failures are more evenly distributed across categories. Execution timeouts are significant for GLM-5 under DIRECT (34/373 failures, 9.1%), driven by models generating exponential-size formulations for combinatorial problems. Both models exhibit SyntaxError and TypeError as the leading execution-error subtypes, typically from incorrect PySCIPOpt or PuLP API usage. The largest failure category across all MILP configurations is incorrect answers (60–76% of failures), reflecting the difficulty of correctly formalizing optimization constraints.

Code: High Reliability with Residual Issues

Code generation is the most reliable algorithm family, with 83–92% per-run accuracy across all configurations. Failures decompose as follows:

• Incorrect answers account for 73–78% of GLM-5 failures and 19–34% of Qwen3-Coder failures.

• Execution errors are more prevalent for Qwen3-Coder (26–39% of failures vs. 12% for GLM-5), with SyntaxError as the leading subtype (incomplete code blocks or malformed expressions).

• Silent failures are a notable Qwen3-Coder, which is a specific issue under REASON: 162 runs produce code that executes successfully (exit code 0) but prints nothing. These arise when the model computes the answer in comments or local variables without a print statement, and the injected fallback (_copilot_pick_final_answer) cannot locate the result in global scope.

AlgoPilot

We further analyze the failure modes of AlgoPilot.

Across 2,220 evaluated problem instances, AlgoPilot produces 6,660 execution runs and achieves 4,942 successful runs.

Table 22 decomposes the remaining 1,718 failed runs using the same five categories as in the baseline analysis.

Failure mode	Count	Fraction of failures
Format mismatch	11	0.6%
Execution error	157	9.1%
Execution timeout	15	0.9%
Generation mismatch	0	0.0%
Incorrect answer	1,535	89.3%

The main qualitative difference from the baselines is that AlgoPilot largely removes low-level prompt–pipeline failures. Generation mismatch is not observed in this evaluation: when AlgoPilot selects PDDL, the system consistently produces both domain and problem files rather than falling back to Python code. Format mismatch is also rare, accounting for only 11 failed runs. Thus, the dominant remaining failure mode is not that AlgoPilot produces the wrong formalism, but that the selected paradigm or generated formulation leads to an executable yet semantically incorrect solution.

Execution errors account for 157 failed runs. They are concentrated in Coding, MILP, and SMT executions. The most common exception types are KeyError (66), AttributeError (20), IndexError (19), TypeError (18), and ValueError (12).

Only 15 failed runs are execution timeouts. This suggests that timeouts are not a broad failure mode of AlgoPilot. Instead, they occur when the generated code uses an overly expensive algorithm for a problem whose constraints require a more efficient implementation. Thus, the timeout failures are better interpreted as algorithmic-complexity errors rather than solver instability.

The baseline PDDL analysis showed many generation mismatches, especially cases where the model generated Python code instead of PDDL. This failure mode is not observed for AlgoPilot: all PDDL failures contain generated PDDL domain and problem files. However, 112 PDDL runs still fail because the planner returns no valid plan. This indicates that AlgoPilot successfully enforces the correct formalism, but PDDL remains sensitive to formulation quality. Typical failures arise when the generated domain/problem encoding is syntactically usable but semantically over-constrained, missing necessary actions, or misrepresents the transition structure.

An additional failure mode specific to AlgoPilot is guidance-induced error. In guided modes, the execution model is conditioned on a structured guidance object. When this guidance contains a wrong invariant, incorrect recurrence, missing constraint, or misleading implementation step, the execution model often follows it faithfully and produces a consistently wrong solution. This effect is visible in the selected-label performance. Code-Direct achieves 91.2% micro success, while Code-Guided achieves 69.3%. Similarly, CoT-Direct achieves 88.3%, while CoT-Guided achieves 64.2%. This does not mean guidance is intrinsically harmful; rather, it shows that guidance is most useful when the formulation itself is correct. For easier Code or CoT problems, an unnecessary or flawed guidance can over-constrain the execution model and introduce errors that a direct solution would avoid.

The largest category is incorrect answers, accounting for 1,535 out of 1,718 failures. This is the expected remaining bottleneck for a small 8B model once format mismatch and generation mismatch are reduced.

Overall, AlgoPilot changes the nature of failures. The baselines often fail because the model produces an output incompatible with the pipeline, such as code in a CoT setting or Python instead of PDDL. In contrast, AlgoPilot usually produces the requested formalism and executable artifacts. Its remaining failures are higher-level: selecting a less reliable paradigm, generating misleading guidance, or constructing an incorrect formulation within the selected paradigm. This supports the main motivation of AlgoPilot: cross-paradigm reasoning requires not only choosing a solving route, but also constructing the correct formulation for that route.

Task Descriptions

Here we describe the 66 domains, which include chain-of-thought reasoning, programmatic coding, mathematical optimization, symbolic planning, and satisfiability modulo theories. Chain-of-Thought tasks (T1-T17) are drawn from Big-Bench-Hard [33], GSM8K [10], and CLUTRR [31]; coding tasks (T18-T44) combine Big-Bench-Hard with LeetCode [37] problems organized by algorithmic topic; Optimization tasks (T45-T56) are sourced from OptiGuide [18], Chain-of-Experts [38], OptiBench [41], NL4Opt [1], NLP4LP [27], and LLMFP [16]. Planning tasks (T57-T60) originate from the International Planning Competition [34], with T76 as a synthetically relabeled variant, and SMT tasks (T61-T66) from SAT-LM [43] and Logic-LM [22].

CoT

T1 - Causal Reasoning Given a word problem describing a sequence of events that modify quantities (e.g., items added, removed, or redistributed among people), determine the final numerical outcome.

T2 - Kinship Reasoning Given a short story involving named individuals and stated family relationships, determine the kinship relation between two specified people (e.g., aunt, nephew) by following implicit multi-hop relational chains.

T3 - Formal Fallacies The task examines a set of statements and judges whether the informal argument that follows is deductively valid or commits a formal fallacy, with particular attention to negations.

T4 - Hyperbaton Given two sentences, choose which of the two follows the natural English ordering of adjectives.

T5 - Logical Reasoning Given a set of statements and constraints, including syllogisms, ordering clues, and truth assignments, derive the correct conclusion.

T6 - Mathematical Reasoning Given a multi-step word problem, apply arithmetic operations sequentially to compute the correct numerical answer.

T7 - Movie Recommendation From four candidate films, select the one that best matches the preferences implied by the movies a user has already enjoyed.

T8 - Navigation Follow a sequence of movement instructions and state whether the agent finishes at its starting point.

T9 - Object Counting Given a list of items and their quantities, count how many belong to a specified category.

T10 - Colored Object Reasoning Using the provided context, state the color of a particular object on a surface.

T11 - Sports Understanding Judge whether a fabricated sports-related statement is plausible.

T12 - Temporal Reasoning Given a description of the calendar, answer a question by conducting arithmetic calculations such as adding or subtracting days, months, or years, or computing weekday differences.

T13 - Temporal Sequences Given a timeline of a person’s daily activities, identify a time slot when they could have performed another specified task.

T14 - Tracking Shuffled Objects (3) Trace a set of 3 objects through a series of pairwise swaps to determine their final positions.

T15 - Tracking Shuffled Objects (5) Trace a set of 5 objects through a series of pairwise swaps to determine their final positions. T16 - Tracking Shuffled Objects (7) Trace a set of 7 objects through a series of pairwise swaps to determine their final positions.

T17 - Web of Lies Decide whether a Boolean function described in a word problem evaluates to true or false.

Coding

T18 - Boolean Expression Evaluation This task determines whether a randomly generated Boolean expression (built from the constants True and False and the operators and, or, and not) evaluates to true or false.

T19 - Dyck Languages The task aims to complete a Dyck-4 string by providing the missing closing parentheses that properly balance the given prefix.

T20 - Penguins in a Table Refer to a table of individual penguins and their attributes (possibly with extra information) to answer a question about one of those attributes.

T21 - Word Sorting Arrange the provided words in standard alphabetical order.

T22 - Array Solve array manipulation problems involving techniques such as two-pointer traversal, sliding windows, and prefix sums.

T23 - Backtracking Find valid solutions to constraint-satisfaction problems by systematically exploring candidates and pruning infeasible branches.

T24 - Binary Indexed Tree Answer prefix-sum or order-statistic queries over a sequence subject to point updates.

T25 - Binary Search Tree Solve problems involving BST operations including construction, traversal, insertion, deletion, and structural validation.

T26 - Bit Manipulation Solve problems using bitwise operations including AND, OR, XOR, shifts, and bit counting.

T27 - Brainteaser Identify a non-obvious mathematical or logical insight to solve a concise puzzle.

T28 - Dynamic Programming Solve optimization or counting problems by decomposing them into overlapping subproblems and memoizing intermediate results.

T29 - Enumeration Exhaustively generate all configurations satisfying a set of constraints and return those meeting the specified criteria.

T30 - Geometry Solve computational geometry problems involving collinearity, distances, intersections, or polygon properties.

T31 - Greedy Solve optimization problems by making locally optimal decisions at each step to achieve a global optimum.

T32 - Hash Table Solve problems requiring fast lookup, grouping, or frequency counting using hash maps.

T33 - Heap Solve problems requiring a dynamically maintained ordered collection, such as finding the $k$-th largest element or merging sorted streams.

T34 - Linked List Solve problems involving linked list manipulation such as reversal, cycle detection, or merging sorted lists.

T35 - Math Solve number-theoretic and combinatorial problems including digit manipulation, modular arithmetic, and prime testing.

T36 - Memoization Solve problems by caching intermediate results to avoid redundant computation in a top-down recursive approach.

T37 - Queue Solve problems using FIFO queue or deque semantics, such as sliding window maximum or first-occurrence tracking.

T38 - Recursion Solve problems whose structure is naturally expressed recursively, such as divide-and-conquer or tree traversal.

T39 - Segment Tree Answer range queries (sum, minimum, or maximum) over a sequence subject to point updates.

T40 - Stack Solve problems using a stack to track state, such as bracket matching, next greater element, or monotonic stack applications.

T41 - String Solve problems involving string parsing, pattern matching, or character frequency analysis.

T42 - Trie Solve problems involving prefix tree construction and traversal, such as word segmentation or prefix matching.

T43 - Two Pointers Solve problems using two-pointer traversal over sorted arrays or strings, such as palindrome detection or pair finding.

T44 - Union-Find Solve connectivity problems using disjoint-set union, such as finding connected components or detecting cycles.

Mixed Integer Programming

T45 - Coffee Supply Chain A coffee company sources beans from multiple suppliers, roasts them at one of two facilities into dark or light blends, and ships to retail locations. Given supply capacities, demand requirements, and cost tables, find the production and distribution plan that minimizes total cost.

T46 - Facility Location A company ships products from plants to warehouses and considers closing some plants to reduce fixed costs. Given plant capacities, warehouse demands, and shipping costs, determine which plants to keep open and how to route shipments to minimize total cost.

T47 - Linear Programming (Notable) Solve a linear program presented in natural language with a named real-world structure (e.g., pricing, coverage, blending). Given the objective and constraints, return the optimal value.

T48 - Linear Programming (Table) Solve a linear program whose constraint data is organized in tabular form. Given the table and objective, return the optimal value.

T49 - Linear Programming (Word Problems) Solve linear programming word problems covering resource allocation and transportation scenarios. Given the natural language description, determine the optimal objective value.

T50 - Network Flow Route multiple products from production cities to warehouse cities through a transportation network with arc capacities. Given supply, demand, and cost data, find the minimum-cost feasible flow.

T51 - NL4Opt Solve a linear programming problem presented as a natural language optimization scenario. Return the optimal objective value.

T52 - NLP4LP Given a natural language description of a linear or mixed-integer programming problem, formulate and solve it to return the optimal objective value.

T53 - Nonlinear Programming Solve a nonlinear program (e.g., with multiplicative or quadratic decision variables) presented in natural language. Return the optimal objective value.

T54 - Traveling Salesman A salesman must visit each city exactly once and return to the starting city. Given city coordinates, find the tour minimizing total Euclidean distance and return its cost.

T55 - Task Allocation Assign tasks of three types across three heterogeneous robots working in parallel. Given task counts and per-robot processing times, minimize the makespan.

T56 - Workforce Scheduling Assign workers to shifts over a two-week horizon subject to individual availability and daily staffing requirements. Find the schedule that satisfies all constraints while minimizing total labor cost.

PDDL

T57 - Blocksworld In Blocksworld, the objective is to stack a set of blocks according to a specific order. The robot can perform four actions: (1) pick up a block, (2) unstack a block from the top of another block, (3) put down a block, (4) stack a block on top of another block. A robot can only pick up, unstack, or stack a block if it is clear, that is, the block has no other blocks on top and is not currently being held. Tasks span plan generation, optimality checking, replanning, plan reuse, and step verification.

T58 - Depots A fleet of trucks and hoists must transport crates between depots and distributors. Given an initial world state and delivery goals, produce a valid sequential plan using drive, lift, drop, and load/unload actions.

T59 - Logistics Trucks and airplanes transport packages between locations within and across cities using drive, fly, load, and unload actions. Tasks span plan generation, optimality verification, replanning, plan reuse, and partial plan completion.

T60 - Mystery Blocksworld A relabeled variant of Blocksworld in which objects and actions are replaced with abstract symbols (e.g., attack, succumb, overcome), preventing direct domain recognition. The model must infer action semantics from precondition and effect descriptions alone and produce a valid plan.

SMT

T61 - LSAT Logic Games LSAT-style scheduling problems in which a group of entities must be assigned to slots subject to a set of stated constraints. Given the scenario and a question, identify a valid assignment or determine which option is consistent with all rules.

T62 - Boardgame Reasoning (Depth 1) A boardgame with named players and logical interaction rules. Given the current game state, apply the rules at depth 1 to determine whether a specified predicate holds, is false, or cannot be determined.

T63 - Boardgame Reasoning (Depth 2) Same as T78 but requiring two levels of rule application before reaching a conclusion.

T64 - Boardgame Reasoning (Depth 3) Same as T78 but requiring three levels of rule application, substantially increasing the length of the reasoning chain.

T65 - Logical Deduction Given a set of spatial ordering clues about objects arranged in a fixed sequence, determine the complete ordering or answer a question about a specific object’s position.

T66 - Proof Writing Given a set of first-order logical rules and facts, determine whether a target statement is true or false by chaining up to five inference steps.

NeurIPS Paper Checklist

1. Claims

Question: Do the main claims made in the abstract and introduction accurately reflect the paper’s contributions and scope?

Answer: [Yes]

Justification: The abstract and introduction accurately summarize the contribution and scope.

Guidelines:

• The answer [N/A] means that the abstract and introduction do not include the claims made in the paper.

• The abstract and/or introduction should clearly state the claims made, including the contributions made in the paper and important assumptions and limitations. A [No] or [N/A] answer to this question will not be perceived well by the reviewers.

• The claims made should match theoretical and experimental results, and reflect how much the results can be expected to generalize to other settings.

• It is fine to include aspirational goals as motivation as long as it is clear that these goals are not attained by the paper.

2. Limitations

Question: Does the paper discuss the limitations of the work performed by the authors?

Answer: [Yes]

Justification: The paper discusses the limitation in the Conclusion section.

Guidelines:

• The answer [N/A] means that the paper has no limitation while the answer [No] means that the paper has limitations, but those are not discussed in the paper.

• The authors are encouraged to create a separate “Limitations” section in their paper.

• The paper should point out any strong assumptions and how robust the results are to violations of these assumptions (e.g., independence assumptions, noiseless settings, model well-specification, asymptotic approximations only holding locally). The authors should reflect on how these assumptions might be violated in practice and what the implications would be.

• The authors should reflect on the scope of the claims made, e.g., if the approach was only tested on a few datasets or with a few runs. In general, empirical results often depend on implicit assumptions, which should be articulated.

• The authors should reflect on the factors that influence the performance of the approach. For example, a facial recognition algorithm may perform poorly when image resolution is low or images are taken in low lighting. Or a speech-to-text system might not be used reliably to provide closed captions for online lectures because it fails to handle technical jargon.

• The authors should discuss the computational efficiency of the proposed algorithms and how they scale with dataset size.

• If applicable, the authors should discuss possible limitations of their approach to address problems of privacy and fairness.

• While the authors might fear that complete honesty about limitations might be used by reviewers as grounds for rejection, a worse outcome might be that reviewers discover limitations that aren’t acknowledged in the paper. The authors should use their best judgment and recognize that individual actions in favor of transparency play an important role in developing norms that preserve the integrity of the community. Reviewers will be specifically instructed to not penalize honesty concerning limitations.

3. Theory assumptions and proofs

Question: For each theoretical result, does the paper provide the full set of assumptions and a complete (and correct) proof?

Answer: [N/A] Justification: This paper does not include theoretical results.

Guidelines:

• The answer [N/A] means that the paper does not include theoretical results.

• All the theorems, formulas, and proofs in the paper should be numbered and cross-referenced.

• All assumptions should be clearly stated or referenced in the statement of any theorems.

• The proofs can either appear in the main paper or the supplemental material, but if they appear in the supplemental material, the authors are encouraged to provide a short proof sketch to provide intuition.

• Inversely, any informal proof provided in the core of the paper should be complemented by formal proofs provided in appendix or supplemental material.

• Theorems and Lemmas that the proof relies upon should be properly referenced.

Experimental result reproducibility

Question: Does the paper fully disclose all the information needed to reproduce the main experimental results of the paper to the extent that it affects the main claims and/or conclusions of the paper (regardless of whether the code and data are provided or not)?

Answer: [Yes]

Justification: All details needed to reproduce the main experimental results are included in the Method, Experiment Results, and Appendix sections. We include the codes in supplementary material.

Guidelines:

• The answer [N/A] means that the paper does not include experiments.

• If the paper includes experiments, a [No] answer to this question will not be perceived well by the reviewers: Making the paper reproducible is important, regardless of whether the code and data are provided or not.

• If the contribution is a dataset and/or model, the authors should describe the steps taken to make their results reproducible or verifiable.

• Depending on the contribution, reproducibility can be accomplished in various ways. For example, if the contribution is a novel architecture, describing the architecture fully might suffice, or if the contribution is a specific model and empirical evaluation, it may be necessary to either make it possible for others to replicate the model with the same dataset, or provide access to the model. In general. releasing code and data is often one good way to accomplish this, but reproducibility can also be provided via detailed instructions for how to replicate the results, access to a hosted model (e.g., in the case of a large language model), releasing of a model checkpoint, or other means that are appropriate to the research performed.

• While NeurIPS does not require releasing code, the conference does require all submissions to provide some reasonable avenue for reproducibility, which may depend on the nature of the contribution. For example (a) If the contribution is primarily a new algorithm, the paper should make it clear how to reproduce that algorithm. (b) If the contribution is primarily a new model architecture, the paper should describe the architecture clearly and fully. (c) If the contribution is a new model (e.g., a large language model), then there should either be a way to access this model for reproducing the results or a way to reproduce the model (e.g., with an open-source dataset or instructions for how to construct the dataset). (d) We recognize that reproducibility may be tricky in some cases, in which case authors are welcome to describe the particular way they provide for reproducibility. In the case of closed-source models, it may be that access to the model is limited in some way (e.g., to registered users), but it should be possible for other researchers to have some path to reproducing or verifying the results.

Open access to data and code

Question: Does the paper provide open access to the data and code, with sufficient instructions to faithfully reproduce the main experimental results, as described in supplemental material?

Answer: [Yes]

Justification: We upload the code and data in the supplementary material.

Guidelines:

• The answer [N/A] means that paper does not include experiments requiring code.

• Please see the NeurIPS code and data submission guidelines (https://neurips.cc/public/guides/CodeSubmissionPolicy) for more details.

• While we encourage the release of code and data, we understand that this might not be possible, so [No] is an acceptable answer. Papers cannot be rejected simply for not including code, unless this is central to the contribution (e.g., for a new open-source benchmark).

• The instructions should contain the exact command and environment needed to run to reproduce the results. See the NeurIPS code and data submission guidelines (https://neurips.cc/public/guides/CodeSubmissionPolicy) for more details.

• The authors should provide instructions on data access and preparation, including how to access the raw data, preprocessed data, intermediate data, and generated data, etc.

• The authors should provide scripts to reproduce all experimental results for the new proposed method and baselines. If only a subset of experiments are reproducible, they should state which ones are omitted from the script and why.

• At submission time, to preserve anonymity, the authors should release anonymized versions (if applicable).

• Providing as much information as possible in supplemental material (appended to the paper) is recommended, but including URLs to data and code is permitted.

Experimental setting/details

Question: Does the paper specify all the training and test details (e.g., data splits, hyperparameters, how they were chosen, type of optimizer) necessary to understand the results?

Answer: [Yes]

Justification: Detailed experimental settings are included in the experiment section and appendix.

Guidelines:

• The answer [N/A] means that the paper does not include experiments.

• The experimental setting should be presented in the core of the paper to a level of detail that is necessary to appreciate the results and make sense of them.

• The full details can be provided either with the code, in appendix, or as supplemental material.

Experiment statistical significance

Question: Does the paper report error bars suitably and correctly defined or other appropriate information about the statistical significance of the experiments?

Answer: [Yes]

Justification: Error bars are reported in appendix due to space limit.

Guidelines:

• The answer [N/A] means that the paper does not include experiments.

• The authors should answer [Yes] if the results are accompanied by error bars, confidence intervals, or statistical significance tests, at least for the experiments that support the main claims of the paper.

• The factors of variability that the error bars are capturing should be clearly stated (for example, train/test split, initialization, random drawing of some parameter, or overall run with given experimental conditions).

• The method for calculating the error bars should be explained (closed form formula, call to a library function, bootstrap, etc.)

• The assumptions made should be given (e.g., Normally distributed errors).

• It should be clear whether the error bar is the standard deviation or the standard error of the mean.

• It is OK to report 1-sigma error bars, but one should state it. The authors should preferably report a 2-sigma error bar than state that they have a 96% CI, if the hypothesis of Normality of errors is not verified.

• For asymmetric distributions, the authors should be careful not to show in tables or figures symmetric error bars that would yield results that are out of range (e.g., negative error rates).

• If error bars are reported in tables or plots, the authors should explain in the text how they were calculated and reference the corresponding figures or tables in the text.

Experiments compute resources

Question: For each experiment, does the paper provide sufficient information on the computer resources (type of compute workers, memory, time of execution) needed to reproduce the experiments?

Answer: [Yes]

Justification: We discuss about the resource needed in the appendix.

Guidelines:

• The answer [N/A] means that the paper does not include experiments.

• The paper should indicate the type of compute workers CPU or GPU, internal cluster, or cloud provider, including relevant memory and storage.

• The paper should provide the amount of compute required for each of the individual experimental runs as well as estimate the total compute.

• The paper should disclose whether the full research project required more compute than the experiments reported in the paper (e.g., preliminary or failed experiments that didn’t make it into the paper).

Code of ethics

Question: Does the research conducted in the paper conform, in every respect, with the NeurIPS Code of Ethics https://neurips.cc/public/EthicsGuidelines?

Answer: [Yes]

Justification: Our paper followed the NeurIPS Code of Ethics

Guidelines:

• The answer [N/A] means that the authors have not reviewed the NeurIPS Code of Ethics.

• If the authors answer [No], they should explain the special circumstances that require a deviation from the Code of Ethics.

• The authors should make sure to preserve anonymity (e.g., if there is a special consideration due to laws or regulations in their jurisdiction).

Broader impacts

Question: Does the paper discuss both potential positive societal impacts and negative societal impacts of the work performed?

Answer: [Yes]

Justification: We include a Broader Impact Statement in appendix.

Guidelines:

• The answer [N/A] means that there is no societal impact of the work performed.

• If the authors answer [N/A] or [No], they should explain why their work has no societal impact or why the paper does not address societal impact.

• Examples of negative societal impacts include potential malicious or unintended uses (e.g., disinformation, generating fake profiles, surveillance), fairness considerations (e.g., deployment of technologies that could make decisions that unfairly impact specific groups), privacy considerations, and security considerations.

• The conference expects that many papers will be foundational research and not tied to particular applications, let alone deployments. However, if there is a direct path to any negative applications, the authors should point it out. For example, it is legitimate to point out that an improvement in the quality of generative models could be used to generate Deepfakes for disinformation. On the other hand, it is not needed to point out that a generic algorithm for optimizing neural networks could enable people to train models that generate Deepfakes faster.

• The authors should consider possible harms that could arise when the technology is being used as intended and functioning correctly, harms that could arise when the technology is being used as intended but gives incorrect results, and harms following from (intentional or unintentional) misuse of the technology.

• If there are negative societal impacts, the authors could also discuss possible mitigation strategies (e.g., gated release of models, providing defenses in addition to attacks, mechanisms for monitoring misuse, mechanisms to monitor how a system learns from feedback over time, improving the efficiency and accessibility of ML).

Safeguards

Question: Does the paper describe safeguards that have been put in place for responsible release of data or models that have a high risk for misuse (e.g., pre-trained language models, image generators, or scraped datasets)?

Answer: [Yes]

Justification: the paper poses no such risks

Guidelines:

• The answer [N/A] means that the paper poses no such risks.

• Released models that have a high risk for misuse or dual-use should be released with necessary safeguards to allow for controlled use of the model, for example by requiring that users adhere to usage guidelines or restrictions to access the model or implementing safety filters.

• Datasets that have been scraped from the Internet could pose safety risks. The authors should describe how they avoided releasing unsafe images.

• We recognize that providing effective safeguards is challenging, and many papers do not require this, but we encourage authors to take this into account and make a best faith effort.

Licenses for existing assets

Question: Are the creators or original owners of assets (e.g., code, data, models), used in the paper, properly credited and are the license and terms of use explicitly mentioned and properly respected?

Answer: [Yes]

Justification: Used assets are publicly available and are properly cited.

Guidelines:

• The answer [N/A] means that the paper does not use existing assets.

• The authors should cite the original paper that produced the code package or dataset.

• The authors should state which version of the asset is used and, if possible, include a URL.

• The name of the license (e.g., CC-BY 4.0) should be included for each asset.

• For scraped data from a particular source (e.g., website), the copyright and terms of service of that source should be provided.

• If assets are released, the license, copyright information, and terms of use in the package should be provided. For popular datasets, paperswithcode.com/datasets has curated licenses for some datasets. Their licensing guide can help determine the license of a dataset.

• For existing datasets that are re-packaged, both the original license and the license of the derived asset (if it has changed) should be provided.

• If this information is not available online, the authors are encouraged to reach out to the asset’s creators.

New assets

Question: Are new assets introduced in the paper well documented and is the documentation provided alongside the assets?

Answer: [Yes]

Justification: We provide details of the dataset and model in appendix, and we provide readme for code submission.

Guidelines:

• The answer [N/A] means that the paper does not release new assets.

• Researchers should communicate the details of the dataset/code/model as part of their submissions via structured templates. This includes details about training, license, limitations, etc.

• The paper should discuss whether and how consent was obtained from people whose asset is used.

• At submission time, remember to anonymize your assets (if applicable). You can either create an anonymized URL or include an anonymized zip file.

Crowdsourcing and research with human subjects

Question: For crowdsourcing experiments and research with human subjects, does the paper include the full text of instructions given to participants and screenshots, if applicable, as well as details about compensation (if any)?

Answer: [N/A]

Justification: the paper does not involve crowdsourcing nor research with human subjects

Guidelines:

• The answer [N/A] means that the paper does not involve crowdsourcing nor research with human subjects.

• Including this information in the supplemental material is fine, but if the main contribution of the paper involves human subjects, then as much detail as possible should be included in the main paper.

• According to the NeurIPS Code of Ethics, workers involved in data collection, curation, or other labor should be paid at least the minimum wage in the country of the data collector.

Institutional review board (IRB) approvals or equivalent for research with human subjects

Question: Does the paper describe potential risks incurred by study participants, whether such risks were disclosed to the subjects, and whether Institutional Review Board (IRB) approvals (or an equivalent approval/review based on the requirements of your country or institution) were obtained?

Answer: [N/A]

Justification: the paper does not involve crowdsourcing nor research with human subjects

Guidelines:

• The answer [N/A] means that the paper does not involve crowdsourcing nor research with human subjects.

• Depending on the country in which research is conducted, IRB approval (or equivalent) may be required for any human subjects research. If you obtain IRB approval, you should clearly state this in the paper.

• We recognize that the procedures for this may vary significantly between institutions and locations, and we expect authors to adhere to the NeurIPS Code of Ethics and the guidelines for their institution.

• For initial submissions, do not include any information that would break anonymity (if applicable), such as the institution conducting the review.

Declaration of LLM usage

Question: Does the paper describe the usage of LLMs if it is an important, original, or non-standard component of the core methods in this research? Note that if the LLM is used only for writing, editing, or formatting purposes and does not impact the core methodology, scientific rigor, or originality of the research, declaration is not required.

Answer: [Yes]

Justification: LLMs are used as baselines and also are finetuned, which is discussed in Method and Appendix Section.

Guidelines:

• The answer [N/A] means that the core method development in this research does not involve LLMs as any important, original, or non-standard components.

• Please refer to our LLM policy in the NeurIPS handbook for what should or should not be described.