GitHub Copilot Retires Six More Models on October 19

Four Copilot models retired on October 2, and six more are scheduled to leave on October 19. Check the current replacement map before updating your workflow: the confirmed recommendation for Opus 4.7 is now Opus 5.5.

The September 1 retirement covered Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6, and Raptor Mini. GitHub’s official migration table names supported alternatives. One exception matters: Sonnet 4.6 remains available to individual annual subscribers.

September 18 update: six more Copilot models retire October 19

GitHub has added a third migration deadline. On October 19, 2026, it will remove Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini and Grok 4.5 across Copilot Chat, inline edits, ask and agent modes, and code completions.

The policy detail matters for Business and Enterprise accounts. Under GitHub’s default model enablement, suggested alternatives are enabled automatically unless an administrator disabled the global default or explicitly disabled that model. Organizations that turned the default off must enable the replacement in Copilot model policies before users can select it.

Treat this as a new wave rather than editing the October 2 checklist in place. Add October 19 to the migration board, test the suggested alternative against the same repository tasks and verify both availability and authorization. GitHub will remove the old entries after deprecation, but it will not prove that your integrations, aliases or instructions now point to the intended replacement.

Read GitHub’s September 18 Copilot retirement notice.

Update checked September 18, 2026. Dates and alternatives come from GitHub. Migration and testing advice is MustHave.ai analysis. Marker: copilot-model-retirement-20261019.

October 2 retirements are now confirmed

GitHub confirmed these removals in its October 2 retirement announcement. They apply across Copilot experiences. Administrators may need to enable replacement models, but no action is required to remove the retired entries.

Opus 4.7 is the trap in the combined timeline. It appeared in GitHub’s earlier replacement suggestions for Opus 4.5 and 4.6, but it is not a durable destination for a migration you are starting now. Keep the historical table below as a record of that first notice; use the October deadline when choosing a route that must remain supported afterward.

Add a removal date to each model entry in your assignment board. For each job, record the current model, tested successor, policy owner, acceptance test, and last safe switch date. A fallback only counts if the account can actually use it. A launch announcement or a model name in a configuration file is not that test.

For teams adding a new high-capability route at the same time, GPT-6 Astra now has a separate Copilot access and cost check. Do not let a retirement migration silently turn into a blanket upgrade to a more expensive default.

Models retired on September 1

A suggested replacement is not a claim of behavioral equivalence. A faster model can change how often an agent asks for clarification. A more capable model can use more premium requests or take longer paths. A newer model can also follow repository instructions more reliably. The only useful comparison is the work your team assigns.

Find model IDs outside the chat picker

• Enterprise and organization model policies.
• Repository-level Copilot settings and instruction files.
• VS Code profiles, extensions, and workspace settings.
• CLI aliases, agent definitions, and scheduled automation.
• Documentation, onboarding guides, and internal screenshots.
• Cost dashboards that group usage by the old model name.

Search configuration repositories for exact IDs and human-readable names. Treat a silent fallback as a migration event, not a success. If a job quietly moves to a different model, the result may look normal while cost, latency, or approval behavior changes.

Do not confuse availability with authorization

GitHub controls whether a model is offered. Your organization still controls whether that model is allowed for a repository or user group. Replacements may also differ by plan. Confirm that enterprise policy, organization policy, and repository policy all agree before announcing a new default.

Our guide to Copilot billing, retention, and policy changes explains why a model rollout should be reviewed with data boundaries and budget rules, not as a picker-only change.

Use a small assignment board

Pick five real jobs: a familiar bug, a repository-wide search, a test-writing task, a risky dependency change, and a pull-request review. Run each old baseline, where still available, against the candidate replacement with the same repository state and instructions.

Record tests passed, defects introduced, useful review findings, false positives, premium requests, wall time, retries, and human repair minutes. A model that writes more code is not automatically better. The strongest route is the one that produces the most verified work per reviewer minute.

The Sonnet 4.6 exception can hide drift

Individual annual subscribers can still see Sonnet 4.6 while teammates on other plans cannot. That creates an awkward support condition: a maintainer may document a workflow that another developer cannot reproduce. Record the plan and model in debugging reports until the team converges on one supported route.

Do not build a long migration around the exception. It preserves access for a group of users, but it does not reverse GitHub’s broader retirement decision.

Pair the migration with review controls

GitHub also introduced Copilot approval assessments on September 1. Every Copilot review can now report whether it considers a pull request ready, while an actual approval that counts toward branch rules stays off by default. If an admin enables it, later commits dismiss the approval and a fresh review is required.

That feature should not turn a model migration into an approval-policy change. Keep the two decisions separate. First verify review quality on the replacement model. Then decide which paths, if any, an automated approval may cover. The Copilot review effort guide gives a practical risk split for lighter and deeper review.

My verdict: route jobs, not users

Watch the first week after the switch for more than obvious request failures. Compare acceptance rate, reverted commits, review discussion, test failures, and the number of times developers manually select another model. A rising override rate is a routing signal. It may mean the default is wrong for a job class even when the service is technically healthy. Publish the approved assignment board in the repository so the decision is visible where work begins.

Give developers one clear fallback path. When the preferred model is unavailable or performs poorly, the fallback should preserve repository policy and logging rather than encourage an unmanaged personal workaround. Retire the fallback when evidence shows the new primary route is stable.

Update incident and support templates with a model field. "Copilot failed" is not enough when several routes are available. Capture the selected model, plan, editor, extension version, repository policy, and request time. That context separates a retirement issue from a tool outage, policy denial, or model-quality problem and shortens the path to a reproducible report.

A single organization default is convenient and often wasteful. Fast edits, broad code search, security review, and difficult refactoring do not need the same model. Use the retirement to define a small assignment board with one approved primary route and one fallback per job class.

Finish by setting a date to remove legacy names from policy, docs, and dashboards. The migration is complete when the old model no longer appears in configuration or incident reports, not when the picker stops showing it.

Read the primary sources

• Read GitHub’s model retirement notice.
• Review GitHub’s Copilot approval announcement.
• Check the current supported model documentation.

Updated October 3, 2026 with GitHub’s confirmation of the October 2 retirements and its revised Opus replacement. The October 19 wave remains scheduled. Historical September 1 suggestions are retained as a record, not current migration recommendations. Test design is MustHave.ai guidance.