GitHub hat am 4. September 2026 Project HydraFusion vorgestellt. Auf den ersten Blick sieht das nach einem weiteren Eintrag im Copilot-Modellmenü aus.
HydraFusion ist aber kein neues Modell.
Das System entscheidet während einer Coding-Aufgabe, welche Modelle überhaupt arbeiten sollen und wie. Eine kleine Aufgabe kann direkt an ein einzelnes Modell gehen. Bei einer schwierigeren Aufgabe kann zunächst ein günstigeres Modell versuchen, das Problem zu lösen. Reicht das Ergebnis nicht, eskaliert HydraFusion an ein stärkeres Modell. In einem anderen Workflow schreibt ein Modell die Lösung und ein zweites Modell aus einer anderen Modellfamilie kontrolliert sie.
Für unsere Arbeit bei Quavon ist genau das interessanter als die nächste Rangliste zwischen GPT, Claude und Gemini.
Die Frage könnte sich verschieben von „Welches Modell ist gerade das beste?“ zu „Welches Modell sollte diesen Teil der Aufgabe überhaupt übernehmen?“
Drei Wege statt eines festen Modells
GitHub nennt die drei aktuellen HydraFusion-Workflows Single, Cascade und Critique.
Single ist unspektakulär: Ein Modell bekommt die Aufgabe und erledigt sie direkt.
Bei Cascade startet ein effizienteres Modell. Danach prüft ein Quality Gate das Ergebnis. Wenn es nicht reicht, geht die Aufgabe an ein stärkeres Modell weiter.
Critique finde ich spannender. Ein Modell erstellt zunächst einen Entwurf. Danach prüft ein zweites Modell aus einer anderen Modellfamilie die Arbeit. Dieser Kritiker ist laut GitHub read-only und bekommt keinen Tool-Zugriff. Anschließend erhält das ursprüngliche Modell genau eine Überarbeitungsrunde.
Das ist näher an einem kleinen Review-Prozess als an einem klassischen LLM-Aufruf.
Gerade bei Coding-Agenten ergibt die Trennung Sinn. Wenn derselbe Agent Code schreibt, seine eigenen Ergebnisse bewertet und anschließend selbst entscheidet, ob alles gut genug ist, fehlt eine unabhängige Perspektive. HydraFusion versucht genau dort eine zweite Sicht einzubauen, ohne dem Reviewer gleichzeitig Schreibrechte auf das Repository zu geben.
Nicht jede Aufgabe braucht Opus 5
Wenn ein Agent eine Änderung über mehrere Packages eines Monorepos hinweg umsetzen soll, darf das Modell ruhig teuer sein, wenn es dadurch zuverlässig arbeitet.
Bei einer kleinen TypeScript-Anpassung oder einer offensichtlichen Konfigurationsänderung sieht das anders aus.
Genau hier liegt die Idee hinter dem Routing. Ein günstigeres Modell bekommt die Aufgaben, bei denen es wahrscheinlich reicht. Erst wenn das System Zweifel hat oder ein Ergebnis durch das Quality Gate fällt, wird mehr Rechenleistung eingesetzt.
Das ist nicht besonders spektakulär. Für ein Produkt mit vielen Modellaufrufen kann es trotzdem einen großen Unterschied machen.
Wir würden bei Quavon auch nicht jeden Backend-Request auf die teuerste Infrastruktur schicken, wenn ein günstigerer Pfad denselben Job zuverlässig erledigt. Bei Modellen ist die Logik ähnlich. Nur ist die Entscheidung schwerer, weil man vorher nicht immer weiß, wie kompliziert eine Aufgabe wirklich wird.
GitHubs Benchmarks sind gut – aber nicht so eindeutig wie die Überschrift
GitHub beschreibt HydraFusion als System, das in kontrollierten Offline-Evaluationen die Qualität von Claude Opus 5 erreichen oder übertreffen könne und dabei die geschätzten Workflow-Kosten senkt.
Die vollständige Tabelle ist etwas nüchterner.
Auf TerminalBench 2.1 liegt HydraFusion laut GitHub 4,9 Prozentpunkte vor Opus 5. Die geschätzten Kosten sind gleichzeitig 67 Prozent niedriger.
Bei DeepSWE liegt HydraFusion 1,5 Prozentpunkte hinter Opus 5. Die Kosten sollen dort 36 Prozent niedriger sein.
Auf CheckpointBench fehlen 0,1 Prozentpunkte auf Opus 5, bei 65 Prozent niedrigeren geschätzten Kosten.
HydraFusion schlägt Opus 5 also nicht pauschal bei der Qualität. Der deutlichere Effekt in GitHubs eigener Tabelle ist der Preis.
Das ist für mich ehrlich gesagt interessanter.
Wenn ein System bei schwierigen Repository-Aufgaben knapp hinter einem Frontier-Modell liegt, aber deutlich weniger kostet, kann das für echte Produkte attraktiver sein als ein weiterer Benchmark-Sieg.
Trotzdem bleiben es GitHub-Evaluationen. GitHub hat feste Policies getestet, dieselben Inputs und Tools verwendet und die jeweils am besten abgestimmte HydraFusion-Konfiguration gezeigt. CheckpointBench ist außerdem ein interner GitHub-Benchmark.
Ob die Kostenersparnis in einem echten Team ähnlich aussieht, wissen wir damit noch nicht.
Kosten pro erledigter Aufgabe statt Kosten pro Token
Bei Modellen schauen wir oft zuerst auf die API-Preise.
Das ist bei Agenten irgendwann die falsche Kennzahl.
Ein günstiges Modell kann drei Versuche brauchen, unnötige Dateien verändern und danach noch einen Entwickler beschäftigen. Ein teureres Modell kann dieselbe Aufgabe beim ersten Mal sauber lösen.
Andersherum muss ein Frontier-Modell keine triviale Änderung übernehmen, die ein kleineres Modell zuverlässig in zwei Minuten schafft.
GitHub zählt bei HydraFusion deshalb den kompletten Workflow: Drafts, Reviews, Revisionen, Eskalationen, Retries und Fallbacks.
Für unsere eigenen Agenten interessiert mich dieselbe Zahl.
Was kostet eine korrekt erledigte Aufgabe?
Nicht nur: Was kostet eine Million Tokens?
Der Router wird damit selbst zu einem kritischen Teil des Systems
HydraFusion kann nur dann günstiger arbeiten, wenn seine Entscheidungen gut sind.
Schickt der Router zu viele Aufgaben direkt an teure Modelle, verschwindet der Kostenvorteil. Bleibt er zu lange bei einem schwächeren Modell, sinkt die Qualität. Und wenn das Quality Gate einen schlechten Entwurf akzeptiert, wird das stärkere Modell nie aufgerufen.
Das würde ich in einem echten Projekt genauer beobachten als die Frage, welche Modelle gerade im Pool liegen.
GitHub veröffentlicht die feste Modellliste bewusst nicht. Der Pool soll sich ändern können, wenn neue Modelle erscheinen oder interne Evaluationen andere Ergebnisse zeigen.
Aus Produktsicht verstehe ich das. Als Entwickler möchte ich trotzdem nachvollziehen können, warum eine Aufgabe geroutet oder eskaliert wurde.
Welche Aufgabe hielt HydraFusion für schwierig? Welches Modell hat welchen Teil erledigt? Was hat der Kritiker beanstandet? Wo entstand der größte Teil der Kosten?
Wenn all das hinter einer einzigen Modellbezeichnung verschwindet, wird die Bedienung einfacher. Debugging wird dafür potenziell schwieriger.
Das Critique-Prinzip würde ich zuerst testen
Von den drei Workflows reizt mich Critique am meisten.
Nicht, weil zwei Modelle automatisch besser sind als eines. Das sind sie nicht.
Interessant ist die Rollentrennung. Das zweite Modell bekommt die Aufgabe, Fehler zu finden, aber keine Möglichkeit, selbst am Repository herumzuschreiben. Der ursprüngliche Agent muss anschließend mit dieser Kritik weiterarbeiten.
Für riskantere Änderungen wäre das bei Quavon ein sinnvoller Test: Ein Modell implementiert, ein anderes kontrolliert Architektur, offensichtliche Seiteneffekte oder überflüssige Änderungen. Danach darf genau ein Agent korrigieren.
Ich würde das lieber gegen unseren normalen Workflow messen als gegen einen abstrakten Benchmark.
Wie oft findet der zweite Reviewer einen echten Fehler? Wie oft produziert er nur zusätzliche Arbeit? Werden Pull Requests sauberer? Und kostet der zusätzliche Review am Ende weniger Zeit, als ein menschlicher Entwickler sonst investieren müsste?
Wenn die Antworten schlecht ausfallen, bringt auch die schönste Multi-Model-Architektur nichts.
Die Research Preview hat noch klare Grenzen
HydraFusion ist aktuell eine Research Preview in GitHub Copilot CLI. GitHub stellt sie Nutzern aller Copilot-Pläne über die experimentellen Funktionen bereit.
GitHub empfiehlt für den Moment vor allem größere, klar abgegrenzte Coding-Aufgaben, die in einem ersten Prompt sauber beschrieben werden können. Multi-Turn-Sessions mit längerer Zusammenarbeit sind ausdrücklich noch ein Schwerpunkt der weiteren Entwicklung.
Auch die Zwischenergebnisse der einzelnen Modelle sind derzeit nicht sichtbar. Nutzer bekommen am Ende das überprüfte Ergebnis, nicht jeden Draft, jede Kritik und jede verworfene Version.
In der GitHub-Community gibt es bereits Feedback genau dazu. Ein Nutzer beschreibt beispielsweise, dass bei einem Research-Workflow die fehlende Sicht auf Zwischenergebnisse problematisch wurde. GitHub sagt selbst, dass man daran arbeitet, während der Ausführung mehr sichtbar zu machen.
Das ist für mich kein kleines UI-Detail. Wenn mehrere Modelle an einer Änderung arbeiten, möchte ich bei einem Fehler verstehen können, was passiert ist.
Für Quavon wäre Routing langfristig interessanter als ein weiterer Modellvergleich
Wir könnten heute GPT-6 Astra gegen Claude Opus 5 testen und in zwei Wochen wieder von vorne anfangen, weil das nächste Modell erschienen ist.
Das wird auf Dauer ziemlich sinnlos.
Eine Orchestrierungsschicht kann dieses Problem zumindest teilweise verschieben. Neue Modelle landen im Pool, während die Anwendung weiter danach entscheidet, welcher Workflow zur Aufgabe passt.
Für eine kleine Änderung könnte ein schnelles, günstiges Modell reichen. Ein schwieriger Bug über Frontend und Backend bekommt einen stärkeren Agenten. Bei einer riskanten Änderung kommt zusätzlich ein unabhängiger Review dazu.
Ich würde HydraFusion deshalb nicht danach beurteilen, ob es Opus 5 auf TerminalBench um 4,9 Punkte schlägt.
Ich würde zwanzig oder fünfzig echte Aufgaben aus unseren Repositories nehmen und messen, was danach übrig bleibt: Sind die Tests grün? Wie viele unnötige Änderungen wurden gemacht? Wie oft musste ein Mensch eingreifen? Wie lange dauerte das Review? Und was hat ein erfolgreich abgeschlossenes Issue tatsächlich gekostet?
Wenn HydraFusion dort ähnlich gut arbeitet wie ein dauerhaft eingesetztes Frontier-Modell und gleichzeitig deutlich günstiger ist, wird Model Routing für uns sehr interessant.
Dann ist die wichtigste Modellentscheidung irgendwann vielleicht die, die wir gar nicht mehr selbst treffen.
Quellen
GitHub, 4. September 2026: „Project HydraFusion: Frontier quality via multi-model orchestration“ https://github.blog/ai-and-ml/github-copilot/project-hydrafusion-frontier-quality-via-multi-model-orchestration/
GitHub Community: „HydraFusion is live in GitHub Copilot CLI: Frontier quality via multi-model orchestration“ https://github.com/orgs/community/discussions/206492
VentureBeat, 4. September 2026: „GitHub’s HydraFusion cuts AI coding costs in every benchmark. It only matches quality in one.“ https://venturebeat.com/orchestration/githubs-hydrafusion-cuts-ai-coding-costs-in-every-benchmark-it-only-matches-quality-in-one