Why GitHub's HydraFusion Sends Your Code to a Rival Model for Review

Self-review by the same model is theater. Here is what GitHub, Cloudflare, and Spotify actually shipped instead, and how to copy the pattern this week.

Buried in GitHub's September 4 announcement of Project HydraFusion is a design choice that reads like a small implementation detail and is not. When HydraFusion picks its Critique workflow, it hands the draft to a critic that runs on a different AI model from the one driving your session, in a context with no tools, with read-only access to the codebase. GitHub's own documentation for the underlying rubber duck agent spells out why: the critic "is less likely to share the same blind spots, biases, or failure modes as the model that produced the work." And if no suitable contrasting model is available, Copilot CLI simply skips the critique step rather than let the same model grade its own homework.

Sit with that. The largest coding-agent vendor on earth looked at the practice everyone has been shipping for two years, the one where you ask the model "are you sure? check your work," and concluded it does not count.

The pattern showed up three times in 48 hours

I would not read much into one product decision. But the same shape landed three times between September 3 and September 4, from three organizations that do not coordinate their roadmaps.

GitHub's HydraFusion is one. It offers three execution patterns per request. Single sends one model at the task. Cascade lets a cheap model draft, then a quality gate decides whether to accept or escalate. Critique drafts, hands off to the cross-family read-only critic, and lets the drafting model revise exactly once. Around all three sit five stated operating principles, and four of them are about constraint rather than capability: bounded execution with explicit timeouts and cancellation, isolated review in tool-less contexts, fail-safe application so no patch reaches the repository if the workflow is cancelled or fails validation, and validated routing that verifies model bindings and availability before anything runs.

Cloudflare is two. Its Vulnerability Discovery and Remediation service, announced September 3 as invitation-only early access inside Cloudflare Managed Defense, runs GPT-5.6 Cyber over customer code and proposes both a patch and a scoped WAF rule. Three sentences from that post are worth memorizing. The model "cannot apply any patch or rule it proposes." Every proposal "must pass checks implemented outside the model," and if a check fails "the workflow stops before the proposal reaches customer review." And the harness "treats source code, logs, and request metadata as evidence to inspect, rather than instructions to follow." That last one is a prompt-injection posture written into the product architecture instead of a security blog post.

Spotify is three, and it is the most instructive because it started out wrong. An engineer there wanted to stop burning frontier tokens on file reads, so he wrote routing rules into CLAUDE.md telling Claude to delegate bulk reads to a cheaper model. His own assessment, published September 3: it "sort of worked." The rules were advisory. Claude could ignore them. Every project needed its own copy. The version that actually worked replaced instructions with PreToolUse hooks that block any Read over a configurable line threshold, defaulting to 350 lines, and redirect it. Reported mean savings on bulk reads across a Java monorepo: about 90%.

Three different problems. Three different companies. One conclusion: the check has to sit somewhere the model cannot reach.

What "structurally unable to cooperate" actually means

There is a real mechanism here, and it has three parts. Miss any one and you get the appearance of review without the substance.

Different failure modes. A model reviewing its own output shares its own priors. It liked that approach a moment ago for reasons that have not changed. GitHub's implementation picks a contrasting model automatically based on your session model, so a Claude session gets a GPT critic and vice versa, and it re-picks if you switch models mid-session with /model. You are not buying a second opinion. You are buying a second distribution of mistakes.

No hands. The rubber duck agent has read-only access through standard exploration tools and, per GitHub's docs, "cannot edit files or run commands that change your environment." This is the part teams skip. If your reviewer can also write, then under pressure it stops being a reviewer and starts being a second author, and the two roles collapse into one voice again. Cloudflare's version of the same rule is blunter: the model cannot apply what it proposes, full stop.

Enforcement below the prompt. Spotify's CLAUDE.md experiment is the cleanest natural experiment I have seen on this. Identical intent, identical rules, two different enforcement layers, and only the one below the model's discretion held. A prompt is a request. A hook is a wall.

Put this into practice

None of this needs a platform team. Here is the lowest-friction path, roughly in order of effort.

Turn on HydraFusion and watch what it routes. It is available on all GitHub Copilot plans through the Copilot CLI, billed at each underlying model's standard token rate rather than a premium tier.

/update
/experimental on
/model     # then select HydraFusion (Research Preview)

Start with substantial, well-scoped, single-prompt tasks, which is what GitHub says the preview is tuned for. The point of the exercise is less the output than watching which workflow it picks for which kind of request.

Add a reviewer that cannot write. If you are not on Copilot, build the same thing by hand: run your review pass through a subagent configured with read-only tools only, on a model from a different provider than your author model. In Claude Code that means a subagent whose tool list excludes Edit, Write, and mutating Bash. The constraint is the feature. Do not give the reviewer a way to "just fix it."

Move your rules out of the instructions file. Anything in CLAUDE.md that reads like a prohibition belongs in a PreToolUse hook. The shape is small: Claude Code sends the tool input as JSON on stdin, and your script returns a decision.

{
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "deny",
    "permissionDecisionReason": "Destructive command blocked by hook"
  }
}

Exit 0 with no output means the hook has no opinion and the call proceeds through the normal permission flow. Worth internalizing the asymmetry Anthropic's docs state directly: the hook can deny the call, but staying silent does not approve it.

Account for every leg, not the winning one. HydraFusion's first operating principle is complete accounting: aggregate cost and usage across drafting, critique, revision, escalation, retry, and fallback. If your homegrown router only logs the call that produced the final answer, your savings number is fiction. Log the discarded drafts too.

Start with the domain that has a checker. Cloudflare's service proposes patches and WAF rules, which are exactly the two artifacts you can validate mechanically. That is not a coincidence, it is the scope. Ask what in your pipeline has a compiler, a test suite, a schema, or a linter behind it, and route agent output there first.

Where this breaks

I want to be specific about the limits, because the pattern is being oversold already and the honest version is more useful.

Cross-family critique is not free and does not always win. GitHub published its own numbers against Claude Opus 5, and two of three went the wrong way on quality. TerminalBench 2.1 came in 4.9 points better at 67% lower estimated cost. DeepSWE came in 1.5 points worse at 36% lower cost. Internal CheckpointBench came in 0.1 points worse at 65% lower. GitHub also notes these are controlled offline results, specific to the evaluated benchmark revisions, workflow configurations, model pool, and pricing assumptions, with all models at the same medium reasoning level. The pitch is cost parity at near-equal quality. It is not "better."

Hooks are not a security boundary. Anthropic's own hooks documentation says it plainly: when Claude Code cannot determine which commands a Bash input runs, the hook fires regardless of the pattern, and because that filter is best-effort you should use the permission system rather than a hook to enforce a hard allow or deny. Hooks are excellent for routing and for making a policy non-optional in the common case. They are not a sandbox.

The reviewer inherits the substrate. On September 4, Google patched CVE-2026-85046, an actively exploited V8 type confusion bug, and CISA added it to the Known Exploited Vulnerabilities catalog the same day with a September 18 federal deadline. Every browser-driving agent runs on that engine. A read-only critic model is a fine idea and it does nothing about the process it lives inside being someone else's.

Latency is real. Spotify's delegation round trips take 10 to 30 seconds, with Portal capping a single invocation at 30 seconds. Below the line threshold, the overhead costs more than it saves. Their author is also candid that the worker model missed a subtle thread-safety bug that Claude spotted in seconds once given the right context, which is why their routing explicitly excludes debugging, architectural decisions, and safety-critical code.

And no checker covers judgment. Anthropic's Fermat's Last Theorem formalization, published the same day, is the purest example of this whole pattern: Lean's kernel verified the proof, and a separate comparator confirmed the theorem statement Claude proved actually matches Mathlib's statement of FLT. That is about as strong as mechanical verification gets. It still cannot tell you the statement was worth proving. Cloudflare's checks validate a patch; they never ask whether that code should have shipped. The verifier boom this week covered correctness. It did not touch whether the work was the right work, and that part is not waiting on a bigger model.

What to do with this

The question worth carrying into Monday is not which model you should switch to. It is a shorter one: what does my agent's output get checked against, and can the agent influence that check?

If the answer is "the model reviews its own work," you do not have review. If the answer is "the rules are in the instructions file," you have a request that mostly gets honored. If the answer is a different model family with no write access, or a compiler, or a test suite, or a policy engine that vetoes before a human ever sees the proposal, then you have something the model has to actually get past.

Three of the most capitalized engineering organizations on the planet independently concluded the same thing within 48 hours of each other. The cheap version of what they built is a subagent with its tools taken away and a hook file with about twenty lines in it. Go take your reviewer's hands away and see what it says.

Sources: Project HydraFusion and the rubber duck agent docs, GitHub, September 4 2026. Cloudflare Vulnerability Discovery and Remediation, September 3 2026. Portal by Spotify cut my Claude Code token usage by 90%, Spotify Engineering, September 3 2026. Claude Code hooks reference. Formalizing Fermat's Last Theorem, Anthropic, September 4 2026. CVE-2026-85046 coverage, Help Net Security, September 4 2026.

Medium metadata

Title: Why GitHub's HydraFusion Sends Your Code to a Rival Model for Review
Subtitle: Self-review by the same model is theater. Here is what GitHub, Cloudflare, and Spotify actually shipped instead, and how to copy the pattern this week.
Tags: AI Agents, GitHub Copilot, Software Engineering, LLM, Developer Tools
Suggested kicker image: two ink-drawn figures at one desk, one drafting and one holding a stamp, with the stamp-holder's hands drawn as empty gloves
Canonical: import from the fervorai.dev URL after publish