Die Modellauswahl wird zur Orchestrierungsauswahl

GitHub hat HydraFusion am 30. September aus der Kommandozeile in den Editor verlagert. Die Research Preview läuft jetzt in VS Code 1.140 und neuer sowie in der GitHub-Copilot-App – und stellt normale Entwicklerinnen und Entwickler vor eine recht ungewöhnliche Idee: Wähle kein Modell, wähle einen Workflow.

HydraFusion ist kein Modell. Es ist eine Schicht, die für jeden Turn entscheidet, wie viele Modellrollen die Aufgabe benötigt.

Drei Formen für eine Anfrage

Single ist der vertraute Fall. Ein Modell bearbeitet die Anfrage, so wie Copilot Auto bereits arbeitet.

Cascade beginnt günstig. Ein effizientes Modell schreibt einen ersten Entwurf, und ein Quality Gate akzeptiert ihn entweder oder eskaliert die Arbeit an ein stärkeres Modell. Der Sinn: Routineänderungen bei kostengünstigen Modellen halten und die teuren für Probleme reservieren, die sie tatsächlich brauchen.

Critique gibt mehr aus, um sicherer zu sein. Ein Modell entwirft, ein zweites Modell aus einer anderen Familie fungiert als Read-only-Kritiker, und das entwerfende Modell überarbeitet einmal auf Basis dieses Feedbacks. Der Kritiker berührt den Code nie, was verhindert, dass die Schleife zu einem Streitgespräch zweier Modelle wird.

Der Unterschied zu Auto ist architektonisch. Auto entscheidet, welches einzelne Modell deinen Prompt erhalten soll. HydraFusion entscheidet, wie viele Rollen der Turn benötigt und wie sie zusammenspielen. Das ist eine bedeutsame Verschiebung dessen, wo die Steuerung der Intelligenz liegt. Historisch wählte man ein Modell, weil es bei der eigenen Art von Arbeit besser war. Hier wählt man eine Optimierungsstrategie und lässt die Plattform die Modelle darunter zusammensetzen.

Die Ökonomie ist real – und selbst berichtet

Der Haken ist die Abrechnung. GitHub berechnet nach Tokens zum Standardtarif des jeweils gewählten Modells. Ein Critique-Durchlauf ruft mindestens zwei Modelle auf, kann also pro Anfrage mehr kosten als ein einzelner Aufruf. Cascade ist darauf ausgelegt, weniger zu kosten, indem einfache Arbeit nach unten weitergereicht wird. Die Ersparnis ist kein Rabatt auf irgendein Modell. Sie ist eine Wette darauf, dass die meisten Turns nicht das beste Modell brauchen.

GitHubs eigene kontrollierte Evaluationen berichteten von Workflow-Kostensenkungen zwischen 36 und 67 Prozent gegenüber der Claude-Opus-5-Baseline über drei Coding-Agent-Benchmarks, bei einer um 4,9 Prozentpunkte höheren Qualität auf TerminalBench 2.1, 1,5 Punkten niedriger auf DeepSWE und 0,1 Punkten niedriger auf CheckpointBench. Das sind vom Anbieter erzeugte Zahlen auf GitHubs eigenem Testaufbau. Sie sind eine Hypothese über dein Repository, keine Garantie, und der Modellpool, der an HydraFusion teilnimmt, wurde nicht vollständig veröffentlicht. Alles, was auf der Preview aufbaut, sollte Routing-Verhalten als etwas behandeln, das sich ohne Ankündigung ändern kann.

Dazu kommt ein schlichter Latenzkostenfaktor. Ein Entwurf plus eine Überprüfung dauert länger als eine einzelne Antwort. Teams mit Business- und Enterprise-Plänen müssen die Nutzungs-Dashboards genau im Blick behalten, denn das System entscheidet, wann eskaliert wird, und diese Entscheidung ist nicht kostenlos.

Eine Optimierung, die man nicht einsehen kann, ist schwer zu vertrauen

Das Unangenehme am Routing ist, dass die Entscheidung von der Plattform getroffen wird, nicht vom Entwickler. Man kann im Nachhinein sehen, welches Modell geantwortet hat, aber man kann nicht ohne Weiteres sehen, warum das System einen Workflow gewählt hat, was das Quality Gate gemessen hat oder wie knapp ein Cascade-Durchlauf vor der Eskalation stand. GitHubs Benchmark-Angaben beschreiben einen Durchschnitt über den eigenen Testsatz, und Durchschnitte verbergen die Fälle, auf die es ankommt.

Diese Lücke macht Orchestrierung zu einem Governance-Problem statt zu einem rein technischen. Ein Engineering-Team, das erklären muss, warum ein bestimmter Pull Request von zwei Modellfamilien geprüft und entsprechend abgerechnet wurde, braucht Routing-Telemetrie – und die Preview legt sie noch nicht offen. Das Gegenmittel ist nicht, das Feature zu meiden. Es ist, es so zu testen, wie man jede Abhängigkeit mit verborgenem Innenleben testen würde: an einem festen, langweiligen Satz von Repository-Aufgaben, indem man die Kosten abgeschlossener Aufgaben gegen ein einzelnes Frontier-Modell misst und auf Wiederholungen und Review-Aufwand achtet statt auf den Listenpreis einer einzelnen Auswahl.

Der Vergleich mit Auto lohnt sich festzuhalten. Auto beantwortet die Frage, welches Modell am besten zu einem Prompt passt. HydraFusion beantwortet die Frage, wie viel Prozess ein Turn verdient – und der Prozess war schon immer der teure Teil der Softwarearbeit.

Der kuriose Nebeneffekt: Die Modellwahl wird weniger emotional. Entwicklerinnen und Entwickler bauen Bindungen zu bestimmten Modellen auf, und diese Bindungen beruhen meist auf einer Handvoll einprägsamer Erfolge. Ein System, das nach Aufgabentyp routet und bei Fehlschlag eskaliert, räumt still ein, dass kein einzelnes Modell jede Kategorie gewinnt – was seit einer Weile gilt und selten Konsequenzen hat.

Die nächste Ecke des Editors wird dafür gebaut

Der Insiders-Build zeigt bereits, wohin es als Nächstes geht. Ein Feature namens Compare Agents, beschriftet mit Run Multiple Agents, schickt einen Prompt parallel an mehrere Agenten, jeder in seinem eigenen Git-Worktree, und lässt dann einen Schiedsrichter-Agenten einen Gewinner küren oder die Auswahlliste an eine Person weitergeben.

Das interessante Detail ist, worauf der Schiedsrichter schaut. Er vergleicht geänderte Dateien und Diff-Statistiken, Testergebnisse, Build-Status, Diagnosen, Timing und architektonische Unterschiede. Er führt die Testsuite aus. Er bittet kein anderes Sprachmodell, den Code zu lesen und zu raten. Das ist eine kleine Entscheidung mit großen Folgen, denn sie bedeutet, dass der Vergleich auf dem tatsächlichen Zustand des Projekts fußt statt auf der Meinung eines Modells darüber.

Der Rest desselben Releases ist leisere Infrastruktur, die erst zählt, wenn Agenten parallel laufen. Multi-Folder-Sessions lassen jede Konversation in einer Session den eigenen Ordner oder Worktree nutzen, sodass Änderungen nicht mehr kollidieren. Remote Delegation übergibt eine Aufgabe an einen verbundenen Remote-Agent-Host. Shared Worktree Folders verwenden ignorierte Verzeichnisse wieder, um Abhängigkeiten nicht auf jedem Branch neu zu installieren. Dev Containers stoppen jetzt nach fünf Minuten Leerlauf und starten bei Bedarf neu.

Governance kommt weiterhin in denselben Commits wie die Features

Die IT-seitige Hälfte des Releases ist kein Nachgedanke. Wenn KI-Features nicht verfügbar sind, nennt der Editor jetzt die mindestens erforderliche Version statt eines generischen Hinweises zum Aktualisieren. Administratoren können eine Standardstufe für das Auto-Modell festlegen. Eine neue OpenTelemetry-Einstellung ordnet die Copilot-Nutzung einzelnen Entwicklerinnen und Entwicklern zu.

Liest man diese drei zusammen, ist die Stoßrichtung klar. Eine Plattform, die mehrere Modelle über mehrere Turns koordiniert, erzeugt Kosten, Telemetrie und Berechtigungsfragen, die eine Single-Model-Autovervollständigung nie aufgeworfen hat. Kostenattribution ist keine Finanzspielerei mehr, sondern eine Voraussetzung dafür, das Feature überhaupt in die Nähe der Produktion zu lassen.

Multi-Model-Review ist bei sorgfältigen Engineering-Teams seit einer Weile gängige Praxis. Man lässt ein Modell schreiben und ein anderes nach Fehlern suchen, oder man probiert erst ein schnelles Modell und eskaliert, wenn die Ausgabe enttäuscht. HydraFusion nimmt diese Gewohnheit und automatisiert sie, was praktisch ist – und zugleich eine Entscheidung entfernt, die manche Teams gern selbst getroffen haben.

Wie lange ein Preview-Feature ein Preview bleiben sollte, ist eine berechtigte Frage. Das Tooling landet schneller als die Richtlinien drumherum, und die Preisvorhersehbarkeit ist das erste Opfer. Ein Critique-Durchlauf, der auf einem großen Repository still zwei Frontier-Modelle aufruft, kann echtes Geld ausgeben, bevor es jemand merkt. Ob HydraFusion zum Standard wird, hängt weniger davon ab, ob das Routing funktioniert, als davon, ob GitHub die Rechnung lesbar genug machen kann, damit jemand sie abzeichnet.