Was passiert: GPT-5.2 verlässt den Copilot-Selector
GitHub stellt im Copilot-Changelog die Deprecation der Modelle GPT-5.2 und GPT-5.2-Codex in Aussicht. Beide werden schrittweise aus dem Modell-Selector in VS Code, JetBrains und der GitHub.com-Oberfläche entfernt; der Default wechselt auf nachfolgende Modelle, die OpenAI parallel zur ChatGPT-Plattform ausgerollt hat.
Für die meisten Copilot-Nutzer ist das ein stiller Modell-Upgrade — wer aber Modell-Auswahl explizit fixiert oder im Workspace per Policy gesteuert hat, bekommt mit der Deprecation einen Breaking Change in der Dropdown-Liste. GitHub Copilot Modelle brauchen damit ein kurzes Review.
Wo sich die Umstellung bemerkbar macht
Drei typische Stellen, an denen GPT-5.2 noch hinterlegt ist:
- Workspace- oder Repository-Settings, die ein Modell als Default für Chat oder Inline-Suggest fixieren
- Editor-spezifische Settings (z. B. github.copilot.chat.preferredModel in VS Code) mit hartem Modell-String
- Custom Agents, MCP-Workflows oder Eval-Skripte, die GPT-5.2 oder GPT-5.2-Codex per Modellname referenzieren
Sobald das Modell entfernt ist, fällt Copilot in der Regel auf den jeweiligen Default zurück. Bei Settings, die strikt auf einen nicht mehr existierenden Modellnamen verweisen, kann der Chat-Modus aber leise Fehlermeldungen oder einen Auto-Fallback ohne Hinweis erzeugen — beides verhindert sauberes Auditing.
Was Entwickler-Teams jetzt tun sollten
Die Deprecation ist ein guter Anlass für ein Modell-Audit über alle Repositories und Workspaces. Empfohlene Schritte:
- Repos und Workspace-Settings nach gpt-5.2 und gpt-5.2-codex durchsuchen
- Modell-Defaults im Copilot-Workspace einmal zentral neu setzen, statt sie pro Repo zu pflegen
- Eval-Pipelines auf das nachfolgende Modell umziehen und Quality-Baselines neu ziehen — die alten Werte sind nicht mehr direkt vergleichbar
- Custom Instructions und Prompt-Library auf Modell-spezifische Tonalitäten prüfen, die unter GPT-5.2 stabil waren
Fazit
Die Deprecation von GPT-5.2 und GPT-5.2-Codex ist technisch unspektakulär, organisatorisch aber relevant: jeder Workspace sollte einmal aktiv auf das nachfolgende Modell wechseln, statt sich auf den stillen Auto-Fallback zu verlassen. Wer Modell-Selektion per Policy oder Eval-Pipeline pflegt, plant eine kurze Migrations-Schleife ein — sonst rutscht das Update in einer Quartals-Retro als unerklärte Qualitäts-Drift wieder auf den Tisch.