HydraFusion in GitHub Copilot: das passende Modell für jede Aufgabe

Ein „Modell", das eigentlich mehrere ist

In der Modellauswahl von GitHub Copilot steht seit Kurzem ein neuer Eintrag: HydraFusion. Er sieht aus wie ein weiteres Modell, ist aber keines. HydraFusion wählt für jede Aufgabe das passende Modell – oder eine passende Kombination aus mehreren Modellen –, statt alles pauschal einem einzigen Modell zu geben.

Seit dem 1. September 2026 ist HydraFusion als Research Preview in der Copilot CLI verfügbar, seit dem 30. September auch in VS Code und der Copilot-App. Für Unternehmen ist das in doppelter Hinsicht interessant: für die Qualität der Ergebnisse und für den Verbrauch an AI-Credits. Wir ordnen ein, wie HydraFusion funktioniert, was hinter den Zahlen steckt und was Sie vor dem Einsatz klären sollten.

So arbeitet HydraFusion

Für jede Anfrage wählt HydraFusion eines von drei Mustern:

• Single: Ein ausgewähltes Modell löst die Aufgabe direkt.
• Cascade: Ein günstiges Modell erstellt einen Entwurf. Eine Qualitätsprüfung entscheidet, ob der Entwurf reicht oder ob ein stärkeres Modell übernimmt.
• Critique: Ein Modell erstellt einen Entwurf, ein unabhängiger Kritiker aus einer anderen Modellfamilie prüft ihn – nur lesend –, und das erste Modell überarbeitet sein Ergebnis einmal.

flowchart TD
    R[Anfrage] --> H{HydraFusion wählt den Ablauf}
    H -->|Single| S[Ein Modell löst die Aufgabe]
    H -->|Cascade| C1[Günstiges Modell entwirft]
    C1 --> G{Qualitätsprüfung}
    G -->|reicht| E[Ergebnis]
    G -->|reicht nicht| C2[Stärkeres Modell übernimmt]
    C2 --> E
    H -->|Critique| K1[Modell entwirft]
    K1 --> K2["Kritiker aus anderer<br/>Modellfamilie prüft"]
    K2 --> K3[Einmal überarbeiten]
    K3 --> E
    S --> E

Welches Muster passt, entscheidet HydraFusion anhand von Signalen wie Schlussfolgerungstiefe, Codekomplexität, Fehlersuche und Werkzeugeinsatz. Laut GitHub wählt es dabei den einfachsten Ablauf, der die Qualitätsanforderung voraussichtlich erfüllt, und setzt zusätzliche Modellaufrufe nur ein, wenn sie das Ergebnis wahrscheinlich verbessern.

Besonders das Critique-Muster ist ein kluger Gedanke: Ein Modell aus einer anderen Familie hat andere Stärken und andere blinde Flecken. Das ist dasselbe Prinzip wie ein Code-Review durch eine zweite Person.

Auto, HyDRA, HydraFusion – wo ist der Unterschied?

Die Namen sind leicht zu verwechseln:

• Auto ist die automatische Modellauswahl in Copilot. Dahinter steckt inzwischen HyDRA, ein Routing-Modell, das für jede Anfrage ein passendes Modell auswählt – stärker, wenn die Aufgabe es verlangt, sparsamer, wenn nicht.
• HydraFusion geht einen Schritt weiter: Es wählt nicht nur ein Modell, sondern einen Ablauf, an dem mehrere Modelle beteiligt sein können.

GitHub fasst es so zusammen: Auto wählt das passende Modell, HydraFusion den passenden Ablauf. Langfristig sollen beide zu einer gemeinsamen Funktion zusammenwachsen.

Einen verwandten Ansatz verfolgen Entscheidungsmodelle: Kleine, spezialisierte Modelle beantworten die vielen einfachen Ja/Nein-Fragen in einem Agenten mit einer Wahrscheinlichkeit, statt dafür ein großes Modell zu bemühen. Mehr dazu in Decisions API: 2B or not 2B? Entscheidungsmodelle für KI-Agenten.

Die Zahlen – und was nicht in der Überschrift steht

GitHub wirbt mit einem Ergebnis aus dem Benchmark TerminalBench 2.1: 4,9 Prozentpunkte bessere Qualität bei 67 % geringeren geschätzten Kosten im Vergleich zu Claude Opus 5. Das klingt eindeutig. Der vollständige Blogbeitrag zeigt aber drei Benchmarks:

Das Gesamtbild ist trotzdem positiv: In allen drei Tests waren die geschätzten Kosten deutlich niedriger, und die Qualität lag nahe am Vergleichsmodell oder darüber. Aber die Schlagzeile zeigt den besten der drei Werte. Bei DeepSWE war die Qualität etwas schlechter.

Wichtig für die Einordnung:

• Es sind Offline-Tests von GitHub selbst, einer davon auf einem internen Benchmark.
• Es sind geschätzte Kosten, berechnet aus den Modellpreisen – keine gemessenen Rechnungen.
• Bewertet wurde die jeweils am besten abgestimmte Konfiguration.
• Verglichen wurde mit Claude Opus 5 und GPT-5.6 Sol. Ob HydraFusion auch gegen das jeweils neueste Spitzenmodell besteht, sagen die Zahlen nicht.

Daraus ergibt sich die eigentliche Abwägung: Wenn ein einzelnes Spitzenmodell bei Ihren Aufgaben durchgängig bessere Ergebnisse liefert, bringt die Orchestrierung für die Qualität wenig – bei DeepSWE lag Opus 5 bereits vorn. Der Vorteil von HydraFusion liegt dann vor allem darin, nahezu dieselbe Qualität mit weniger Aufwand zu erreichen und bei schwierigen Aufgaben eine zweite Modellfamilie gegenlesen zu lassen.

Das heißt nicht, dass die Ergebnisse falsch sind. Es heißt nur: Ob HydraFusion in Ihrem Code und Ihren Aufgaben genauso abschneidet, zeigt erst ein eigener Test.

Was HydraFusion wirklich kostet

HydraFusion ist in erster Linie darauf ausgelegt, für jede Aufgabe das passende Modell zu finden. Geringere Kosten sind ein möglicher Nebeneffekt, aber nicht das oberste Ziel – auch wenn GitHub in den Benchmarks vor allem mit Einsparungen wirbt.

Einen Aufpreis gibt es nicht. Abgerechnet werden die Modelle, die HydraFusion tatsächlich einsetzt – die Kosten einer Anfrage sind die Summe ihrer Schritte. Wie sich Anfragen und AI-Credits in Copilot grundsätzlich berechnen, erklären wir in GitHub Copilot: Was das neue Abrechnungsmodell bedeutet.

Daraus folgt: HydraFusion ist nicht automatisch günstiger. Löst ein günstiges Modell die Aufgabe im Cascade-Muster direkt, spart es. Muss eskaliert werden oder läuft eine Critique-Runde, zahlen Sie für mehrere Modelle. GitHub sagt in der Diskussion zur Preview selbst, dass HydraFusion bewusst mehr ausgibt, wenn das die Chance auf ein richtiges Ergebnis erhöht. Es sucht also nicht den billigsten Weg, sondern den wirtschaftlichsten für die geforderte Qualität.

Für die Kostenkontrolle gelten deshalb dieselben Regeln wie sonst auch: Verbrauch im Blick behalten, Kontext schlank halten und nicht mitten in einer Sitzung das Modell wechseln, damit der Cache greift. Mehr dazu in Token-Caching: wie Teams AI-Credits sparen und GitHub Copilot: neue Limits und wie man sie klug nutzt.

Was Unternehmen vor dem Einsatz klären sollten

1. Modelle nur über die Richtlinien steuerbar. Welches Modell HydraFusion im Einzelfall einsetzt, können Sie nicht festlegen. GitHub veröffentlicht bewusst keine feste Modellliste, weil sich die Auswahl mit neuen Modellen ändert. Die Modell-Richtlinien Ihres Unternehmens gelten aber: Laut GitHub-Dokumentation nutzt HydraFusion nur Modelle, die in Ihrem Plan enthalten und von den Richtlinien Ihrer Organisation oder Ihres Enterprise freigegeben sind. Lassen die Richtlinien keines der benötigten Modelle zu, erscheint HydraFusion gar nicht erst in der Auswahl. Wer einen Anbieter sperrt, sperrt ihn damit auch für HydraFusion.

2. Zwischenschritte bleiben verborgen. Angezeigt wird nur das geprüfte Endergebnis, nicht die Entwürfe und Kritiken davor. GitHub begründet das damit, dass Zwischenstände noch verworfen werden können. Für die Nachvollziehbarkeit ist es trotzdem ein Nachteil: Man sieht nicht, welches Modell was beigetragen hat.

3. Freischaltung durch den Admin. HydraFusion steht in Copilot Pro, Pro+, Business und Enterprise zur Verfügung. In Business und Enterprise muss ein Administrator zuerst die Preview-Funktionen freigeben, in der Copilot CLI zusätzlich der experimentelle Modus aktiv sein (copilot --experimental oder /experimental on). Neben HydraFusion steht dort auch HydraFusion Max zur Wahl, abgestimmt auf anspruchsvollere Aufgaben. Die Freigabe durch den Admin ist sinnvoll: So entscheidet das Unternehmen bewusst, ob und wo getestet wird.

4. Research Preview. Funktionsumfang, Modellauswahl und Verhalten können sich ändern. Für produktive Prozesse, die verlässlich gleich laufen sollen, ist das noch keine Grundlage.

Unsere Empfehlung: messen statt glauben

HydraFusion ist ein vielversprechender Ansatz. Die Idee, Aufgaben nicht pauschal dem teuersten Modell zu geben, ist wirtschaftlich richtig, und der Review durch eine andere Modellfamilie kann die Qualität tatsächlich verbessern. Wir würden es so angehen:

1. Preview-Funktionen bewusst freigeben und zunächst nur ein kleines Pilotteam testen lassen.
2. Modell-Richtlinien vorher prüfen: HydraFusion hält sich an die freigegebenen Modelle. Prüfen Sie, ob diese Liste dem entspricht, was Sie wirklich zulassen wollen, und testen Sie zunächst an einem Projekt ohne besonders sensible Daten.
3. Vorher und nachher messen: Credit-Verbrauch und Ergebnisqualität über ein, zwei Wochen mit der bisherigen Modellwahl vergleichen.
4. Bei Routineaufgaben auf Auto setzen, HydraFusion bei Aufgaben testen, bei denen sich eine zweite Meinung lohnt – Fehlersuche, Refactoring, Reviews.

Ob HydraFusion in Ihrem Team bessere Ergebnisse liefert und was das kostet, zeigt am Ende Ihr eigener Test, nicht ein Benchmark.

Sie nutzen GitHub Copilot im Unternehmen und möchten Kosten, Modelle und Richtlinien im Griff behalten? Mehr zu unserem Angebot finden Sie unter GitHub Copilot im Unternehmen. Oder sprechen Sie uns direkt an.

Quellen: GitHub Blog – Project HydraFusion: Frontier quality via multi-model orchestration · GitHub Changelog – HydraFusion in VS Code und der Copilot-App · GitHub Docs – HydraFusion · GitHub Community – HydraFusion Research Preview (Diskussion und FAQ) · GitHub Blog – Getting more from each token: Context Handling und Model Routing