TL;DR
AgentBaton is a “relay baton” approach for long agentic tasks (coding, terminal work). An expensive model does the first part: the plan, a working prototype, the first runs. Then it hands control off once to a cheap model, which carries the work to the finish line. The authors added a small trained detector that picks the handoff moment on its own. But for practitioners, the real value isn't the detector — it's the handoff rules they tested.
The key finding is an asymmetry. If you start with the cheap model and call in the strong one “for the hard part,” the result is usually worse than the strong model alone, and you barely save anything. In the first few steps the cheap model manages to make a mess, and the strong one has to clean it up. The reverse order works: the strong model builds the foundation and gets feedback from runs, and the cheap one fixes, checks, and polishes. Accuracy stays nearly the same, while cost drops by two-thirds or more. Asking the model itself to “hand off control when you're ready” is useless. Some models never do it at all; others always hand off, but the savings are small.
The method boils down to three rules: (1) hand off top-down, once; (2) pick the moment by the state of the work, not by step count; (3) choose how to pass the history based on the direction. Going up (cheap → strong), it's better to pass the history as a log file. Going down, it's often better to keep it in the same conversation.
Want this for your own case? Apply this study to your task: AI adapts its method to what you are working on and writes the prompt.
Method Blueprint
STEP 1: The strong model takes the task → plan, prototype, first runs
STEP 2: Check handoff readiness (3 signs):
• a working prototype or the required artifact exists
• it was run/tested and produced feedback (even bad feedback)
• the remaining work is local: fix, check, finish
STEP 3: ONE handoff → the cheap model gets the same workspace
+ the history (in the conversation OR as a log file)
STEP 4: The cheap model finishes the job. No switching back.
The steps happen within a single agent session. Switching the model is a manual action or a tool setting.
Example in Practice
Task: You run a small Amazon store. You need a script that every morning pulls stock levels from a QuickBooks export and updates them through the Amazon Selling Partner API. You work in Claude Code and have both an expensive and a cheap model available.
What you do: 1. The expensive model designs the script, writes the first working version, and runs it on test data. Some stock levels didn't update because of an encoding issue in the SKUs. That's normal feedback: the problem has narrowed down. 2. You check the three signs. There's a prototype. It was run, and we know where it fails. What's left is a local repair. 3. You switch to the cheap model. You either continue in the same conversation or hand it a log (see the template below).
Prompt for the cheap model (handoff via log):
You are continuing work on a task. Original task: a script for daily
syncing of stock levels from a QuickBooks export to the Amazon Selling Partner API.
The previous worker's history is in the file ./handoff/log.jsonl.
Each line is one step: step number, the model's response, and a list of actions.
Each action has a command, return code, stdout, and stderr.
Entries are in chronological order. Read the LAST entries first
to understand the current state. The working files are already in the project folder.
What's needed: fix the handling of SKUs with non-ASCII characters, run the test
on tests/sample_stocks.csv, and make sure every item got updated.
Result: the cheap model will open the end of the log first, find the failed run, and make a targeted encoding fix. Then it'll run the test and wrap up. The expensive tokens went only to the design and the first prototype.
Why It Works
The weakness. In a long task, a cheap model is more likely to start from wrong assumptions and head down a false path. The strong model then has to spend effort fixing it. That's why handing off “up” and switching frequently “along the way” cause losses: every switch piles up errors and overhead. The strong model itself also can't reliably decide when to hand over control. The experiments with the “hand off when you're ready” instruction proved that.
The strength. The cheap model doesn't need to invent a solution from scratch. It only needs to see a finished artifact and a run result to fix, check, and fill in the gaps locally. At that, it's nearly as good as the strong model. Even a failed run is useful if it narrows the problem: it shows exactly where things break.
How the method uses this. The strong model takes the uncertain part of the work (the concept, the foundation, finding the root cause). The cheap one takes the well-defined part (the finishing). The handoff moment is set by the state of the work, not by percentages or step counts.
Levers: - Handoff moment. It varies by model pair: from roughly 30% to 60% of the strong model's trajectory. If in doubt, hand off later, but before the final polish. The later you hand off, the smaller the savings. - How to pass history down. If the source model's reasoning is visible, keep the history in the conversation. If not, try a log file. For some models the difference was noticeable; for others it was mixed. - How to pass history up. In most cases a log file gave both better accuracy and lower cost than pasting everything into context. - Log-reading instruction. “Last entries first” helps the model grasp the current state faster.
Prompt Template
This is a text instruction for a new session on the receiving model. The structure comes from the paper: the original task, the path to the log, a description of the fields, the order of entries, and an instruction to read the end first.
You are continuing work on a task that another worker started.
ORIGINAL TASK:
{original_task}
THE WORK HISTORY is in the file: {log_path}
Format: one entry for each step of the previous worker. Entry fields:
- step number
- its original response
- list of actions: command, return code, stdout, stderr
Entries are in chronological order. Start with the LAST entries
to understand the current state of the work. Go back to earlier entries
only if you need to figure out why something was done a certain way.
The working files are already in {project_folder}, in the state
the previous worker left them.
WHAT'S LEFT TO DO:
{remaining_work}
HOW TO TELL IT'S DONE:
{done_criterion}
What to fill in:
- {original_task} — the exact task statement the strong model received.
- {log_path} — the file the history was dumped into. If your tool doesn't create one on its own, ask the strong model to write the log in this format at the end of its part.
- {remaining_work} — local items: fix a specific error, check, finish.
- {done_criterion} — a test, command, or check that confirms the result.
🚀 Quick start — paste into the chat:
Here's a template for handing work off between models. Adapt it to my task: [your task].
Ask me questions to fill in the fields.
[paste the template above]
The LLM will ask what your original task is, what's already done, what failed or hasn't been checked, and how to tell the work is finished. It needs this so the receiving model gets a clear list of remaining work instead of “figure it out yourself.”
Limitations
⚠️ The detector needs training: AgentBaton itself is a separate small trained model, trained on hundreds of thousands of steps from agentic runs. Readers without GPUs and a dev team can't use it. Only the conclusions from the analysis apply, and you'll have to pick the handoff moment by hand.
⚠️ Manual timing wasn't tested: the authors derived the readiness signs by analyzing examples and used them for labeling. They didn't measure how a human with a checklist performs.
⚠️ Accuracy sometimes drops: in some pairs, handing off to the cheap model caused a noticeable accuracy drop, in some cases by 5–12%. In others it matched the baseline, and sometimes beat it. The outcome depends on the model pair.
⚠️ “Hand off on your own” doesn't work: telling the strong model “hand off control when you're ready” failed. One model never handed off, another almost never did. A third always handed off, but the savings were modest.
⚠️ Coding and terminal only: tested on programming and terminal tasks, mostly with one simple agent scaffold. Transfer to writing and analytical tasks hasn't been tested.
⚠️ A single handoff: switching back and forth wasn't tried. The authors believe frequent switching piles up errors.
⚠️ Cost accounting: local models were counted as free in the calculations. If you pay for a cloud-hosted cheap model, your savings will be smaller.
How They Studied It
The researchers took three strong models and one cheap one (27B), plus two benchmarks: terminal tasks and hard software-engineering tasks in real repositories. First they ran each model solo and recorded the trajectories. Then they replayed the strong model's actions up to a chosen point (15%, 30%, 45%, 60%, 75%, 90% of the way) and let another model continue from the same working state. That makes for a fair comparison of “handed off here” vs. “didn't hand off.”
The result was asymmetric. Handing off upward usually cost accuracy, and the savings were small. One model at 30% of the trajectory got slightly higher accuracy, 70.8% vs. 68.1%, but cost dropped by only 6.1%. Handing off downward showed the opposite. Kimi K3 at 45% of the way: 72.57% vs. 73.45% on its own, while 61.5% cheaper. GLM-5.3 at 30%: 61.1%, exactly the same as solo, and 82.4% cheaper. GPT-5.6 Sol at 60%: 67.26% vs. 68.10%, 47.9% cheaper.
Next they compared two ways of passing the history: pasting it into context or providing it as a log file. For upward handoffs, the log was better almost everywhere. For downward handoffs, it depended on the model. The authors suspect it comes down to whether the source model's reasoning is visible.
To understand what exactly makes a handoff succeed, they took cases where the cheap model failed after an early handoff but succeeded after the next one. They looked at what the strong model did between those two points and derived three readiness signs. Simply asking the model to decide when to hand off failed. That's what led to training a detector on 4,000 trajectories. The detector is a small 2B-parameter model trained on 16 H100 GPUs, and it responds in 0.3 seconds. Across 11 model pairs and two benchmarks, it cuts costs by 65.9% on average and, at best, adds up to 8.8 pp of accuracy over the strong model alone.
Adaptations and Extrapolations
🔧 Technique: a readiness checklist before switching → fewer premature handoffs
Before switching models, ask the strong model to answer three questions. This is my adaptation: the authors identified the signs but didn't measure a human-run check.
Before I hand this work off to another model, answer briefly:
1. Is there already a working prototype or the required artifact? Which one?
2. What did we run or check, and what did the check show?
3. What's left: a local fix/check, or does something still need to be figured out?
If the answer to (3) is “something still needs to be figured out,” it's too early to hand off.
Hand off based on the answers: if the model says “local fix” for item 3, you can switch. This is an add-on, not a result from the paper. Use it as a starting point and test it on your own tasks.
Resources
- AgentBaton: Efficient Model Collaboration in Agentic Tasks — Junlong Li (HKUST), Jindong Jiang, Yonggan Fu, Jiarui Yao (UIUC), Hanrong Ye, Wonmin Byeon, Peter Belcak, Hao Zhang, Pavlo Molchanov; NVIDIA, 2026.
- Benchmarks: Terminal-Bench 2.1 and DeepSWE v1.1; agent scaffold — mini-SWE-agent.
- Detector training data: SWE-rebench V2.