You know the scene: hovering over the model picker, wondering "Opus for this, Sonnet for that?"

GitHub keeps moving that decision into the runtime. The October 14 HydraFusion update is the latest step.

HydraFusion = a runtime that orchestrates multiple models into one response
              (not a feature for picking a single model)

What's new
  1. Refresh pool: Claude Opus 5.5, GPT-6 Astra, GPT-6.1 Sol, GPT-6 Luna
  2. Per-stage reasoning effort: medium for drafts, high for review
  3. A judging step in Cascade
  4. Critique now inspects the actual workspace with tools (parallel critics)
  5. HydraFusion Max, tuned for the most demanding tasks

It is still a research preview. But the update captures the shift clearly: from picking a model to designing how work gets distributed.

Start with the three execution patterns

HydraFusion picks one pattern per prompt.

Single    — one model solves it directly. No overhead.
Cascade   — a cheaper model drafts, a quality gate decides,
            escalating to a stronger model only when needed.
Critique  — one model drafts, a read-only critic from a different
            model family reviews in parallel, then one revision.

That is where the October 14 changes land:

Cascade
  Before: draft → escalate to stronger model when needed
  Now:    a judging step inspects the draft and requests
          a repair only when necessary

Critique
  Before: reviewed mainly through text summaries
  Now:    uses tools to inspect the actual workspace
          + multiple critic models review in parallel

Reasoning effort is now stage-specific: medium for the initial draft, high for review. Efficient drafting, deep checking — the budget-matching idea from our Reasoning High vs Max guide shipped as a product default.

HydraFusion vs Max

Max is the same architecture with a depth dial.

HydraFusion      — balanced, moderate token savings.
                   Agentic tasks needing speed/cost/performance balance.
HydraFusion Max  — frontier capability for demanding tasks.
                   Higher effort where depth matters, orchestration keeps tokens sane.

Both appear in VS Code, the GitHub Copilot app, and Copilot CLI, on Copilot Pro, Pro+, Business, and Enterprise plans with experimental or preview features enabled — subject to your organization's model policies.

Background: the September launch, the benchmarks, and the caveats

HydraFusion started as a research preview in Copilot CLI on September 4 and reached VS Code and the Copilot app on September 30. GitHub's offline test results versus Claude Opus 5, all at medium reasoning effort:

TerminalBench 2.1   : 67% lower cost, +4.9 points quality
DeepSWE             : 36% lower cost, -1.5 points quality
CheckpointBench(int): 65% lower cost, -0.1 points quality

Absolute figures (pass@1, cost per task)
  TerminalBench 2.1  HydraFusion 84.7% / $0.30
                     Opus 5      79.8% / $0.90
  DeepSWE            HydraFusion 62.6% / $2.70
                     Opus 5      64.1% / $4.20

Three things to remember when reading this table:

1. It wins on one benchmark of three (near-draws at big savings on the rest)
2. The comparators are a generation old (Opus 5.5 and GPT-6.1 Sol came later)
3. Offline tests, best-tuned configuration, specific pricing assumptions

Not "better than Opus" — "similar quality far cheaper, and stronger on one exam." Just like our Gemini 4 Argon analysis, different exams give different verdicts. That's normal now.

Billing and latency: two things to know up front

Billing
  Every leg (draft, critique, revision, escalation, retry) is billed at
  each model's standard rate, summed. The Auto selection discount does not apply.
  → charged in AI credits (1 credit = $0.01)

Latency
  Single behaves like one model call.
  Cascade and Critique add review passes and take longer.
  → fine for hand-off tasks, not for interactive loops

Pattern selection itself is lightweight; the passes are the cost. Same prompt, open gate, higher bill — and Critique always runs at least two model calls. That is why the CLI offers a per-run cap (--max-ai-credits), and why teams should set that cap when they set a default model.

Clear limits

- Research preview, no SLA, not intended for production (per docs)
- No published model roster, by stated policy
- Sub-agents are not orchestrated by HydraFusion
- Discarded drafts do not roll back edits already made on disk
- The context window shown is the smallest among participating models
- First-turn, well-scoped single-prompt tasks are the sweet spot

Do not misread the fourth item. "No patch applied on failure" is not working-tree protection: edits that reached disk stay there. Run it on a branch or disposable worktree and review the diff, as with any agent.

CodeBridge mini lab: run all three on the same job

1. Pick 2 verifiable tasks (e.g. fix one failing test, one multi-file refactor)
2. Run three configurations under identical conditions: Auto / HydraFusion / Max
3. Two repetitions each, recording:

   [ ] success rate (deterministic criteria, like tests passing)
   [ ] median elapsed time
   [ ] AI credits consumed
   [ ] models actually used and the pattern (Single/Cascade/Critique)
   [ ] read the diff (watch for tests deleted to go green)
4. Decide by: where did quality hold and budget shrink?

The point is not trusting GitHub's table but rebuilding it on your workload. The preview will shift — record CLI version and date with your results.

Conclusion: from picking a model to allocating work

The good question is no longer "which model?"
It is "how many passes is this task worth?"

Cheap drafts, deep review, sparse escalations. HydraFusion Max is a product attempt to make that allocation the default. The preview still is not production material, so let one self-made comparison table decide adoption. Without that table, "67% cheaper" is somebody else's story.

Further reading

References

Go deeper with a course

Splitting draft, review, and escalation into stages outlives any single multi-model feature. Practice designing harness, loop, and graph structures — deciding where to swap models and where to verify.