GitHub Copilot Kosten: Was Fusion kann und wie es abrechnet

Abgeglichen mit der aktuellen Dokumentation und den Ankündigungen von GitHub am 29. Oktober 2026. Diese Einschätzung beruht auf der Dokumentation, nicht auf einem eigenen Praxistest.

Was ändert sich durch GitHub Copilot Fusion?

GitHub Copilot Fusion übernimmt die Modellauswahl und koordiniert bei Bedarf mehrere Modelle. Das ähnelt einem technischen Leiter, der entscheidet, ob eine Änderung direkt umgesetzt werden kann, eine zusätzliche Prüfung braucht oder an eine leistungsfähigere Instanz weitergereicht werden sollte. Die Aufgabe zu definieren und den erzeugten Code abzunehmen, bleibt Sache des Menschen.

GitHub hat Fusion am 28. Oktober 2026 allgemein verfügbar gemacht. Es verbindet die Orchestrierung von Project HydraFusion mit der automatischen Modellauswahl von Auto. Wer bisher Auto, HydraFusion oder HydraFusion Max ausgewählt hatte, wird auf die entsprechende Fusion-Aufwandsstufe umgestellt. Die Forschungsvorschau vom Oktober ist damit der Vorläufer von Fusion und kein zusätzlich benötigtes Produkt. GitHubs Ankündigung zu Fusion.

Die Ausführungsmuster legen fest, wie die Arbeit verteilt wird:

• Single: Ein Modell erledigt die Aufgabe direkt.
• Cascade: Eine Bewertungsinstanz prüft den Entwurf und nimmt ihn entweder an oder reicht die Aufgabe weiter.
• Critique: Ein Entwurf wird unabhängig kritisiert, bevor das ursprüngliche Modell ihn überarbeitet.

Diese Muster stammen aus GitHubs Forschung zu HydraFusion. Die aktuelle Fusion-Dokumentation beschreibt parallel arbeitende Kritiker, deren Rückmeldungen zusammengeführt werden. Das heißt nicht, dass jeder Prompt sämtliche Muster durchläuft. So arbeitet Fusion.

Eine Beschriftung zu korrigieren und eine Race Condition zu untersuchen, sollte beispielsweise nicht automatisch denselben Aufwand auslösen. Fusion entscheidet darüber innerhalb der Sitzung. Der übergreifende Erklärartikel zu Model Routern erläutert das Prinzip dahinter: Der Aufgabe wird eine passende Modellleistung zugeordnet; anschließend wird geprüft, ob diese Auswahl geholfen hat.

Wo ist Fusion verfügbar und wie wird es aktiviert?

Fusion lässt sich in der Copilot-App, in Visual Studio Code, in der Copilot CLI und in JetBrains-IDEs nutzen. GitHub nennt diese Anwendungen und die Verfügbarkeit über die Copilot-Tarife hinweg. Daraus folgt jedoch nicht, dass jedes Konto auf dieselben Aufwandsstufen zugreifen kann: Tarif und Richtlinien begrenzen weiterhin die verfügbaren Modelle. Aktuelle Verfügbarkeit.

Vor der Einrichtung sollte der jeweilige Client aktualisiert werden. Die früheren Schalter für die HydraFusion-Vorschau gehören nicht mehr zur aktuellen Fusion-Einrichtung.

GitHub Copilot-App

Unter dem Eingabefeld auf den Modellnamen klicken, Copilot Fusion aktivieren und eine der angebotenen Aufwandsstufen auswählen. Für die Rückkehr zu einem bestimmten Modell den Schalter deaktivieren und dieses Modell auswählen. Die App merkt sich die Auswahl für künftige Sitzungen. Modellauswahl in der App.

Visual Studio Code

In den Einstellungen prüfen, ob chat.copilot.dynamicAutoTiers.enabled aktiviert ist. Einen neuen Chat mit dem Copilot harness starten, also der Laufzeitumgebung, die das Modell mit den Werkzeugen des Agenten verbindet. In der Modellauswahl Copilot Fusion und anschließend eine verfügbare Stufe auswählen. Die Einstellung selbst schaltet keine Zugriffsberechtigung frei: Wenn keine berechtigte Fusion-Stufe angeboten wird, kann die Auswahl weiterhin Auto anzeigen. Einrichtung in VS Code.

GitHub Copilot CLI

In einer interaktiven Sitzung /model eingeben, Fusion samt Aufwandsstufe auswählen und bestätigen. Für einen klar begrenzten ersten Versuch dokumentiert GitHub die folgende Befehlsstruktur. Dieses Beispiel fordert eine Analyse ohne Dateiänderungen an:

copilot --model fusion --fusion-tier standard -p "Explain how this repository runs its tests. Do not edit files."

Das ist die aktuelle Fusion-Option; das frühere experimentelle HydraFusion-Flag wird dafür nicht verwendet. Modellauswahl in der CLI.

Welche Modelle kann Fusion einsetzen?

Der genannte Claude/GPT-Modellpool ist eine Momentaufnahme mit Datum und keine dauerhafte Zusage für das Routing. GitHubs HydraFusion-Update vom 14. Oktober 2026 führte ausdrücklich folgende Modelle auf:

• Claude Opus 5.5 von Anthropic.
• GPT-6 Astra von OpenAI.
• GPT-6.1 Sol von OpenAI.
• GPT-6 Luna von OpenAI.

Mit diesem Update kamen außerdem HydraFusion Max und ein höherer Denkaufwand für Entwurf und Prüfung hinzu. Die aufgeführten Namen sind die in der Vorschau-Ankündigung belegten Modelle. Update zum Modellpool im Oktober.

Die aktuelle Fusion-Übersicht veröffentlicht keine feste, vollständige Liste der Cloud-Modelle. Laut Dokumentation ändert sich der Pool. Welche Modelle tatsächlich verwendet wurden, lässt sich anzeigen, indem der Mauszeiger über die Aufwandsanzeige unter einer Antwort bewegt wird. Der gesamte Copilot-Modellkatalog ist keine Zusage, dass Fusion jeden Eintrag ansteuert. Aktuelles Verhalten des Modellpools.

Für die technische Leitung zählt vor allem, welche Modelle im eigenen Konto zugelassen sind. Enterprise-Verantwortliche finden die Konfiguration unter AI controls → Copilot → Models → Configure Copilot Fusion models. Auch diese Auswahl bleibt den übrigen Modellrichtlinien des jeweiligen Nutzers untergeordnet. Modellsteuerung für Enterprise.

Für lokales Routing gibt es eine separate Vorschau. Sie unterstützt bestimmte Konfigurationen mit MAI Code 1.1 Flash oder Qwen3.8 Flash Next auf der Stufe Standard. Ein beliebiges lokales Modell hinzuzufügen, macht es nicht automatisch nutzbar. Auch lokale Inferenz macht Fusion nicht offlinefähig: Das Routing findet weiterhin in der Cloud statt. Grenzen beim Einsatz lokaler Modelle.

Mit Standard beginnen und den Aufwand gezielt erhöhen

Standard ist der Ausgangspunkt. High oder Max sind erst sinnvoll, wenn die zusätzliche Prüfung eine konkrete Aufgabe hat. GitHub beschreibt Standard als Stufe für den Programmieralltag, High als Option für schwierige Aufgaben und gründlicheres Nachdenken und Max als Stufe für die anspruchsvollsten Arbeiten. Definitionen der Aufwandsstufen.

Die folgenden Aufgaben sind redaktionelle Empfehlungen für einen Test, keine gemessenen Leistungsaussagen:

Die vage Aufforderung, eine ganze Anwendung zu verbessern, eignet sich schlecht als Max-Test. Ohne definiertes Erfolgskriterium lässt sich nicht beurteilen, ob mehr Denkaufwand geholfen hat. Besser ist ein beobachtbares Problem, etwa einen doppelten Anfragepfad zu entfernen und dabei das Verhalten bei Wiederholungsversuchen beizubehalten.

Fusion Max bezeichnet eine Aufwandsstufe, kein dafür erforderliches Abonnement. Daneben gibt es Fusion Fast. Diese Stufe lässt sich jedoch nicht selbst auswählen und ist auf den Inline-Chat in VS Code beschränkt. Verfügbare Aufwandsstufen.

GitHub Copilot Kosten: Wie Fusion KI-Credits verbraucht

Abgerechnet wird die Arbeit, die die ausgewählten Modelle tatsächlich leisten. Eingabe-, Ausgabe- und zwischengespeicherte Tokens werden nach dem jeweiligen Modellpreis berechnet. Gegebenenfalls kommen Gebühren für das Schreiben in den Cache hinzu. Anschließend werden die Beträge in KI-Credits umgerechnet. Einen veröffentlichten Festpreis in Credits pro Fusion-Aufgabe gibt es nicht. So rechnet GitHub ab.

Fusion erhebt keine separate Orchestrierungsgebühr. Kostenpflichtige Copilot-Tarife erhalten derzeit 30% Rabatt auf die Fusion-Modellkosten bis zum 30. November 2026. Abrechnung von Fusion. Die Tarife und enthaltenen Kontingente behandelt der Preisleitfaden zu GitHub Copilot.

Entwurf, Kritik und Überarbeitung verursachen jeweils Verbrauch. Auch Denkaufwand, Kontextgröße, Werkzeugaufrufe und Caching wirken sich darauf aus. Deshalb kann ein Durchlauf mit mehreren Bearbeitungsschritten mehr Credits benötigen als eine Anfrage an ein einzelnes Modell, selbst wenn das Routing genau wie vorgesehen funktioniert. Die VS-Code-Erklärung zum Verbrauch von KI-Credits.

Im Test müssen auch gescheiterte Versuche und Korrektur-Prompts mitgezählt werden. Ein günstiger Entwurf, der wiederholt nachgebessert werden muss, kann insgesamt schlechter abschneiden als ein teurerer Durchlauf mit einer akzeptablen Änderung. Umgekehrt bringt eine zusätzliche Kritik bei einer einfachen Umbenennung womöglich keinen Nutzen. Entscheidend ist die abgeschlossene Arbeit, nicht die günstigste Einzelantwort.

Was belegt GitHubs Benchmark – und was nicht?

GitHub meldet ein vielversprechendes Ergebnis. Einsparungen im eigenen Repository sind damit noch nicht belegt. In seiner Universe-Ankündigung schreibt GitHub:

Die genannte Auswertung ist der Artificial Analysis Coding Agent Index. Es handelt sich um eine von GitHub veröffentlichte Benchmark-Aussage, nicht um einen unabhängigen Test für diesen Artikel. GitHubs Universe-Ankündigung.

Im ausführlichen Changelog nennt GitHub als Vergleich Claude Code mit Opus 5.5 Max und beschreibt die Kostenkennzahl als durchschnittliche API-Kosten pro Aufgabe. Das ist eine deutlich engere Aussage als die Behauptung, Fusion halbiere eine Copilot-Rechnung. Kontext zu GitHubs Benchmark.

Daraus lässt sich ableiten, dass Orchestrierung starke Ergebnisse möglicherweise effizienter erreicht als die dauerhafte Wahl einer besonders aufwendigen Konfiguration. Nicht belegt ist dagegen, dass jede Fehlerbehebung schneller oder günstiger wird. Ob sich das Ergebnis übertragen lässt, hängt vom Aufgabenmix, den Abnahmekriterien und der nötigen Nacharbeit ab. Auch die befristete Rabattaktion und der Benchmark-Vergleich sind unterschiedliche Aussagen. Sie dürfen nicht zu einem gemeinsamen Sparversprechen verrechnet werden.

Was bedeutet Fusion für Entwicklung, technische Leitung und Einkauf?

Entwickler können die Modellauswahl abgeben. Wer seine Arbeit immer wieder unterbricht, um über das passende Modell für die nächste Aufgabe nachzudenken, sollte Fusion in einem begrenzten Rahmen testen. Problembeschreibung, erwartetes Verhalten und Prüfmaßstab müssen dabei klar bleiben. Die delegierte Auswahl soll Ablenkung reduzieren, ohne die Aufgabe ungenauer zu machen.

Technische Führungskräfte brauchen Regeln für die Aufwandsstufen und eine Dokumentation der abgenommenen Ergebnisse. Als Ausgangspunkt bietet sich Standard für Routineaufgaben an, High für klar umrissene Änderungen mit Prüfbedarf und Max nach bewusster Entscheidung. Festgehalten werden sollte, warum eine höhere Stufe geholfen hat. Sonst wird die höchste Einstellung schnell zur Gewohnheit, ohne dass ein Nutzen für den ausgelieferten Code belegt ist.

Wer Copilot mit Claude Code oder Cursor vergleicht, sollte den tatsächlich geplanten Arbeitsablauf testen. Ein Benchmark liefert einen Anlass zur Prüfung, aber noch keinen Grund, eine ganze Organisation umzustellen. Neben den Credits zählen Prüfaufwand, Eignung für das Repository und abgeschlossene Ergebnisse. Der Vergleich von Claude Code und GitHub Copilot hilft bei der übergeordneten Entscheidung; Fusion verändert einen Teil davon.

Wo wird Fusion überschätzt und wann sollte es ausgeschaltet bleiben?

Mehr beteiligte Modelle entbinden nicht von der Verantwortung für den Diff. GitHub dokumentiert eine besonders wichtige Einschränkung: Auch verworfene Entwürfe können Dateiänderungen hinterlassen. Fusion besitzt außerdem kein eigenes, zusammengeführtes Kontextfenster und startet keine Unteragenten. Grenzen von Fusion.

Fusion sollte ausgeschaltet bleiben, wenn ein bestimmtes Modell für einen kontrollierten Vergleich, eine reproduzierbare Untersuchung oder einen ausdrücklich freigegebenen Arbeitsablauf benötigt wird. Eine feste Modellauswahl verhindert, dass das Routing zu einer weiteren Variablen wird. Deterministisch wird ein Sprachmodell dadurch nicht; es entfällt lediglich eine Quelle von Schwankungen.

Erledigt eine vertraute Konfiguration mit einem fest ausgewählten Modell die klar begrenzte Aufgabe bereits mit wenig Korrekturaufwand, besteht erst dann Handlungsbedarf, wenn ein Test einen praktischen Vorteil zeigt. Ein Wechsel ist kein Muss.

Abwarten ist auch sinnvoll, wenn ein Offline-Arbeitsablauf gefordert ist oder eine akzeptable Änderung weder definiert noch geprüft werden kann. Bei winzigen Routineanfragen kann es genügen, auf Aufwandsstufen mit viel Orchestrierung zu verzichten und Standard beizubehalten. „Max ausgeschaltet lassen“ und „Fusion ausgeschaltet lassen“ sind unterschiedliche Entscheidungen.

GitHub Copilot Fusion in der Praxis: Diese Woche an einem Repository testen

Der Test sollte klein genug bleiben, um jedes Ergebnis prüfen zu können. Dafür ein bekanntes Repository auswählen und Fusion mit der bisher verwendeten Modellkonfiguration vergleichen.

Der nächste Schritt für diese Woche: Eine Person für die Entwicklung und eine für die Prüfung dieses Repositorys benennen, die Abnahmeprüfungen vereinbaren und die Standardeinstellung erst nach Sichtung der entstandenen Änderungen festlegen. Eine nachvollziehbare Entscheidungsdokumentation ist nützlicher als ein Screenshot der schnellsten Antwort.

Den Newsletter abonnieren für praktische Leitfäden zur Auswahl und zum Einsatz von KI-Entwicklungswerkzeugen.