Copilot HydraFusion adds a deeper review mode. Check the extra passes.

A coding agent can answer with one model, or send the task through a draft, a review, and a revision. The second path may catch more problems. It can also take longer, use more AI credits, and leave you with changes to inspect even if a draft was later discarded.

That tradeoff is the point of GitHub Copilot's HydraFusion update. On October 14, GitHub added a HydraFusion Max option and updated how the preview coordinates models. You can choose HydraFusion for a substantial, well-scoped coding task; Max is aimed at tasks where deeper reasoning and more thorough analysis matter. But HydraFusion remains a research preview. GitHub says it has no service-level agreement and isn't intended for production workloads. Its current documentation also warns that discarded drafts may leave workspace edits behind.

The useful question isn't whether Max is the “best” setting. It's whether the task needs the extra review path, and whether you can afford to check what it changed.

HydraFusion is a workflow picker, not a model

HydraFusion appears in Copilot's model picker, but it isn't one model. It's a runtime orchestrator: it chooses an execution pattern, reasoning effort, and models for each request, then returns a single response. GitHub describes three patterns in its documentation:

| Pattern | What happens | Likely tradeoff | | -------- | --------------------------------------------------------------------------------------- | ------------------------------------------------------------- | | Single | One model handles the task. | Fewer passes for a direct task. | | Cascade | A model drafts; a judging step can accept the result or ask for a repair or escalation. | A check and possible extra work. | | Critique | A model drafts; other models review in parallel; the original model revises once. | More review perspectives, with more time and potential usage. |

The patterns address different jobs. A small, clear change may be fine with one model. A change across files may benefit from a reviewer checking the actual workspace. A task that needs a deliberate second look may justify a critique pass. HydraFusion decides which pattern to use for each prompt, so two requests in the same conversation can take different routes.

That is different from Copilot's Auto selection. Auto chooses one model for the request. HydraFusion chooses the execution pattern, which may involve multiple models. You don't pick the model for each stage yourself, and you can't choose or exclude the models HydraFusion uses. Its model pool can change as GitHub adds models and evaluates them.

The October 14 update expands the pool to include Claude Opus 5.5, GPT-6 Astra, GPT-6.1 Sol, and GPT-6 Luna, according to GitHub's announcement. The exact mix used for a given task varies with the workflow. GitHub says it now assigns medium reasoning effort to drafting and high effort to review; Max can use extra-high reasoning for demanding tasks. Those settings describe how the orchestration is designed. They don't prove that any particular code change is correct.

Who can use it now

The announcement lists Copilot Pro, Pro+, Business, and Enterprise plans, subject to the organization's model policies and experimental or preview features being enabled. HydraFusion and Max are available in VS Code, the GitHub Copilot app, and Copilot CLI. The rollout is gradual, so a supported plan doesn't guarantee the option is already visible in your client.

The setup differs a little by client. GitHub's usage guide says the CLI needs experimental features enabled; VS Code requires version 1.140 or later and the chat.copilot.hydraFusion.enabled setting; and the Copilot app needs HydraFusion enabled in its Experimental settings. An organization administrator can also control preview features and the models that are allowed. If the option is missing, check those settings and your client version before assuming your plan lacks access.

This is a product update, not a production-readiness announcement. The guide explicitly calls HydraFusion a research preview, says behavior may change, and says not to use it for production workloads. That's a sensible boundary for a system whose routing and models can change during the preview. If a task affects live customer data, payments, security controls, or a production release, follow your usual review and release process; don't make a preview orchestrator the control that decides whether a change is safe.

The bill follows the route

HydraFusion doesn't have a separate line-item fee, but that doesn't make it free. GitHub says each model pass is billed at that model's standard rate, and the automatic-selection discount doesn't apply. If a workflow uses several models, a task can consume more AI credits than using one model. The Copilot pricing documentation explains how token use becomes credits and how included allowances work across individual and organization plans.

GitHub presents the update as balancing quality and efficiency: use extra passes when they may help, not automatically on every task. That is the intended design, not a promise that your tasks will cost less. The actual spend depends on the work, context size, models selected, and route used. Max's label is no substitute for checking usage.

There's a practical complication: a single final response can conceal several passes. GitHub's docs say you can see progress through execution steps in supported clients, and the CLI's /usage command can show the AI credits used by each model in a session. You can also collect detailed execution logs in the CLI with /collect-debug-logs. Those are useful ways to inspect a run. Don't treat one task as a forecast for a team's monthly bill.

A small independent project shows why that visibility matters. The HydraFusion traces repository builds a dashboard from the Copilot CLI's local session log to display the models, phases, and credit costs behind a run. Its author describes observations across 24 turns, not a controlled evaluation of quality. The project also says the session log isn't a stable public API and its details may change. So it illustrates a way to examine routes; it doesn't establish what a typical HydraFusion task costs or whether the route improves code.

If you're trying the preview, check the actual usage information available in your client and compare it with a single-model run on similar work. Keep the task and starting conditions as similar as you reasonably can. One example can help you understand the interface; it can't establish a reliable savings rate.

Review the working tree, not just the final answer

The most consequential limitation in the documentation is easy to miss: if HydraFusion discards a draft, edits that draft already made in your workspace aren't automatically undone. A workflow may revise its reasoning while your files still contain an earlier patch. The final response and the current working tree can therefore tell different stories.

That means review starts with the files. Before accepting a result, inspect the diff, confirm that only intended paths changed, and run the checks that fit the project. For code that handles money, customer records, access rules, or data deletion, make the reviewer inspect the relevant behavior and test the boundary cases. Don't infer from the number of review models that the review was complete.

A model review can improve the odds of catching a mistake, but multiple model passes aren't automatically independent verification. They can share blind spots, misunderstand the requirement, or approve a faulty assumption. Keep a human decision point for merge, release, or other consequential action. The tool can help produce a candidate patch and review notes; your project still needs its own tests and acceptance criteria.

HydraFusion also works separately from subagents and doesn't start them, according to the documentation. If your current workflow relies on splitting work among agents, selecting HydraFusion won't create that coordination step for you. Its role is to pick a single-versus-multi-model execution pattern for a request.

A bounded way to evaluate the update

You don't need a benchmark lab to decide whether the option is useful to you. You do need a task where the result can be checked. Pick a contained, non-production change with an acceptance condition you can state before the run, such as “the parser rejects this malformed input and preserves valid records.” Avoid a vague request like “clean up this module”; it makes it harder to tell whether the result improved anything.

For a simple comparison, record four things for each attempt:

1. The task and starting state. Use the same issue description, files, and acceptance checks. Note whether you selected HydraFusion, Max, Auto, or a specific model.
2. The route and elapsed time. Where the client exposes execution steps, note whether it used Single, Cascade, or Critique. Include the wait and review time, not just the first generated response.
3. The working-tree result. Inspect the diff, run the checks, and record any unrelated edits, errors, or fixes you had to make yourself.
4. The usage. Check the credits or other usage record for the run. Don't compare a cheap short task with a large change and call the difference an orchestration effect.

You're not trying to prove HydraFusion is generally better. You're trying to see whether the extra process helps on one kind of work you actually do. If a second pass catches a bug that your normal review would have missed, that can be useful. If it adds delay and credits without improving the verified result, Auto or a directly selected model may be the better fit for that task.

Set a stop condition before experimenting. For example, stop if the final answer doesn't explain the relevant change, if the workspace contains edits the run doesn't account for, if a required test fails, or if usage exceeds the amount you were willing to spend on the trial. A preview is easier to evaluate when “stop” is a real option rather than a failure to get the tool to finish.

What the launch evidence does and doesn't establish

GitHub's September announcement reports controlled offline evaluations across three agentic coding benchmarks. The company says HydraFusion improved verified task quality by 4.9 percentage points at 67% lower estimated cost than Claude Opus 5 on TerminalBench 2.1. Those are GitHub's benchmark results, under the evaluation setup and comparison it describes. They aren't independent results, a guarantee of savings on your codebase, or evidence that Max is better on your team's tasks.

The October update describes a newer model pool and orchestration changes, but doesn't provide a new independent benchmark in the announcement. I also didn't find independent testing of the October 14 update that would establish how it performs on ordinary team repositories. That leaves a useful but limited case for trying it: GitHub has made the preview more accessible across clients and added a higher-effort option, while the costs, routes, and results remain task-dependent.

There is a fair reason to stick with Auto or one chosen model. If your work is small and easy to verify, extra review passes can add friction without changing the result. If you need a predictable model, a fixed cost, or a workflow that can be audited consistently, HydraFusion's changing pool and preview status may not fit. And if nobody has time to review a diff or run the tests, adding more model review doesn't solve the missing human check.

For a bounded, non-production task, HydraFusion is now worth evaluating if your plan and organization allow it. Use Max only when the work warrants the extra reasoning, then inspect the route, the credits, the diff, and the test result. Keep using Auto for routine work that doesn't benefit from that additional process.

Sources: GitHub's HydraFusion update, the HydraFusion usage and limitations guide, Copilot models and pricing, GitHub's original evaluation announcement, and an independent HydraFusion tracing project.