AIREITEREine Coding-Aufgabe wirkt oft simpel – bis plötzlich Abhängigkeiten über mehrere Dateien hinweg ins Spiel kommen. Project HydraFusion wählt dafür einen Workflow, der voraussichtlich die gewünschte Qualitätsgrenze erreicht. Die Research Preview legt den genauen Pfad allerdings noch nicht offen und verspricht auch nicht für jedes Repository dieselben Einsparungen.
Das Routing auf einen Blick
Project HydraFusion ist eine Laufzeit-Orchestrierungsschicht im GitHub Copilot CLI und kein neues Foundation Model. Du wählst HydraFusion (Research Preview); die Laufzeit entscheidet anschließend über Modelle und Ausführungsablauf.
| Workflow | Ablauf zur Laufzeit | Größter Vorteil | Wichtigster Nachteil |
|---|---|---|---|
| Single | Ein ausgewähltes Modell bearbeitet die Aufgabe direkt. | Geringster Workflow-Overhead und der einfachste Latenzpfad. | Keine integrierte Eskalation und keine unabhängige Prüfung. |
| Cascade | Ein effizientes Modell erstellt einen Entwurf; ein Quality Gate akzeptiert ihn oder eskaliert an ein leistungsfähigeres Modell. | Das stärkste Modell kommt nur zum Einsatz, wenn der erste Durchlauf nicht ausreicht. | Ein nicht bestandenes Gate kann zusätzliche Modellaufrufe, Tokens und Wartezeit verursachen. |
| Critique | Ein Modell erstellt den Entwurf; ein unabhängiger, schreibgeschützter Kritiker aus einer anderen Modellfamilie prüft ihn; anschließend überarbeitet das erste Modell das Ergebnis einmal. | Eine zweite Perspektive für fehleranfällige Änderungen. | Der Ablauf wird länger, und der Kritiker kann weder Tools ausführen noch das Repository bearbeiten. |
Um die Preview auszuprobieren, führst du zunächst /update und danach /experimental on aus. Anschließend öffnest du mit /model die Modellauswahl und wählst HydraFusion (Research Preview). GitHub beschreibt diese Abfolge in der offiziellen HydraFusion-Ankündigung. Die Preview steht in allen Copilot-Tarifen zur Verfügung. Bei von Organisationen verwalteten Zugängen kann die Freischaltung jedoch von der durch einen Administrator aktivierten Copilot-CLI-Richtlinie abhängen.
Bei Single, Cascade und Critique handelt es sich um Ausführungsmuster – nicht um drei öffentliche Schalter, mit denen sich jede Anfrage manuell auf einen bestimmten Ablauf festnageln lässt. Das Launch-Material beschreibt stattdessen, dass man HydraFusion auswählt und die Laufzeit Performance, Kosten und Latenz selbst austarieren lässt.
Was die Laufzeit vorhersagen will
GitHub zufolge nutzt HydraFusion Fähigkeitssignale für Reasoning, Codegenerierung, Debugging und Tool-Nutzung. Die Laufzeit wählt das effizienteste Ausführungsmuster, von dem sie erwartet, dass es die Qualitätsanforderungen der Anfrage erfüllt. Die konkreten Schwellenwerte veröffentlicht GitHub jedoch nicht – ebenso wenig eine feste Regel nach dem Muster „Drei Dateien bedeuten Cascade“.
Die Form der Aufgabe ist deshalb nur ein Anhaltspunkt und keine Routing-Garantie: Eine kleine Änderung mit eindeutigem Testpfad passt konzeptionell zu Single, eine möglicherweise schwierige Aufgabe zu Cascades selektiver Eskalation und eine Änderung mit Mehrwert durch unabhängige Prüfung zu Critique. Die Ankündigung nennt weder für jede Anfrage eine feste Modellzusammenstellung noch eine lesbare Routing-Spur.
Lassen sich Single, Cascade oder Critique erzwingen?
GitHub dokumentiert lediglich die Auswahl von HydraFusion und die anschließende Entscheidung durch die Laufzeit. Einen öffentlichen Befehl, mit dem sich eines der drei Muster erzwingen lässt, beschreibt GitHub nicht. Wenn ein vorhersehbares Routing wichtig ist, solltest du ein fest ausgewähltes Copilot-Modell verwenden.
Wann sich der zusätzliche Aufruf lohnt
Single: direkte Ausführung bei eindeutigem Lösungsweg
Single schickt die Aufgabe durch einen einzigen Solver im normalen, berechtigungsbewussten Agenten-Loop von Copilot. Das passt zu einer kleinen, klar beschriebenen Änderung, einer kurzen Erklärung oder einem Fix mit eindeutigem Implementierungs- und Testpfad.
Der Vorteil liegt in einem einfacheren Kosten- und Latenzprofil. Der Workflow fügt bewusst weder ein Quality Gate noch eine zweite Meinung hinzu. Wenn der Solver die Aufgabe falsch versteht, bleibt der Entwickler damit der wichtigste Prüfer.
Cascade: erst eskalieren, wenn der erste Durchlauf nicht reicht
Cascade beginnt mit einem effizienten Modell. Ein Quality Gate bewertet dessen Ergebnis und kann die Aufgabe an ein leistungsfähigeres Modell weiterreichen, wenn der Entwurf die Qualitätsgrenze nicht erreicht.
Die wirtschaftliche Logik dahinter ist bedingt:
- Das erste Modell übernimmt Aufgaben, die es ausreichend gut lösen kann.
- Das Quality Gate filtert schwache oder unsichere Ergebnisse.
- Nur Aufgaben mit höherem Bedarf an Fähigkeiten nehmen den stärkeren Pfad.
Im Durchschnitt kann das die Workflow-Kosten gegenüber der Weiterleitung jeder Aufgabe an ein Frontier-Modell senken. Eine Eskalation, ein erneuter Versuch oder ein Fallback kann jedoch für einen teureren und langsameren Randbereich sorgen. Eine allgemeingültige Eskalationsrate für die Planung in einzelnen Repositories hat GitHub nicht veröffentlicht.
Critique: eine zweite Perspektive einkaufen
Critique folgt einem Entwurf-Prüfung-Überarbeitung-Ablauf. Der erste Solver erstellt das Ergebnis, ein Kritiker aus einer anderen Modellfamilie prüft es in einer isolierten, tool-losen und schreibgeschützten Umgebung, und der ursprüngliche Solver überarbeitet es anschließend einmal.
Der Kritiker kann keine Projekttests ausführen, eine generierte Datei nicht per Kommando untersuchen und die nötige Reparatur nicht selbst anwenden. Critique liefert also eine vielfältigere Prüfung – keine unabhängige Implementierung von Anfang bis Ende.
Die Benchmark-Bilanz: Niedrigere Kosten bedeuten nicht automatisch dieselbe Qualität
GitHub hat feste HydraFusion-Richtlinien auf drei agentischen Coding-Benchmarks mit Claude Opus 5 verglichen. Die folgenden Zahlen stammen aus der offiziellen Ankündigung von GitHub.
| Benchmark | HydraFusion-Qualität gegenüber Claude Opus 5 | Geschätzte Workflow-Kosten gegenüber Claude Opus 5 | Praktische Einordnung |
|---|---|---|---|
| TerminalBench 2.1 | +4.9 Prozentpunkte | 67 % niedriger | In dieser Evaluation höhere verifizierte Aufgabenqualität bei niedrigeren geschätzten Kosten. |
| DeepSWE | −1.5 Punkte | 36 % niedriger | Spürbare Einsparung, aber mit messbarem Qualitätsverlust bei schwierigen Repository-Aufgaben. |
| CheckpointBench | −0.1 Punkt | 65 % niedriger | Nahezu gleichwertige Qualität bei deutlich niedrigeren geschätzten Kosten. |
Genau darin liegt die Aussage der gemischten Qualitätsergebnisse: HydraFusion soll zusätzliche Inferenz nur dann einsetzen, wenn der erwartete Qualitätsgewinn die höheren Kosten und die zusätzliche Latenz rechtfertigt – nicht bei jeder Anfrage mehrere Modelle verwenden.
GitHub zufolge blieben Eingaben, Tools, Ausführungsgrenzen, Preise und Bewertung einheitlich. In die Berechnung flossen Entwurf, Kritik, Überarbeitung, Eskalation, Wiederholungen und Fallback-Pfade ein. Es handelt sich trotzdem um kontrollierte Offline-Schätzungen, die an die getesteten Richtlinien, den verwendeten Modellpool, die Benchmark-Versionen und die Preisannahmen gebunden sind.
Daraus folgt weder, dass eine normale Copilot-Aufgabe 67 % weniger kostet, noch dass HydraFusion in einer bestimmten Codebasis Claude Opus 5 schlägt. GitHub empfiehlt, die Preview zunächst mit umfangreichen, klar abgegrenzten Coding-Aufgaben im ersten Turn zu testen, die in einen einzelnen Prompt passen.
Die Kostenrechnung hat drei Dimensionen
Bei der Bewertung von HydraFusion solltest du erwartete Token-Kosten, Kosten im Worst-Case-Bereich und Wartezeit getrennt betrachten.
| Faktor | Single | Cascade | Critique |
|---|---|---|---|
| Erste Bearbeitung | Ein Solver | Zuerst ein effizienter Solver | Zuerst ein Solver für den Entwurf |
| Zusätzlicher Aufwand | Von Haus aus keiner | Leistungsfähigeres Modell nach einem nicht bestandenen Gate | Kritiker plus einmalige Überarbeitung durch den Solver |
| Kostenprofil | Vorhersehbarer | Bedingt; steigt bei Eskalation oder erneutem Versuch | Strukturell höher als bei einem direkten Entwurf |
| Latenzprofil | Einfachster Pfad | Kurz bei Akzeptanz, länger nach einer Eskalation | Zusätzliche Prüfung und Überarbeitung verlängern den Ablauf |
| Qualitätsmechanismus | Fähigkeiten des Solvers | Quality Gate plus Eskalation | Unabhängige Prüfung plus Überarbeitung |
Niedrigere geschätzte Workflow-Kosten bedeuten nicht automatisch eine schnellere Antwort: Cascade kann bei eskalierten Fällen langsamer werden, Critique fügt eine sequenzielle Prüfung hinzu, und Single liefert zwar schnell ein Ergebnis, überlässt dem Entwickler dafür mehr Validierungsarbeit.
Die Nutzungsdokumentation für Copilot CLI von GitHub zufolge zeigt /usage die Sitzungsdauer, verbrauchte AI Credits, bearbeitete Zeilen und eine Aufschlüsselung des Token-Verbrauchs nach Modell an. Diese Daten helfen beim Vergleich realer Aufgaben. Sie erklären jedoch nicht jede Routing-Entscheidung und machen verworfene Zwischenentwürfe nicht sichtbar.
Die Blackbox zwischen Prompt und Patch
GitHub beschreibt eine vollständige Abrechnung über alle Workflow-Abschnitte hinweg, begrenzte Ausführung mit Timeout- und Abbruchverhalten, isolierte Prüfungen, validiertes Routing sowie eine ausfallsichere Patch-Anwendung nach ungültigen oder abgebrochenen Workflows. Diese Kontrollen senken das operative Risiko. Sie beweisen aber weder, dass der gewählte Pfad richtig war, noch dass der finale Code korrekt ist.
Außerdem sagt GitHub, dass die Preview Zwischenentwürfe zurückhält, bis sie ein zusammenhängendes Ergebnis liefern kann. Dadurch lässt sich nur schwer erkennen, ob eine Aufgabe bei Single blieb, über Cascade eskaliert wurde oder den Critique- und Überarbeitungszyklus durchlaufen hat.
Ein Nutzer hat diese Lücke bei der Beobachtbarkeit direkt angesprochen:
„Das nächste Produkt-Feature, das ich mir wünschen würde, wäre eine lesbare Spur darüber, welches Modell was getan hat und warum der Router gewechselt hat.“ — @_Mazzana auf X
Ohne einen Routing-Beleg können Entwickler Kosten, Latenz und finalen Patch einer Aufgabe nicht vollständig mit dem Workflow verknüpfen, der sie erzeugt hat.
So testest du die Preview, ohne zu viel hineinzuinterpretieren
Behandle HydraFusion zunächst als Experiment und nicht als Standard für das ganze Team:
- Lege einen sauberen Branch oder ein Worktree an und notiere den Ausgangs-Commit.
- Teste einen gewöhnlichen Fix, eine Änderung über mehrere Dateien hinweg und eine mehrdeutige Aufgabe mit reproduzierbarer Abnahmeprüfung.
- Formuliere erwartetes Verhalten, Einschränkungen und Testbefehle bereits im ersten Prompt.
- Prüfe den finalen Diff, achte auf Änderungen an nicht betroffenen Dateien und führe die relevanten Tests selbst aus.
- Notiere Sitzungsdauer, sichtbare AI-Credit- oder Token-Nutzung, Testergebnis sowie jedes erkennbare Signal für Wiederholung oder Eskalation.
- Wiederhole den Test mit mehreren Aufgaben, bevor du HydraFusion mit einem festen Modell vergleichst.
Leite den verborgenen Modus nicht allein aus der Länge der Antwort ab. Eine lange Antwort kann auch durch die Komplexität des Repositorys entstehen und muss nicht auf Critique hindeuten. Halte für umfangreiche Aufgaben, lange Multi-Turn-Sitzungen, latenzkritische Vorhaben oder Arbeiten mit hohen Konsequenzen einen Fallback auf ein festes Modell bereit: GitHub empfiehlt für die aktuelle Preview Aufgaben im ersten Turn und nennt eine bessere Leistung bei Multi-Turn-Szenarien als künftigen Schwerpunkt in den Launch-Hinweisen.
HydraFusion-FAQ
Kann ich Single, Cascade oder Critique manuell auswählen?
Nicht über einen dokumentierten HydraFusion-Befehl für den Modus. Aktuell wählst du HydraFusion aus und überlässt die Entscheidung der Laufzeit. Wenn ein deterministisches Routing wichtig ist, solltest du ein festes Modell verwenden.
Wie wird HydraFusion abgerechnet?
GitHub zufolge richtet sich die Nutzung nach den Tokens, die von den eingesetzten HydraFusion-Modellen verbraucht werden. Abgerechnet wird jedes Modell zu seinem regulären Tarif, wie in der offiziellen Ankündigung beschrieben. Eine Reduktion in einem Benchmark ist kein allgemeiner Kundenrabatt, und mehrstufige Workflows können mehr verbrauchen als eine direkte Anfrage.
Am überzeugendsten ist HydraFusion bei Aufgaben, die wichtig genug für eine selektive Eskalation oder Prüfung sind und sich zugleich gut verifizieren lassen. Bei schnellen Änderungen kann die Einfachheit von Single wichtiger sein. Für lange oder kritische Arbeiten bleibt ein vorhersehbares Verhalten mit festem Modell möglicherweise die bessere operative Wahl – zumindest so lange, bis Erfahrungen aus dem eigenen Repository den zusätzlichen Orchestrierungsaufwand rechtfertigen.