Copilot model retirements: check access to the suggested replacement

Two cutoffs require different timing

If a coding workflow names a Copilot model, check its retirement date before choosing a replacement. GitHub’s October 2 notice says it deprecated four models across all Copilot experiences that day. A separate notice, published September 18, schedules six more for October 19. On October 6, the first date has passed and the second remains ahead. [1][2]

For the October 2 group, review any remaining references to the retired model now. For the October 19 group, prepare the change before the announced cutoff. GitHub says administrators do not need to remove deprecated models themselves; that does not remove the need to update dependent workflows and establish access to an alternative. [1][2]

October 2: already retired, according to GitHub

The notice says Copilot Enterprise administrators may need to enable alternative-model policies. In particular, a suggestion to use Kimi K3 should not be read as confirmation that the general default policy has enabled it. [1][4]

October 19: the next announced cutoff

For this group, the September 18 notice says the suggested alternatives are automatically enabled for Copilot Business and Enterprise unless an administrator has turned off the global default or explicitly disabled the model. It also limits model-selector visibility to supported Copilot experiences. This is conditional enablement for the notice’s alternatives, not a promise of universal access or automatic workflow migration. [2]

Kimi K3 shows why a suggestion is not an access guarantee

GitHub’s model default policy applies to unconfigured, generally available models, identified in settings by “Delegate to Default Policy.” Kimi K3 is an explicit exception: the documentation lists it among open-weight models disabled by default regardless of the global default-availability setting. That is an exception to default enablement, not a universal ban on using the model. [3][4]

The same policy excludes pre-GA models, the named Claude Fable models outside GitHub’s data-retention agreement, and models incompatible with an enterprise’s data-residency or FedRAMP restrictions. Explicitly disabling an individual model also prevents its automatic enablement. Check the model-specific policy rather than inferring permission from the global setting. [4]

Access has other conditions. GitHub’s access guide names the Copilot plan, the client and organization or enterprise restrictions. Its supported-models reference adds minimum IDE or extension versions for some models and calls that guidance tentative. “TBD” or no listed minimum does not establish support on an older client. Individual plans do not use the Business/Enterprise administrator-policy setup, but their model access still depends on the plan; the guide says Free and Student have auto selection only. [3][5]

Keep the differing Opus advice visible

GitHub’s September 3 advance notice suggested Claude Opus 5 for retiring Opus 4.7. Its October 2 notice instead suggests Claude Opus 5.5. The October 2 table above uses the October 2 suggestion; it does not silently rewrite the earlier notice or establish that the two replacements produce equivalent results. [6][1]

The supported-models page also returned differing representations during the October 6 source check. Extracted versions suggested Opus 5 in the retirement row and still included the four October 2 retired names in the top available-model list. A separately preserved direct HTML response instead said “Latest Claude Opus model” in that row and omitted those names from the top list. The cause and document-update sequence are unresolved, so this is not proof that GitHub corrected the page in a known order. [3]

Use the dated notices to identify each announced cutoff and its attributed suggestion. Neither a generic list nor either page representation proves what a particular account can access. Blank support-icon cells in extracted text are not evidence of client support or its absence. [1][2][3]

The next check belongs to the intended workflow

Proposed follow-up, not performed for this briefing: identify the exact retired-model reference and its cutoff, then record the candidate suggested by the relevant notice. Have the responsible user or authorized administrator check that candidate against the intended plan, client and installed version, and applicable model policy. For Business/Enterprise seats, include both the global default and any explicit model setting; for Kimi K3, do not assume global default enablement applies. [1][2][3][4][5]

Confirm whether the model is offered in the supported Copilot experience you actually intend to use. If eligibility, client support or policy remains unresolved, keep that dependency open and investigate another supported candidate rather than recording the migration as ready. Even confirmed access would not establish equivalent output quality, cost or integration behavior; this briefing contains no model or migration test.

All cited sources are GitHub’s announcements or documentation, not independent empirical confirmation. The practical decision is time-specific: review references to the October 2 models now, and prepare for October 19 without treating a suggested alternative as an already-verified replacement workflow.