One model picker. Three engines under the hood.

The dropdown just grew a pit crew.

GitHub says HydraFusion currently chooses among three patterns. Single sends the job to one selected model. Cascade lets an efficient model try first, then uses a quality gate to decide whether to escalate. Critique sends a draft to a read-only critic from a different model family, then gives the original drafter one revision.

That is a meaningful product shift. GitHub’s existing Auto selection chooses a model using task complexity plus live health and availability. HydraFusion can choose an execution graph. The user still sees one model-like selection, but the runtime may contain several priced, timed, stateful legs.

A compound model should not masquerade as a single opaque oracle. Show the route, the bill, the gate, and the patch that survived.

The benchmark claim is promising—and tightly scoped.

In GitHub’s controlled offline evaluation, its best tuned HydraFusion configuration reported 4.9 percentage points higher verified task quality on TerminalBench 2.1 at 67% lower estimated cost than its evaluated Opus 5 baseline. On DeepSWE it reported 1.5 points lower quality at 36% lower estimated cost; on GitHub’s internal CheckpointBench, 0.1 points lower at 65% lower cost.

Keep the dyno sheet attached. These are vendor-reported results for specific benchmark revisions, model pools, workflow configurations, pricing assumptions, and medium reasoning settings—not a universal law that orchestration is cheaper. GitHub explicitly calls the feature a research preview and says real workloads still need validation. Terminal-Bench’s public leaderboard also exposes resolution rate, tokens, and cost as separate columns, which is the right reminder: “best” is a vector, not a crown.

The clever part is not extra calls. It is containment.

GitHub’s five stated operating principles are the meat: complete accounting across every leg; explicit timeouts and cancellation; read-only, tool-less review contexts; no patch when validation fails or execution is cancelled; and preflight validation of routes, bindings, fallbacks, and model availability.

The separate Rubber Duck documentation sharpens the critic boundary. Its critic can read the codebase but cannot edit files or run environment-changing commands. A different model family is meant to reduce shared blind spots. That is not proof of independence, but it is better than asking the same process to grade its own homework in the same writable room.

What the IDE should expose next.

1. Route receipt. Name the pattern actually used—single, cascade, or critique—and show each leg’s role without leaking disposable chain-of-thought.
2. Budget envelope. Put an explicit ceiling on aggregate cost, latency, retries, and escalations before ignition.
3. Critic isolation. Make read-only and tool-less status visible, not an implementation footnote.
4. Patch gate. Show which tests or validations allowed the final change to cross into the repository.
5. Fallback truth. Report degraded routes and unavailable models instead of quietly changing the job’s shape.

HydraFusion’s bet is that selective coordination can beat reflexively hiring the biggest engine for every lap. The garage agrees. But when the pit wall chooses the driver, fuel load, and safety car, the dashboard cannot stop at a spinner.