HydraFusion in VS Code: Cascade ist kein Modell im Picker

Neulich habe ich einem Kollegen stolz erklärt, ich hätte die Modellwahl in meinem Editor „endlich im Griff“. Eine Stunde später starrte ich auf eine Antwort, die weder zum Problem noch zu meiner Laune passte. Ich hatte das falsche Modell für eine banale Aufgabe gewählt und dann das nächste für eine knifflige. Genau diese Handarbeit will GitHub mit HydraFusion in Copilot abnehmen. Der Name klingt nach Monster mit vielen Köpfen, und das trifft es erstaunlich gut: Mehrere Modelle arbeiten hinter einem einzigen Eintrag, und eines der Muster heißt Cascade.

Ich habe den Changelog vom 30. September und den Research-Blog zu Project HydraFusion vom 4. September nebeneinandergelegt. Beide Texte stammen von GitHub, und sie sagen nicht an jeder Stelle dasselbe. Das ist keine Verschwörung, sondern der übliche Abstand zwischen einem Forschungsbericht und einer Release-Notiz. Wir bei digital-magazin.de legen solche Abweichungen lieber offen, als sie zu einer glatten Geschichte zu verschmelzen.

Die kurze Version: HydraFusion ist eine Research Preview, kein fertiges Produkt. Die Zahlen stammen aus Offline-Evaluationen von GitHub, nicht aus unseren Messungen. Und manches, was die Preview kann oder kosten wird, steht schlicht nicht in den Quellen.

HydraFusion im Picker ist kein Modell

Im Model Picker sieht HydraFusion aus wie jeder andere Eintrag. Man wählt es aus, schreibt seinen Prompt und fertig. Dahinter steckt aber kein einzelnes Sprachmodell, sondern eine Orchestrierung. Laut Changelog koordiniert HydraFusion mehrere Modelle und behandelt die Wahl des Workflows als Optimierungsproblem. Als Grundlage dienen Capability-Signale für vier Fähigkeiten: Reasoning, Code-Generierung, Debugging und Tool-Nutzung. Aus diesen Signalen wählt das System das effizienteste Ausführungsmuster, das die Qualitätsschwelle erreicht.

Der Research-Blog beschreibt die Idee aus Sicht der Praxis. Entwickelnde koordinieren Modelle längst von Hand: ein Modell für die Aufgabe, ein zweites für das Review, bei einem schwierigen Problem der Wechsel zu einem stärkeren. HydraFusion verlegt diesen Ablauf in die Laufzeit. Man wählt es einmal aus und bleibt bei der eigentlichen Arbeit, während im Hintergrund Modelle und Workflow verwaltet werden.

Der Schlüsselbegriff in der Quelle lautet Selektivität. Manche Coding-Aufgaben lassen sich direkt lösen, andere profitieren von Review, Revision oder Eskalation. HydraFusion bewertet jede Anfrage und wählt laut Blog den am wenigsten komplexen Workflow, der den Bedarf voraussichtlich deckt. Zusätzliche Modellaufrufe gibt es nur, wenn sie das Ergebnis wahrscheinlich verbessern. Das klingt einfach, ist es aber nicht, denn irgendjemand muss vorher einschätzen, wann sich der Aufwand lohnt.

Auch das Modell-Portfolio ist nicht eingefroren. Wenn neue Modelle in GitHub Copilot erscheinen, können sie laut Blog bewertet und in den Modellpool aufgenommen werden. Welche Modelle aktuell im Pool stecken, nennen die Quellen nicht. Ich spekuliere deshalb nicht darüber. Fest steht nur: Die Modelle stammen laut Research-Blog von mehreren Anbietern, und für Critique kommt der Prüfer aus einer anderen Modellfamilie.

Cascade, Single und Critique: die drei Workflows

Aktuell wählt HydraFusion pro Anfrage eines von drei Ausführungsmustern. Der Blog betont, dass jedes Muster einen anderen Kompromiss zwischen Qualität und Kosten adressiert. Gehen wir sie einzeln durch.

Single: ein Modell, direkt

Beim Single-Workflow löst ein ausgewähltes Modell die Aufgabe direkt. Kein Entwurf, kein Gate, kein Prüfer. Laut Blog bleibt so Geschwindigkeit und Effizienz erhalten, wenn ein Modell allein ausreicht. Das ist der unspektakulärste der drei Wege, und gerade deshalb wichtig: Ein Orchestrierer, der jede Kleinigkeit durch drei Modelle schickt, wäre eine teure Spielerei. Die Selektivität steht und fällt damit, dass Single oft genug die richtige Antwort ist.

Cascade: erst günstig, dann gegebenenfalls stärker

Bei Cascade entwirft ein effizientes Modell eine Lösung. Danach entscheidet ein Quality-Gate, ob der Entwurf akzeptiert oder zu einem stärkeren Modell eskaliert wird. Der Blog formuliert es so: Das effiziente Modell bekommt den ersten Versuch, ein Weg zu stärkerer Inferenz bleibt aber offen, falls der Kandidat das Akzeptanz-Gate nicht passiert.

Man kennt das aus dem Büro. Die Juniorin schreibt den ersten Wurf, die Seniorin schaut nur drauf, wenn es wackelt. Mit einem Unterschied: Hier prüft ein Gate, kein Mensch mit Bauchgefühl. Wie genau dieses Gate entscheidet, steht in den Quellen nicht. Ich kann also nicht sagen, wie streng es ist, und behaupte es auch nicht.

Critique: Entwurf, unabhängige Prüfung, einmal revidieren

Beim Critique-Workflow entwirft ein Modell ein Ergebnis. Ein unabhängiger, schreibgeschützter Critic aus einer anderen Modellfamilie prüft es. Anschließend revidiert das entwerfende Modell genau einmal. Beide Quellen sagen, dass dies dem Review-Muster von Rubber Duck folgt. Der Blog nennt den Einsatzzweck: Critique bringt eine unabhängige Perspektive für Aufgaben, bei denen ein Review nützlicher ist als ein weiterer Versuch ohne Hilfe.

Dass der Critic aus einer anderen Familie stammt, ist der interessante Teil. Zwei Modelle derselben Herkunft teilen womöglich dieselben blinden Flecken. Das ist meine Lesart, die Quellen begründen die Wahl nicht ausdrücklich. Dass der Critic nur lesen darf, passt jedenfalls zum Prinzip der isolierten Prüfung, auf das ich weiter unten komme.

Copilot in VS Code ab 1.140 und in der App

Der Changelog vom 30. September ist im Kern eine Verfügbarkeitsmeldung. Die HydraFusion Research Preview gibt es ab sofort in Visual Studio Code und in der GitHub Copilot App. Vorher war sie laut Changelog auf die Copilot CLI beschränkt, jetzt kommen also zwei weitere Oberflächen dazu. Der Changelog nennt das den meistgewünschten Punkt aus dem frühen Feedback.

Der Weg in VS Code

Sie brauchen Visual Studio Code in Version 1.140 oder neuer, alternativ VS Code Insiders. Dann wählen Sie HydraFusion im Model Picker des Copilot Chat aus. Taucht der Eintrag nicht auf, hilft das Setting chat.copilot.hydraFusion.enabled. Wer Copilot über eine Organisation oder ein Unternehmen bezieht, braucht möglicherweise eine administrierende Person, die Preview-Features in den Organisations- oder Enterprise-Einstellungen erlaubt.

Wer ohnehin viel zwischen Modellen im Editor wechselt, findet im Beitrag über den Modellwechsel im Editor weiteren Kontext. HydraFusion ersetzt diese Wechsel nicht komplett, es nimmt sie nur in bestimmten Fällen ab.

Der Weg in der Copilot App

In der GitHub Copilot App aktualisieren Sie zuerst auf die letzte Version. Danach öffnen Sie die Einstellungen, suchen nach „HydraFusion“ und schalten die Option ein. Zum Schluss wählen Sie HydraFusion im Picker aus. Drei Schritte, nichts Exotisches. Ich finde es angenehm, dass hier kein geheimes Flag nötig ist.

Wer es bekommt

Der Changelog nennt die Pläne Copilot Pro, Pro+, Business und Enterprise. Für Business und Enterprise muss eine administrierende Person Preview-Features aktivieren. Für Teams heißt das: Wenn der Eintrag im Picker fehlt, ist oft nicht der Editor schuld, sondern ein nicht gesetzter Schalter auf Organisationsebene. Ähnliche Freigabefragen gab es schon bei älteren Modellwechseln, was unser Bericht zu früheren Copilot-Modellwechseln und Admin-Freigaben zeigt. Außerdem gilt: HydraFusion bleibt eine Research Preview und ist laut Changelog Änderungen unterworfen.

Wo sich HydraFusion von Auto trennt

Auto gibt es in Copilot schon länger. Der Research-Blog erinnert daran: Auto prüft die Aufgabe und ordnet ihr das am besten passende Modell zu. Der Changelog bringt den Unterschied auf eine kurze Formel. Auto wählt pro Request ein Modell. HydraFusion untersucht, wie Copilot in einem einzigen Turn sowohl einen Workflow wählen als auch mehrere Modelle koordinieren kann.

Anders gesagt: Auto beantwortet die Frage „welches Modell?“. HydraFusion beantwortet die Frage „welcher Ablauf, und mit welchen Modellen darin?“. HydraFusion ist nicht Auto. Wer beide gleichsetzt, übersieht den Kern der Sache.

Ein Beispiel aus dem Alltag, ohne Messwerte: Bei Auto bekommt eine Aufgabe ein Modell und damit eine Antwort. Bei HydraFusion kann dieselbe Aufgabe, je nach gewähltem Workflow, einen Entwurf, ein Gate und eine Eskalation durchlaufen, oder einen Entwurf, eine unabhängige Prüfung und eine Revision. Aus Sicht der Nutzenden bleibt es ein Prompt und eine Antwort. Der Blog formuliert das Ziel so, dass die Komplexität hinter den Kulissen bleibt und der Workflow Leistung, Kosten und Latenz je Aufgabe abwägt.

Ob das im Alltag so unsichtbar bleibt, wie es klingt, ist eine offene Frage. Die Preview soll laut Blog gerade klären, welche Aufgaben von zusammengesetzten Workflows profitieren und wie sich Orchestrierung auf Latenz und Kosten auswirkt. Das ist eine ehrliche Aussage. Sie bedeutet auch: Die Antwort steht noch aus.

Was die Offline-Evals ausweisen und was nicht

Dieses Bild wurde komplett mit KI generiertProviderhiggsfieldModellgpt_image_2PromptPhotorealistic close photo of adult hands resting beside a keyboard, monitor facing away and out of focus, no logos, no readable text, no watermarks, 16:9

Jetzt zu den Zahlen. Das Lede des Research-Blogs lautet sinngemäß: In kontrollierten Offline-Evaluationen haben die selektiven Coding-Workflows von HydraFusion die evaluierte Opus-5-Baseline erreicht oder übertroffen, bei niedrigeren geschätzten Workflow-Kosten. Die Tabelle des Blogs, relativ zu Claude Opus 5, sieht allerdings differenzierter aus.

Bei TerminalBench 2.1 stehen 67 Prozent niedrigere Kosten und +4,9 Punkte Qualität in der Tabelle. Im Fließtext heißt es, die verifizierte Aufgabenqualität habe sich um 4,9 Prozentpunkte verbessert, bei 67 Prozent niedrigeren geschätzten Kosten gegenüber Claude Opus 5.

Bei DeepSWE stehen 36 Prozent niedrigere Kosten und −1,5 Punkte Qualität in der Tabelle. Der Fließtext sagt, HydraFusion komme „within 1.5 percentage points“ an Opus 5 heran und senke die Kosten um 36 Prozent. Hier gibt das Vorzeichen die Richtung vor: minus 1,5. Ich schreibe es so hin, wie es dasteht, ohne es schönzureden oder schlechtzureden.

Bei CheckpointBench, dem internen Benchmark von GitHub auf Basis echter Copilot-Sessions, nennt die Tabelle 65 Prozent niedrigere Kosten und −0,1 Punkte Qualität. Der Fließtext spricht von „within 0.1 percentage points“ bei 65 Prozent niedrigeren Kosten.

Lesen Sie die drei Zeilen also nebeneinander: Das Lede gilt nicht für jede Zeile gleich. Nur bei TerminalBench 2.1 steht ein positives Vorzeichen bei der Qualität. Bei den anderen beiden steht ein Minus, bei CheckpointBench ein sehr kleines.

Zwei Grafiken fassen die Werte für TerminalBench 2.1 und DeepSWE zusammen. Sie stammen aus der GitHub-Angabe, nicht aus einer Messung von uns.

Wie die Evals gebaut sind

Laut Blog wurden feste HydraFusion-Policies auf drei agentischen Coding-Benchmarks bewertet: TerminalBench 2.1, DeepSWE und CheckpointBench. Als Vergleichsbaselines nennt die Methodenpassage Claude Opus 5 und GPT-5.6 Sol. Die veröffentlichte Tabelle bezieht sich jedoch nur auf Opus 5, zu GPT-5.6 Sol liefert der Text keine Zahlen, und ich erfinde keine.

Jede Policy erhielt dieselben Task-Inputs, Tools, Ausführungslimits, Preisannahmen, Bewertungsbedingungen und denselben Umgang mit fehlenden Ergebnissen. Gemessen wurden zwei Dinge. Erstens die „verified task quality“, also der Anteil der Aufgaben, die als korrekt bestätigt wurden. Zweitens die vollständigen geschätzten Workflow-Kosten, die jede aufgerufene Etappe einschließen: Entwurf, Critique, Revision, Eskalation, Retry und Fallback. Alle Modelle liefen auf derselben mittleren Reasoning-Stufe.

Die Grenzen nennt der Blog selbst. Die Ergebnisse gelten für die evaluierten Benchmark-Revisionen, die Workflow-Konfigurationen, den Modellpool und die Preisannahmen. Gezeigt wird die am besten abgestimmte HydraFusion-Konfiguration. Das ist kein Vorwurf, aber ein Hinweis: „Best tuned“ ist nicht „Standard nach dem Einschalten“. Die Prozentwerte zu den Kosten sind eine Schätzung von GitHub, keine Preisliste und keine Messung von uns.

Ob die Resultate auf echte Entwickler-Workloads übertragbar sind, will GitHub laut Blog erst mit der Research Preview validieren. Ich finde das sauber formuliert. Es heißt aber auch: Wer heute auf Basis dieser Tabelle seine Modellstrategie umbaut, springt der Beweislage voraus.

Ein Stimmungsbild liefert der Blog auch. Aus frühen internen Tests zitiert er einen Principal Software Engineer at Microsoft: „So far, the reasoning and task solving capability [of HydraFusion] is at or better than Opus.“ Der Name wird nicht genannt, und es handelt sich um Early internal testing. Ein Zitat ist kein Benchmark. Ich lese es als Anekdote, die zur Tabelle passt, mehr nicht.

Fünf Prinzipien unter der Haube

Der Research-Blog erklärt, wie aus adaptiver Orchestrierung ein verlässliches Coding-Erlebnis werden soll. Dafür nennt er fünf Operating Principles. Sie sind weniger glamourös als die Benchmark-Tabelle, aber ich halte sie für den spannenderen Teil.

• Complete accounting: Kosten und Nutzung werden über jede Etappe des Workflows aggregiert, einschließlich Entwurf, Critique, Revision, Eskalation, Retry und Fallback.
• Bounded execution: Jede Etappe bekommt ein explizites Timeout- und Abbruchverhalten, damit Ausführung und Kosten in definierten Grenzen bleiben.
• Isolated review: Review-Schritte laufen in isolierten Kontexten ohne Tools. Solver-Schritte nutzen den gemeinsamen Workspace und die normale, rechtebewusste Agent-Schleife.
• Fail-safe application: Wird der Workflow abgebrochen oder scheitert die Validierung, wird kein Patch angewendet.
• Validated routing: Workflow-Definitionen, Modellbindungen, Fallback-Verhalten und Modellverfügbarkeit werden geprüft, bevor die Ausführung beginnt.

Besonders der dritte und vierte Punkt gefallen mir. Ein Critic, der nur lesen darf, kann das Repository nicht kaputtmachen, und ein abgebrochener Lauf hinterlässt keinen halben Patch. Wer schon einmal einen Agenten bei halber Arbeit abgebrochen hat und danach das Arbeitsverzeichnis aufräumen musste, weiß, warum das zählt. Ich persönlich halte diese Garantie für wertvoller als jede Prozentzahl.

Intern protokolliert die Laufzeit laut Blog Rolle, Ergebnis, Kosten, Latenz und Diagnosedaten jeder Etappe, damit sich der Ablauf nachvollziehen lässt. Nach außen sieht der Entwickelnde eine zusammenhängende Antwort und einen rechtebewussten Änderungssatz.

Beam Search statt Handarbeit

Beim Routing verzichtete GitHub auf manuell getunte Schwellenwerte. Stattdessen nutzte das Team Beam Search, um die Entscheidungspolicy aufzubauen. Jeder Kandidat wurde gegen eine eingefrorene Baseline gemessen, nach Qualität, Kosten und Failure Modes. So sollten Verbesserungen auf stabilem Grund beurteilt werden.

Der Verlauf war laut Blog nicht linear. Zwischen dem 11. und dem 25. August erzeugten zwei operative Fehler im Evaluation Harness ungültige Läufe. Diese wurden aus dem Leistungstrend ausgeschlossen, korrigiert, und danach gab es weitere Zugewinne. Am 25. August erreichte HydraFusion auf TerminalBench 2.1 seine stärksten Betriebspunkte der aufgezeichneten Serie. Ich schätze diese Offenheit: Ein Entwicklungsprotokoll mit Pannen wirkt glaubwürdiger als eine glatte Kurve.

Der Blog räumt außerdem ein, dass TerminalBench 2.1 relativ gesättigt ist. Deshalb sei breitere Validierung wichtig, und deshalb gehöre auch DeepSWE mit seinen anspruchsvolleren Aufgaben auf Repository-Ebene zur Bewertung. Die Policies wurden über alle drei Evaluationssätze hinweg verfeinert, nicht auf einen einzelnen Benchmark hin.

Wer Terminal-Workflows und lokale Modelle im Blick hat, findet in unserem Beitrag zu Terminal-Workflows und lokalen Modellen eine passende Ergänzung. HydraFusion spricht in den Quellen zwar von Strategien zwischen lokalen, Cloud- und zusammengesetzten Modellen, konkrete lokale Modelle nennen sie aber nicht.

Wo die beiden GitHub-Texte auseinanderlaufen

Jetzt der Teil, den ich wirklich wichtig finde. Zwischen dem Research-Blog vom 4. September und dem Changelog vom 30. September liegen knapp vier Wochen. In dieser Zeit hat sich die Darstellung verändert. Beide Stände stehen hier nebeneinander.

Verfügbarkeit: CLI für alle, Editor für vier Pläne

Der Research-Blog vom 4. September sagt: HydraFusion ist für Nutzende auf allen GitHub-Copilot-Plänen verfügbar, und zwar über /experimental in der GitHub Copilot CLI. Die Schritte dort lauten: /update ausführen, /experimental on ausführen, dann /model öffnen und HydraFusion (Research Preview) wählen.

Der Changelog vom 30. September nennt dagegen Copilot Pro, Pro+, Business und Enterprise, und zwar für VS Code und die Copilot App. Das ist kein Widerspruch im strengen Sinn, denn es geht um verschiedene Oberflächen. Es ist aber auch nicht dieselbe Aussage. Der Blog spricht von allen Plänen in der CLI, der Changelog von vier genannten Plänen in den neuen Oberflächen. Ob es daneben weitere Pläne gibt, sagt der Changelog nicht, und ich rate nicht.

Abrechnung: nur ein Text sagt etwas

Der Research-Blog erklärt die Abrechnung. Die Nutzung basiert auf den Tokens der Modelle, die HydraFusion einsetzt, bepreist zum jeweiligen Standardtarif des Modells. Der Changelog vom 30. September wiederholt diesen Satz nicht. Ob das Prinzip in VS Code und der App identisch gilt, geht aus dem Changelog also nicht hervor. Konkrete Tokenpreise nennt keine der beiden Quellen, und ich habe keine.

Fortschritt: abwartend gegen angekündigt

Beim Thema Fortschrittsanzeige ist die Differenz am deutlichsten. Der Research-Blog schreibt unter „Showing progress without showing unfinished work“: Heute zeigt HydraFusion Workflow-Stufen, hält aber Zwischenentwürfe zurück, bis es ein zusammenhängendes Ergebnis liefert. Die Begründung: Diese Entwürfe können geprüft, revidiert oder verworfen werden, und ein Live-Anzeigen könnte unfertige Arbeit wie ein Endergebnis wirken lassen. Das Team räumt ein, dass Warten ohne ausreichende Sicht ein echter Kompromiss für Entwickelnde ist. Als Nächstes erkunde man aktiv bessere Fortschrittsmeldungen.

Der Changelog vom 30. September liest sich, als sei einiges davon bereits passiert. Er verspricht mehr Transparenz darüber, was HydraFusion in jedem Schritt tut, häufigere Fortschrittsupdates und einen klareren Status bei langen Aufgaben. Das hat sich also offenbar zwischen den beiden Terminen bewegt, und der Changelog ist der jüngere Stand. Der Blog nennt diese Verbesserungen nur als Absicht, der Changelog als Verbesserung.

Beide Aussagen sind nicht dasselbe wie „Sie sehen Zwischenentwürfe“. Der Blog erklärt, dass Entwürfe zurückgehalten werden. Der Changelog behauptet nicht das Gegenteil. Er spricht von Transparenz über Schritte und von Statusmeldungen. Ich lese beides so: Sie sehen mehr vom Ablauf, aber nicht zwingend die Zwischenstände selbst. Genaueres steht in den Quellen nicht, und ich werde es nicht auffüllen.

Wir bei digital-magazin.de halten das für den spannendsten Prüfpunkt der Preview. Wie fühlt sich eine lange Aufgabe an, wenn mehrere Etappen im Hintergrund laufen und nur Statusmeldungen herauskommen? Das beantwortet keine Tabelle.

Mehrere Legs: ein Gedankenexperiment zur Kostenfrage

Die Kostenrechnung der Quelle zählt jede Etappe mit: Entwurf, Critique, Revision, Eskalation, Retry und Fallback. Das ist ein Quellenfakt. Einen Messwert liefert er nicht, und eine Preisliste ebenso wenig. Was er bedeutet, lässt sich aber als Denkübung durchspielen.

Redaktionelles Gedankenexperiment, ohne Zahlen und ohne Messung: Stellen Sie sich eine Aufgabe vor, die im Cascade-Workflow läuft. Das effiziente Modell entwirft, das gleiche Gate lehnt den Entwurf ab, ein stärkeres Modell übernimmt. Schon sind es zwei Etappen. Fällt dann ein Aufruf aus und läuft ein Retry, ist es eine dritte. Bei Critique wären es Entwurf, Prüfung und Revision, also ebenfalls mehrere Etappen für eine einzige Aufgabe. Nach der Logik der Quelle würden alle in die geschätzten Workflow-Kosten einfließen. Der Gedanke dahinter: Ein Workflow ist nur dann günstig, wenn er im Mittel selten auf die teuren Pfade ausweichen muss. Wie oft das in Ihrer Codebasis passiert, weiß heute niemand außerhalb von GitHub. Das ist die offene Frage, die die Preview beantworten soll.

Warum erzähle ich das? Weil „67 Prozent niedrigere Kosten“ eine Durchschnittsaussage über einen Benchmark ist, nicht über die einzelne Aufgabe auf Ihrem Rechner. Dass die Quelle alle Etappen mitzählt, spricht für ehrliche Buchführung. Dass die Zahl eine Schätzung unter Preisannahmen bleibt, bleibt trotzdem bestehen.

Was die Preview noch nicht verspricht

Der Blog ist an dieser Stelle erfreulich nüchtern. Für diese Preview sind Coding-Aufgaben im ersten Turn mit einem einzigen Prompt der beste Einstieg. Starke Multi-Turn-Leistung bei längeren, iterativen Sessions steht erst als Nächstes auf der Liste. Das ist eine klare Einschränkung: Wer im Chat fünfmal nachsteuert, ist nicht der Zielfall.

Für das beste Erlebnis empfiehlt der Blog heute umfangreiche, gut abgegrenzte Coding-Aufgaben, die man Copilot im Autopilot-Modus in einem einzelnen Prompt übergibt. Das ist eine Empfehlung aus einem einzigen Quellensatz, mehr gebe ich dazu nicht wieder. Rückmeldungen sammelt GitHub über /feedback in der Copilot CLI und in der Community-Diskussion.

Dazu kommt der Generalvorbehalt. Ergebnisse, Modelle, Workflows, Verfügbarkeit, Namen und Produktverhalten können sich laut Blog ändern. Der Changelog wiederholt das mit dem Hinweis, HydraFusion bleibe eine Research Preview.

Meine Einschätzung

Ich halte die Grundidee für plausibel: Wer ohnehin Modelle von Hand kombiniert, spart sich Klickarbeit. Ich bin zugleich skeptisch gegenüber jeder Tabelle, in der die beste Konfiguration einer eigenen Evaluation gegen eine Baseline antritt. Das gilt nicht speziell für GitHub, sondern für Benchmark-Berichte allgemein. Die Zeile mit +4,9 Punkten ist beachtlich, die Zeilen mit −1,5 und −0,1 sind kein Fehlschlag, aber auch kein Sieg. Ob 36 oder 65 Prozent niedrigere geschätzte Kosten im Alltag ankommen, hängt davon ab, wie oft Single reicht.

Wer es ausprobieren will, hat jetzt drei Wege: die CLI laut Blog, VS Code ab 1.140 oder die Copilot App laut Changelog. Beginnen Sie mit einem gut abgegrenzten Auftrag, den Sie ohnehin Copilot geben würden, und achten Sie darauf, was HydraFusion in den Statusmeldungen zeigt. Notieren Sie, wo es hakt. Genau dieses Feedback wünscht sich GitHub.

Wir bei digital-magazin.de bleiben dran, sobald Quellen zu Multi-Turn-Verhalten oder zur Abrechnung in den neuen Oberflächen nachkommen. Bis dahin gilt: HydraFusion ist ein interessanter Versuch, die Modellwahl in den Ablauf zu verlegen. Ob er trägt, zeigt sich erst an echten Aufgaben.