In this work, we evaluate a simple inference-time scaling approach based on turn-level best-of-N sampling (\method) for large language model (LLM) agents on complex, long-horizon tasks. We instantiate this using a generator-selector framework with two LLMs; at each turn, a generator model generates N candidate actions and a selector model selects one of them, which is then executed in the environment. This paper is closely related to the work of \cite{zainullina2025guided} who used critic models for guided search at inference time. Different from their work, we evaluate if off-the-shelf, open-weight LLMs can be effective at comparing different candidate actions directly. Experiments on long-horizon terminal tasks show that \method can lead to significant performance improvements, both in terms of accuracy (5--10%) and consistency across repeated attempts. Analysis of agent trajectories reveal a shift in agent behaviour towards desirable patterns such as reduction in number of attempts to solve the task, improved task instruction following, debugging and testing.
Figures & tables
Figure 1: An illustration of the Turn-BoN method. At each turn the generator proposes N candidate actions; the selector picks the “best” action, which is executed in the environment, and the resulting observation (along with the action) is appended to the context for the next turn.
Figure 2: Pass rates under turn-level best-of-N sampling on terminal-bench v2.1 (89 tasks) for two generator models under different selector-model configurations. Subfigures ( 2(a) ) and ( 2(c) ) plot mean pass rate (pass@1 averaged over 4 trials); subfigures ( 2(b) ) and ( 2(d) ) show pass@k curve for k∈{1,2,3,4} .
Figure 3: Efficiency and consistency of Turn-BoN sampling on Terminal-Bench v2.1 (89 tasks) for two generator models under different selector-model configurations. Subfigures ( 3(a) ) and ( 3(c) ) plot the distribution of turns taken to solve a task averaged over all 4 trials; subfigures ( 3(b) ) and ( 3(d) ) plot consistency solve rate curves — the percentage of tasks correctly solved in all k out of 4 trials.
Generator
Selector
N
Average Turns
Generator Tokens
Selector Tokens
Total Tokens (vs. base)
K2-Horizon 375b-a23b
Baseline
1
69.5
72K
–
1.0 ×
[2pt/2pt]
Kimi-K3
4
41.0
196K
67K
3.6 ×
8
33.9
334K
69K
5.6 ×
[2pt/2pt]
DeepSeek V4.1 Flash
4
41.2
197K
85K
3.9 ×
8
36.8
346K
107K
6.3 ×
Qwen3.6 35b-a3b
Baseline
1
64.9
50K
–
1.0 ×
Table 1: Cost of per-turn BoN on Terminal-Bench v2.1 (89 tasks), averaged over four runs. – marks the baseline (i.e., no selectors). All columns are per-attempt totals, averaged over attempts: Generator Tokens counts the generator’s output across all N candidates, Selector Tokens the selector’s output, and Total Tokens the ratio of (generator + selector) output to the corresponding baseline (K = thousand tokens).
Figure 4: Preference of selector models across eight behaviours on Terminal-Bench 2.1 — refer to Appendix 9 for the definition of each behaviour. Within each panel, x-axis groups by the generator model and number of candidates N∈{4,8} . Solid lines ( ): denote the percentage of turns where the selector’s pick shows a particular behaviour. Dashed lines ( ): shows the expected percentage of turns with a behaviour under random selection from N candidates. The gap between the two measures preference of the selector model for a behaviour. The gap for all behaviours is statistically significant by paired bootstrap over tasks (10,000 resamples, p<0.01 in every setting), except “ loops on a command ” behaviour with K2-Horizon-375B as the generator model.
Figure 5: Reasoning tokens per turn (top): the number of reasoning tokens associated with a tool call, counted with the generator’s tokenizer. Command characters per turn (middle): the number of characters in the shell commands of a response. Except for the gap between reasoning tokens of the selector picked action and the baseline for Qwen3.6, all other differences are statistically significant using paired bootstrap over tasks (10,000 resamples, p<0.01 in every setting).
Failed attempts
Generator
Setting
Pass ↑
Wrong submission ↓
Out of context ↓
Time limit ↓
Agent Error ↓
K2-Horizon
Baseline
73.3
20.2
0 4.2
0 0.0
0 2.2
[2pt/2pt]
N=4
77.9
19.5
0 1.1
0 0.4
0 1.0
N=8
76.7
20.9
0 0.1
0 1.5
0 0.7
Qwen3.6
Baseline
47.5
44.9
0 5.3
0 2.0
0 0.3
[2pt/2pt]
N=4
52.8
38.5
0 6.0
0 2.7
0 0.0
Table 2: How attempts end on Terminal-Bench 2.1 tasks under turn BoN sampling (% of attempts over four trials of 89 tasks each). For BoN sampling, we pool trials among the two selector models and show average results. Bold indicates best value in each column for each generator. See Appendix 9.2 for a definition of each outcome.
K2-Horizon
Qwen3.6
Δ
Δ
Behavior
Base
N=4
N=8
Base
N=4
N=8
Looping
24%
−14 ∗
−16 ∗
42%
−16 ∗
−18 ∗
Incomplete implementation
14%
−5
−6
53%
−13
−20 ∗
Insufficient testing
11%
+2
−4
49%
−19 ∗
−19 ∗
Ignored instructions
17%
−9 ∗
−4
36%
−12
−16 ∗
Table 3: Behaviours annotated by the LLM judge on 36 hard tasks (360 total trajectories). Refer to Appendix Table 6 for the definition of each behaviour). The top 13 behaviours are from Wang et al. (2026b) and the bottom 15 are the ones we added. Base : the share of trajectories from baseline run flagged by LLM judge for each behaviour, so lower is better. Δ : the difference between flagged trajectories from BoN sampling and the baseline run, pooled over the two selector models. Green is better and red is worse. The superscript ∗ denotes statistical significance at p<0.05 (paired bootstrap over tasks, 10,000 resamples). Looping behaviour drops substantially for BoN with both generator models. In addition, for Qwen3.6, the agent also tests its work more thoroughly, guided by the selector model.
Figure 6: The two-message chat request sent to the selector at every turn: a fixed system prompt and a user message assembled from the full task-and-conversation transcript, the N candidate next actions (rendered without their private reasoning), and the required JSON response schema. The selector returns a single JSON object whose selected_index names the chosen candidate.
Behaviour
Meaning
Example
Edits a file
Changes a file in the workspace. Writes into /tmp by redirect or Python open() do not count.
sed -i ’s/x/y/’ app.py cat > solve.py <<EOF
Tests its last edit
Runs code while the latest edit is untested, i.e., no turn since the edit has run or tested anything.
python solve.py right after editing solve.py
Runs a test or check
Runs a test, checker, or comparison against expected output.
pytest tests/ diff -u out.txt expected.txt
File operations
Moves, copies, deletes, or archives files, changes permissions, or stops processes.
cp out.txt /app/ chmod +x run.sh
Installs a package
Installs software with a package manager.
pip install numpy apt-get install -y jq
Only reads or inspects
Every command is a known read or inspect command, so nothing is written, run, checked, installed, or submitted.
ls /app cat README.md
Table 4: Definitions and example commands for the eight behaviours in Figure 4 , listed in the same order as in the figure.
The sandbox stopped responding or failed, the verifier timed out, or the reward file was missing
Agent error
Table 5: How each attempt is assigned its ending in Table 2 . The harness log records the exception that stopped each attempt, or none if the agent ended on its own. Only an attempt without an exception can pass, in which case the verifier decides its ending.
Figure 7: A failed attempt. Kimi-K3 prefers one of the two candidates that run their script over five that follow the specified format but do not run it, and later accepts a submission because the agent’s own check passes.
Figure 8: Both selectors move K2-Horizon from analysis to the deliverable. (a) Six of the eight candidates keep analyzing the binary, and Kimi-K3 picks the one that drafts the required program, which no baseline run writes. (b) Deepseek-v4.1-Flash picks the candidate that writes the required file at turn 28, while the baselines first write it 38 to 90 turns later.
Figure 9: Both selectors hold Qwen3.6 to the task’s requirements. (a) Two candidates write the script, and Kimi-K3 rejects the one whose layout breaks the task’s limit, which three of the four baseline runs never check. (b) Five candidates dismiss a failing test and move on, as three baseline runs do, and Deepseek-v4.1-Flash picks one that reads the failing code.
Figure 10: Two patterns that recur across many turns. (a) Five of the eight candidates rerun a command that has just failed, and Kimi-K3 picks one that asks why it failed. (b) All eight candidates write the next file and three also check the configuration. Deepseek-v4.1-Flash picks a checker, and the check exposes the bug from the previous edit.
Behaviour
What the judge flags
From Wang et al. (2026b)
Looping
Repeated the same failed action ≥3 times without changing strategy.
Incomplete implementation
Delivered incomplete or nonfunctional code.
Insufficient testing
Skipped reasonable validation or test runs.
Ignored instructions
Agent ignored explicit instructions.
Insufficient debugging
Ignored or failed to debug observed failures.
Table 6: All 28 rubrics that the judge annotates for each attempt. For each rubric, the judge answers yes or no to the description in the second column, which is a shortened version of the definition the judge receives. The 13 rubrics at the top come from Wang et al. (2026b) , and the 15 at the bottom are ours. A rubric is flagged only when the judge finds evidence of it, and we report how often each one is flagged, so lower is better. Rows follow the order of Table 3 .
K2-Horizon
Qwen3.6
N
Selector
Passed
Reward hacking
Passed
Reward hacking
Baseline
261
2
169
2
4
Kimi-K3
278
3
189
3
4
Deepseek-v4.1-Flash
277
1
187
2
8
Kimi-K3
275
1
207
0
8
Deepseek-v4.1-Flash
271
2
186
1
Table 7: Reward hacking on Terminal-Bench 2.1. Passed : passing attempts over four runs of 89 tasks. Reward hacking : passing attempts that the agentic judge labels as reward hacking under the AA setup. No BoN setting differs significantly from its baseline ( p>0.2 in every setting; paired bootstrap over tasks, 10,000 resamples).
Inference-time scaling studies how extra computation during deployment can improve model performance through search, sampling, verification, or adaptive reasoning.
Long-horizon LLM agents interact with their environments through complete assistant turns while generating each action token by token. We observe that critic values vary primarily across turns, motivating optimization anchored at turns with finer credit allocation among tokens. We propose Multiscale Policy Optimization (MPO), combining Multiscale Advantage Estimation (MAE) and turn-level importance sampling to align credit assignment and policy updates at the turn scale. Extensive experiments across search, tool-use, and automation tasks with 4B and 30B-A3B models demonstrate consistent gains over strong RL baselines.
Tao Ren, Hui Yang, Jia Deng +16
Peking University · IQuest Research · Tsinghua University +3
Large language model (LLM) agents often rely on long sequences of low-level textual actions, resulting in large effective decision horizons and high inference cost. While prior work has focused on improving inference efficiency through system-level optimizations or prompt engineering, we argue that a key bottleneck lies in the representation of the action space itself. We propose Latent Action Reparameterization (LAR), a framework that learns a compact latent action space in which each latent action corresponds to a multi-step semantic behavior. By reparameterizing agent actions into latent units, LAR enables decision making over a shorter effective horizon while preserving the expressiveness of the original action space. Unlike hand-crafted macros or hierarchical controllers, latent actions are learned from agent trajectories and integrated directly into the model, allowing both planning and execution to operate over abstract action representations. Across a range of LLM-based agent benchmarks, LAR significantly reduces the effective action horizon and improves inference efficiency under fixed compute budgets. As a consequence, our approach achieves substantial reductions in action tokens and corresponding wall-clock inference time, while maintaining or improving task success rates. These results suggest that action representation learning is a critical and underexplored factor in scaling efficient LLM agent inference, complementary to advances in model architecture and hardware.
Wenhao Huang, Qingwen Zeng, Qiyue Chen +11
Université de Montréal · Mila - Quebec AI Institute · The University of Sydney +7
Inference-time compute scaling has emerged as a powerful technique for improving the reliability of large language model (LLM) agents, but existing methods apply compute uniformly: every decision step receives the same budget regardless of its difficulty. We introduce TrACE (Trajectorical Adaptive Compute via agrEement), a training-free controller that allocates LLM calls adaptively across agent timesteps by measuring inter-rollout action agreement. At each step, TrACE samples a small set of candidate next actions and measures how consistently the model commits to the same action. High agreement signals an easy decision; the controller commits immediately. Low agreement signals uncertainty; the controller samples additional rollouts up to a configurable cap before committing to the plurality action. No learned components, no external verifier, and no human labels are required. We evaluate TrACE against greedy decoding and fixed-budget self-consistency (SC-4, SC-8) on two benchmarks spanning single-step reasoning (GSM8K, n=50) and multi-step household navigation (MiniHouse, n=30), using a Qwen 2.5 3B Instruct model running on CPU. TrACE-4 matches SC-4 accuracy while using 33% fewer LLM calls on GSM8K and 39% fewer on MiniHouse. TrACE-8 matches SC-8 accuracy with 55% fewer calls on GSM8K and 65% fewer on MiniHouse. We further show that inter-rollout agreement is a reliable signal of step-level success, validating the core hypothesis that the model's own output consistency encodes difficulty information that can be exploited without training. TrACE is the first training-free, per-timestep adaptive-compute controller for LLM agents to be evaluated on multi-step sequential decision tasks.