Analysis
GitHub Copilot retires nine models in four weeks, and opens an API to manage which ones your teams get
1AYM is an OpenAI Select Partner.
Published . Vendor facts checked on against each vendor’s own pages, listed at the end. Plans, prices and availability change. Neither OpenAI nor Anthropic has reviewed this analysis.
The short version
Two retirements and one new control. The first section covers which models went, which go next and how replacements are switched on; the second covers the policy API; the rest covers what that means for running Copilot at scale.
- Model retirements
- GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini, Gemini 3.7 Flash and Grok 4.5 left most Copilot experiences on 19 October. Claude Opus 4.8, Claude Opus 5 and GPT-5.6 Terra follow on 16 November, each with a suggested replacement.
- Model policy API
- GET and PATCH endpoints for Copilot model policies are generally available at enterprise, enterprise team, enterprise app and organisation level, so model access can be read and changed by script.
Six models retired on 19 October, three more on 16 November
What was announced
On 19 October 2026 GitHub deprecated six models across most Copilot experiences, including Copilot Chat, inline edits, ask and agent modes and code completions. The suggested replacements are GPT-6.1 Sol for GPT-5.5 and GPT-5.4, GPT-6 Luna for GPT-5.4 mini and GPT-5 mini, Gemini 3.8 Flash for Gemini 3.7 Flash and Grok 4.7 for Grok 4.5. GitHub had announced these retirements on 18 September 2026. Its notice says Copilot Enterprise administrators may need to enable the alternatives through model policies, and that nothing needs doing to remove the retired models.
On 15 October GitHub announced the next round for 16 November 2026, across all Copilot experiences: Claude Opus 4.8 and Claude Opus 5, both replaced by Claude Opus 5.5, and GPT-5.6 Terra, replaced by GPT-6.1 Sol or GPT-6 Luna. Claude Opus 4.8 stays available to individual subscribers on annual plans, so they keep an Opus option.
For Copilot Business and Copilot Enterprise, the November notice explains how replacements appear. Under default model enablement the suggested alternatives are switched on automatically, unless an administrator has turned the global default off or has disabled that model. Where the default is off, an administrator has to enable the replacements in the model policies before users see them in the model picker.
What it means for enterprises
A model a team relies on can now disappear with about a month's notice, which is the gap GitHub gave for both rounds. Teams that have pinned a model in scripts, agent configurations or internal guidance will likely need to update them, and anyone who tuned prompts or review habits to one model's behaviour will be working with a different one afterwards.
The enterprises most exposed are the careful ones. An organisation that turned the default off so that only vetted models are available will not get the replacements automatically, so its developers can be left without the model they were using until someone approves the new one. That approval is also a decision about cost and data handling, so it is worth making before 16 November rather than on the day.
Before you switch it on
- Default policy
- Check whether the Default availability policy is on or off. If it is off, the replacement models stay disabled until someone enables them.
- Pinned models
- Search scripts, agent settings and internal guides for Claude Opus 4.8, Claude Opus 5 and GPT-5.6 Terra, and update them before 16 November.
- Approval owner
- Name who signs off a new model for use, so a retirement does not wait on an unassigned decision.
A REST API for Copilot model policies, now generally available
What was announced
Also on 19 October 2026 GitHub made REST API endpoints for Copilot model policies generally available. GET and PATCH work at four levels: the enterprise, enterprise teams, enterprise apps and organisations. Enterprise policies can hand model decisions down to organisations, in what GitHub calls organisation mode, or to teams and apps, in enterprise teams mode.
GitHub's documentation sets out how those levels combine. An enterprise owner sets each model to enabled, disabled or delegated. Enterprise teams mode is an opt-in preview: switching to it deactivates organisation-level model settings, team settings only add to the enterprise baseline, and a user in several teams gets every model any of them enables. Models delegated to organisations become unavailable when an enterprise opts in, until they are enabled for specific teams.
What it means for enterprises
Model access becomes something that can be managed like other access: kept in a reviewed configuration, applied by script and checked for drift. With retirements now arriving monthly, that likely matters more than it did when the model list changed a few times a year.
Enterprise teams mode lets access follow roles and training rather than organisation structure, for example higher-cost models only for teams that have been through training, which GitHub's documentation gives as an example. The opt-in has a regression risk that GitHub itself flags, so it is worth testing in a copy of the policy before switching.
Before you switch it on
- Current state
- Read the current model policies through the API and store them, so there is a record to compare against after each retirement.
- Teams mode
- Before opting in, list every model delegated to organisations. Those become unavailable until a team is given access.
Where the market is heading: model choice as a managed policy
Coding tools now offer models from several vendors in one picker, and each vendor's release cycle drives retirements. Nine models are leaving Copilot across two dates four weeks apart (our count from GitHub's two notices). Model choice is becoming an ongoing administrative task, with its own owner, rather than a setting made once at rollout.
GitHub's response is to make model access programmable and to tie it to teams. That likely pushes larger organisations towards treating the approved model list like any other governed configuration, with review, change records and an owner.
What is not known yet
The notices and documentation, read on 20 October, leave some questions open.
- Usage rates
- The notices do not say whether each suggested replacement draws on usage allowances at the same rate as the model it replaces.
- Teams mode
- No date is given for enterprise teams mode to leave preview.
- Next retirements
- GitHub has not published a schedule beyond 16 November. The two rounds so far each came with about a month's notice.
For engineers: the endpoints and how policies combine
The four endpoints
GET and PATCH are available on /enterprises/{enterprise}/copilot/model-policies, /enterprises/{enterprise}/teams/{team_slug}/copilot/model-policies, /enterprises/{enterprise}/copilot/apps/model-policies and /orgs/{org}/copilot/model-policies. GitHub points to its REST API documentation for request and response shapes.
A practical first use is a scheduled read of each level into version control, so a retirement or a manual change shows up as a diff.
Sources: [3]
How the settings resolve
At enterprise level each model is enabled, disabled or delegated. Models never configured show as Delegate to Default Policy and follow the Default availability policy. In organisation mode, a delegated model left unset by an organisation follows that organisation's default for released models. In enterprise teams mode, a model disabled at enterprise level cannot be enabled for a team, a model enabled at enterprise level is enabled for every team, and teams have no explicit disabled setting.
Agent apps normally get the models enabled where they are installed; in enterprise teams mode their models are set at enterprise level. Rolling back from teams mode restores the earlier policy state, but enterprise-level changes made while in teams mode are lost.
Sources: [4]
Where 1AYM fits
Keeping model access, guardrails and review consistent as models come and go is the operating layer around a coding tool. Our AI Engineering Transformation engagement builds that layer on the tools teams already use: architecture, repository rules and permissions enforced in the path to production, and the same CI gates every other change passes.
If the open question is which coding tool to standardise on in the first place, our comparison of Claude Code and GitHub Copilot sets out where each runs, how each is billed and which admin controls each gives you.
Sources
- [1]GitHub Changelog, GitHub Copilot models deprecated on October 19, 2026 (checked 20 October 2026)
- [2]GitHub Changelog, Upcoming deprecation of selected GitHub Copilot models in mid-November, 15 October 2026 (checked 20 October 2026)
- [3]GitHub Changelog, Copilot model policy API for enterprise, orgs, and teams, 19 October 2026 (checked 20 October 2026)
- [4]GitHub Docs, Managing availability of models in your enterprise (checked 20 October 2026)
Frequently asked questions
Which GitHub Copilot models were retired on 19 October 2026?
GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini, Gemini 3.7 Flash and Grok 4.5, across most Copilot experiences. GitHub suggests GPT-6.1 Sol, GPT-6 Luna, Gemini 3.8 Flash and Grok 4.7 instead.
Which Copilot models are retired on 16 November 2026?
Claude Opus 4.8, Claude Opus 5 and GPT-5.6 Terra. GitHub suggests Claude Opus 5.5, or GPT-6.1 Sol or GPT-6 Luna. Individual subscribers on annual plans keep Claude Opus 4.8.
Are the replacement models switched on automatically?
For Copilot Business and Enterprise, yes under default model enablement, unless an administrator has turned the global default off or disabled that model. Then an administrator has to enable them.
What does the Copilot model policy API do?
It lets administrators read and update which Copilot models are available, through GET and PATCH endpoints at enterprise, enterprise team, enterprise app and organisation level. It became generally available on 19 October 2026.
Further
- Claude Code vs GitHub Copilot · Where each runs, US dollar pricing and the admin controls each gives a team on GitHub.
- Codex vs GitHub Copilot · GitHub integration, plan prices, usage billing and admin controls, from each vendor's documentation.
- AI spend governance · How seats, credits and metered agent runs add up, and how to budget, cap and charge them back.
- AI code review at Anthropic and GitHub · The October code review releases from both vendors and what each means for an engineering team.
Running Copilot across several teams?
Half an hour is enough to agree who approves new models, how the policy is kept and what changes before 16 November.
Last reviewed · 1AYM