AgentBaton: Efficient Model Collaboration in Agentic Tasks

© 2026 NVIDIA. All rights reserved.

Introduction

Language-model agents tackle long-horizon tasks through repeated interactions with their environments, using tools, observing feedback, and revising their actions over multiple steps [1, 2]. Reliable and state-of-the-art performance is often achieved by expensive capable models available through cloud providers [3, 4], whose repeated invocation can incur substantial inference costs. Meanwhile, alternative efficient models, including lower-tier cloud models [5] and smaller open-weight models [6] deployable on local hardware such as NVIDIA DGX Spark and Apple Mac Studio, offer much lower costs but often achieve lower task accuracy when used alone.

Prior work on combining heterogeneous models has largely focused on query-level routing and cascading for individual requests [7, 8, 9, 10]. However, assigning a task to a model solely based on its initial query falls short in long-horizon agentic tasks. In these environments, actions alter the workspace and yield dynamic feedback, meaning the actual capabilities required evolve across turns rather than being determined upfront. This necessitates collaboration throughout the task trajectory. For example, a capable model might draft an initial plan or produce key intermediate results for an efficient model to build upon. Conversely, an efficient model could handle preliminary steps like information gathering before handing off to a capable model for more demanding steps. Both directions are intuitively plausible, leaving open the question of which paradigm best balances accuracy and cost.

Beyond the handoff direction, transferring interaction history introduces another trade-off. Directly including the full history in context ensures the receiving model understand prior progress and reuse existing ideas, but increases the prefill sequence length at handoff and, while that history is retained, the input sequence length in subsequent turns. Moreover, exposing the receiving model to its predecessor’s reasoning and actions may bias its subsequent decisions, potentially carrying forward unproductive assumptions or strategies.

To understand how handoff direction and context transfer affect the accuracy–cost trade-off, we evaluate both handoff directions across multiple capable–efficient model pairs on two agentic benchmarks, Terminal Bench 2.1 [11] and DeepSWE v1.1 [12]. For each direction, we compare two context transfer methods: directly including prior interaction history in the receiving model’s context, or providing structured execution history through a log file that the receiving model can inspect as needed using standard commands such as cat, grep, and sed. In both cases, the receiving model continues from the workspace produced by its predecessor.

The experiments reveal an asymmetry between the two handoff directions. Efficient-to-capable handoffs generally underperform capable-only execution, sometimes even at higher cost, despite benefiting from logfile transfer over in-context transfer. In contrast, capable-to-efficient handoffs at suitable stages of task progress can largely preserve capable-only accuracy while substantially reducing cost, although the preferred context-transfer method varies across models. These findings suggest that the progress established by a capable model can enable an efficient model to complete tasks that it struggles to solve independently. This one-way dependency also implies that per-turn routing may be impractical, as frequent switching risks accumulating trajectory errors that the capable model must repeatedly expend effort to recover from.

Our case studies help characterize these handoff opportunities: the capable model has often produced a substantive implementation or artifact and obtained task-relevant feedback, leaving primarily localized repair, validation, or finalization. Motivated by these recurring patterns, we introduce AgentBaton, a lightweight detector trained to identify suitable handoff points from execution history. The capable model begins the task, and AgentBaton evaluates progress after each turn; once it predicts a suitable handoff point, the efficient model takes over and continues until termination. Across 11 model pairs and two benchmarks, AgentBaton reduces API costs by 65.9% on average while largely preserving task accuracy, with gains of up to 8.8 percentage points over capable-only execution. As shown in Figure 1, AgentBaton extends the empirical accuracy–cost Pareto frontier beyond the evaluated single-model configurations across reasoning-effort settings.

To sum up, we make three main contributions:

• We systematically analyze how handoff direction, context transfer, and task progress affect the accuracy–cost trade-offs of model collaboration within long-horizon agentic tasks.

• We introduce AgentBaton, a lightweight learned detector that identifies suitable capable-to-efficient handoff points online based on recurring patterns in agent execution.

• We evaluate AgentBaton across multiple model pairs and two agentic benchmarks, demonstrating

substantial API cost reductions with largely preserved accuracy and improved accuracy–cost trade-offs across reasoning-effort settings.

Experimental Design

Model handoff and context transfer. For simplicity and controlled analysis, we study model collaboration through one-time handoffs, where an initial model begins a task and transfers control to another after several turns. The receiving model then continues until termination, without switching back to the source model. The total cost of a handoff run is the sum of the source model’s cost before handoff and the receiving model’s cost afterward. The receiving model inherits the workspace state, including all file modifications and artifacts produced by the source model. To transfer the accompanying execution history, we consider two approaches. 1) In-context transfer directly includes the pre-handoff conversation in the receiving model’s context, preserving message roles, assistant responses, tool calls, and their corresponding tool outputs. When the source model uses a different response format, we convert its visible text and tool interactions into the receiving model’s chat format. When the source model does not expose its chain-of-thought, we omit the reasoning_content field rather than reconstructing unavailable reasoning. 2) Logfile transfer instead writes the history to a .jsonl file inside the task environment, where the receiving model can inspect it using its tools. The file contains one JSON record per source-model turn, ordered chronologically. Each record includes the turn index, the original model response, and a list of actions. Each action records the original command and the tool output, including its return code, standard output, and standard error. Under Logfile transfer, the receiving model starts a new agent session with the original task instruction, the logfile path, and a textual schema describing the fields and structure of the log. The instruction specifies that records are ordered chronologically and directs the model to inspect the final records first to understand the latest task state. Figure 2 illustrates the handoff process and the two context-transfer approaches.

Benchmarks, Models, Harness and Settings We evaluate on Terminal-Bench 2.1 [11] and DeepSWE v1.1 [12]. Terminal-Bench covers diverse terminal-based workflows, including software engineering, scientific computing, and system administration, whereas DeepSWE focuses on challenging, long-horizon software engineering tasks in active open-source repositories, requiring substantial implementation work evaluated using program-based verifiers. For the analysis experiments, we primarily use GPT-5.6 Sol [13], Kimi K3 [14], and GLM-5.3 [15] as capable models, with reasoning effort set to max. We use Qwen3.8-27B [6] as the efficient model, with reasoning effort set to xhigh, as it offers strong coding and reasoning capabilities at a scale suitable for deployment on local workstations or PCs. We adopt mini-SWE-agent v2.4.0 [16], a minimal yet effective scaffold with a shell-based action interface and a linear interaction history. Its simple agent loop provides a common interface for comparing models and inspecting their trajectories, while capturing the basic interaction pattern of more complex harnesses. The scaffold is also used in official evaluations of frontier foundation models [17, 18, 15, 14]. For both benchmarks, we impose a two-hour agent execution timeout per task and allow up to 16K newly generated tokens per turn. We use the model providers’ recommended sampling parameters where available and otherwise retain the serving defaults. For cloud models, we calculate cost from the token usage reported for each request and the provider’s official token pricing, while assigning zero cost to locally deployable models under our accounting convention.

Understanding Model Handoffs in Agentic Tasks

Handoff Direction and Context Transfer

We first run each of the three capable models and the efficient model independently to obtain single-model baselines and execution trajectories. For a given trajectory, we replay its recorded actions in a task container to restore the workspace state after a selected turn, allowing a receiving model to continue from that checkpoint. We select handoff points at 30% and 75% of the source model’s completed baseline trajectory to represent relatively early and late stages of execution. At each checkpoint, we evaluate both capable-to-efficient and efficient-to-capable handoffs using the in-context and logfile transfer methods described in § 2.

The results in Table 1 show that the effect of context transfer depends on the handoff direction. For efficient-to-capable handoffs, logfile transfer generally matches or exceeds the accuracy of in-context transfer, while significantly reducing the cost in most cases. In the reverse direction, in-context transfer is more effective for GLM 5.3 and Kimi K3, achieving higher accuracy in most cases. GPT-5.6 Sol yields a mixed result: logfile transfer has higher accuracy at 30% on both benchmarks and at 75% on DeepSWE v1.1, whereas in-context transfer performs better at 75% on Terminal-Bench. We hypothesize that this difference may partly stem from the availability of reasoning traces: unlike GLM-5.3 and Kimi K3, GPT-5.6 Sol does not expose its full chain-of-thought, which may limit the reasoning context available to the receiving model under in-context transfer. Thus, we conclude that logfile transfer is more favorable for efficient-to-capable handoffs, while the preferred format for capable-to-efficient handoffs depends on the source model and checkpoint.

Handoff	Terminal-Bench 2.1 30% In-context	Terminal-Bench 2.1 30% Logfile	Terminal-Bench 2.1 75% In-context	Terminal-Bench 2.1 75% Logfile	DeepSWE v1.1 30% In-context	DeepSWE v1.1 30% Logfile	DeepSWE v1.1 75% In-context	DeepSWE v1.1 75% Logfile
Efficient → Capable
Qwen → GLM	83.2 / 1.32	83.2 / 1.22	68.5 / 1.19	79.8 / 1.26	51.3 / 4.04	62.8 / 2.93	38.9 / 2.61	53.1 / 1.87
Qwen → Kimi	79.8 / 2.91	84.3 / 1.58	70.8 / 3.31	79.8 / 1.30	47.8 / 7.77	62.0 / 4.45	37.2 / 5.76	50.4 / 2.52
Qwen → GPT	83.2 / 1.19	89.9 / 0.87	82.0 / 2.15	85.4 / 0.85	73.5 / 6.20	70.8 / 5.00	58.4 / 8.84	67.3 / 5.74
Capable → Efficient
GLM → Qwen	77.5 / 0.15	76.4 / 0.15	83.2 / 0.64	79.8 / 0.64	61.1 / 0.56	54.9 / 0.56	62.8 / 2.07	59.3 / 2.07
Kimi → Qwen	79.8 / 0.33	75.3 / 0.33	87.6 / 1.06	82.0 / 1.06	69.9 / 1.11	56.6 / 1.11	76.1 / 3.34	76.1 / 3.34
GPT → Qwen	64.0 / 0.24	69.7 / 0.24	83.2 / 0.70	77.5 / 0.70	54.9 / 1.25	56.6 / 1.25	66.4 / 3.65	67.3 / 3.65

When Does Handoff Preserve Accuracy?

We next ask at what stages of task progress a handoff can preserve capable-only accuracy while substantially reducing cost. Building on the context-transfer comparison, we evaluate both handoff directions at 15%, 30%, 45%, 60%, 75%, and 90% of the source model’s completed baseline trajectory. We use logfile transfer for efficient-to-capable handoffs and in-context transfer for GLM-5.3 and Kimi K3 handing off to Qwen 3.8 27B.

For GPT-5.6 Sol handing off to Qwen 3.8 27B, we use logfile transfer, which achieves higher accuracy in most comparisons in § 3.1. Figure 3 reports DeepSWE v1.1 accuracy and mean cost per task. The 0% endpoint corresponds to running the receiving model alone. Terminal-Bench 2.1 results are reported in Appendix § 8.

Efficient-to-capable handoffs. Figure 3(a) and Figure 3(b) show that starting with the efficient model does not consistently preserve capable-only accuracy while substantially reducing cost. On DeepSWE v1.1, later handoffs to GLM-5.3 and Kimi K3 generally reduce cost but also lose accuracy. Handoffs to GPT-5.6 Sol can retain comparable accuracy, yet offer limited savings: at 30% progress, accuracy reaches 70.80%, compared with 68.10% for GPT-5.6 Sol alone, while cost falls by only 6.1%. Thus, delaying the capable model’s involvement does not provide a consistent way to achieve substantial savings without sacrificing accuracy. These results also imply that fine-grained or per-turn routing may face steep hurdles, as frequent switching can amplify coordination and recovery overheads.

Capable-to-efficient handoffs. Figure 3(c) and Figure 3(d) show more favorable trade-offs in the reverse direction: at suitable stages of progress, capable-to-efficient handoffs can approach capable-only accuracy while substantially reducing cost. With Kimi K3 as the source model, handing off at 45% reaches 72.57% accuracy, close to the capable-only baseline of 73.45%, while reducing cost by 61.5%. With GPT-5.6 Sol, logfile transfer at 60% reaches 67.26% accuracy versus 68.10% for this capable model alone, with 47.9% lower cost. GLM-5.3 can hand off at 30% and attain 61.1% accuracy, matching its capable-only baseline, while reducing cost by 82.4%. These results suggest that progress made by a capable model can enable an efficient model to complete the remaining work.

Patterns of Successful Handoffs

The checkpoint experiments show that handoff timing matters, but do not explain what task progress enables an efficient model to take over successfully. To investigate this question, we analyze trajectories where Qwen 3.8 27B fails after an earlier handoff but succeeds after the next one, comparing the capable model’s intervening actions and tool feedback to identify recurring patterns. Figure 4 presents three illustrative cases across two benchmarks and two capable models, all of which fail under Qwen-only execution and succeed under capable-only execution. The key changes include (a) fixing a quoted-path handling issue, (b) validating the coordinate transformation, and (c) localizing an encoding fault that helps Qwen reimplement a still-incorrect encoder.

The analysis suggests three recurring signs of handoff readiness: 1) a substantive implementation, runnable prototype, or task-required artifact is available; 2) actual execution, testing, or inspection has provided task-relevant feedback; and 3) the remaining work has become more focused, often involving localized diagnosis, repair, validation, or final-output preparation. Crucially, this feedback need not be 100% positive; even a failed execution is informative if it narrows down the unresolved problem, as demonstrated in the compressor case. These observations suggest that readiness depends on both the progress already established and the nature of the remaining work, rather than elapsed turns alone.

AgentBaton

The patterns identified in § 3.3 motivate a natural question: can we train a lightweight model to recognize suitable handoff points during a capable model’s execution? Such a detector would enable the system to transfer control to an efficient model when the observed progress indicates that it is ready to take over.

Prompt-based handoff

Before training a detector, we test whether the capable model can decide when to hand off through prompting alone. We prompt the capable model to transfer control when it recognizes the handoff-readiness patterns identified in § 3.3. Table 2 shows that this behavior varies substantially across models: Kimi K3 never hands off, while GLM-5.3 does so on only 6 of 113 tasks. Thus, a handoff instruction does not reliably induce models to relinquish control, limiting opportunities to reduce capable-model usage. GPT-5.6 Sol does hand off on every task, but its mean cost remains $3.75, compared with $5.32 for capable-only execution. Even consistent handoff behavior therefore does not ensure a favorable accuracy–cost trade-off. These results motivate a dedicated detector that explicitly evaluates handoff readiness, rather than relying on the executing model to decide when to transfer control.

Capable model	Handoffs	Acc. (%)	Cost ($)
GLM-5.3	6/113	54.9	2.54
Kimi K3	0/113	64.6	4.89
GPT-5.6 Sol	113/113	62.8	3.75

Training AgentBaton

Data collection and annotation. We collect agent trajectories on a randomly sampled subset of 2,000 tasks from SWE-rebench V2 [19]. For each task, we randomly select two distinct capable models from a pool of five: GPT-6 Astra [20], GPT-5.6 Sol [13], Claude Opus 5 [18], Kimi K3 [14], and GLM-5.3 [15]. We use medium reasoning effort for GPT-6 Astra and max for the other models. Each selected model independently attempts the task using mini-swe-agent, yielding 4,000 trajectories. We use Codex² to annotate suitable handoff points in these trajectories. The annotation criteria generally follow the qualitative patterns identified in § 3.3: a substantive implementation or task-required artifact exists, task-relevant execution or inspection provides concrete feedback, and the remaining work is primarily localized diagnosis, repair, or validation. Codex reviews each trajectory retrospectively to better locate the earliest suitable handoff point. Trajectories without a clear transition receive a separate no-clear-handoff label. Appendix § 9 provides the annotation protocol, including evidence restrictions and turn indexing.

Training details. We initialize AgentBaton from Qwen 3.5 2B [21] for low-overhead detection at each turn.³ The input is a multi-turn conversation consisting of a system instruction that guides pattern detection, the original task, and the capable model’s actions and tool observations, interleaved with previous handoff decisions. For a trajectory whose annotated handoff occurs at turn $h$, we supervise every decision up to and including turn $h$: the model is trained to output the JSON object {"judgement":"HANDOFF_NOT_READY"} for turns before $h$ and {"judgement":"HANDOFF_READY"} at turn $h$. We also train on all subsequent turns. Each such turn yields an additional example in which the target response for the current turn is set to {"judgement":"HANDOFF_READY"}. All preceding decision responses are set to {"judgement":"HANDOFF_NOT_READY"} and excluded from the loss calculation. These additional positive examples help balance the decision labels and simulate missed handoff opportunities, encouraging the detector to trigger a handoff at a later turn even if it previously failed to do so. We train for two epochs with a maximum sequence length of 32K tokens. We split and truncate overlong sequences and pack shorter ones together to reduce padding and improve computational efficiency. We train with NeMo Automodel [23] on 16 NVIDIA H100 GPUs using FSDP2, bfloat16 precision, and activation checkpointing. The global batch size is 16 packed sequences, with one sequence per GPU. We use AdamW with a learning rate of $10^{-5}$, $\beta_1 = 0.9$, $\beta_2 = 0.95$, $\epsilon= 10^{-8}$, and weight decay 0.1.

Online Handoff Detection At inference time, the capable model begins the task. After each turn, AgentBaton processes the updated trajectory and predicts whether a suitable handoff point has been reached. When the context exceeds this limit, we discard the oldest half of the historical turns while always retaining the system instruction and original task. A HANDOFF_NOT_READY decision leaves control with the capable model; the first HANDOFF_READY decision transfers control to the efficient model, which inherits the current workspace and continues until termination using the context-transfer method selected for that model pair. Figure 5 illustrates this process. Across 360 evaluations on real inputs ranging from 2K to 121K tokens, AgentBaton achieves a median latency of 338 ms and a 95th-percentile latency of 1.11 s on a single NVIDIA H100 GPU, demonstrating low latency.

Experimental Results

We further extend the model pool in § 3 with two additional capable models, Claude Opus 5 [18] and Gemini 3.8 Flash [24], and another efficient model, GPT-5.6 Luna [13]. We also evaluate GPT-5.6 Luna as a source model handing off to Qwen 3.8 27B, testing whether handoff detection remains useful when the source is itself a lower-cost model. We evaluate both in-context and logfile transfer for each model pair. Table 3 uses a fixed context-transfer method for each source model across both benchmarks and receiving models: logfile transfer for GPT-5.6 Sol and GPT-5.6 Luna, and in-context transfer for all other source models. Complete results for both transfer methods are provided in Appendix § 10.

Capable model	Efficient model	DeepSWE v1.1 Handoff (%)	DeepSWE v1.1 Acc. (%) ↑	DeepSWE v1.1 Cost ($) \downarrow| Terminal-Bench 2.1 Handoff ($) ↓
—	Qwen 3.8 27B	—	29.2	0.00	—	69.7	0.00
—	GPT-5.6 Luna	—	60.2	0.40	—	82.2	0.07
GPT-5.6 Sol	—	—	68.1	5.32	—	87.6	0.97
GPT-5.6 Sol	Qwen 3.8 27B	26.6	$60.2_{-11.6\%}$	$1.02_{-80.8\%}$	58.4	$82.0_{-6.4\%}$	$0.43_{-55.7\%}$
GPT-5.6 Sol	GPT-5.6 Luna		$67.3_{-1.2\%}$	$1.39_{-73.9\%}$		$82.0_{-6.4\%}$	$0.47_{-51.5\%}$
Claude Opus 5	—	—	67.3	9.91	—	84.3	2.83
Claude Opus 5	Qwen 3.8 27B	36.6	$61.9_{-8.0\%}$	$2.61_{-73.7\%}$	55.6	$87.6_{+3.9\%}$	$1.13_{-60.1\%}$
Claude Opus 5	GPT-5.6 Luna		$76.1_{+13.1\%}$	$2.92_{-70.5\%}$		$86.5_{+2.6\%}$	$1.17_{-58.7\%}$
GLM-5.3	—	—	61.1	3.16	—	86.5	1.02
GLM-5.3	Qwen 3.8 27B	28.6	$58.4_{-4.4\%}$	$0.49_{-84.5\%}$	55.7	$80.9_{-6.5\%}$	$0.27_{-73.5\%}$
GLM-5.3	GPT-5.6 Luna		$66.4_{+8.7\%}$	$0.83_{-73.7\%}$		$79.8_{-7.7\%}$	$0.33_{-67.6\%}$
Kimi K3	—	—	73.5	4.73	—	86.5	1.50
Kimi K3	Qwen 3.8 27B	35.3	$72.6_{-1.2\%}$	$1.28_{-72.9\%}$	64.0	$86.5_{0.0\%}$	$0.57_{-62.0\%}$
Kimi K3	GPT-5.6 Luna		$77.0_{+4.8\%}$	$1.58_{-66.6\%}$		$80.9_{-6.5\%}$	$0.62_{-58.7\%}$
Gemini 3.8 Flash	—	—	65.5	6.15	—	86.5	1.02
Gemini 3.8 Flash	Qwen 3.8 27B	41.1	$61.9_{-5.5\%}$	$1.21_{-80.3\%}$	68.9	$86.5_{0.0\%}$	$0.51_{-50.0\%}$
Gemini 3.8 Flash	GPT-5.6 Luna		$73.5_{+12.2\%}$	$1.71_{-72.2\%}$		$85.4_{-1.3\%}$	$0.56_{-45.1\%}$
GPT-5.6 Luna	Qwen 3.8 27B	32.6	$55.8_{-7.3\%}$	$0.10_{-75.0\%}$	64.4	$77.5_{-5.7\%}$	$0.04_{-42.9\%}$

The results show that AgentBaton detects handoff points at an average of 26.6–41.1% of the source model’s trajectory on DeepSWE, compared with 55.6–68.9% on Terminal-Bench, indicating that detected handoff points occur at different stages across benchmarks. AgentBaton substantially reduces API cost, with accuracy preservation varying across model pairs and benchmarks: 12 of the 22 (model-pair, benchmark) settings either improve accuracy or incur a relative loss of less than 5%. For example, on DeepSWE, Kimi K3 handing off to Qwen 3.8 27B achieves 72.6% accuracy compared with 73.5% for capable-only execution, while reducing cost by 72.9%. A stronger efficient model can further improve the outcome: with GPT-5.6 Luna, four of the five capable models exceed their capable-only accuracy on DeepSWE, while GPT-5.6 Sol incurs only a 1.2% relative loss. These configurations reduce cost by 66.6–73.9%; for instance, Opus-to-Luna improves accuracy from 67.3% to 76.1% while reducing cost by 70.5%. Even when the source model is already efficient, Luna-to-Qwen reduces API cost by 75.0% on DeepSWE and 42.9% on Terminal-Bench, with relative accuracy losses of 7.3% and 5.7% respectively, indicating the versatility of AgentBaton.

Comparison with Routing and Handoff Baselines

To put these results in context, we compare AgentBaton with query-level and per-turn routing as alternative ways. We first test query-level routing by fine-tuning Qwen 3.5 2B to predict whether Qwen 3.8 27B can solve a task from its initial description, using success labels from 2,000 SWE-rebench V2 rollouts with balanced positive and negative examples. Despite 99.55% acc. on the training set, the router selects Qwen for only one out of all tasks, thus it effectively reduces to capable-only execution and provides little cost savings.

We then reproduce MTRouter [25] with the same model pairs to investigate whether a more fine-grained, model-specific per-turn routing strategy can achieve better accuracy–cost trade-offs. As shown in Table 4, AgentBaton reduces API cost by 46.7–86.6% relative to MTRouter, while matching or improving accuracy in all four settings. These results indicate that our learned one-time handoff strategy achieves even better accuracy–cost trade-offs than per-turn routing in the evaluated settings.

Method	DeepSWE v1.1 Acc. (%)	DeepSWE v1.1 Cost ($) | Terminal Bench 2.1 Acc. (%) | Terminal Bench 2.1 Cost ($)
MTRouter	58.4	3.67	80.9	1.35
Fixed progress	59.3	0.52	78.7	0.38
Fixed turn	54.9	0.48	76.4	0.18
AgentBaton	58.4	0.49	80.9	0.27
MTRouter	66.4	4.37	85.4	1.07
Fixed progress	74.3	1.28	86.5	0.83
Fixed turn	69.9	1.15	82.0	0.37
AgentBaton	72.6	1.28	86.5	0.57

We also compare AgentBaton with fixed-progress and fixed-turn handoffs, using its mean handoff progress and mean handoff turn for each benchmark and model pair as the respective thresholds. Fixed-progress handoff has access to future information, i.e., the source model’s final trajectory length, that is unavailable during online execution. Table 4 reveals that despite this advantage, its accuracy remains close to AgentBaton, while AgentBaton incurs equal or lower API cost. Compared with fixed-turn handoff, AgentBaton achieves consistently higher accuracy. These results show that online detection can achieve accuracy comparable to a fixed-progress baseline with access to future information, while preserving accuracy better than a fixed turn threshold.

Pushing the Accuracy–Cost Pareto Frontier

Finally, we examine whether AgentBaton can improve the accuracy–cost trade-offs obtained by varying a model’s reasoning effort. On DeepSWE v1.1, we sweep low, medium, high, xhigh, and max for GPT-5.6 Sol and Claude Opus 5; low and max for GLM-5.3; low, high, and max for Kimi K3; and high, xhigh, and max for GPT-5.6 Luna. For each source configuration, we use AgentBaton to detect a handoff point and continue with Qwen 3.8 27B. We additionally evaluate continuations with GPT-5.6 Luna for the first four source models. We use logfile transfer for handoffs from GPT-5.6 Sol and GPT-5.6 Luna, and in-context transfer for all other source models. Figure 1 compares these configurations with single-model baselines, and Appendix § 11 provides the complete numerical results. The results show that AgentBaton extends the empirical accuracy–cost frontier beyond the evaluated single-model configurations across a range of budgets. At the low-cost end, Luna-to-Qwen with xhigh effort matches Luna’s standalone accuracy of 56.6% while reducing mean API cost from $0.21 to approximately $0.06 per task. At a higher budget, GLM-to-Luna with max effort achieves 72.6% accuracy at $0.80 per task, compared with 69.0% at $3.06 for GLM alone. Kimi-to-Luna with high effort reaches 79.6% accuracy at $1.60 per task, exceeding the highest single-model accuracy in the sweep, 75.2% from Opus with xhigh effort at $8.90. Different source models, effort settings, and receiving models contribute to the frontier, suggesting that reasoning effort and model handoff offer complementary ways to allocate computation over a task.

Related work

Request-level routing and cascades. Prior work optimizes inference allocation at the request level. For instance, FrugalGPT [7] and Dekoninck et al. [26] explore cost-aware cascading pipelines, while RouteLLM [8], RouterDC [9], and Route to Reason [27] learn query-level model selection, compatibility, or reasoning strategies, supported by unified evaluation benchmarks [10]. These approaches primarily address individual requests. In interactive agentic tasks, an agent’s actions modify the workspace and accumulate interaction history, changing the state inherited by a subsequent model. Consequently, determining which model can resolve this evolving state requires accounting for task progress beyond the original request.

Multi-round routing and orchestration. Beyond single-turn decisions, multi-round orchestration architectures dynamically coordinate model and tool execution. Frameworks such as Router-R1 [28], ToolOrchestra [29], and SkillOrchestra [30] learn competence, invocation patterns, or skill-specific costs from execution feedback. Similarly, MTRouter [25] uses interaction history for turn-level routing, while Agent-as-a-Router [31] draws on verified experience across a stream of coding tasks. These approaches select among candidate models or tools, sometimes using model descriptions to support generalization to unseen candidates, as demonstrated by Router-R1 and ToolOrchestra. AgentBaton separates handoff timing from model selection: for a given capable–efficient model pair, a lightweight learned detector assesses task progress after each turn and decides whether to transfer control. We evaluate the same detector across multiple model pairs, with the receiving model continuing until termination after a handoff.

Model handoffs and trajectory transfer. A closely related line of research uses execution feedback to inform model transitions. SWE-Router [32] uses an exploratory trajectory to inform escalation, while TACIT-Switch [33] learns permanent small-to-large handoffs based on accumulated risk signals. The Handoff Tax [34] studies how handoff direction, timing, and trajectory-transfer interfaces affect coding-agent performance, finding direction-dependent accuracy–cost trade-offs. Its experiments use predefined switch points to isolate the effects of handoff and inherited history. Our analysis likewise examines handoff direction and context transfer, and further motivates a learned policy that identifies suitable capable-to-efficient handoff points online based on recurring patterns observed in agent trajectories.

Switching within a reasoning output. Finally, several approaches perform fine-grained handoffs within a single reasoning trajectory. STEER [35] and SplitReason [36] offload reasoning steps based on confidence or learned difficulty, while Speculative Thinking [37] delegates reflective reasoning to larger models. Most relevant, RelayGen [38] transfers simpler generation segments from a strong model to a smaller one via model-specific cues without router training. Our handoffs occur between complete agent turns, involving tool use, a shared workspace, and persistent changes to the task state. The receiving model inherits this workspace and accesses prior interaction history through in-context or logfile transfer, then continues acting until termination. Our focus is on how task progress and context transfer support continuation across models.

Conclusion

We study how capable and efficient models can collaborate within a single long-horizon agentic task through a one-time handoff. Our experiments show that capable-to-efficient handoffs offer favorable accuracy–cost trade-offs, particularly once the capable model has established an implementation, gathered feedback, and narrowed the remaining work to localized refinement. Motivated by these findings, we introduce AgentBaton, a lightweight detector that dynamically identifies suitable handoff points. Across DeepSWE v1.1 and Terminal-Bench 2.1, AgentBaton substantially reduces API cost while largely preserving, and occasionally improving, task accuracy. Further reasoning-effort sweeps demonstrate that such handoffs can extend the empirical Pareto frontier beyond single-model configurations, highlighting task progress as an effective signal for dynamic capability allocation.

Handoff progress on Terminal-Bench

Figure 6 reports the Terminal-Bench 2.1 results using the same handoff checkpoints as the DeepSWE experiments in the main text. As in the main text, we use logfile transfer for GPT-5.6 Sol handing off to Qwen 3.8 27B. For efficient-to-capable handoffs, accuracy and cost fluctuate across checkpoints, and Qwen-to-GLM handoffs cost more than GLM alone throughout the sweep. Capable-to-efficient handoffs offer favorable trade-offs at some checkpoints: Kimi K3 handing off at 75% reaches 87.64% accuracy versus 86.52% for Kimi alone, with 29.4% lower cost. However, the results are less consistent across models and checkpoints than on DeepSWE, and later handoffs do not monotonically improve accuracy.

Handoff-point annotation protocol

We use Codex to annotate the earliest suitable handoff point in each collected trajectory. The protocol follows the qualitative patterns in § 3.3. Codex reviews each trajectory retrospectively to better locate the earliest suitable handoff point.

Evidence available to the annotator. The annotator reads the task description and the chronological sequence of tool calls and their responses. Private reasoning text, post-trajectory verifier outputs, final rewards, and outcomes of receiving-model continuations are excluded as annotation evidence.

Readiness criteria. The annotator selects the earliest turn at which the evidence establishes all three conditions:

1. A substantive artifact exists. There is an implementation, runnable prototype, or task-required artifact. Investigation, a plan, or an unexecuted code sketch alone is insufficient.

2. The artifact has received real feedback. It has been compiled, executed, tested, or inspected by a task-relevant checker, with an observed response. Issuing a command does not establish that it

succeeded. A failed check can qualify when it exposes a localized problem; an environment failure that prevents the artifact from being exercised does not by itself establish this condition.

3. The remaining work has become localized. The evidence indicates that the work ahead mainly concerns diagnosis, repair, hardening, validation, or final-output preparation, rather than selecting the core approach or implementing the main solution from scratch.

These conditions do not require all tests to pass. Conversely, a passing check on an unrelated component or a substitute that bypasses the central requested behavior is insufficient. The annotator considers what the observed check actually establishes about the task-required artifact.

Selecting the first point and handling uncertainty. The label records the first qualifying point, not the final successful test or submission. If later work introduces a regression or substantially rewrites the implementation, the earlier point is retained and the instability is noted. If the conditions are never jointly established, the trajectory is labeled no_clear_handoff_point, with no handoff index. Missing or unreadable trajectories are recorded separately and are not assigned this label. Readable failed or interrupted trajectories remain eligible for annotation. The provenance of an implementation does not by itself determine readiness; when relevant, it is documented as a caveat.

Turn indexing and annotation record. A turn consists of one assistant step containing one or more tool calls together with their responses. Both the handoff index and evidence indices are zero-based within these tool-bearing steps, rather than indices over all conversation messages. We also preserve each step’s original identifier to support traceability to the source trajectory. Each record includes the task and source model, the actual trajectory path, the total number of tool-bearing turns, the readiness status, the handoff index and source step identifier, supporting tool evidence, a brief rationale, a confidence level, and any caveats. For trajectories without a clear handoff point, the handoff fields are null.

Complete AgentBaton results

Table Table 5 reports both in-context and logfile transfer for all five capable models and both efficient models, as well as GPT-5.6 Luna handing off to Qwen 3.8 27B. The main-text table uses logfile transfer for GPT-5.6 Sol and GPT-5.6 Luna as source models, and in-context transfer for all other source models. Single-model baselines are reported in Table 3.

Table 5: Complete AgentBaton results for both context-transfer methods. Each row reports accuracy and mean API cost per task from the same configuration.

Capable model	Efficient model	Transfer	DeepSWE v1.1 Acc. (%)	DeepSWE v1.1 Cost ($) | Terminal-Bench 2.1 Acc. ($)
GPT-5.6 Sol	Qwen 3.8 27B	In-context	54.9	1.03	85.4	0.43
		Logfile	60.2	1.02	82.0	0.43
	GPT-5.6 Luna	In-context	61.9	1.27	84.3	0.47
		Logfile	67.3	1.39	82.0	0.47
Claude Opus 5	Qwen 3.8 27B	In-context	61.9	2.61	87.6	1.13
		Logfile	61.1	2.44	87.6	1.06
	GPT-5.6 Luna	In-context	76.1	2.92	86.5	1.17
		Logfile	70.8	2.99	85.4	1.19
GLM-5.3	Qwen 3.8 27B	In-context	58.4	0.49	80.9	0.27
		Logfile	53.1	0.49	78.7	0.26
	GPT-5.6 Luna	In-context	66.4	0.83	79.8	0.33
		Logfile	67.3	0.87	85.4	0.34
Kimi K3	Qwen 3.8 27B	In-context	72.6	1.28	86.5	0.57
		Logfile	65.5	1.19	84.3	0.53
	GPT-5.6 Luna	In-context	77.0	1.58	80.9	0.62
		Logfile	74.3	1.64	85.4	0.61
Gemini 3.8 Flash	Qwen 3.8 27B	In-context	61.9	1.21	86.5	0.51
		Logfile	54.0	1.20	80.9	0.51
	GPT-5.6 Luna	In-context	73.5	1.71	85.4	0.56
		Logfile	68.1	1.64	85.4	0.56
GPT-5.6 Luna	Qwen 3.8 27B	In-context	54.9	0.10	74.2	0.04
		Logfile	55.8	0.10	77.5	0.04

Complete reasoning-effort sweep results

Table Table 6 lists all single-model and AgentBaton configurations plotted in Figure 1, including dominated configurations. Qwen and Luna denote Qwen 3.8 27B and GPT-5.6 Luna, respectively. The Qwen baseline uses a 1M-token context window.

Table 6: Complete numerical results for the reasoning-effort sweep on DeepSWE v1.1 in Figure 1. Effort refers to the source model. Accuracy is in percent and cost is mean API cost in USD per task. Dashes indicate configurations not evaluated in this sweep.

Source model	Effort	Single model Acc.	Single model Cost	AgentBaton → Qwen Acc.	AgentBaton → Qwen Cost	AgentBaton → Luna Acc.	AgentBaton → Luna Cost
GPT-5.6 Sol	low	35.4	0.65	47.8	0.20	65.5	0.60
	medium	51.3	1.26	54.9	0.30	68.1	0.80
	high	62.8	1.88	57.5	0.50	62.8	0.90
	xhigh	71.7	2.79	59.3	0.70	69.0	1.10
	max	71.7	4.84	61.9	1.00	70.8	1.40
Claude Opus 5	low	54.0	1.45	49.6	0.70	65.5	1.00
	medium	68.1	3.14	55.8	1.10	75.2	1.40
	high	64.6	5.87	59.3	1.70	69.9	2.00
	xhigh	75.2	8.90	55.8	2.20	70.8	2.60
	max	67.3	9.91	61.9	2.61	76.1	2.92
GLM-5.3	low	59.3	1.71	61.9	0.29	67.3	0.60
	max	69.0	3.06	66.4	0.48	72.6	0.80
Kimi K3	low	54.9	1.40	54.0	0.55	72.6	0.90
	high	69.9	3.81	71.7	1.20	79.6	1.60
	max	73.5	4.73	72.6	1.28	77.0	1.58
Gemini 3.8 Flash	high	65.5	6.15	—	—	—	—
Qwen 3.8 27B	xhigh	29.2	0.00	—	—	—	—
GPT-5.6 Luna	high	38.1	0.11	50.4	0.04	—	—
	xhigh	56.6	0.21	56.6	0.06	—	—
	max	60.2	0.40	55.8	0.10	—	—