--- service: "Publicasta" schema_version: "1.0" article_id: 524 title: "Copilot will vier Modelle einstellen: So gelingt die Umstellung bis zum 2. Oktober" language: "de" default_language: "en" canonical_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=de" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=de" api_url: "https://publicasta.com/api/public/v1/channels/ai_practice/articles/github_copilot_model_retirement_workflow_migration?lang=de" channel_url: "https://publicasta.com/api/public/v1/channels/ai_practice" channel_articles: "https://publicasta.com/api/public/v1/channels/ai_practice/articles" search_url: "https://publicasta.com/api/public/v1/search" documentation_url: "https://publicasta.com/api-docs#reading-publicasta" openapi_url: "https://publicasta.com/api-docs/openapi.json" published_at: "2026-09-06T10:50:14+00:00" updated_at: "2026-09-06T10:50:14+00:00" translations: - language: "ar" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=ar" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=ar" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=ar" - language: "de" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=de" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=de" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=de" - language: "en" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=en" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=en" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=en" - language: "es" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=es" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=es" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=es" - language: "fr" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=fr" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=fr" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=fr" - language: "pl" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=pl" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=pl" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=pl" - language: "ru" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=ru" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=ru" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=ru" - language: "zh" html_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration?lang=zh" markdown_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.md?lang=zh" json_url: "https://publicasta.com/ai_practice/github_copilot_model_retirement_workflow_migration.json?lang=zh" --- # Copilot will vier Modelle einstellen: So gelingt die Umstellung bis zum 2. Oktober > GitHubs Modellwechsel betrifft Chat, Codevervollständigung und agentengestützte Abläufe. Ein praxistauglicher Leitfaden für Bestandsaufnahme, Richtlinienprüfung, Vergleichstests und eine kontrollierte Einführung. ![Entwicklungsteam prüft einen übersichtlichen Ablauf zur Umstellung mehrerer KI-Modelle mit Bestandsaufnahme, Vergleichstest, begrenzter Einführung und Ausweichlösung.](https://publicasta.com/storage/projects/8/pages/524/2026/09/36618231-a8a7-4cc0-b021-44ed5452d883.webp) ## Copilot will vier Modelle einstellen: Was Teams bis zum 2. Oktober prüfen sollten GitHub will am 2. Oktober 2026 vier Modelle aus GitHub Copilot entfernen: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code und Claude Opus 4.7. Die Ankündigung vom 3. September betrifft laut GitHub sämtliche Copilot-Nutzungsarten, ausdrücklich also Chat, Änderungen direkt im Editor, den Frage- und den Agentenmodus sowie Codevervollständigungen. Noch ist die Umstellung nicht vollzogen. Für Entwicklungsteams beginnt deshalb jetzt ein knappes Zeitfenster, in dem sie Abhängigkeiten erfassen, Alternativen freischalten und ihr tatsächliches Arbeitsprofil erproben können. GitHub nennt für jedes auslaufende Modell einen Nachfolger: Gemini 3.8 Flash für die beiden bisherigen Flash-Varianten, Kimi K3 für Kimi K2.7 Code und Claude Opus 5 für Claude Opus 4.7. Diese Zuordnung ist eine Empfehlung, kein Nachweis für identisches Verhalten. Antwortqualität, Bearbeitungsdauer, Fehlerneigung und Kosten können sich unterscheiden. Eine saubere Migration besteht daher nicht darin, lediglich einen Modellnamen in einer Einstellung auszutauschen. ## Zuerst die Abhängigkeiten sichtbar machen Die wichtigste Bestandsaufnahme umfasst drei Arten von Abhängigkeiten. Explizite Abhängigkeiten sind leicht zu finden: Ein Modell ist in einer Arbeitsanweisung, einer Integration oder in der Konfiguration eines Werkzeugs fest ausgewählt. Weniger auffällig sind Voreinstellungen auf Unternehmens- oder Organisationsebene. Hinzu kommen stillschweigende Annahmen: Ein Team hat vielleicht keinen Modellnamen dokumentiert, seine Prüfabläufe aber auf die typische Ausgabe eines bestimmten Modells abgestimmt. Für jede relevante Nutzung sollte festgehalten werden, wo die Auswahl erfolgt, wer sie verwaltet und welche Aufgabe davon abhängt. Ein zweckmäßiges Inventar trennt beispielsweise Codevervollständigung, Chat-Fragen, Änderungen im Editor und agentengestützte Abläufe. Damit bleibt erkennbar, ob eine Umstellung nur eine persönliche Auswahl betrifft oder ob sie einen gemeinsam genutzten Prozess verändert. Bei Copilot Business und Enterprise reicht der Blick auf die Auswahl beim einzelnen Nutzer nicht aus. Administratoren müssen gegebenenfalls zunächst das Ersatzmodell in den Modellrichtlinien zulassen. Die Vorgabe kann durch den Unternehmensinhaber gesetzt, an eine Organisation delegiert oder von der allgemeinen Verfügbarkeit übernommen werden. Besonders zu beachten ist Kimi K3: GitHub führt es als Modell mit offenen Gewichten; solche Modelle sind für Business und Enterprise standardmäßig deaktiviert, unabhängig von der allgemeinen Verfügbarkeit. Sie können ausdrücklich erlaubt werden, sofern keine andere Einschränkung entgegensteht. Deshalb gehören immer zwei Kontrollen zusammen: die Verwaltungsrichtlinie und die tatsächlich sichtbare Auswahl in der Oberfläche des Nutzers. Ist ein Modell laut Dokumentation verfügbar, in der betreffenden Anwendung aber nicht auswählbar, muss das nicht auf einen Produktfehler hindeuten. Tarif, Richtlinie und eingesetzte Softwareversion können die Verfügbarkeit begrenzen. ## „Allgemein verfügbar“ heißt nicht überall verfügbar Die aktuelle GitHub-Dokumentation kennzeichnet sowohl die auslaufenden Modelle als auch die vorgeschlagenen Nachfolger als allgemein verfügbar. Daraus folgt jedoch nicht, dass jedes Modell in jedem Tarif und in jeder Oberfläche bereitsteht. Auch aktuelle IDEs oder Erweiterungen können Voraussetzung sein. GitHub bezeichnet die Tabelle der Mindestversionen ausdrücklich als vorläufig: Für Gemini 3.8 Flash sind einzelne Angaben noch offen; für Kimi K3 wird VS Code 1.131 genannt, für Claude Opus 5 VS Code 1.128.0. Vor einem fachlichen Vergleich sollte das Team daher die technische Ausgangslage vereinheitlichen. Wer ein neues Modell mit unterschiedlichen Versionen der Anwendung erprobt, vermischt die Eigenschaften des Modells mit Problemen der Oberfläche oder Erweiterung. Der erste erfolgreiche Test lautet nicht „Die Antwort wirkt gut“, sondern: Das vorgesehene Modell ist unter den geltenden Richtlinien in der vorgesehenen Anwendung tatsächlich erreichbar und wird dort auch als verwendetes Modell ausgewiesen. ## Vergleich mit eigenen, bereits bewerteten Aufgaben GitHub weist selbst darauf hin, dass sich Modelle bei Qualität, Relevanz, Reaktionszeit, Halluzinationsneigung und Eignung für bestimmte Aufgaben unterscheiden. Die Produktdokumentation ist jedoch weder ein unabhängiger Leistungsvergleich noch ein Test des eigenen Quellcodes. Aussagekräftiger ist ein Wiederholungstest mit Aufgaben, deren Ergebnis das Team bereits kennt und geprüft hat. Dafür eignet sich eine kleine, aber repräsentative Auswahl aus der täglichen Arbeit: etwa eine klar umrissene Fehleranalyse, eine Änderung über mehrere Dateien, eine Erklärung zu bestehendem Code und eine Aufgabe, bei der Tests oder Nebenbedingungen besonders wichtig sind. Entscheidend ist, dieselbe Aufgabenbeschreibung und denselben zulässigen Kontext mit altem und neuem Modell zu verwenden. Eigene Messwerte liegen für diese Umstellung bislang nicht vor; allgemeingültige Sieger lassen sich deshalb nicht seriös benennen. Die Bewertung sollte sich nicht auf wohlklingende Antworten beschränken. Für jede Aufgabe sind mindestens vier Fragen relevant: - Ist das Ergebnis fachlich richtig und mit den Anforderungen vereinbar? - Wie lange dauert es bis zu einer brauchbaren Antwort oder Änderung? - Wie viel Prüfung und Nacharbeit durch einen Menschen ist nötig? - Welcher Verbrauch und welche Kosten entstehen für ein tatsächlich akzeptiertes Ergebnis? Gerade der letzte Punkt verhindert einen irreführenden Preisvergleich. Ein günstigerer Preis je Million Token bedeutet nicht automatisch geringere Kosten je erledigter Aufgabe. Ein Modell kann mehr Ausgaben erzeugen, häufiger neu angesetzt werden müssen oder zusätzlichen Prüfaufwand verursachen. Umgekehrt beweist derselbe Tarif nicht, dass Verbrauch und Ergebnis gleich bleiben. ## Preise als veränderlichen Ausgangswert behandeln Der dokumentierte Preisstand vom 6. September zeigt erhebliche Unterschiede. Je eine Million Token kosten bei Gemini 3.5 Flash 1,50 US-Dollar für Eingaben, 0,15 Dollar für zwischengespeicherte Eingaben und 9 Dollar für Ausgaben. Bei Gemini 3.6 und dem vorgeschlagenen Gemini 3.8 Flash sind es jeweils 0,75, 0,075 und 3,75 Dollar. Für Kimi K2.7 nennt GitHub 0,95 Dollar für Eingaben, 0,19 Dollar für zwischengespeicherte Eingaben und 4 Dollar für Ausgaben. Kimi K3 liegt mit 3, 0,30 und 15 Dollar darüber. Claude Opus 4.7 und Claude Opus 5 haben in der Tabelle dieselben Sätze: 5 Dollar für Eingaben, 0,50 Dollar für zwischengespeicherte Eingaben, 6,25 Dollar für das Schreiben in den Zwischenspeicher und 25 Dollar für Ausgaben. Diese Werte sind eine Momentaufnahme, keine Vorhersage der nächsten Rechnung. Der tatsächliche Betrag hängt unter anderem von Tarif, Funktion, Tokenmenge und Nutzung des Zwischenspeichers ab. Ein AI Credit entspricht laut GitHub 0,01 US-Dollar; Codevervollständigungen und Vorschläge für die nächste Änderung verbrauchen keine AI Credits. Auch deshalb sollten Teams Nutzungskategorien getrennt betrachten, statt aus einem einzelnen Tokenpreis einen pauschalen Kosteneffekt abzuleiten. Vor einer Entscheidung müssen die veränderlichen Preisangaben erneut geprüft werden. ## Mit einer begrenzten Freigabe beginnen Nach dem Wiederholungstest sollte das Ersatzmodell zunächst in einem begrenzten, gut beobachtbaren Bereich eingesetzt werden. Geeignet ist ein Team oder ein Arbeitsablauf, für den Rückmeldungen schnell verfügbar sind und ein Rückweg feststeht. Die Testgruppe benötigt klare Kriterien: Welche Fehler führen zum Abbruch? Welche Nacharbeit ist noch akzeptabel? Wann wird die Freigabe ausgeweitet? Der Rückweg darf nicht erst nach einem Fehlschlag entworfen werden. Bis zum 2. Oktober kann das bisherige Modell noch als Vergleichspunkt dienen. Für die Zeit danach muss die Ausweichlösung auf einem weiterhin verfügbaren Modell beruhen. Alte Modelle müssen nach ihrer Außerbetriebnahme zwar nicht von Hand entfernt werden; Konfigurationen, Anleitungen und Integrationen sollten dennoch rechtzeitig auf die neue Auswahl vorbereitet sein, damit keine veralteten Verweise den Betrieb stören. ## Automatische Auswahl ist eine eigene Betriebsart Copilots Einstellung „Auto“ kann als zusätzliche Ausweichmöglichkeit erprobt werden. GitHub zufolge berücksichtigt sie die Verfügbarkeit, den Systemzustand und die Komplexität einer Aufgabe. Sie bleibt jedoch an Tarif und Richtlinien gebunden, und die Menge der von ihr berücksichtigten Modelle kann sich ändern. In unterstützten Oberflächen lässt sich nachvollziehen, welches Modell tatsächlich verwendet wurde. Damit ist „Auto“ kein stiller Ersatz für einen Ablauf, der bisher bewusst auf ein bestimmtes Modell festgelegt war. Wer reproduzierbares Verhalten benötigt, sollte die automatische Auswahl separat testen und die tatsächlich eingesetzten Modelle in die Auswertung einbeziehen. Andernfalls wird eine Veränderung möglicherweise dem neuen bevorzugten Modell zugeschrieben, obwohl die automatische Auswahl im Hintergrund ein anderes verwendet hat. Seit dem 2. September können zentral verwaltete Einstellungen zudem ein beliebiges verfügbares Modell als Vorgabe für neue Unterhaltungen festlegen und diese Vorgabe je Unternehmensteam überschreiben. GitHub nennt diese allgemein verfügbare Funktion für Business und Enterprise ausdrücklich für die Copilot-App, die Kommandozeile und VS Code. Eine solche Vorgabe, eine ausdrückliche Auswahl durch den Nutzer und „Auto“ sind drei verschiedene Steuerungswege. Die angekündigte Unterstützung sollte deshalb nicht ohne Beleg auf weitere Oberflächen übertragen werden. Für Verantwortliche ergibt sich daraus eine praktische Reihenfolge. Zunächst wird entschieden, ob ein Modell verbindlich vorgegeben, nur als Ausgangswert angeboten oder automatisch gewählt werden soll. Danach werden die entsprechenden Richtlinien gesetzt. Zum Schluss prüft ein Nutzer aus jeder betroffenen Gruppe, welche Auswahl in seiner realen Arbeitsumgebung erscheint und welches Modell bei einer Testaufgabe tatsächlich zum Einsatz kommt. ## Ein belastbarer Umstellungsplan in sieben Schritten 1. **Nutzungen erfassen:** Alle betroffenen Copilot-Nutzungsarten, Integrationen und dokumentierten Arbeitsabläufe aufnehmen, ohne sich auf offensichtliche Auswahllisten zu beschränken. 2. **Verantwortung klären:** Für jede Modellvorgabe bestimmen, ob sie im Unternehmen, in der Organisation, im Team, in der eingesetzten Anwendung oder durch den einzelnen Nutzer gesteuert wird. 3. **Zugang herstellen:** Ersatzmodelle in den Richtlinien freigeben und Tarif sowie Mindestversionen der eingesetzten Anwendungen prüfen. 4. **Bekannte Aufgaben wiederholen:** Altes und neues Modell mit identischen, bereits bewerteten Aufgaben vergleichen; Richtigkeit, Dauer, Prüfaufwand, Verbrauch und Kosten getrennt festhalten. 5. **Begrenzt einführen:** Die neue Auswahl zunächst in einem überschaubaren Bereich aktivieren und Abbruchkriterien sowie Ausweichmodell vorab bestimmen. 6. **Dokumentation umstellen:** Anleitungen, Integrationen und feste Modellverweise vor dem 2. Oktober aktualisieren. Dabei die automatische Auswahl und feste Vorgaben nicht miteinander verwechseln. 7. **Nach der Umstellung kontrollieren:** In den unterstützten Oberflächen die tatsächlich verwendeten Modelle prüfen und beobachten, ob Fehlerrate, Bearbeitungszeit oder menschlicher Prüfaufwand vom Test abweichen. Der Zeitdruck sollte nicht zu einer Scheingenauigkeit führen. GitHubs empfohlene Nachfolger sind sinnvolle Ausgangspunkte, doch sie ersetzen keine Prüfung unter den Bedingungen des eigenen Teams. Ebenso wenig rechtfertigen vorläufige Versionsangaben oder aktuelle Preise eine dauerhafte Annahme. Beides kann sich bis zur Abschaltung ändern. Die robuste Lösung verbindet daher Verwaltung und redaktionell-technische Sorgfalt: Richtlinien müssen das gewünschte Modell erlauben, Clients müssen es unterstützen, und reale Aufgaben müssen zeigen, ob es für den jeweiligen Zweck taugt. Wer diese drei Ebenen jetzt getrennt prüft, kann die Abschaltung am 2. Oktober als kontrollierte Umstellung behandeln statt als überraschenden Ausfall.