HydraFusion adds Max: what changed on October 14 and how to evaluate it

The announced changes concern orchestration

The October 14 GitHub announcement describes an updated model pool, reasoning tailored to drafting and review, judgment and conditional repair in Cascade, and stronger tool inspection with parallel critics in Critique. Max applies the same architectural approach to more demanding work. Neither option became generally available for production through this announcement.

Editorial interpretation: the returned answer still needs acceptance evidence. Whether a failure is fixed without breaking existing behavior matters more than counting participating models. The announcement does not establish that every task becomes faster, cheaper or correct.

Check the account, client and policies

The announcement lists Pro, Pro+, Business and Enterprise, across VS Code, the Copilot app and CLI, with preview or experimental features enabled and organization model policies respected. A colleague’s picker does not establish access for your own account.

The HydraFusion documentation identifies it as an orchestrator and states that the research preview has no SLA and is not intended for production workloads. It also describes per-model billing and no Auto-selection discount. Inspect actual usage rather than assuming a flat charge or importing an untested savings percentage.

Original evaluation case: prevent duplicate refunds

This is a proposed exercise, not an account benchmark performed for this article. Use a practice repository disconnected from payment systems. Repeated submissions with the same refundId should record one refund; different IDs should remain separate. Write a failing test and save the starting commit before comparing approaches.

Ask for changed locations, the identity rule, boundary cases and actual test results. If refund identity is undefined, require a clarification instead of allowing the implementation to merge transactions because amounts happen to match. A polished explanation alone cannot accept a business rule.

This fictional refund exercise is disconnected from real payments. Repeated submissions with the same refundId must record one refund; different refundIds must remain separate. Locate the relevant implementation and failing tests, then propose the smallest repair. Do not change billing, account permissions or external systems. Report assumptions, changed files, tests actually run and unrun checks. Never label an unrun test as passing.

Separate correctness from cost and open questions

Start each comparison from the same clean state. Check that repeated IDs do not duplicate entries, different IDs survive, and existing ordinary-refund tests still pass. Review concurrency and persistence assumptions separately: a serial practice test does not establish production payment safety.

Record usage and elapsed observations in a second part of the report. Keep failures and their conditions rather than combining everything into a flattering score. For a different availability question, see Gemini 4 Argon’s Copilot rollout. That concerns one model integration, whereas this update concerns runtime orchestration.

Expand “refund once” into six concrete requests

Complete the earlier exercise with a manually checkable sequence. Every ID, amount and state is invented; no payment service or real ledger is connected. The contract is: the same refundId and amount returns the existing record without adding a refund; the same ID with a different amount is a conflict that does not overwrite the original. In this exercise, the record count increases only on commit. Currency conversion, partial refunds and provider-specific rules are outside the contract.

Start from an empty ledger. Six received requests do not establish six successful refunds, and the second R1 response adds no money. After step three, the committed amount is 12 + 7 = USD 19. Step five is explicitly a failure before commit, leaving USD 19 until the retry.

Missing acknowledgment does not establish a missing commit

Add step seven: R4 / USD 3 commits, but the caller receives no acknowledgment. The stipulated ledger now has four records and USD 27. Retrying the same ID must leave four records and USD 27. A candidate that replaces the ID after a timeout and creates another record violates this contract. This differs from the pre-commit failure in step five; one undifferentiated retry rule cannot explain both.

This gives the orchestration update an acceptance question. After a draft implementation, review should identify specific sequences: conflicting amounts, failure before commit and acknowledgment lost after commit. Praise for a comprehensive explanation is insufficient. After a repair, restart from the same empty ledger and inputs. Concurrency is a separate concern: passing sequential cases does not establish that simultaneous requests create only one record. Real systems require corresponding constraints and concurrent tests.

Judge whether Cascade’s judgment and repair or Critique’s workspace inspection help your task through such inspectable differences. Retain unrun cases and actual usage charges. The cost-per-deliverable ledger explains useful denominators; the number of participating models is not a refund-accuracy measure.

This is a simulation without payment connections or real refunds. Use this article’s R1–R4 contract and inputs.
For each step list request ID, amount, whether commit occurred, returned state, ledger count and amount.
Distinguish: same ID/same amount; same ID/different amount; failure before commit; and commit with lost acknowledgment.
Identify the smallest sequence in which the candidate violates the contract, and propose the missing test. Mark unrun tests as unrun. Do not infer real-provider or concurrency correctness.

Choose a task with observable value

Our editorial suggestion is to start with a well-scoped change across files that has runnable tests. For a one-line wording edit, extra orchestration may provide little observable benefit. If the meaning of “duplicate” is unclear, define it before comparing options. Record access limitations without changing organization policy merely to try a preview.

For team expense ownership, read the Copilot code-review billing controls explainer, while keeping that feature’s rules separate from HydraFusion billing. Preserve announcement, checking and experiment dates so later updates can identify exactly which evidence changed.