The expensive model should stop typing: what the handoff research actually found
Synergised Consulting Ltd
Last Updated: 22 October 2026
Two of this week's developments point the same direction from opposite ends. On Wednesday, Flowtivity published an account of splitting its coding work in two: a strong Claude model reads the code, decides the fix and writes a brief, while a cheaper GLM model on a flat-rate plan makes the edits and runs the tests, with the strong model reviewing the diff before anything ships. At the same time, a controlled research paper on model hand-offs in coding agents has put numbers on which direction of that split actually pays. The two agree, and the agreement is more useful than either alone.
The expensive model's job is judgement, not typing
Most of what an AI agent spends its tokens on is not hard reasoning. It is applying an edit across files, writing test cases, renaming things: work where the judgement happened earlier, when someone decided what to change, and what remains is execution. Paying frontier-model rates for that work is not a moral failing, it is a billing arrangement, and this year it has produced a wave of routing tools designed to break it.
The pattern has a name now in the literature: the orchestrator-executor split. A high-capability model plans, decomposes the task and reviews the result. A cheaper model carries out the well-specified work. The idea is not that the cheap model is clever; it is that most of the work is not clever either, and the split lets each model bill for the part it is actually good at. [1]
What turned the pattern from an economy into a measurable engineering question was a study published this August on what its authors call the handoff tax. When work moves from one model to another mid-task, the receiving model inherits a trajectory written by a different model. That inheritance has a measurable cost, and the cost depends almost entirely on direction. [2]
The research: escalation is expensive, downshift pays
The favourable direction in a model handoff is from the strong model to the cheap one. That is the central finding of the handoff tax study, and it holds across both model families tested.
The study measured what happens when a coding task moves between a low-cost and a high-cost model mid-run, under controlled conditions, varying the direction, the timing and how much of the first model's working context transfers. When a cheap model struggled and its work was escalated to the strong model, handing over the full trajectory recovered less than half of the quality gap between the models: 47 per cent of it for the Claude pair and 36 per cent for the GPT pair. That partial rescue came at a cost multiplier of roughly 4.0 times for the Claude pair and 6.1 times for the GPT pair, and for the Claude pair the escalated run ended up costing more than twice as much as simply starting the task on the strong model in the first place: $1.61 against $0.72 per task. [1]
Escalation fails because it inherits a foreign trajectory
The intuition behind the expensive direction is that the strong model can rescue anything. The study found it can rescue some of it: never more than half the gap, in either family tested. The failure is structural. The strong model receives not just a problem but a partly-built solution shaped by another model's habits, and continuing a non-native trajectory turns out to be a different, harder task than solving the original one. [1]
Downshift pays, with a boundary
The downshift is the mirror image, and it is where the economics reverse. When the strong model did the early, judgement-heavy portion of the task and handed the remainder to a cheaper model to finish, the result landed at an intermediate quality level but at a cost below running the strong model for the whole task. Preserving the strong model's trajectory helped the cheaper receiver; the direction the study found favourable is exactly the direction the orchestrator-executor pattern already assumes. [1]
A second paper from the same month reaches the same boundary from the production side. Task-to-Model Optimisation, a framework built around routing production coding sessions to the cheapest model that meets quality and latency requirements, prices task failures and escalations explicitly into its objective. Its authors show that optimising cost per completed task, with the cost of failed handoffs counted, does at least as well as naively minimising token spend, because naive minimisation quietly assumes every task succeeds on the cheap model the first time. The routing boundary they derive is a minimum pass rate a cheaper model must reach on a task type before it is worth deploying at all. [2]
Together the papers say something specific: the split pays when the planner writes a brief good enough that the executor rarely fails, and the review catches what does fail. It stops paying when the split is done loosely and work bounces upward.
Why direction beats price
The intuition behind the expensive direction, escalating cheap work upward, is that the strong model can rescue anything. The study found it can rescue some of it: never more than half the gap, in either family tested. The failure is structural. The strong model receives not just a problem but a partly-built solution shaped by another model's habits, and continuing a non-native trajectory turns out to be a different, harder task than solving the original one. [1]
The favourable direction works for the mirror reason. When the strong model plans first, the cheaper executor receives a specification, not a mystery: the goal, the files, the approach, the constraints and the acceptance test. Most of the judgement the task requires has already been spent. What remains is the part cheap models are actually adequate at.
What a working split looks like
The Flowtivity setup is a small, concrete instance of the pattern, and its details matter more than its headline. The strong model's first output is not code, it is a written brief with a fixed shape: the goal including why it matters, the exact files and functions involved, the chosen approach and the alternative that was rejected, the constraints on what must not change, the acceptance commands with their expected output, and the format of the report that comes back. The executor has no memory of any conversation; everything it needs has to be on the page. [3]
Two of the paper's findings map directly onto that design. A precise brief with a real acceptance test is what keeps the executor's failure rate low enough for the split to pay, which is the routing boundary the production paper derives: below a minimum pass rate on a task type, the cheaper model is not worth deploying on it. And the strong model reviewing the actual diff, rerunning the acceptance commands itself rather than trusting the executor's report, is what turns a failure into a cheap loop instead of an escalation, which is the direction the handoff research shows is affordable. [1][2][3]
Where the pattern does not apply
The split is not a general saving, and Anthropic's own account of its multi-agent research system says so plainly: the pattern suits work that genuinely parallelises into independent, well-scoped pieces, and most coding tasks involve fewer of those than people expect. Tightly coupled work, where each change depends on the state of the last, pays a coordination cost that the cheaper model does not offset. [4]
In discovery workshops the constraint usually shows up as a subscription that keeps running out before the month ends, and the first instinct is to move work to a cheaper model wholesale. The research says the cheaper model should take the typing and never the judgement, because the one handoff direction that reliably costs money is sending half-finished thinking up to the expensive model to fix.
Sources
- [1] [1] The Handoff Tax: Continuing Non-Native Trajectories in LLM Agents, arXiv:2608.24358,
- [2] [2] Task-to-Model Optimization for Enterprise LLM Coding Assistants, arXiv:2608.08528,
- [3] [3] Claude leads, GLM builds: splitting thinking from typing, Flowtivity, 22 October 2026, (news hook and qualitative setup description only; no figures in this piece rest on it)
- [4] [4] How we built our multi-agent research system, Anthropic, (qualitative guidance on parallelisation, figures not relied on)
