DEV Community

Ahab
Ahab

Posted on Originally published at indieseek.co

GitHub Copilot deprecates six models October 19: a migration checklist for teams

GitHub Copilot deprecates six models October 19: a migration checklist for teams

Quick answer

GitHub says six models will be deprecated across GitHub Copilot experiences on October 19, 2026. The list covers Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini, and Grok 4.5. This is a future Copilot change, not evidence that these model families have disappeared from every provider or API today.

Do not wait for the old names to vanish from a selector. Inventory pinned models and team instructions now, confirm that each suggested replacement is allowed by enterprise and organization policy, and replay representative chat, edit, agent, and completion tasks. Record the actual selected model and the test result. GitHub says deprecated models require no manual removal after the date; migration of workflows and access still deserves an explicit owner.

Who this is for

This is for Copilot Business and Enterprise administrators, engineering leads, and developers who select a model explicitly in Copilot Chat or maintain a shared workflow that assumes a particular model. Solo users can apply the same task-level canaries without the organization policy step.

This article is about GitHub Copilot model availability. The earlier GitHub Models retirement guide concerns a separate GitHub Models service and a different deadline. Do not conflate the two migrations.

What changed

GitHub's September 18 changelog names October 19 as the deprecation date across Copilot Chat, inline edits, ask and agent modes, and code completions. Its alternatives are suggestions, not a published claim that output quality, latency, or price will be identical. The announcement does not supply a universal automatic rewrite of your prompts, saved instructions, or other integrations. Treat those as inventory items to check, not assumed platform behavior.

Copilot model scheduled for deprecation GitHub's suggested alternative Migration check
Gemini 3.7 Flash Gemini 3.8 Flash Recheck fast-response tasks and answer format
GPT-5.5 GPT-5.6 Sol Recheck complex edits and agent task completion
GPT-5.4 GPT-5.6 Sol Recheck reasoning-heavy prompts and review gates
GPT-5.4 mini GPT-5.6 Luna Recheck short edits and lightweight workflows
GPT-5 mini GPT-5.6 Luna Recheck lightweight prompts and expected output
Grok 4.5 Grok 4.6 Recheck task-specific answers and tool behavior

The last column is our suggested test focus, not an official equivalence guarantee. Keep a baseline example for every workflow that matters.

Decide whether the replacement is actually available

For Copilot Business and Enterprise, GitHub says alternatives are automatically enabled under default model enablement unless an administrator turned off the global default or explicitly disabled the model. Its documentation adds an important nuance: an unconfigured model can show “Delegate to Default Policy,” while an enterprise-enforced status cannot be changed by an organization owner. A model appearing in the Copilot Chat selector is a useful access check only in experiences where that selector is supported.

Use this decision tree before assigning migrations:

  1. Replacement already enabled? Confirm the intended users can select it in a supported Copilot experience, then run the task canaries.
  2. Delegated to the default policy? Inspect whether the enterprise or organization default permits it. Do not infer the effective state from the model name alone.
  3. Explicitly disabled or default disabled? Ask the appropriate owner to review the model policy. Organization owners can use Settings → Copilot → Models when the enterprise delegates control; enterprise-enforced settings require enterprise ownership.
  4. Still absent? Check the relevant supported experience and policy scope before filing an access issue. Do not bypass an intentional compliance restriction simply to hit the deadline.

For more detail on the earlier default-enablement rule, see our Copilot policy audit.

A bounded migration workflow

1. Find real dependencies. Search team documentation, shared prompt libraries, Copilot instructions, onboarding material, and any integration configuration for the six exact old names. List affected teams and owners. A text hit is a lead, not proof that a runtime still uses that model.

2. Classify each dependency. Separate user-selected Copilot Chat models from admin availability policies, written recommendations, and integrations outside Copilot. The October 19 announcement concerns Copilot experiences; independently verify other products with their own provider documentation.

3. Confirm policy and surface. For each suggested alternative, capture the enterprise/organization policy state and a user-visible selection check where supported. Record exceptions instead of silently broadening access.

4. Replay four canaries. Run one representative chat answer with expected citations or structure, one inline edit against a known failing test, one ask/agent task with bounded permissions, and one completion task where the team actually depends on completions. Compare against saved acceptance criteria, not a vague impression of “better.” The official scope lists these surfaces; it does not promise identical model controls in each one.

5. Promote with a rollback boundary. Update your documented default recommendation or explicit selection only after the canaries pass. Keep the old task fixture and a named owner for failures. Rollback here means restoring the previous workflow or pausing that workflow before the deadline; do not promise the deprecated model remains available after October 19.

Copyable migration receipt

date_checked: 2026-09-__
copilot_plan: Business | Enterprise | Individual
workflow_owner: 
old_model: 
suggested_replacement: 
policy_scope: enterprise | organization | not_applicable
policy_state: enabled | disabled | delegate_to_default | unknown
supported_selector_check: pass | fail | not_applicable
chat_canary: pass | fail | not_used
inline_edit_canary: pass | fail | not_used
ask_agent_canary: pass | fail | not_used
completion_canary: pass | fail | not_used
acceptance_criteria: 
decision: promote | hold | escalate
Enter fullscreen mode Exit fullscreen mode

Only mark “promote” when the relevant surfaces, policy scope, and review gates are recorded. This receipt is an operational template, not a claim that we tested your tenant.

Common mistakes

  • Calling October 19 a provider-wide shutdown. GitHub announced a Copilot deprecation; other products need separate evidence.
  • Assuming “suggested alternative” means equal cost, speed, or behavior. Run your own comparison and consult current plan documentation for commercial terms.
  • Seeing a model name in one selector and assuming every user or surface has access. Enterprise overrides, organization policy, and supported experiences matter.
  • Treating an API acceptance, a saved policy, or a green agent summary as proof. Preserve actual user access and task-level test evidence.
  • Waiting until after the deadline to discover a critical pinned prompt or instruction.

Building something? Turn your product page into a show people want to watch with PromoFast—hosted, embeddable, and ready to export.

FAQ

Will GitHub remove the old models automatically?

GitHub says no action is required to remove deprecated models after October 19. That does not remove the need to update your own workflow references and confirm the replacements work for you.

Are replacement models automatically enabled for my organization?

Only under the stated default-enablement conditions. A disabled global default or explicit model disablement changes the answer; check the effective policy and enterprise delegation.

Does this change OpenAI, Google, or xAI APIs?

The cited announcement is scoped to GitHub Copilot experiences. It does not establish the status of those providers' separate APIs.

Sources

Originally published on IndieSeek.

Top comments (0)