· 阅读中文版 →
You might have seen the news about Project HydraFusion, a new research preview in GitHub Copilot CLI. You pick it like any other model, but behind the scenes it decides how to solve the task, not just which model to call.
Sometimes that means one model is enough. Other times, it means getting a second opinion or bringing in a stronger model. Here's what that looks like in 31 seconds:
What you already (probably) do by hand
You might already be juggling models and subscriptions. You send a request, the answer looks weak, and you take it to another model for a second opinion. Maybe you already have a review step in place, like Rubber Duck in GitHub Copilot CLI, to help you decide whether to trust the output.
HydraFusion automates that cycle. You make one selection, and it handles the routing, including whether to bring in another model for review or escalate to a stronger one. You get one answer and one permission-aware change set without having to coordinate those steps yourself.
Three ways it can run a task
For each of your requests, HydraFusion picks one of three execution patterns:
Single. One model does the job directly. If that's enough to meet the quality bar, there's no need to add more steps.
Cascade. An efficient model drafts first. Then a quality gate either accepts the draft or decides it needs more work and escalates to a stronger model. You only pay for that more expensive pass when the first attempt doesn't meet the quality bar.
Critique. One model drafts, and a model from a different family reviews in a read-only, tool-less context. Basically, the same spirit as Rubber Duck. The original drafter then takes that feedback and revises once. This is useful when a second set of eyes would help more than just making another attempt without feedback.
The routing treats this as an optimization problem: find the lightest workflow that's likely to meet the quality bar. If the simpler approach gets you there, that's enough.
What the numbers actually say
In offline evals against Claude Opus 5:
Now, let's talk about savings. We need to look at this table carefully because the comparison is against always running Opus 5, with every leg counted: draft, critique, revise, escalate, retry, and fallback. It's not a promise that HydraFusion will be cheaper than a single inexpensive Auto pick on a smaller task.
Cascade and Critique add model calls. That's the trade-off when quality matters, and it's the same sort of decision you'd make if you were coordinating those models manually. HydraFusion can cost less than always using Opus and still cost more than a simpler workflow. Both can be true; they're different baselines.
I'm still doing my own testing around token usage, particularly how this compares with manually passing context between models.
Guardrails for shipping patches
The runtime is built so multi-model load doesn't trash your repos:
- Cost is counted across every leg.
- Legs have timeouts and cancellation.
- Reviews run isolated and tool-less so the critic can't mutate the tree.
- Failed or cancelled workflows apply no patch.
- Routing is validated before anything runs.
The end result is one coherent response, with all the permission checks you usually get.
How to try it today
Best fit right now: first-turn, well-scoped coding tasks in Copilot autopilot. Multi-turn polishing is next on their list. Feedback goes through /feedback in Copilot CLI or the GitHub Community discussion thread.
HydraFusion is still a research preview, so we can expect the names, models, and behavior to change as it evolves. But I think the core philosophy is here to stay. There's always going to be a new model, and the next improvement isn't just going to come from picking a better one. We also need to build a better plan for how to use those models on each task. That's what HydraFusion is tackling right now.
Read the official blog release: Project HydraFusion on the GitHub Blog
Top comments (0)