GitHub Copilot stellt sechs KI-Modelle ein: Das ändert sich jetzt

Was GitHub zum 1. September offiziell ändert

GitHub nennt den 1. September 2026 als Abschaltdatum für sechs Modelle in Copilot: Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6 und Raptor Mini. Die Ankündigung umfasst ausdrücklich Copilot Chat, Inline Edits, Ask- und Agent-Modi sowie Code Completions. Entscheidend für die Aktualität ist damit der heutige Wirksamkeitstermin, nicht das Veröffentlichungsdatum des Changelog-Eintrags vom 31. Juli.

GitHub erklärt, dass Nutzer nichts unternehmen müssen, um die auslaufenden Modelle aus Copilot zu entfernen. Anders sieht es bei eigenen Abläufen aus: Workflows und Integrationen mit einer festen Modellwahl sollen auf ein unterstütztes Modell umgestellt werden. Wo ein Modell nur interaktiv ausgewählt wurde, verschwindet es aus der verfügbaren Auswahl; wo sein Name in Regeln oder Automationen steckt, ist eine bewusste Prüfung nötig.

Der bestätigte Stichtag ist der 1. September 2026. Die Änderung gilt laut GitHub über sämtliche Copilot-Erlebnisse hinweg.

Diese Ersatzmodelle empfiehlt GitHub

Für jedes auslaufende Modell nennt GitHub mindestens eine Alternative. Gemini 3.1 Pro soll durch Gemini 3.6 Flash ersetzt werden. Für Claude Opus 4.5 und 4.6 nennt GitHub Claude Opus 4.7, 4.8 oder 5. Bei Claude Sonnet 4.5 und 4.6 führt die Empfehlung zu Claude Sonnet 5. Raptor Mini soll durch MAI-Code-1-Flash ersetzt werden.

Das sind offizielle Migrationsvorschläge innerhalb von Copilot, aber keine Aussage über funktionale Gleichheit. Die Modelle stammen teils aus anderen Generationen oder Modellfamilien und können Aufgaben anders planen, mehr oder weniger Kontext verbrauchen und bei Agentenläufen andere Werkzeuge wählen. GitHubs Mitteilung enthält weder Vergleichsmessungen noch eine Garantie für identische Kosten oder Antwortzeiten.

• Gemini 3.1 Pro: Gemini 3.6 Flash
• Claude Opus 4.5 und 4.6: Claude Opus 4.7, 4.8 oder 5
• Claude Sonnet 4.5 und 4.6: Claude Sonnet 5
• Raptor Mini: MAI-Code-1-Flash

Für Claude Sonnet 4.6 gilt eine begrenzte Ausnahme

Claude Sonnet 4.6 bleibt nach GitHubs Ankündigung für individuelle Copilot-Abonnenten mit einem Jahresplan verfügbar. GitHub begründet die Ausnahme damit, diesen Kunden weiterhin ein Sonnet-Angebot bereitzustellen. Für andere Nutzergruppen gilt die allgemeine Einstellung zum 1. September.

Die Ausnahme sollte nicht auf Organisationen, monatliche Einzelabos oder andere Copilot-Pläne übertragen werden. Welche Modelle tatsächlich auswählbar sind, hängt laut GitHub-Dokumentation zusätzlich vom Copilot-Plan, vom verwendeten Client und von Richtlinien der Organisation oder des Unternehmens ab. Maßgeblich ist deshalb die verfügbare Modellauswahl im eigenen Konto, nicht nur eine allgemeine Modellliste.

Ausnahme laut GitHub: Claude Sonnet 4.6 bleibt individuellen Copilot-Abonnenten mit Jahresplan erhalten.

Enterprise-Richtlinien können den Wechsel blockieren

GitHub weist darauf hin, dass Copilot-Enterprise-Administratoren den Zugriff auf ein vorgeschlagenes Ersatzmodell möglicherweise erst über die Modellrichtlinien freigeben müssen. Ein Modell kann technisch von Copilot unterstützt werden und trotzdem für ein bestimmtes Unternehmen nicht im Auswahlmenü erscheinen. Die aktuelle Einstellung lässt sich in den Copilot-Richtlinien und anschließend im Modellselektor von Copilot Chat kontrollieren.

Für Business- und Enterprise-Teams reicht es daher nicht, nur eine alte Modellkennung durch einen neuen Namen zu ersetzen. Vorher muss geklärt sein, ob das Zielmodell für den jeweiligen Plan, Client und Organisationskontext verfügbar und erlaubt ist. GitHubs Dokumentation zur Modellfreigabe beschreibt genau diese Abhängigkeiten.

• Unterstützte Modelle in der aktuellen GitHub-Dokumentation prüfen
• Organisations- und Enterprise-Richtlinien für das Zielmodell kontrollieren
• Verfügbarkeit im tatsächlich verwendeten Client bestätigen
• Erst danach gespeicherte Defaults und Automationen umstellen

Wo feste Modellvorgaben übersehen werden können

Betroffen sind nicht nur sichtbare Chat-Einstellungen. Modellnamen können in IDE-Konfigurationen, Teamvorgaben, wiederverwendeten Prompts, Agentenprofilen, API-nahen Integrationen oder internen Anleitungen festgehalten sein. Auch ein automatisch gewähltes Modell kann indirekt von Richtlinien abhängen, die nur bestimmte Alternativen zulassen.

Besondere Aufmerksamkeit brauchen unbeaufsichtigte Abläufe. Ein Entwickler bemerkt eine fehlende Auswahl meist sofort; ein nächtlicher Agentenlauf, eine automatisierte Review-Aufgabe oder eine Codegenerierung in einer Pipeline kann dagegen erst später fehlschlagen. Vor dem nächsten produktionsnahen Lauf sollten Teams deshalb alte Modellnamen systematisch suchen und für jede Fundstelle einen verantwortlichen Besitzer festlegen.

Ein sicherer Modellwechsel braucht Vergleichsaufgaben

Die offizielle Alternative ist ein sinnvoller Startpunkt, aber noch keine Abnahme. Für wiederholbare Entwicklungsaufgaben sollte das Ersatzmodell denselben Repository-Stand, denselben Prompt und dieselben Werkzeuge wie der bisherige Referenzlauf erhalten. So wird sichtbar, ob sich Änderungsumfang, Testverhalten, Laufzeit oder notwendige menschliche Eingriffe verschieben.

Ein kompakter Testsatz umfasst mindestens eine Fehleranalyse, ein Refactoring, Testgenerierung, Code-Review und einen längeren Agentenlauf. Teams sollten nicht nur prüfen, ob am Ende Code entstanden ist, sondern ob die richtigen Dateien verändert wurden, Tests vollständig liefen und Freigabegrenzen eingehalten wurden. Bei kritischen Workflows gehört außerdem eine Rückfalloption zu einem bereits freigegebenen Modell in den Plan.

• Bisheriges Ergebnis und verwendete Modellkennung dokumentieren
• Ersatzmodell mit identischem Code, Prompt und Werkzeugzugriff testen
• Dateiumfang, Testergebnis, Eingriffe, Laufzeit und Verbrauch vergleichen
• Unbeaufsichtigte Läufe zunächst überwacht ausführen
• Modellfreigabe und Rückfalloption schriftlich festhalten

Was die Ankündigung offenlässt

GitHub beschreibt nicht für jeden Client, wie eine gespeicherte alte Modellwahl nach der Einstellung dargestellt oder behandelt wird. Die Mitteilung sagt auch nicht, ob einzelne Oberflächen automatisch auf das vorgeschlagene Modell wechseln, einen Fehler anzeigen oder eine neue Auswahl verlangen. Das kann während des Rollouts je nach Client und Konfiguration unterschiedlich sichtbar werden.

Ebenso fehlen in der Abschaltungsmitteilung belastbare Aussagen zu Qualitätsunterschieden, Latenz, Kontextgrenzen und tatsächlichen Kosten der Ersatzmodelle. Diese Punkte müssen in der aktuellen Modell- und Preisdokumentation sowie im eigenen Copilot-Plan geprüft werden. Behauptungen, eines der neuen Modelle sei pauschal besser oder günstiger, lassen sich aus dem Changelog allein nicht ableiten.

Die MindrAils-Einordnung

Die gleichzeitige Einstellung von sechs Modellen zeigt, wie schnell sich das Angebot einer Multi-Modell-Plattform verändert. Ein Modell kann beim ursprünglichen Anbieter oder in anderen Produkten weiterbestehen und trotzdem aus Copilot verschwinden. Für Nutzer zählt deshalb nicht nur, ob ein Modell grundsätzlich existiert, sondern ob es im eigenen Plan, Client und Richtlinienkontext verfügbar ist.

Für gelegentliche Chat-Nutzer bleibt die Umstellung meist überschaubar. Das größere Risiko liegt in fest verdrahteten oder unbeaufsichtigten Workflows, die von einem bestimmten Modellverhalten ausgehen. Wer Modellabhängigkeiten auffindbar hält, Alternativen mit echten Aufgaben testet und die Freigabe zentral dokumentiert, kann solche Wechsel kontrolliert statt unter Zeitdruck bewältigen.