GitHub Copilot: Vier Modelle bis 2. Oktober migrieren

GitHub stellt am 2. Oktober 2026 vier Modelle in sämtlichen GitHub-Copilot-Erlebnissen ein: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code und Claude Opus 4.7. Betroffen sind laut GitHub Copilot Chat, Inline Edits, Ask- und Agent-Modi sowie Code Completions. Unternehmen sollten deshalb nicht nur den Modellselektor einzelner Entwickler prüfen. Entscheidend ist, wo ein auslaufendes Modell in persönlichen Einstellungen, Teamkonventionen, Integrationen oder automatisierten Abläufen fest hinterlegt ist.

Diese vier Modelle und Alternativen nennt GitHub

Die folgende Zuordnung ist offiziell bestätigt. Die Alternativen sind Empfehlungen von GitHub, aber noch keine automatische Aussage über funktionale Gleichheit, Qualität, Kosten oder Laufzeit im eigenen Kontext.

• Gemini 3.5 Flash endet am 2. Oktober 2026; als Alternative nennt GitHub Gemini 3.8 Flash.
• Gemini 3.6 Flash endet am 2. Oktober 2026; auch hier ist Gemini 3.8 Flash die vorgeschlagene Alternative.
• Kimi K2.7 Code endet am 2. Oktober 2026; GitHub verweist auf Kimi K3.
• Claude Opus 4.7 endet am 2. Oktober 2026; als Nachfolger wird Claude Opus 5 genannt.

Warum ein Wechsel im Modellselektor nicht genügt

GitHub entfernt die alten Modelle nach der Abschaltung selbst; für deren Löschung ist keine Aktion erforderlich. Das löst jedoch nicht die betriebliche Migration. Ein Entwickler kann sein bevorzugtes Modell manuell ändern, während eine andere Arbeitsanweisung, IDE-Konfiguration oder Integration weiter mit einer alten Modellreferenz arbeitet. Zusätzlich kann ein Ersatzmodell technisch verfügbar, aber durch eine Organisations- oder Enterprise-Richtlinie noch gesperrt sein. Aus GNS-Sicht braucht der Wechsel deshalb drei getrennte Inventuren.

• Nutzerinventur: Welche Teams verwenden eines der vier Modelle bewusst in Chat, Ask, Inline Edits, Agent Mode oder Code Completions?
• Workflow-Inventur: Wo sind Modellnamen in Integrationen, Vorlagen, internen Anleitungen, gespeicherten Abläufen oder Tests festgeschrieben?
• Policy-Inventur: Sind Gemini 3.8 Flash, Kimi K3 und Claude Opus 5 auf der richtigen Organisations- oder Enterprise-Ebene freigegeben und für die vorgesehenen Nutzer sichtbar?

Migrationsplan bis zum 2. Oktober 2026

1. Betroffenheit erfassen: Die vier Modellnamen organisationsweit in Konfigurationen, Dokumentation und bekannten Copilot-Abläufen suchen. Parallel die Teams abfragen, die Modelle manuell auswählen.
2. Zielmodell zuordnen: Für jeden betroffenen Anwendungsfall die von GitHub genannte Alternative als Ausgangspunkt dokumentieren. Zwei Gemini-Versionen laufen auf dasselbe Zielmodell zu; diese Konsolidierung sollte bewusst getestet werden.
3. Richtlinien zuerst aktivieren: Administratoren prüfen die Verfügbarkeit in den Copilot-Modelleinstellungen der Organisation oder des Enterprise-Kontos und aktivieren die benötigte Richtlinie. Die Sichtbarkeit im Modellselektor dient als erster, aber nicht einziger Nachweis.
4. Repräsentative Aufgaben testen: Für Chat, Code-Vervollständigung, Inline Edits und Agenten jeweils reale, bereinigte Aufgaben verwenden. Erwartete Ausgabe, erlaubte Dateiänderungen und notwendige menschliche Freigaben vorab festlegen.
5. Workflows und Anleitungen umstellen: Feste Modellreferenzen ersetzen, Teamdokumentation aktualisieren und einen klaren Rückfallpfad auf ein weiterhin unterstütztes Modell festlegen.
6. Vor dem Stichtag abnehmen: Verantwortliche bestätigen pro Workflow Funktion, Ergebnisqualität, Laufzeit, Richtlinienzugriff und Sicherheitskontrollen. Nach dem 2. Oktober werden Fehlermeldungen und Supportanfragen gezielt auf verbliebene Altmodell-Referenzen geprüft.

Ersatzmodelle mit geschäftlichen Kriterien abnehmen

Eine von GitHub vorgeschlagene Alternative reduziert die Sucharbeit, ersetzt aber keinen unternehmenseigenen Abnahmetest. Die Modelle können Aufgaben anders strukturieren, andere Codevorschläge machen oder bei Agentenläufen Werkzeuge anders einsetzen. Diese möglichen Unterschiede sind eine nachvollziehbare Ableitung aus einem Modellwechsel, keine von GitHub zugesicherte Verschlechterung oder Verbesserung. Der Test sollte deshalb den vollständigen Arbeitsablauf und nicht nur eine einzelne Beispielantwort bewerten.

• Funktion: Wird die Aufgabe in der jeweiligen Copilot-Oberfläche vollständig ausgeführt?
• Qualität: Erfüllt das Ergebnis dieselben fachlichen, Test- und Review-Kriterien wie zuvor?
• Kontrolle: Bleiben Repository-Regeln, Freigaben und erlaubte Agentenaktionen wirksam?
• Betrieb: Sind Modellzugriff, Fehlermeldungen und Nutzerprobleme für Support und Administration nachvollziehbar?
• Wirtschaftlichkeit: Bleiben Bearbeitungszeit und notwendige Nacharbeit innerhalb der intern akzeptierten Grenzen?

Verantwortung zwischen Admins und Engineering aufteilen

Die Migration scheitert leicht an einer unklaren Übergabe. Copilot-Administratoren verantworten Modellrichtlinien, Verfügbarkeit und organisatorische Kommunikation. Engineering-Leads bestimmen repräsentative Aufgaben und Abnahmekriterien. Workflow-Eigentümer ändern feste Referenzen und kontrollieren Folgeaktionen. Der interne Support benötigt eine kurze Zuordnung von Altmodell, Ersatzmodell und zuständigem Team. Die Geschäftsführung muss nicht jede Konfiguration kennen, sollte aber einen belastbaren Abschlussnachweis verlangen: keine verbleibenden produktiven Referenzen, freigegebene Zielmodelle und dokumentierte Testergebnisse für kritische Abläufe.

Fazit: Richtlinie, Workflow und Nutzer gemeinsam migrieren

Für die GitHub Copilot Modelle am 2. Oktober 2026 ist die technische Ersatzliste klar. Der operative Aufwand liegt in der Umsetzung: Richtlinien müssen vor der Nutzerauswahl stimmen, feste Modellreferenzen müssen gefunden und reale Arbeitsabläufe müssen mit den Alternativen geprüft werden. Wer diese drei Ebenen getrennt erfasst und anschließend gemeinsam abnimmt, vermeidet sowohl überraschende Ausfälle als auch eine unkontrollierte Umstellung kurz vor dem Stichtag.