AIREITERGitHub HydraFusion ist ein Orchestrierungssystem in der Research Preview für Copilot CLI. Seine Offline-Benchmark-Ergebnisse sind kein Beleg dafür, dass es in großen, unübersichtlichen Repositories ebenso gut funktioniert.
Die kurze Einschätzung vorab
Wenn du einen GitHub-Copilot-Plan hast und eine größere, klar abgegrenzte Coding-Aufgabe in einem einzigen Prompt beschreiben kannst, lohnt sich ein Test mit GitHub HydraFusion. Für kritische Produktivänderungen oder lange Dialog-Sessions würde ich es derzeit noch nicht zum Standard machen: GitHub führt die Funktion weiterhin als Research Preview und nennt besseren Multi-Turn-Support ausdrücklich als künftige Arbeit.
HydraFusion ist kein neues Foundation Model. Das System läuft innerhalb von GitHub Copilot CLI und entscheidet zur Laufzeit, ob eine Aufgabe mit einem Modell erledigt wird, eine Eskalation braucht oder vor der Antwort unabhängig geprüft werden soll.
HydraFusion im Copilot CLI aktivieren
Die Preview wird im Copilot CLI aktiviert, nicht über die gewöhnliche Modellauswahl in VS Code. Laut offizieller GitHub-Ankündigung steht sie über eine experimentelle Befehlsfolge für alle Copilot-Pläne bereit. Die Installation und Anmeldung behandelt der Copilot CLI quickstart separat.
- Aktualisiere Copilot CLI mit
/update. - Schalte experimentelle Funktionen mit
/experimental onein. - Öffne die Modellauswahl über
/model. - Wähle HydraFusion (Research Preview).
- Starte mit einer größeren, eindeutig eingegrenzten Coding-Aufgabe statt mit einem langwierigen Konversationsprojekt.
Falls HydraFusion nicht angezeigt wird, aktualisiere zuerst das CLI und prüfe, ob dein Copilot-Konto, die Organisationsrichtlinie und dein CLI-Build die Preview unterstützen. Die offizielle Ankündigung von GitHub ist maßgeblich für die aktuelle Befehlsfolge; Name und Verfügbarkeit der Preview können sich ändern.
In Suchergebnissen erscheint außerdem AICPS/hydrafusion, ein Forschungs-Repository zur Sensorfusion für autonome Fahrzeuge. Dieses Projekt hat nichts mit GitHubs Project HydraFusion für Copilot zu tun.
Welcher Workflow zu welcher Aufgabe passt
HydraFusion wählt zwischen drei Ausführungsmustern, abhängig von erwarteter Qualität, Kosten und Latenz der Aufgabe. In der aktuellen Preview ist das praktisch kein manuell auswählbarer „Modus“: GitHub stellt HydraFusion als modellähnliche Option dar, die den zugrunde liegenden Workflow zur Laufzeit bestimmt.
| Workflow | So läuft er ab | Geeignet zum Einstieg für | Wichtigster Kompromiss |
|---|---|---|---|
| Single | Ein Modell bearbeitet die Aufgabe direkt. | Einfache Änderungen, Erklärungen oder kleine Fehlerbehebungen. | Geringster sichtbarer Overhead, aber ohne Eskalation oder unabhängige Prüfung. |
| Cascade | Ein effizientes Modell erstellt zunächst einen Entwurf; ein Qualitäts-Gate kann die Aufgabe an ein stärkeres Modell eskalieren. | Aufgaben, die vielleicht einfach sind, aber mehr Leistungsfähigkeit benötigen könnten. | Spart Kosten, wenn der erste Durchlauf genügt, ergänzt aber ein Gate und potenziell einen zweiten Aufruf. |
| Critique | Ein Modell entwirft die Lösung, ein isolierter Kritiker aus einer anderen Modellfamilie prüft sie, anschließend überarbeitet das erste Modell sie einmal. | Änderungen, bei denen eine zweite Perspektive Fehler finden kann. | Mehr Aufrufe und höhere Latenz; der Kritiker hat keinen direkten Tool-Zugriff. |
Single: direkt zur Lösung
Single ist der geradlinigste Weg. Laut GitHub erhält ein einzelner Solver die Aufgabe und arbeitet im üblichen, berechtigungsbewussten Copilot-Agent-Loop. Das passt besonders zu Anfragen mit klarer Umsetzung und kurzem Testweg.
Der Vorteil liegt im geringeren Workflow-Overhead. Eine eingebaute zweite Meinung gibt es bei Single allerdings nicht.
Cascade: erst effizient, bei Bedarf leistungsstärker
Cascade beginnt mit einem effizienten Modell. Ein Qualitäts-Gate entscheidet dann, ob dessen Ergebnis ausreicht oder die Aufgabe eskaliert werden sollte. Die ökonomische Idee dahinter: Routineanfragen sollen nicht automatisch das stärkste verfügbare Modell verbrauchen.
Cascade kann Kosten senken, wenn der erste Durchlauf das Gate passiert. Eine allgemeingültige Eskalationsrate veröffentlicht GitHub jedoch nicht. Bewerte den Workflow daher anhand der beobachteten Resultate deiner Aufgaben, statt davon auszugehen, dass jede Anfrage den günstigen Pfad nimmt.
Critique: Entwurf, unabhängige Prüfung, eine Überarbeitung
Critique ergänzt einen separaten Reviewer aus einer anderen Modellfamilie. Laut GitHub arbeitet der Kritiker in einem isolierten Kontext ohne Tools, prüft den Entwurf und gibt dem ursprünglichen Solver Feedback für genau eine Überarbeitung. Das Repository kann er nicht selbst bearbeiten.
Damit ähnelt Critique einem automatisierten Peer Review, verursacht aber einen zusätzlichen Modellaufruf und mehr Latenz.
Benchmark-Werte als Abwägung lesen, nicht als Versprechen
GitHubs Offline-Tests zeigen benchmark-spezifische Abwägungen zwischen Qualität und Kosten. Sie versprechen nicht, dass jede Copilot-Aufgabe 67% günstiger wird.
| Benchmark | HydraFusion-Qualität gegenüber Claude Opus 5 | Geschätzte Kosten gegenüber Claude Opus 5 | Die relevante Aussage |
|---|---|---|---|
| TerminalBench 2.1 | +4,9 Prozentpunkte | 67% niedriger | Das stärkste gemeldete Resultat: bessere verifizierte Aufgabenqualität bei niedrigeren geschätzten Kosten. |
| DeepSWE | −1,5 Punkte | 36% niedriger | Eine spürbare Ersparnis, aber mit messbarem Qualitätsnachteil bei schwieriger Repository-Arbeit. |
| CheckpointBench | −0,1 Punkte | 65% niedriger | Nahezu gleiche Qualität in GitHubs internem Replay-ähnlichen Benchmark – bei deutlich niedrigeren geschätzten Kosten. |
Nach Angaben in der offiziellen HydraFusion-Ankündigung nutzte GitHub einheitliche Evaluierungseinstellungen und zählte sämtliche Workflow-Aufrufe mit, einschließlich Retries, Kritiken, Eskalationen und Fallbacks.
CheckpointBench wird als Wiederholung kuratierter Copilot-Sessions gegenüber unveränderlichen Commits öffentlicher Repositories beschrieben. Das ist für Coding-Agent-Arbeit aussagekräftiger als ein einfacher Textgenerierungstest, bleibt aber ein kontrollierter Benchmark. Das schwächere HydraFusion-Ergebnis bei DeepSWE ist wichtig, weil es verhindert, die Tabelle als pauschalen Sieg zu lesen.
Unabhängige Evidenz aus der Praxis ist bislang dünn. @DoDataThings on X, ein unabhängiger Entwickler, bringt den entscheidenden Prüfpunkt auf:
„Das Modell, das plant, muss nicht das Modell sein, das den Code schreibt. GitHubs Hinweis besagt, dass HydraFusion die Opus-5-Basislinie in kontrollierten Offline-Evaluierungen erreichte oder übertraf – und genau beim Sprung von Offline-Evals zu chaotischen echten Repositories verliert Orchestrierung meist ihren Vorsprung. Ich bin gespannt, wie viel von der Kostendifferenz davon übrig bleibt.“
Der Beitrag stellt eine Frage, keine Messung. Er benennt aber den richtigen Test: Kosten und Qualität in unübersichtlichen Repositories.
Worauf es im echten Repository ankommt
Der Nutzen von HydraFusion hängt von mehr ab als von der Auswahl eines günstigeren Modells. GitHub dokumentiert Kontrollen für Abrechnung, Abbruch, Routing-Validierung, Review-Isolation und Patch-Anwendung. Mehrere Modellaufrufe erzeugen schließlich mehr Betriebszustände als eine einzelne direkte Anfrage.
| Kontrolle | Was das für Anwender bedeutet |
|---|---|
| Kosten- und Zeitsteuerung | HydraFusion erfasst Aufrufe über alle Workflow-Abschnitte hinweg und unterstützt begrenzte Ausführungen. Critique, Eskalationen, Retries und Fallbacks können Latenz oder Gesamtnutzung dennoch erhöhen. |
| Routing- und Patch-Kontrollen | GitHub erklärt, dass Routen validiert werden und nach einem ungültigen oder abgebrochenen Workflow kein Patch angewendet wird. Keine der beiden Kontrollen beweist jedoch, dass die gewählte Route oder der finale Code korrekt ist. |
| Isoliertes Review | Kritiker haben nur Lesezugriff und keine Tools, während Solver den gemeinsamen Workspace nutzen. Das reduziert direkte Änderungen durch Reviewer, macht Diff-Review und Tests aber nicht überflüssig. |
Die GitHub-Ankündigung beschreibt zudem einen Transparenz-Kompromiss: Zwischenentwürfe bleiben bis zum finalen Ergebnis verborgen. Das sorgt für eine aufgeräumtere Antwort, verdeckt während der Wartezeit aber Entwürfe, Retries, Eskalationen und verworfene Ergebnisse.
Ein sinnvoller erster HydraFusion-Test
Für den ersten Test eignet sich eine klar abgegrenzte Repository-Aufgabe mit objektiv prüfbarem Akzeptanzkriterium – keine offene Aufforderung, eine Codebasis „zu verbessern“. Behandle die Preview als Experiment mit bekanntem Ausgangs-Commit und fest definierter Erfolgsmessung.
- Lege einen sauberen Branch oder Worktree an und notiere den Ausgangs-Commit.
- Wähle eine Aufgabe mit enger Dateiabgrenzung und einem reproduzierbaren Testbefehl.
- Formuliere erwartetes Verhalten, Einschränkungen und Tests direkt im ersten Prompt.
- Lass HydraFusion die Aufgabe abschließen, prüfe danach aber den Diff, statt die Erfolgsmeldung des Agenten ungeprüft zu übernehmen.
- Führe die relevanten Tests selbst aus und kontrolliere auf nicht zusammenhängende Dateiänderungen.
- Halte Latenz, sichtbare Nutzungs- oder Kostendaten, Retries, Eskalationsverhalten und das finale Testergebnis fest, sofern das CLI sie anzeigt.
- Wiederhole das mit einigen Aufgaben, bevor du HydraFusion mit einem festen Modell vergleichst oder den Teamstandard änderst.
Ein einziger erfolgreicher Patch reicht nicht, um die Benchmark-Aussagen zu bestätigen. Aussagekräftig wird eine kleine Aufgabensammlung: ein Routinefix, eine Änderung über mehrere Dateien und ein bewusst mehrdeutiger Fall, bei dem Eskalation oder Critique relevant sein könnten.
Kosten und Grenzen von HydraFusion
GitHub nennt in der Ankündigung keinen separaten Dollarpreis für HydraFusion. Stattdessen wird die Nutzung zu den Standard-Tokenpreisen der zugrunde liegenden Modelle abgerechnet. Die endgültigen Kosten hängen also davon ab, welche Modelle und Workflow-Abschnitte die Laufzeit verwendet.
| Frage zur Abrechnung | Aktueller Stand |
|---|---|
| Gibt es eine separate HydraFusion-Abogebühr? | In GitHubs Ankündigung wird keine separate Gebühr für HydraFusion genannt. |
| Wie wird die Nutzung abgerechnet? | Über die von den beteiligten Modellen verbrauchten Tokens zu deren Standardpreisen. |
| Kann eine Aufgabe mehrere kostenpflichtige Aufrufe auslösen? | Ja. Cascade und Critique können mehrere Workflow-Abschnitte umfassen; die Abrechnung berücksichtigt auch Retries und Fallbacks. |
| Bedeutet eine Benchmark-Ersparnis von 67% auch 67% Ersparnis für Kunden? | Nein. Es handelt sich um einen geschätzten Vergleich für einen bestimmten Benchmark, eine bestimmte Policy, einen Modellpool und eine Preisgestaltung. |
| Ist HydraFusion ein stabiles Produktivfeature? | Nein. GitHub führt es als Research Preview und weist darauf hin, dass Modelle, Workflows, Verfügbarkeit, Verhalten und Name sich ändern können. |
Setze HydraFusion zunächst bei überprüfbaren Aufgaben mit einem Prompt ein. Für lange Multi-Turn-Arbeit oder Änderungen mit hohen Folgen sollte ein festes Modell als Fallback bleiben, bis Tests auf Repository-Ebene einen breiteren Einsatz rechtfertigen.
HydraFusion FAQ
Ist HydraFusion ein Modell oder ein Router?
HydraFusion ist ein Multi-Modell-Orchestrierungssystem zur Laufzeit in GitHub Copilot CLI, kein eigenständiges Foundation Model. Es wählt für eine Coding-Aufgabe Modelle und Ausführungsmuster aus.
Wie aktiviere ich HydraFusion im Copilot CLI?
Führe /update, /experimental on und /model aus und wähle anschließend HydraFusion (Research Preview).
Ist HydraFusion in jedem Copilot-Plan verfügbar?
GitHub zufolge ist die Preview über Copilot CLI für alle Copilot-Pläne verfügbar. Konto, Organisationsrichtlinien, CLI-Version oder Änderungen bei der Verfügbarkeit können jedoch beeinflussen, ob sie angezeigt wird.
Welche zugrunde liegenden Modelle verwendet HydraFusion?
GitHub beschreibt eine Auswahl aus Modellen mehrerer Anbieter, veröffentlicht aber keine feste Modellliste pro Anfrage. Gehe daher nicht davon aus, dass jede Aufgabe von einem bestimmten namentlich genannten Modell bearbeitet wird.
Schlägt HydraFusion Claude Opus 5 immer?
Nein. GitHub berichtet über einen Vorteil bei TerminalBench 2.1, nahezu gleiche Ergebnisse bei CheckpointBench und einen Rückstand von 1,5 Punkten bei DeepSWE.
Kostet HydraFusion extra?
Die Nutzung wird zu den Standard-Tokenpreisen der zugrunde liegenden Modelle abgerechnet, und eine Route kann mehrere Modelle aufrufen. Einen separaten Dollarpreis für HydraFusion nennt GitHub in der Ankündigung nicht.
Ist HydraFusion in VS Code verfügbar?
Die Launch-Unterlagen dokumentieren die Preview über Copilot CLI. Prüfe die aktuelle GitHub-Dokumentation, um eine weitergehende Verfügbarkeit zu bestätigen.
Kann HydraFusion ein Repository sicher bearbeiten?
GitHub beschreibt berechtigungsbewusste Solver, isolierte Kritiker, validiertes Routing, begrenzte Ausführung und ein Verhalten ohne Patch bei ungültigen oder abgebrochenen Workflows. Prüfe dennoch vor dem Merge den Diff und führe Tests aus.