Dynamic Model Escalation for Coding Agents: A GMI Router Experiment Across Two Harnesses

Over the past few weeks, we ran 89 Terminal-Bench 2.1 tasks through Terminus 2 and Claude Code with two models that sit at opposite ends of the price list: DeepSeek V4 Flash and Claude Fable 5. As we extend GMI Router from request-level model selection toward agentic workloads, we wanted to know whether a coding agent could begin on a lower-cost model and bring in a stronger one only when the trajectory actually needed it. Here is what we saw, including a result about harnesses that surprised us.

GMI Router today makes a request-level model decision before generation starts: which model should handle this request?A coding agent behaves differently. One trajectory can include repository inspection, planning, code edits, debugging, test runs, and recovery after a failed attempt, and the capability the agent needs at step 3 can differ a lot from what it needs at step 30.

So we asked a narrower question.

Can GMI Router go beyond choosing a model at step 0 and dynamically escalate capability during a coding-agent trajectory, only when the run actually calls for it?

The main goal was to test the mechanics of live model switching and what it does to the quality-to-cost ratio. Along the way we found that the harness itself changed model performance and which tasks looked like escalation candidates. That second finding gets its own section.

Experimental setup

The benchmark holds 89 verifier-scored Terminal-Bench 2.1 tasks. For V4 Flash we ran five seeds per task in each harness. For Fable 5 we used the official trajectories, also five trials per task.

Static model results

Fable 5 wins on pass rate in both harnesses, 80.7% against 69.2% on Terminus 2 and 84.3% against 70.3% on Claude Code. Then you look at the bill. A Flash trial cost us $0.04 on Terminus 2 and $0.07 on Claude Code. A Fable trial cost $1.15 and $1.97. That is a 26x to 28x spread for the same task load, and it is the whole reason a router exists. Run everything on Fable and you pay the premium on tasks Flash handles fine. Run everything on Flash and a chunk of the benchmark stays unsolved. Somewhere between those two fixed strategies there is a better operating point, and finding it is the job.

Pass rate by arm (bars show pass@1, ticks mark pass@5 over each arm's five runs) beside cost per trial. The gap on the right is what a router monetizes.

Two layers of routing

We tested routing at two levels.

Layer 1: step-0 model selection

Before the first step, the system picks a model based on the routing objective. A quality objective picks Fable 5, a cost objective picks V4 Flash. This is the same request-level decision GMI Router makes today.

Layer 2: live escalation

The second layer runs during execution. The policy watches trajectory-level failure signals. When the signals say stronger capability is needed, it escalates from V4 Flash to Fable 5. Once the trajectory looks safe again, it downshifts back to Flash. The transcript and working tree carry across the switch, so the incoming model inherits everything the previous one did. Guards on dwell time, switch count, and wall clock keep the policy from bouncing between models.

The hypothesis behind this layer is simple. The model that should start a task may be a different model from the one that should finish it.

Layer 1 picks once per task. Layer 2 can switch per step. The escalation head fires on P(fail) or on loop and overrun signals; the downshift head returns to Flash after two consecutive safe steps. Dwell, switch-count, and clock guards bound the behavior.

Most tasks were fine on the cheaper model

Before testing live switching we sorted the benchmark by how the two models split it. Each task landed in one of four bands based on repeated-run outcomes. LOWER means V4 Flash suffices. MIXED means neither model clearly owns the task, typically 2 or 3 passes out of 5. UPPER means the task needs Fable. INTRACTABLE means both models fail it reliably.

The LOWER band dominates in both harnesses, 57 tasks on Terminus 2 and 58 on Claude Code. An always-Fable strategy pays the premium on every one of those. The MIXED and UPPER bands together hold 21 tasks on Terminus 2 and 25 on Claude Code, and those are the tasks an always-Flash strategy leaves on the table. A router that can tell the two groups apart has a lot of room to work with here.

Task bands per harness. Blue is where Flash alone is sufficient.

Can live escalation rescue hard tasks?

For the quality side of the hypothesis we picked the nine tasks V4 Flash had failed in every one of its ten observed runs across both harnesses, and gave each a single live-routing trial. Three passed.

On chess-best-move the router escalated at step 8 and Fable closed the task. On make-mips-interpreter Flash worked for 28 steps before the handoff. path-tracing was the messy one. The router escalated at step 27, downshifted at step 30, escalated again at step 33, and the verifier still scored the task at 1.0. In all three cases Flash did the early work, the router picked up failure signals, and Fable finished from where Flash left off.

Nine trials is a small sample, so 3 of 9 is a demonstration that the mechanism works. A recovery rate needs the full run. What the demonstration shows is worth stating plainly. A task that exceeds the starting model can continue on a stronger model from its current state, with the full transcript intact. The stronger model enters only once the trajectory shows evidence it is needed.

The six failures matter too. Escalation gives a task a second chance with a stronger model, and it stops there. If the model pool lacks the capability, the router has nowhere to send the task.

The three rescued trajectories. Triangles mark escalation (up) and downshift (down) steps. Bottom: all nine hard-set trials, 3 passed and 6 failed.

Can the router leave easy tasks alone?

Over-escalation is the other way this can go wrong. A router that upgrades at every hiccup erases its own cost advantage. So we took six tasks V4 Flash solves on its own and ran them through the same live-switching policy. All six passed.

Four stayed on Flash the whole way at $0.01 to $0.09 per trial. Two switched on a false signal. fix-ocaml-gc escalated at step 27, downshifted at step 30, and still came in at $0.93, under the $1.08 a Fable-only run costs. mailman escalated at step 26, stayed on Fable, and finished at $1.51 for a task Flash closes for cents. Those two runs are the clearest picture we have of where escalation precision needs work.

The control set makes a point that is easy to skip past. A useful escalation policy has to know when to leave the cheaper model alone, and that restraint is worth as much as the rescues above.

Six control tasks Flash already solves. Orange segments are mistaken switches to Fable; the two late escalations account for most of the control set's cost.

Secondary finding: the harness changes model performance

Because the same tasks and the same model pair ran through both Terminus 2 and Claude Code, we could compare how the execution environment shaped model behavior. The gap was larger than we expected.

We looked at the MIXED and UPPER bands, the tasks most likely to benefit from escalation. Nine of those tasks appeared only under Terminus 2. Thirteen appeared only under Claude Code. Twelve appeared in both. The Jaccard similarity between the two escalation sets is 0.35. A task that needs Fable in one harness often gets by on Flash in the other.

Task difficulty, then, is partly a property of the harness. The harness decides how the agent builds context, orders its actions, manages the trajectory, and recovers after a failed step, and each of those choices changes how well a given model does. For routing that means the best model for a task may depend on the harness running it.

A note on scope. The production GMI Router today routes on the prompt, and this experiment measured harness effects from the outside. What the result gives us is evidence that harness context is a meaningful routing signal. Harness-aware routing is planned for the next GMI Router launch, where harness information becomes an explicit input to the routing layer.

Left: overlap of escalation-candidate tasks across harnesses, Jaccard 0.35. Right: 81 of 89 tasks were solved somewhere; the 8 unsolved are listed.

From static routing to trajectory routing

These results separate two routing problems that usually get lumped together.

Request-level routing asks which model should start this task. That is the conventional problem and the one most routers solve today.

Trajectory-level routing asks whether the current model should keep going, given everything that has happened so far. Much of the useful information only shows up after execution begins: repeated failures, stalled progress, loops, a task that turns out harder than its prompt suggested, or a recovery after a hard intermediate step. Those signals describe the state of the trajectory. For coding agents, routing starts to look like an ongoing capability-allocation problem, with the initial classification as one input among several.

The economic objective: cost per resolved task

Pass rate captures half of the production tradeoff. The stronger model passes more tasks and costs 26x more per trial. The cheaper model costs cents and fails more often. The metric that holds both sides is cost per resolved task. A cheap model that needs four retries gets expensive. A premium model that solves every easy task at $1.50 apiece is expensive in a different way, since most of those tasks would have passed on Flash.

Dynamic escalation aims for the middle. Picture the trajectory as Flash, Flash, Flash, Fable, Fable. Compare that with Fable at every step, or with Flash at every step until the run fails. The question stops being which model is strongest and becomes how much capability each stage needs to keep the trajectory moving toward resolution.

What the experiment shows so far

Four observations hold up across both harnesses. Most coding-agent tasks run fine on a lower-cost model; the LOWER band held 57 of 89 tasks on Terminus 2 and 58 on Claude Code, which is real room for cost savings. Some tasks clearly require stronger capability, and the MIXED and UPPER bands show why a fixed low-cost policy leaves work undone. Stronger capability can arrive mid-run, since three tasks Flash had failed in every static run passed after live escalation. And harness choice materially changes model behavior; a 0.35 overlap between escalation sets puts the execution environment inside the routing problem, which is why harness-aware routing is next on our list.

Limitations

This is an early experiment and the limitations are real.

·       V4 Flash results come from our own runs, while Fable 5 results use official trajectories.

·       The study covers two models and two harnesses.

·       The live-switch sample is small: 9 hard tasks and 6 controls, one trial each.

·       The escalation and downshift policy is still experimental, and false-positive switches remain.

·       Aggregate cost-per-resolved-task numbers across all static and dynamic strategies are still to come.

Read these findings as evidence about the mechanics and potential value of live model escalation. A production benchmark comes after the full run.

What we have next

The next round runs the full 89-task set under the live policy on both harnesses. That gives us the number this post is missing: how much of Fable's task success dynamic routing can recover while paying Fable's price for only part of the trajectory.

The cross-harness result opens a second line of work. How much does routing improve when harness identity and harness-specific behavior become explicit inputs? That is the question harness-aware routing in the next GMI Router release is built to answer.

Conclusion

We started with a simple question: can we defer expensive model capability until a coding agent shows it needs it? The early answer is yes, with caveats. Most Terminal-Bench tasks were already solvable on the lower-cost model. Some needed the stronger one from the start. And in a handful of hard trajectories, the need only became visible after execution had begun, which is exactly the case a static router misses.

Running the same tasks across two harnesses added a wrinkle we now consider central. The agent environment shapes model requirements as much as the task does, and it changes both pass rates and escalation behavior. So the routing question grows. It used to be which model is best for this request.

Given this task, this harness, and the current trajectory state, what level of model capability should be allocated next?

That is the version of the problem we are building toward.

Start routing

GMI Router is live with the first layer from this post. Log in at console.gmicloud.ai, open GMI Router, and run a few of your own prompts. Check our docs for more information. The endpoint is OpenAI-compatible, so integration is a base URL change:

from openai import OpenAI
 client = OpenAI(
     base_url="https://console.gmicloud.ai/api/v1/ie/recommendation",
 	api_key="YOUR_GMI_API_KEY",
 )
 resp = client.chat.completions.create(
 	model="auto",
 	messages=[{"role": "user", "content": "Fix the failing test in src/parser.py"}],
 	extra_body={"mode": "cost"},   # cost | balanced | quality
 )
 print(resp.choices[0].message.content)

Mid-task switching and harness-aware routing ship in the next release, with all 89 tasks rerun and cost per solved task published for each strategy.