PaperlayerView exact revision on arXiv

Source-linked AI summary

Learning to Ask: Information Acquisition for SLM-LLM Collaboration, under a budget

Yongjun Kim, Xiaoxiao Li, Jaeho Lee

arXiv:2610.01236v1cs.AI

TL;DR

Under limited API budgets, collaboration must make effective use of a stronger LLM while addressing SLMs' difficulty deciding when and how to seek help. The paper trains an SLM-centered system to acquire targeted advisor information, improving performance–cost trade-offs across math and coding tasks and sometimes matching or exceeding problem-level oracle routing.

  • Problem

    Under limited API budgets, effective collaboration requires deciding when an SLM needs help and forming useful queries, capabilities that zero-shot SLMs do not reliably provide.

    Source: §1 · pp. 1–2

  • Method

    A stage-wise framework trains an SLM-centered system to selectively invoke a black-box advisor, formulate budget-aware queries, and integrate its responses into reasoning.

    Source: §8 · pp. 9–10

  • Results

    Across mathematical reasoning and coding, the approach achieves favorable performance–cost trade-offs over collaboration baselines and sometimes matches or surpasses problem-level oracle routing.

    Source: §1 · p. 2, §8 · p. 10

  • Takeaways & Limitations

    Targeted information acquisition offers a practical approach to cost-efficient SLM–LLM collaboration, with learned behavior adapting to difficulty and budget and transferring non-universally to unseen advisors.

    Source: §8 · p. 10

    The formulation assumes the SLM can invoke the advisor only once per reasoning trajectory.

    Source: §3 · p. 3

Abstract

from arXiv · show

Collaboration between a small language model (SLM) and a large language model (LLM) offers an opportunity to combine the efficiency of smaller models with the strong reasoning capabilities of larger ones. Existing approaches primarily frame such collaboration as a computation allocation problem, determining which model should handle each portion of the reasoning process. In black-box API-based settings, however, this paradigm can be inefficient due to coarse-grained delegation or repeated transmission of context across model switches. In this work, we instead formulate SLM-LLM collaboration as an information acquisition problem, under an API budget constraint. The SLM remains the primary reasoner and selectively queries a black-box LLM advisor only when needed, issuing targeted queries rather than delegating the reasoning process itself. To realize this strategy, we develop a three-stage RLVR framework that learns whether to call the advisor, how to formulate useful queries, and how to integrate the collaboration into the reasoning process by jointly refining advisor invocation and information use. Across mathematical reasoning and coding tasks, our approach improves the performance--cost tradeoff over existing collaboration baselines and, in some settings, matches or exceeds oracle problem-level routing. Finally, we show that our strategy can transfer to other advisor model families, without further training.

1 INTRODUCTION

SLM–LLM collaboration must make effective use of a stronger, often paid API advisor under a limited budget. The paper keeps the SLM as primary reasoner, trains it to acquire targeted help, and reports improved performance–cost trade-offs across math and coding tasks.

Motivation

  • Existing approaches allocate computation by delegating whole problems or switching models at fine granularity, which can incur repeated transmission of growing reasoning context in black-box APIs.Whole-problem delegation can be inefficient when the SLM needs help only at a particular reasoning bottleneck.Source: §1 · p. 1

Approach

  • The SLM remains the primary reasoner and asks a black-box advisor a short, targeted question at a bottleneck, without sending its full reasoning context.The overview depicts QMaker constructing a focused, self-contained query with a response-budget instruction; the SLM then incorporates the reply and continues reasoning.Source: §1 · p. 2, Figure 1 · p. 2

Motivation

  • Zero-shot SLMs often fail both to recognize when help is needed and to formulate compact, self-contained queries with the critical information.The pilot study reports missed calls and queries that omit necessary context.Source: §1 · p. 2

Approach

  • A three-stage RLVR framework trains the reasoning SLM when to call, QMaker how to ask within the response budget, and the SLM how to use the resulting collaboration.The final stage refines invocation and integration of advisor responses while preserving the learned selective-call behavior.Source: §1 · p. 2

Results

  • Across mathematical reasoning and coding, the framework improves performance–cost trade-offs over routing and fine-grained baselines, sometimes matching or surpassing problem-level oracle routing.The learned policy also adapts calls to problem difficulty and budget, and transfers to other advisor families without further training.Source: §1 · p. 2

2 RELATED WORK

Prior collaboration work either delegates whole problems or allocates generation more finely, while tool-use research studies adaptive invocation. The paper distinguishes its approach by asking a stronger general-purpose advisor targeted questions and learning selective use.

Problem-level SLM-LLM collaboration

  • Problem-level routing and cascading delegate whole problems based on pre-generation difficulty or post-generation quality and confidence, but overlook variation in difficulty across reasoning steps [Aggarwal et al., 2024; Ding et al., 2024; Chen et al., 2024; 2025; Ong et al., 2025].FrugalGPT pioneered selective delegation through LLM cascades; AutoMix uses self-verification and RouteLLM learns routers from preference data.Source: §2 · pp. 2–3

Fine-grained SLM-LLM collaboration

  • Fine-grained co-generation routes tokens, interleaves model generations across reasoning steps, or refines drafts, but black-box interactions can repeatedly transmit growing traces [Huang et al., 2026; Kim et al., 2025].The paper contrasts this with focused, self-contained intermediate queries that avoid repeatedly sending the full reasoning trace.Source: §2 · p. 3

Tool-augmented LMs and adaptive invocation

  • Adaptive tool-use methods train invocation of external tools, whereas this work's advisor is a stronger general-purpose reasoner and must provide enough benefit to justify its cost.Unlike SWE-Protégé's hard penalty on trajectories without expert invocation, this work aims for selective advisor use across general reasoning settings [Kon et al., 2026].Source: §2 · p. 3

3 PROBLEM FORMULATION

The formulation lets an SLM invoke a black-box LLM advisor during reasoning with a focused query, then continue using the advice. It seeks to maximize task performance subject to an average API budget, coupling the decision to consult with what information to send.

Problem formulation

  • The SLM can invoke the advisor once during a reasoning trajectory, and the advisor receives the query rather than the SLM's reasoning state.The SLM continues reasoning conditioned on its prior context and the advisor's response.Source: §3 · p. 3
  • The trainable SLM policy generates reasoning steps or an invocation indicator, after which the advisor takes the generated query as input and returns advice.The SLM then produces its final prediction conditioned on the response and previous context.Source: §3 · p. 3
  • The objective maximizes expected task performance subject to a predefined average API budget over the problem-answer distribution.API cost is a weighted sum of input and output tokens exchanged with the advisor.Source: §3 · pp. 3–4
  • Whether and when to consult and what query to send are mutually dependent, making their joint optimization challenging.The value of invoking the advisor depends on the query, while the best query depends on when invocation occurs.Source: §3 · p. 4

4 PILOT STUDY: CAN SLMS EFFECTIVELY USE THE ADVISOR ZERO-SHOT?

The pilot study finds that zero-shot SLMs do not reliably decide when to seek help or how to ask for it. The proposed training pipeline addresses invocation, query construction, and use of the collaboration.

Pilot study

  • The study evaluates zero-shot advisor use along two dimensions: whether to call and how to formulate an effective query.The figure caption summarizes poor alignment with difficulty, often negative calling utility, and incomplete queries.Source: §4 · p. 4, Figure 3 · p. 5
  • Zero-shot call rates do not consistently rise with problem difficulty and often move in the opposite direction across math benchmarks and coding difficulty groups.The study therefore finds that these SLMs do not reliably recognize when assistance is needed.Source: §4 · p. 4
  • Zero-shot advisor calls often fail to improve accuracy on called problems, and a substantial fraction of generated queries are not answerable as-is.Calling utility compares advisor-augmented trajectories with matched no-tool runs; query answerability is assessed by an LLM judge.Source: §4 · p. 4

Proposed training pipeline

  • The three-stage pipeline trains the SLM when to call, QMaker how to formulate budget-aware self-contained queries, and the SLM how to use the collaboration.The final stage aims to improve downstream performance while retaining selective invocation.Source: Figure 3 · p. 5

5 METHOD: LEARNING TO CALL THE ADVISOR UNDER A BUDGET

The method replaces unstable joint optimization with a stage-wise framework for selective invocation, budget-aware query construction, and integration of advisor responses. It uses coarse standalone performance to guide invocation and refines the collaboration through full interaction trajectories.

5 METHOD: LEARNING TO CALL THE ADVISOR UNDER A BUDGET

  • The stages provide a practical surrogate for jointly optimizing interdependent invocation and query policies, which the authors describe as potentially unstable.The framework comprises selective invocation, budget-aware query construction, and final integration.Source: §5 · p. 5

5.1 LEARNING SELECTIVE INVOCATION FROM COARSE SUPERVISION

  • Stage 1 trains the reasoning SLM to invoke the advisor on problems labeled for consultation from its standalone success rate, without supervising when to call.The consultation target marks low standalone success as a reason to seek assistance; invocation timing is left to the evolving reasoning state.Source: §5.1 · p. 5

5.2 BUDGET-AWARE OPTIMIZATION FOR How to call

  • Stage 2 trains Qmaker to create self-contained queries, keep advisor responses within an output-token budget, and support a correct final answer.Qmaker adds a response instruction to the content request because narrowing the request alone may not limit response length.Source: §5.2 · p. 6

5.3 INTEGRATING THE LEARNED ADVISOR PIPELINE

  • Stage 3 optimizes full interaction trajectories so the reasoning SLM reaches useful invocation states and incorporates advisor responses into subsequent reasoning.Asymmetric pre- and post-invocation rewards preserve invocation selectivity while allowing correctness-driven adaptation; after invocation, optimization uses final-answer correctness alone.Source: §5.3 · p. 6

6 EXPERIMENTS

Across math and coding benchmarks, the method forms a strong performance-cost frontier, especially at low-to-moderate API costs, and can outperform problem-level routing and fine-grained collaboration methods at comparable costs. The experiments evaluate multiple advisor budgets and compare accuracy-cost trade-offs against standalone and collaboration baselines.

6.1 EXPERIMENTAL SETUP

  • Training uses separately optimized Qwen2.5-7B-Instruct reasoning and query-generation models, with math and coding training data and a simulated Qwen3.5-35B-A3B advisor.Stage 1 estimates standalone success from 16 rollouts; stage 2 trains Qmaker for output budgets from 512 to 16,384 tokens.Source: §6.1 · pp. 6–7

6.2 RESULTS

  • At comparable API costs, the method generally outperforms learned routing and fine-grained collaboration baselines, and surpasses the Problem-level Oracle at several AMC23 operating points.Figure 4 plots accuracy-cost Pareto fronts across MATH500, AMC23, AIME25/26, and LiveCodeBench v6 as advisor budget varies.Source: Figure 4 · p. 7, §6.2 · p. 8

6.1 EXPERIMENTAL SETUP

  • Evaluation covers MATH500, AMC23, AIME25, AIME26, and LiveCodeBench v6, comparing standalone models, problem-level routing, and fine-grained collaboration methods.Accuracy uses Avg@4 on MATH500 and LiveCodeBench and Avg@8 on the other benchmarks; API cost weights advisor output tokens more heavily than input tokens.Source: §6.1 · p. 7

6.2 RESULTS

  • STEER and TRIM become less cost-efficient as task difficulty rises; repeated context retransmission is offered as the reason, while this method makes one advisor query without sending the full reasoning trace.The degradation is particularly visible for STEER on harder LiveCodeBench splits.Source: §6.2 · p. 8

7 ANALYSIS

The learned system calls more often on harder problems, adapts query type and budget instructions to available response capacity, and tends to call earlier on harder math problems. Its collaboration behavior transfers to unseen advisor families, though performance depends on how advisor reasoning is exposed to the SLM.

7.1 DOES THE LEARNED SYSTEM LEARN WHETHER AND HOW TO CALL?

  • With γ = 12, call rate rises from 0.2 on MATH500 to 0.85 on AIME, and learned policies correlate positively with difficulty while the base SLM correlates negatively.The reported Spearman correlations are ρ = 0.72 for γ = 4 and ρ = 0.75 for γ = 12, versus ρ = −0.32 for the base SLM.Source: §7.1 · p. 8
  • As the advisor budget increases, Qmaker shifts from targeted TRANSFORM queries toward FULL-TASK queries about the original task.The shift occurs without an explicit constraint on query form.Source: §7.1 · pp. 8–9
  • Under tight budgets, Qmaker instructions mainly constrain response length; larger budgets increasingly direct which information to emphasize or how to present it.At 16,384 tokens, instructions converge to nearly fixed templates, suggesting greater use of the larger response budget for test-time scaling rather than instance-specific control.Source: §7.1 · p. 9

7.2 DOES THE SLM ALSO LEARN WHEN TO CALL?

  • Harder math problems tend to elicit earlier calls, unlike the base model, whose call position is essentially uncorrelated with difficulty (ρ = −0.01).The paper interprets this as an implicit timing behavior emerging from selective whether-to-call training, without direct supervision on call position.Source: §7.2 · p. 9, Figure 6 · p. 9

7.3 TRANSFER TO OTHER ADVISOR MODELS

  • Collaboration gains generally transfer to unseen advisor families without retraining, but withholding a thinking advisor’s unfinished reasoning can substantially degrade performance.The reported transfer varies across advisor models and depends on how their outputs are exposed to the SLM.Source: §7.3 · p. 9

8 CONCLUSION

The paper reframes budget-constrained SLM–LLM collaboration as selective acquisition of targeted information from a black-box advisor, with the SLM remaining central to reasoning. Its framework improves performance–cost trade-offs across mathematical reasoning and coding, and the authors identify multi-round co-adaptation as a next step.

8 CONCLUSION

  • The framework has the SLM selectively acquire targeted information from a stronger black-box advisor rather than delegate its reasoning.Its stage-wise training addresses advisor invocation, query formulation under a response budget, and use of collaboration throughout reasoning.Source: §8 · pp. 9–10
  • Across mathematical reasoning and coding, the approach achieves favorable performance–cost trade-offs against problem-level routing and fine-grained collaboration methods.The learned behavior adapts to problem difficulty and API budget, with non-universal transfer to unseen advisors.Source: §8 · p. 10
  • Co-adapting the query policy and SLM over multiple interaction rounds is identified as a natural next step.The paper also describes its results as a step toward SLM-centered systems that query stronger models sparingly and deliberately.Source: §8 · p. 10

A LIMITATIONS

The framework’s scope is limited by advisor-specific training costs, compact-query information loss, one advisor interaction per trajectory, and an evaluation focused on advisor API monetary cost rather than end-to-end efficiency.

A LIMITATIONS

  • Maximizing performance for a specific target advisor may benefit from training with that advisor, but many black-box interactions can make such retraining costly.Upfront costs may be amortized through inference-time savings over repeated deployments, yet can limit retraining for each target advisor.Source: A LIMITATIONS · p. 15
  • Compact targeted queries can omit information needed for effective assistance when relevant context is distributed across a long trajectory.The current formulation does not explicitly optimize context selection or its input-token cost.Source: A LIMITATIONS · p. 15
  • Evaluation allows at most one advisor interaction per reasoning trajectory, leaving multi-turn and agentic collaboration unaddressed.Such settings require sequential decisions about interaction allocation, later queries, and the value of additional information relative to API cost.Source: A LIMITATIONS · p. 15
  • The cost analysis isolates monetary advisor communication costs rather than end-to-end efficiency, including local inference, orchestration, and latency.Reductions in advisor API cost need not translate proportionally into lower overall runtime cost or latency.Source: A LIMITATIONS · p. 15

B RELATIONSHIP TO CLOSELY RELATED COLLABORATION FRAMEWORKS

The related-work discussion distinguishes this framework’s token-level API-budgeted information acquisition from approaches centered on privacy, invocation frequency, computation allocation, or task specialization. Coding analyses also illustrate adaptive calling and a solve-then-consult pattern.

B RELATIONSHIP TO CLOSELY RELATED COLLABORATION FRAMEWORKS

  • The discussion frames related adaptive-interaction work as distinct mainly in its training objective, including privacy, invocation frequency, model selection, or task specialization.This framework instead targets information acquisition under a token-level API budget.Source: B RELATIONSHIP TO CLOSELY RELATED… · pp. 15–16
  • On coding tasks, the SLM calls more often on harder problems and typically generates candidate code before consulting the LLM.Figure 7 reports that call position varies only weakly with difficulty (Spearman ρ = 0.16), while the pre-call code behavior emerges over training.Source: Figure 7 · p. 16
  • Learning to Seek Help emphasizes privacy-preserving collaboration and interaction frequency, whereas this work targets token-level API cost through compact queries in reasoning-intensive tasks.Its cost model accounts for input and output tokens, which can vary with context size and advisor response length.Source: B RELATIONSHIP TO CLOSELY RELATED… · pp. 15–16
  • Router-R1 allocates computation across candidate models, while this framework fixes model roles and asks what information the SLM needs and how to request it within budget.Router-R1 interleaves reasoning with calls and aggregates responses; this work focuses on task performance subject to an overall cost budget.Source: B RELATIONSHIP TO CLOSELY RELATED… · p. 16
  • Advisor Models train a lightweight advisor to improve a black-box LLM, whereas this framework improves an SLM by selectively acquiring information from a stronger LLM.Their evaluations respectively emphasize advisor specialization and performance–cost trade-offs on general reasoning tasks.Source: B RELATIONSHIP TO CLOSELY RELATED… · p. 16

C.1 Whether AND When-to-call ANALYSIS ON CODING TASK

The analysis finds that coding calls track problem difficulty and usually follow a candidate solution; sensitive-aware query construction reduces leakage, while the token-cost comparison remains robust to pricing weights.

C.1 Whether AND When-to-call ANALYSIS ON CODING TASK

  • The SLM calls the advisor more often on harder coding problems and typically waits until it has produced a candidate code solution.The fraction of calling rollouts with code produced first exceeds 90% later under γ = 4 and stays near 100% for most training under γ = 12; the proposed self-evaluation explanation is not directly measured.Source: §C.1 · pp. 16–17

C.2 SCREENING SENSITIVE TEXT FROM ADVISOR QUERIES

  • Sensitivity-aware Qmaker reduced leakage per trajectory from 5.6% to 0.1%, with accuracy 34.8% →34.1% and API cost 5,059 →4,967.The synthetic coding setup requires retaining planted values for local use while avoiding their disclosure; the screening objective rewards queries that avoid sensitive spans and still support a correct solution.Source: §C.2 · pp. 17, 18, 20, Table 4 · p. 19

C.3 ROBUSTNESS TO INPUT–OUTPUT TOKEN COST RATIOS

  • Across considered input-output token cost ratios, the method maintains a favorable accuracy–cost trade-off on mathematical reasoning and coding benchmarks.The analysis fixes input-token weight cin = 1 and varies output-token weight cout from 1 to 16.Source: §C.3 · p. 20

C.4 COST MEASURED BY THE NUMBER OF LLM CALLS

  • With calls per slot as the cost metric, the method does not consistently outperform problem-level baselines, which can look favorable on easier tasks.The paper uses token-based cost as its primary metric because equal-cost call accounting ignores variation in response length.Source: §C.4 · p. 20

C.5 EFFECT OF STAGE-3 INTEGRATION TRAINING

Stage-3 integration training has different effects by task: it reduces math costs with little accuracy change, but improves coding accuracy while also lowering costs. The supplementary analyses also illustrate incomplete zero-shot queries.

C.5 EFFECT OF STAGE-3 INTEGRATION TRAINING

  • Stage-3 training leaves math accuracy nearly unchanged while reducing advisor calls, but substantially improves coding accuracy and also lowers call rates.The coding accuracy gain is particularly pronounced at larger advisor budgets, while its call-rate reduction is smaller than math’s.Source: §C.5 · pp. 20–21, Figure 9 · p. 21
  • The authors hypothesize that coding benefits more because advisor guidance must be turned into executable, task-compatible code, whereas math advice may be close to the final answer.This is offered as an explanation for the different post-invocation bottlenecks.Source: §C.5 · p. 21
  • After integration training, math call rates fall by approximately 35–40% on easier problems but only about 3% on the hardest problems.This pattern suggests that training removes marginal consultations on problems the SLM can solve independently while largely preserving calls on harder problems.Source: Figure 10 · p. 21, §C.5 · pp. 21–22

C.6 MORE DETAIL ON HOW TO CALL ANALYSIS ON ZERO-SHOT SLMS

  • Zero-shot queries can ask about an intermediate quantity while omitting the problem context needed for the advisor to answer independently.One example asks for the pen’s cost without stating that cost in the query.Source: §C.6 · p. 22

Qwen, MATH500

  • In a Qwen MATH500 example, the query asks for the total score without including the scores needed to calculate it.Another example asks whether an array can be made zero without providing the underlying problem.Source: Qwen, MATH500 · pp. 22–23

D.1 TRAINING

The training appendix describes optimization and trajectory handling, then specifies decoding, checkpoint selection, and task-specific evaluation procedures.

D.1 TRAINING

  • Training uses GRPO with eight rollouts per prompt; gradient masking replaces Qmaker-rewritten queries in trajectories and excludes those query tokens from the SLM objective.Stage-1 uses batch size 256 and other settings use 128; stage-3 uses λ = 0.2.Source: §D.1 · p. 23

D.2 INFERENCE & EVALUATION

  • Inference uses greedy decoding for advisor responses, selects checkpoints on held-out validation data, and evaluates math answers and generated code with task-specific checks.Math answers are extracted from boxed outputs and checked with VeRL; code is assessed with official test codes and the guru dataset executor.Source: §D.2 · p. 23

E BASELINE DETAILS

The section specifies baseline implementations and the prompt, query-generation, advisor, and judging procedures used in the experiments.

E BASELINE DETAILS

  • Baseline routing and cascading evaluations use the same task-specific training data, with routing and escalation decisions evaluated under their respective procedures.The implementations include threshold-based escalation, verifier-based routing, and a three-class router; operating points are varied by sweeping thresholds.Source: E BASELINE DETAILS · pp. 23–24
  • Raising TRIM-Thr’s threshold from 0.3 to 0.9 raises advisor cost roughly 3.2–3.7×, while the input-to-output token ratio reaches up to 39×.Repeatedly resending the accepted prefix drives input costs; STEER’s cost also includes a large input-token component.Source: Figure 11 · p. 24, E BASELINE DETAILS · p. 25, Figure 12 · p. 25

F.1 SLM PROMPTS

  • SLM prompts permit focused advisor queries for intermediate facts or sub-results, while solo prompts remove advisor instructions and task prompts specify the required final-answer format.Math answers are boxed; coding answers must be complete Python programs.Source: §F.1 · p. 30

F.2 QMAKER PROMPT

  • Qmaker analyzes where the student is stuck, then asks a self-contained question targeting the cheapest missing information and gives a small but sufficient reply-budget instruction.If the student has made no progress, it asks for a rough solution plan rather than inventing a reached subproblem.Source: §F.2 · p. 31

F.3 PROMPT FOR LLM

  • The advisor receives only the question and format instruction, while a screening prompt checks whether the question is independently answerable and the reply follows the requested form.The prompt section also specifies that the training judge uses the target advisor model in no-thinking mode.Source: §F.3 · p. 32

F.4 TOOL DESCRIPTION

  • The ask-advisor tool is defined as one focused, self-contained question containing all context the advisor needs, because the advisor sees no other problem context.Source: §F.4 · p. 33

F.5 JUDGE PROMPT

  • The query judge classifies each advisor question against its original problem as incomplete, transformed, hint-bearing, or a full-task restatement.Checks are ordered: incompleteness, transformation, then added information.Source: §F.5 · pp. 33–34

Qmaker prompt

  • The privacy-filter prompt replaces sensitive values with consistent placeholders while preserving the task text and its constraints for external processing.Source: Qmaker prompt · pp. 34–35

G GENERATION EXAMPLES

The generation examples illustrate SLM–advisor collaboration across different communication budgets and query granularities, from targeted intermediate help to full-task assistance. They show the SLM integrating advisor responses in varied ways, including completing solutions itself and, in one coding example, failing to incorporate the suggested strategy.

G GENERATION EXAMPLES

  • For the die problem, the advisor supplies a probability decomposition, while the SLM completes the algebra, uses the inequality to choose between roots, and finishes the solution.The example shows a full-task request yielding intermediate scaffolding rather than a completed solution.Source: G GENERATION EXAMPLES · p. 36
  • For the trapezoid problem, the SLM derives the geometric model and asks the advisor only for the maximizing value, then resumes and completes the solution.The advisor supplies the critical value of a; the SLM substitutes it into its own height and area formulas.Source: G GENERATION EXAMPLES · p. 38
  • For the positive-real equation, the SLM asks for a useful lemma, and the advisor identifies AM-GM and its equality conditions for the SLM to finish the argument.The advisor provides the relevant lower bounds and simultaneous equality conditions, after which the SLM carries out the remainder.Source: G GENERATION EXAMPLES · pp. 39–40
  • For the triangle problem, the SLM asks only how to infer the leg lengths from the altitude; the advisor gives the intermediate geometric calculation, and the SLM completes the area solution.The example reports leg length 8 and area 32.Source: G GENERATION EXAMPLES · pp. 40–41
  • 265 is the final m + n after the advisor counts 294 valid roll sequences and the SLM converts that count into the requested probability.The QMaker isolates the combinatorial counting step rather than resending the full task.Source: G GENERATION EXAMPLES · p. 41
  • 504 is the final r² + s² after the advisor continues from the SLM-derived relation r + s = 24.The QMaker includes the intermediate result in the request, so the advisor supplies the remaining geometric relation.Source: G GENERATION EXAMPLES · p. 42
  • For the palindromic-cube task, the advisor supplies an enumeration strategy examining O(N^1/3) candidate cubes, and the SLM integrates it into the program interface.The request extracts the algorithmic search step into a self-contained query.Source: G GENERATION EXAMPLES · pp. 43–44
  • 19 is the final answer after the advisor is cut off before completing a substitution and the SLM resumes from the setup to finish the algebra.The advisor supplies the structural reduction; the SLM extracts the requested value.Source: G GENERATION EXAMPLES · p. 45
  • 7 is the final distance after the advisor redirects an incorrect cross-product approach to the point-to-line formula and the SLM completes the numerical computation.The advisor recommends using a connecting vector and a single direction vector to find the perpendicular distance.Source: G GENERATION EXAMPLES · p. 47

Gear example

  • In the gear example, the QMaker restates the original problem rather than isolating a subproblem, and the advisor solves it end to end.The SLM performs no further derivation after the call.Source: G GENERATION EXAMPLES · p. 49
  • The gear example’s efficiency gain comes solely from the budget instruction, as the SLM merely repeats the advisor’s conclusion.Source: G GENERATION EXAMPLES · p. 49

LiveCodeBench v6, Problem 236

  • For LiveCodeBench v6 Problem 236, the advisor describes splitting car and train shortest paths at one switch city, but the SLM uses Floyd–Warshall instead of Dijkstra.The paper presents this as an integration failure.Source: G GENERATION EXAMPLES · pp. 50–51
Loading 2610.01236v1…