GitHub hat auf seiner Konferenz Universe am 28. Oktober 2026 GitHub Copilot Fusion allgemein verfügbar gemacht. Statt für jede Aufgabe selbst ein Modell auszuwählen, wählen Entwickler im Model Picker einfach „Copilot Fusion“ und eine Aufwandsstufe. Den Rest erledigt ein Router, der pro Anfrage entscheidet, welches Modell arbeitet und ob ein zweites Modell das Ergebnis prüft. Gleichzeitig startet eine experimentelle Vorschau, bei der Fusion auch lokale Modelle auf dem eigenen Rechner einbeziehen kann.
Das klingt nach Komfort, hat aber handfeste Folgen für Kosten, Nachvollziehbarkeit und Unternehmensrichtlinien. Wir erklären, wie Copilot Fusion funktioniert, was GitHub verspricht und worauf Teams achten sollten.
Key Takeaways
- GitHub Copilot Fusion ist ein Modell-Router und Orchestrator, kein eigenes Modell. Es ist seit dem 28. Oktober allgemein verfügbar.
- Drei wählbare Stufen: Fusion Standard, Fusion High und Fusion Max. Je nach Aufgabe arbeitet ein Modell allein oder mehrere Modelle prüfen sich gegenseitig.
- Laut GitHub erreicht Fusion Max im Coding Agent Index von Artificial Analysis 60 Punkte, zwei Punkte hinter Claude Code mit Opus 5.5 Max, bei etwa halben Kosten pro Aufgabe.
- Abgerechnet wird jedes genutzte Modell zum Standardtarif. Bis 30. November 2026 gibt es 30 % Rabatt auf Modellkosten in bezahlten Plänen.
- Lokale Modelle (MAI Code 1.1 Flash, Qwen3.8 Flash Next) lassen sich in einer experimentellen Vorschau einbinden. Die Routing-Entscheidung fällt trotzdem in der Cloud.
Wie GitHub Copilot Fusion funktioniert
Laut der GitHub-Dokumentation zu Copilot Fusion bewertet das System jede Anfrage anhand von Fähigkeitssignalen für Schlussfolgern, Codegenerierung, Debugging und Werkzeugnutzung. Daraus wählt es eines von drei Ausführungsmustern:
- Single: Ein Modell erledigt die Aufgabe allein. Das verhält sich wie eine normale Anfrage an ein einzelnes Modell.
- Cascade: Ein effizientes Modell schreibt einen Entwurf, ein „Richter“ prüft ihn und entscheidet, ob er akzeptiert oder an ein stärkeres Modell eskaliert wird.
- Critique: Ein Modell entwirft eine Antwort, mehrere andere Modelle kritisieren sie parallel, und das erste Modell überarbeitet sein Ergebnis anhand des gebündelten Feedbacks.
Das Muster wird pro Prompt gewählt. Innerhalb einer Sitzung kann also auf eine einfache Single-Antwort eine aufwendigere Critique-Runde folgen. Fusion berücksichtigt außerdem die aktuelle Auslastung und Verfügbarkeit der Modelle. Den Fortschritt der einzelnen Schritte und das jeweils aktive Modell kann man mitverfolgen, angezeigt wird am Ende aber nur die finale Antwort.
Neu ist die Idee nicht ganz. Copilot Fusion vereint laut GitHub die Multi-Modell-Orchestrierung aus Project HydraFusion mit der bisherigen automatischen Modellauswahl. Über HydraFusion als Forschungsvorschau haben wir Mitte Oktober berichtet. Wer HydraFusion oder Auto bereits nutzte, wird automatisch auf die passende Fusion-Stufe umgestellt.
Die Aufwandsstufen im Überblick
Statt eines Modells wählt man eine Aufwandsstufe. Die Dokumentation beschreibt sie so:
- Fusion Standard: balanciert Kosten, Qualität und Latenz. Für die alltägliche Arbeit, Fusion wählt pro Aufgabe ein Modell.
- Fusion High: orchestriert mehr, für umfangreiche, klar umrissene Aufgaben wie einen komplexen Bugfix oder Änderungen über mehrere Dateien.
- Fusion Max: priorisiert die stärksten Modelle für Aufgaben mit dem tiefsten Schlussfolgern.
Eine vierte Stufe, Fusion Fast, ist nicht auswählbar und wird nur für Inline-Chat in Visual Studio Code genutzt. Copilot Fusion ist in Visual Studio Code, der GitHub-Copilot-App, Copilot CLI und den JetBrains-IDEs verfügbar.
Was GitHub Copilot Fusion kostet
Eine eigene Gebühr für Fusion gibt es nicht. Abgerechnet wird jedes Modell, das Fusion verwendet, zu seinem normalen Tarif. Das ist der Punkt, den Teams genau verstehen sollten: Bei Fusion High und Fusion Max können für eine Aufgabe mehrere Modelle laufen, die Aufgabe kann also mehr AI Credits verbrauchen als mit Fusion Standard. Bis zum 30. November 2026 gewährt GitHub Nutzern bezahlter Pläne 30 % Rabatt auf die Modellkosten bei Fusion.
GitHub argumentiert umgekehrt mit Effizienz. Laut dem Changelog-Eintrag zum Start kam Fusion Max im Coding Agent Index von Artificial Analysis auf 60 Punkte und lag damit zwei Punkte hinter Claude Code mit Opus 5.5 Max. Dafür habe Fusion Max etwa die Hälfte der durchschnittlichen API-Kosten pro Aufgabe benötigt, etwa halb so viele Tokens verbraucht und rund 40 % weniger Zeit gebraucht. Fusion halte die Hauptkonversation zudem möglichst auf demselben Modell, damit gecachte Tokens weiter greifen.
Das sind Herstellerangaben zu einem einzelnen Benchmark. Ob sich die Ersparnis im eigenen Alltag einstellt, hängt stark vom Aufgabenmix ab. Ein sinnvoller Test: eine Woche lang typische Aufgaben mit Fusion Standard und mit dem bisherigen Lieblingsmodell bearbeiten und den Credit-Verbrauch vergleichen.
Lokale Modelle: experimentell und nicht offline
Parallel hat GitHub eine experimentelle Vorschau für lokale Modelle gestartet. Fusion Standard kann dann zwischen unterstützten Modellen auf dem eigenen Gerät und Cloud-Modellen wählen. Unter Windows lässt sich MAI Code 1.1 Flash über den Windows-ML-Provider direkt herunterladen. In Copilot CLI funktioniert das Routing auch unter macOS und Linux mit manuell eingerichteten Modellen, konkret MAI Code 1.1 Flash oder Qwen3.8 Flash Next über einen lokalen OpenAI-kompatiblen Server.
Zwei Einschränkungen nennt GitHub selbst. Erstens wird die Sitzung durch lokale Inferenz nicht offline: Die Routing-Entscheidung trifft Fusion weiterhin in der Cloud. Zweitens können lokale Modelle andere Schutzmechanismen haben als die Cloud-Modelle von Copilot. Wer lokale Modelle aus Datenschutzgründen nutzen will, sollte das im Hinterkopf behalten.
Kontrolle für Administratoren
Für Unternehmen wichtig: Fusion nutzt nur Modelle, die in den Modellrichtlinien von Enterprise und Organisation freigegeben sind. Administratoren können einsehen, aus welchen Modellen Fusion wählt, einzelne Modelle nur für Fusion sperren und Fusion in jeder Stufe als Standardmodell setzen. Modelle, die durch Richtlinien für Datenresidenz oder FedRAMP ausgeschlossen sind, verwendet Fusion ebenfalls nicht. Sind keine passenden Modelle verfügbar, erscheint Fusion gar nicht im Model Picker.
Eine Einschränkung aus der Dokumentation sollten Entwickler kennen: Verwirft Fusion einen Entwurf, werden Änderungen, die dieser Entwurf bereits im Workspace vorgenommen hat, nicht automatisch rückgängig gemacht. Änderungen also vor dem Commit prüfen. Fusion startet außerdem keine Subagenten.
Einordnung: Modellwahl wird zur Plattformfunktion
Copilot Fusion passt zu den Zahlen, die GitHub parallel im Octoverse-Bericht veröffentlicht hat. Demnach nutzten im September 61 % der Copilot-Nutzer, die selbst ein Modell wählen, mehr als ein Modell. Auf bezahlten Plänen kamen im September 47 verschiedene Modelle zum Einsatz, kein einzelnes Modell trug mehr als 25 % der Anfragen. Und mehr als 40 % der Pull Requests starteten laut GitHub inzwischen mit dem Entwurf eines Agenten, im März waren es 17 %.
Wenn die Zahl der Modelle weiter wächst, wird die manuelle Auswahl zur Last. Ein Router nimmt diese Entscheidung ab, macht sie aber auch weniger sichtbar. Wer verstehen will, warum ein Ergebnis so ausgefallen ist, muss nachsehen, welche Modelle beteiligt waren. Das ist bei Fusion möglich, erfordert aber Aufmerksamkeit. Wie sich Agenten-Werkzeuge generell unterscheiden, zeigt unser Vergleich der KI-Agent-Tools.
Fazit
GitHub Copilot Fusion ist eine pragmatische Antwort auf ein echtes Problem: zu viele Modelle, zu viele Entscheidungen. Für Alltagsaufgaben dürfte Fusion Standard vielen Entwicklern Arbeit abnehmen. Die Effizienzversprechen beruhen aber auf einem Benchmark und GitHubs eigenen Angaben, und die höheren Stufen können mehr Credits kosten als erwartet. Teams sollten den Verbrauch in den ersten Wochen beobachten, Richtlinien bewusst setzen und Änderungen vor dem Commit prüfen. Die lokale Variante ist interessant, aber ausdrücklich experimentell.
