GitHub Copilot CLI HydraFusion: Comparing Single, Cascade, and Critique Workflows

AI coding agents are moving beyond the idea of sending every request to one large language model. Modern development tasks vary significantly in complexity, and using the same model and execution strategy for every task can waste both time and AI credits.

GitHub Copilot CLI's HydraFusion research preview takes a different approach. Instead of selecting only a model, HydraFusion selects an execution workflow for each request.

The current HydraFusion implementation can choose among three patterns:

Single
Cascade
Critique

Each pattern represents a different trade-off between quality, cost, and latency. Single favors direct execution, Cascade allows a lower-cost first attempt with escalation when necessary, and Critique adds an independent review and revision step.

This makes HydraFusion particularly interesting for repository-level coding tasks, where the best workflow is not always the same.

What Is HydraFusion?

HydraFusion is a runtime orchestration system available as a research preview in GitHub Copilot CLI.

Traditional AI-assisted development usually looks like this:

Developer
    |
    v
Choose Model
    |
    v
Send Prompt
    |
    v
Model
    |
    v
Result

HydraFusion changes the abstraction:

Developer
    |
    v
HydraFusion
    |
    v
Choose Workflow
    |
    +---- Single
    |
    +---- Cascade
    |
    +---- Critique
    |
    v
Final Result

The developer does not have to manually decide which workflow should be used. HydraFusion evaluates the task and chooses an execution pattern based on capability signals related to reasoning, code generation, debugging, and tool use.

The goal is therefore not simply to find the "best model."

It is to determine the best way to solve the task.

The Three HydraFusion Workflows

Single Workflow

Single is the most direct execution pattern.

One selected model receives the task and attempts to solve it.

Task
 |
 v
Selected Model
 |
 v
Result

There is no additional critique or escalation stage.

This workflow is useful when the task can probably be solved correctly in one pass.

Typical examples include:

Small code changes
Straightforward bug fixes
Simple refactoring
Documentation updates
Basic repository questions
Routine test generation

For example:

Rename the private method getUserData to loadUserData
and update its references.

Using a multi-stage workflow for such a change would add unnecessary overhead.

Cascade Workflow

Cascade introduces escalation.

The first model attempts the task, and a quality gate determines whether the result is good enough.

Task
 |
 v
Efficient Model
 |
 v
Quality Gate
 |
 +---- Pass ----> Final Result
 |
 +---- Fail ----> Stronger Model
                         |
                         v
                    Final Result

This provides an important cost-control mechanism.

A relatively efficient model gets the first opportunity to solve the task. If the result does not meet the required quality threshold, the workflow can escalate to a stronger model.

GitHub describes Cascade as an efficient model drafting a solution followed by a quality gate that can accept the result or escalate to a stronger model.

Critique Workflow

Critique adds an independent review step.

Task
 |
 v
Drafting Model
 |
 v
Initial Result
 |
 v
Independent Critic
 |
 v
Review Feedback
 |
 v
Drafting Model
 |
 v
Revised Result

The critic is read-only and comes from a different model family. It reviews the draft without modifying the workspace, after which the drafting model performs one revision.

This workflow is useful when a second perspective is more valuable than simply trying the same task again.

Single vs. Cascade vs. Critique

The simplest comparison is:

Workflow	Main Strategy	Cost Profile	Latency	Best For
Single	One model solves the task	Lowest potential overhead	Lowest	Straightforward tasks
Cascade	Start efficient, escalate if needed	Adaptive	Low to moderate	Uncertain complexity
Critique	Draft, independently review, revise	Higher	Higher	Complex or error-sensitive work

The important word is potential.

Single is not guaranteed to be cheaper for every task because model choice and token consumption still matter.

Likewise, Critique is not automatically more expensive in a meaningful business sense. If the additional review prevents a failed implementation or significant developer rework, the total engineering cost can still be lower.

How Single Works in Practice

Imagine a developer asks:

Add a null check before accessing customer.Address
in CustomerService.cs.

The Single workflow may be sufficient:

Prompt
  |
  v
Model
  |
  +--> Inspect file
  |
  +--> Modify code
  |
  +--> Run relevant validation
  |
  v
Result

There is little uncertainty.

A second model does not necessarily provide meaningful additional value.

Advantages of Single

Simple execution
Lower orchestration overhead
Lower potential latency
Easier to understand
Good fit for routine work

Disadvantages of Single

No independent review
No automatic escalation
Mistakes can survive the first pass
More dependent on the selected model's capabilities

How Cascade Works in Practice

Consider a more complicated request:

Investigate why the checkout service sometimes calculates
an incorrect discount after multiple promotional rules are applied.
Fix the problem and add regression tests.

The task requires repository exploration, debugging, implementation, and testing.

Cascade can approach it progressively:

Task
 |
 v
Efficient Model
 |
 +--> Inspect checkout logic
 |
 +--> Identify likely cause
 |
 +--> Implement fix
 |
 +--> Validate
 |
 v
Quality Gate
 |
 +---- Good enough ----> Finish
 |
 +---- Not sufficient --> Escalate
                              |
                              v
                        Stronger Model

This avoids automatically paying for the stronger model when the first attempt is already sufficient.

Advantages of Cascade

Efficient first attempt
Automatic escalation
Better cost-quality balance
Useful for uncertain task complexity

Disadvantages of Cascade

Quality-gate decisions add complexity
Failed first attempts consume resources
Escalation can increase latency
Developers have less direct control over the exact model path

How Critique Works in Practice

Now consider a security-sensitive task:

Update the authorization middleware so that users can access
only resources belonging to their organization.

Preserve existing API behavior and add regression tests.

A first implementation may look correct while still containing a subtle authorization flaw.

Critique provides an independent review:

Task
 |
 v
Model A
 |
 v
Implementation
 |
 v
Model B
 |
 +--> Review authorization logic
 +--> Check edge cases
 +--> Identify missing tests
 |
 v
Model A
 |
 v
Revision
 |
 v
Final Result

The important property is independence.

The critic does not simply continue the same reasoning process. It evaluates the draft from another model perspective.

Advantages of Critique

Independent review
Better detection of subtle issues
Useful for complex code
Can improve reliability
Provides another reasoning perspective

Disadvantages of Critique

Additional model invocation
Higher potential token consumption
Higher latency
Review quality still depends on the critic
One critique pass cannot guarantee correctness

Why HydraFusion Does Not Always Use Critique

It may seem logical to ask:

If critique improves quality, why not critique every task?

Because quality is only one dimension.

Consider a simple task:

Add a missing test for CalculateTax().

A full draft-review-revise workflow could require:

Draft
+
Critique
+
Revision

That may be unnecessary.

For a high-risk task:

Rewrite the payment authorization flow.

the additional review could be worthwhile.

HydraFusion therefore treats workflow selection as an optimization problem involving performance, cost, and latency.

A Cost Comparison

Consider three hypothetical workflows.

Assume:

Small model = 2 cost units
Strong model = 10 cost units

These numbers are illustrative only.

Single

Strong model
= 10 units

Cascade

Suppose the efficient model succeeds:

Small model
= 2 units

If escalation is necessary:

Small model + Strong model
= 2 + 10
= 12 units

Critique

Suppose the draft uses a smaller model, followed by a critic and revision:

Draft = 2
Critique = 3
Revision = 5

Total = 10 units

The interesting result is that a multi-model workflow does not necessarily cost more than a single frontier-model attempt.

But this is only a conceptual example.

Actual HydraFusion cost is based on the tokens consumed by the constituent models and their standard rates. There is no separate HydraFusion charge.

Why Token Accounting Matters

A common mistake when comparing AI workflows is counting only the final response.

Consider:

Initial Draft
     +
Critique
     +
Revision
     +
Retry

All of these stages can contribute to usage.

HydraFusion explicitly accounts for workflow legs such as:

Drafting
Critique
Revision
Escalation
Retry
Fallback

GitHub describes this as complete accounting across the workflow rather than counting only the final successful stage.

A realistic cost model is therefore:

Total Cost =
Input Tokens
+
Cached Input Tokens
+
Output Tokens
+
Additional Workflow Calls

The exact amount depends on the models and context involved.

Quality vs. Cost

The three workflows can be viewed as different points on a quality-cost curve.

Quality
  ^
  |
  |                    Critique
  |                      *
  |
  |             Cascade *
  |
  |       Single *
  |
  +----------------------------> Cost

This diagram is conceptual rather than a benchmark result.

The objective is not to maximize one metric independently.

Instead:

Useful Result =
Quality
+ Reasonable Cost
+ Acceptable Latency

A workflow that produces excellent code but takes too long may not be ideal for an interactive development task.

Likewise, a very cheap workflow that produces code requiring extensive manual repair may be more expensive overall.

Quality vs. Latency

Latency is particularly important in developer workflows.

Single can generally finish with one model execution path.

Cascade may require:

First attempt
     ↓
Quality evaluation
     ↓
Possible escalation

Critique can require:

Draft
 ↓
Review
 ↓
Revision

Therefore, developers should expect multi-stage workflows to have more execution overhead.

For tasks where immediate feedback matters, Single may be preferable.

For tasks where correctness matters more than response time, Critique can be more attractive.

What the Benchmarks Show

GitHub evaluated HydraFusion policies across three agentic coding benchmarks:

TerminalBench 2.1
DeepSWE
CheckpointBench

The comparison used Claude Opus 5 as the primary baseline, with GPT-5.6 Sol also included as a comparison baseline during evaluation. GitHub measured verified task quality and complete estimated workflow cost, including additional workflow legs.

The reported best-tuned HydraFusion configuration produced these results against Opus 5:

Benchmark	Estimated Cost vs. Opus 5	Quality vs. Opus 5
TerminalBench 2.1	67% lower	+4.9 percentage points
DeepSWE	36% lower	-1.5 percentage points
CheckpointBench	65% lower	-0.1 percentage points

These results are important because they show that orchestration can achieve competitive quality without simply sending every task to the strongest evaluated model.

However, they should not be interpreted as a guarantee of the same savings on an individual developer's workload.

GitHub describes HydraFusion as an active research effort, and its models, workflows, availability, and behavior can change during the preview.

Which Workflow Is Best for Which Task?

A practical decision matrix looks like this:

Task Type	Recommended Pattern	Reason
Rename a variable	Single	Very low complexity
Add a simple unit test	Single	Straightforward implementation
Small bug fix	Single or Cascade	Depends on uncertainty
Repository-wide refactor	Cascade	May require stronger reasoning
Difficult debugging	Cascade	Allows escalation
Security-sensitive change	Critique	Independent review is valuable
Complex business logic	Critique	More reasoning validation
Architecture-heavy task	Cascade or Critique	Higher uncertainty
Large migration	Critique	Multiple validation points can help

These are practical guidelines rather than fixed HydraFusion rules.

HydraFusion itself makes the workflow selection.

Single Is Not the Same as "Low Quality"

It is important not to misunderstand the Single workflow.

Single does not mean that HydraFusion intentionally chooses a poor model.

It means that one model is considered sufficient for the task.

For example:

Task
 ↓
Capability Assessment
 ↓
Single
 ↓
Appropriate Model
 ↓
Result

The objective is efficient execution, not simply minimizing model capability.

Cascade Is a Quality Safety Net

Cascade is particularly useful when the system cannot confidently determine whether an efficient model will succeed.

The first attempt acts as an inexpensive experiment.

Can an efficient model solve this?
       |
       +---- Yes ----> Finish
       |
       +---- No -----> Escalate

This is similar to progressive optimization in software systems.

You do not necessarily allocate the maximum possible resources before knowing that they are required.

Critique Is an Independent Quality Layer

Critique addresses a different problem.

Suppose Model A produces a solution based on an incorrect assumption.

A second pass by Model A might preserve that assumption.

An independent critic can challenge it:

Model A
  |
  v
Assumption
  |
  v
Implementation
  |
  v
Model B
  |
  +--> "This assumption does not hold
        for requests from another tenant."

The critic therefore acts as a separate reasoning layer.

GitHub specifically describes the critic as an independent, read-only model from a different model family.

Security Considerations

Multi-model workflows introduce additional execution stages, so security boundaries remain important.

HydraFusion uses isolated review steps for critique. GitHub describes these review steps as tool-less contexts, while solver steps operate through the normal permission-aware agent loop.

This separation matters.

A critic should be able to inspect the relevant result without automatically receiving permission to modify the repository.

A useful conceptual model is:

Solver
 |
 +--> Workspace Access
 +--> Development Tools
 +--> Repository Changes
 |
 v
Draft

Critic
 |
 +--> Read-Only Review
 +--> No Repository Modification
 |
 v
Feedback

This reduces the risk that a review stage unintentionally changes the code it is supposed to evaluate.

Fail-Safe Execution

Another important principle is what happens when orchestration fails.

Imagine:

Draft
 ↓
Critique
 ↓
Revision
 ↓
Validation Failure

The system should not blindly apply an incomplete result.

GitHub describes HydraFusion as using fail-safe application behavior, where no patch is applied when the workflow is cancelled or fails validation.

This is especially important for repository-level agents.

An incomplete AI workflow should not leave the working tree in an ambiguous state simply because one execution stage failed.

Bounded Execution

Multi-stage workflows can consume more resources than a single model call.

HydraFusion therefore uses explicit timeout and cancellation behavior for workflow legs.

Conceptually:

Workflow
   |
   +--> Draft
   |     |
   |     +--> Timeout
   |
   +--> Critique
   |     |
   |     +--> Timeout
   |
   +--> Revision

Bounded execution helps prevent a failed or stalled stage from consuming unlimited time or resources.

Visibility Is a Current Trade-Off

HydraFusion does not expose every intermediate draft as if it were the final answer.

GitHub explains that HydraFusion can draft, critique, revise, or discard intermediate results, so the current preview shows workflow stages while holding intermediate drafts until the final coherent result is ready.

This has an advantage:

Developer
   |
   v
One coherent result

But it also creates a disadvantage:

Developer
   |
   +--> Less visibility into intermediate reasoning

For developers accustomed to watching every agent action, this can feel less transparent.

GitHub is actively exploring better progress visibility during the research preview.

HydraFusion vs. Auto Model Selection

HydraFusion should not be confused with ordinary automatic model selection.

Auto model selection answers:

Which model should solve this task?

HydraFusion answers:

Which execution workflow should solve this task?

The difference is significant.

Auto

Task
 ↓
Model Router
 ↓
One Model
 ↓
Result

HydraFusion

Task
 ↓
Workflow Router
 ↓
Single / Cascade / Critique
 ↓
One or More Models
 ↓
Result

GitHub explicitly describes Auto as selecting a model per request, while HydraFusion selects a workflow that may involve multiple models.

How to Try HydraFusion

HydraFusion is currently available as a research preview through GitHub Copilot CLI.

The documented setup is:

/update

Then enable experimental features:

/experimental on

Finally open the model picker:

/model

and select:

HydraFusion (Research Preview)

GitHub states that HydraFusion is currently available through the experimental experience in Copilot CLI.

Because this is a research preview, exact availability and behavior can change.

How Developers Should Test the Three Workflows

If you want to evaluate HydraFusion rather than simply try it, use a controlled test set.

Create three categories:

Category A
Simple tasks

Category B
Medium-complexity tasks

Category C
Complex tasks

Then track:

Metric	What to Record
Task success	Whether the requirement was completed
AI cost	Credits/tokens consumed
Latency	Time until useful result
Rework	Manual changes required
Tests	Tests passing after implementation
Review findings	Issues discovered by developers
Defects	Problems found after merge

Do not evaluate HydraFusion only by asking whether the final answer "looks good."

A coding agent should be evaluated by whether it produces an acceptable engineering result.

A Practical Evaluation Example

Suppose you have 30 repository tasks:

10 simple
10 medium
10 complex

For each task, record:

Task ID
Workflow
Model usage
AI credits
Elapsed time
Tests passed
Manual fixes
Final acceptance

You might eventually discover a pattern such as:

Simple
→ Single performs well

Medium
→ Cascade reduces unnecessary frontier usage

Complex
→ Critique reduces review rework

That is much more useful than simply saying:

HydraFusion is cheaper.

The real question is:

Which workflow provides the best total engineering outcome for this class of task?

Common Mistakes

Treating Critique as a Guarantee

An independent critic improves the review process, but it cannot guarantee correctness.

Measuring Only AI Credits

A lower AI cost can be offset by higher developer rework.

Ignoring Latency

A multi-stage workflow may be economically attractive but too slow for an interactive task.

Comparing Different Tasks

Benchmark comparisons are meaningful only when the underlying tasks and evaluation methodology are controlled.

Assuming Preview Behavior Is Permanent

HydraFusion is a research preview. Current workflow behavior should not be treated as a permanent product contract.

Giving Large, Ambiguous Tasks

Poorly scoped requirements make it harder for any orchestration strategy to succeed.

Best Practices

Use Single for Straightforward Work

Do not add review stages when the task is trivial.

Let Cascade Handle Uncertainty

When the task might be simple or difficult, escalation provides a useful middle ground.

Prefer Critique for High-Risk Changes

Independent review is particularly valuable for security, authorization, concurrency, and complex business logic.

Measure Total Cost

Include all workflow legs:

Draft
+
Critique
+
Revision
+
Escalation
+
Retry
+
Fallback

Measure Human Rework

The developer's time is part of the actual engineering cost.

Keep Tasks Well Scoped

A clear requirement makes workflow evaluation more reliable.

Validate With Tests and CI

AI orchestration does not replace normal engineering validation.

Conclusion

GitHub Copilot CLI HydraFusion represents a shift from model selection to workflow selection.

Instead of forcing every coding task through the same model, HydraFusion can choose among three execution patterns:

Single
   |
   +--> One model solves the task

Cascade
   |
   +--> Efficient model
   +--> Quality gate
   +--> Optional escalation

Critique
   |
   +--> Draft
   +--> Independent review
   +--> Revision

Single is optimized for direct execution. Cascade provides a path from efficient first attempts to stronger inference when necessary. Critique adds an independent perspective when additional validation is valuable.

The benchmark results reported by GitHub suggest that this approach can achieve competitive coding quality with substantially lower estimated workflow cost on the evaluated workloads.

But the more important lesson is broader than HydraFusion itself.

The best AI coding workflow may not always be the one with the strongest individual model. It may be the workflow that uses just enough intelligence, review, and escalation to solve the task correctly without spending unnecessary resources.

That is the core idea behind runtime multi-model orchestration, and it is likely to become increasingly important as AI coding agents handle larger and more complex software-development tasks.