GitHub's HydraFusion turns model selection into a routing decision Copilot makes for you

Trial and error is how the choice gets made now, according to devops.com: a quick model for small edits, a pricier one for hard debugging, sometimes a second model pulled in just to check the first one's work ^[1]. Most organisations handle it informally, per developer ^[12]. Teams often assume there's a house standard for this, but mostly what exists is a habit each developer formed in their first week with the tool and never revisited.

The cost claim rests almost entirely on cascade mode. An efficient model drafts, and the stronger, more expensive model only gets the work if that draft fails a quality gate ^[3]. So the saving is a function of how often the gate passes on your code, not on GitHub's. Where it fails often, the cheap pass adds an extra step in front of the expensive model rather than saving money. The devops.com account names the gate without giving its threshold or saying who can move it ^[14].

The published figures are better read as a spread than a headline. On TerminalBench 2.1, GitHub reports 4.9 percentage points better quality than Claude Opus 5 at an estimated cost 67% lower ^[5]. DeepSWE returns less: 36% cheaper, quality down 1.5 points ^[6]. CheckpointBench comes in 65% cheaper for a 0.1-point drop ^[7]. Best to worst cost result is 31 percentage points apart, and two of the three runs finish below the comparison model on quality ^[15][16]. Every one of those numbers is GitHub's own, measured against Claude Opus 5 and GPT-5.6 Sol at the same medium reasoning level ^[8]. The Microsoft principal software engineer who called the reasoning "at or better than Opus" ^[9] is one team on a preview, which devops.com says plainly, along with the caution that results will not hold the same way on every codebase ^[10].

devops.com's read is that model routing becomes an infrastructure and governance concern, needing visibility into which models touched code and why a particular workflow was picked ^[11]. That describes something a platform team would have to be given. Nothing in the account describes an admin policy, a cap on escalation, or a record attached to a change naming the model that produced it ^[13]. The routing policy in this preview belongs to GitHub, which helps the developer who was routing by hand but leaves whoever signs off on the spend without a guarantee.

Two questions sort it for any team deciding whether to switch it on. Whether you can read the routing decision after the fact, and whether you can set it beforehand. Both yes, and routing is platform capability you own. With read-only access, you get an audit surface: you can explain choices you didn't make. With set-only access, you get a cost dial with no provenance, which works fine until a regression needs tracing back to the model that wrote it. Without either, you've handed over the bill and the byline in one move. On what has been published, the preview sits in that last box, and the thing worth asking for ahead of the discount is the log.