GitHub Copilot’s September 2026 Model Retirements: A Safe Migration and Regression-Test Guide

GitHub Copilot’s September 2026 Model Retirements: A Safe Migration and Regression-Test Guide

GitHub is retiring six Copilot models across Copilot Chat, inline suggestions, ask mode, agent mode, and code completions on September 1, 2026. The affected models are Gemini 3.1 Pro, Claude Opus 4.5, Claude Opus 4.6, Claude Sonnet 4.5, Claude Sonnet 4.6, and Raptor Mini. The practical implication is not simply “pick a newer model”: teams need to inventory explicit model dependencies, enable replacements through policy, run representative coding evaluations, and preserve a rollback path for prompts and workflows that behave differently.

This guide is for intermediate developers and engineering leads operating GitHub Copilot in IDEs, repositories, CI, or enterprise-managed environments.

The short answer

If your team explicitly selects one of the retiring models, move to GitHub’s suggested alternatives before September 1. GitHub lists Gemini 3.6 Flash for Gemini 3.1 Pro; Claude Opus 4.7, 4.8, or 5 for Claude Opus 4.5 and 4.6; Claude Sonnet 5 for Claude Sonnet 4.5 and 4.6; and MAI-Code-1-Flash for Raptor Mini. Claude Sonnet 4.6 remains available to individual subscribers on annual plans, but that exception does not make it a safe enterprise default.

Enterprise administrators should also check model policies. A replacement can exist in GitHub’s catalog while remaining unavailable to users because an organization or enterprise policy has not enabled it.

Migration visual — model replacement map

Retiring model	GitHub-listed alternative	Migration note
Gemini 3.1 Pro	Gemini 3.6 Flash	Re-run long-context and tool-use prompts; do not assume identical output style
Claude Opus 4.5	Claude Opus 4.7, 4.8, or 5	Select one deliberately and test agent tasks
Claude Opus 4.6	Claude Opus 4.7, 4.8, or 5	Check reasoning depth, latency, and premium usage
Claude Sonnet 4.5	Claude Sonnet 5	Test completion idioms and repository instructions
Claude Sonnet 4.6	Claude Sonnet 5	Annual individual subscribers have a documented exception
Raptor Mini	MAI-Code-1-Flash	Validate lightweight completion and edit workloads

What GitHub is changing

GitHub’s July 31 changelog says the retirement applies across all Copilot experiences, including Copilot Chat, inline edits, ask and agent modes, and code completions. The GitHub public roadmap describes the change as an August 31 model-lineup update, while the changelog gives September 1 as the deprecation date. Treat September 1 as the operational cutoff and complete testing earlier.

The change affects more than a model picker. Model names can be embedded in repository instructions, organization documentation, Copilot SDK integrations, scripted prompts, evaluation fixtures, and team runbooks. A developer who only changes the IDE selection may still leave a stale model identifier in automation or onboarding material.

GitHub also says enterprise administrators may need to enable replacement models through Copilot settings. Once a model policy is enforced, previously unconfigured generally available models can inherit the global policy state. Explicit enable and disable decisions are preserved, while open-weight models and models without GitHub’s data-retention coverage are excluded from default enablement.

A migration workflow that does not rely on guesswork

1. Inventory explicit and implicit dependencies

Search repositories and operational documents for the retiring names. Include lowercase variants and punctuation differences:

1git grep -n -i -E 'gemini[- ]?3\.1[- ]?pro|claude[- ]?opus[- ]?4\.[56]|claude[- ]?sonnet[- ]?4\.[56]|raptor[- ]?mini' \
2  -- ':!node_modules' ':!vendor'

Then check the places that a repository search will miss:

• Organization and enterprise Copilot model policies.
• IDE settings and shared dev-container configuration.
• Copilot SDK or CLI scripts that pass a model identifier.
• CI prompts, issue templates, custom agents, and skills.
• Evaluation dashboards and cost reports keyed by model name.
• Internal documentation that tells developers which model to choose.

Do not change every mention blindly. Historical incident reports and old benchmark records should retain their original names, but they should be marked as historical so nobody copies them into a new workflow.

2. Enable and verify replacements before testing

An administrator should confirm that the replacement is available to the correct enterprise, organization, team, and plan. GitHub’s policy documentation describes four useful states: explicitly enabled, explicitly disabled, delegated to an enterprise/team/organization, and delegated to the default policy.

A sensible rollout is:

1. Enable only the replacement models needed for the pilot group.
2. Confirm that users can see them in the relevant model selector.
3. Verify the minimum IDE, plugin, or client version where GitHub documents one.
4. Record the policy decision and effective date.
5. Expand access after the evaluation passes.

The important distinction is between “the model appears in GitHub documentation” and “our users can select it in the surface where the workflow runs.”

3. Build a small, representative evaluation set

Do not benchmark only trivia or code-generation puzzles. Use prompts from your actual work and keep the repository context stable. A useful starter set contains:

• A bug fix with a failing test and a misleading stack trace.
• A refactor that must preserve a public API.
• A security-sensitive change requiring input validation.
• A migration across a framework or SDK version.
• A multi-file agent task with explicit approval boundaries.
• A code-review prompt where false positives matter.
• A completion-heavy task for the developers who use inline suggestions.

Capture at least:

These are team measurements, not claims about the relative capability of the replacement models. GitHub’s deprecation notice supplies the mapping, but it does not promise that every workload will be behaviorally identical after migration.

Protect prompts and agent workflows from model drift

Model migration often exposes assumptions hidden in prompts. A prompt written for a verbose reasoning model may waste budget on a faster model; a prompt written for a lightweight model may underspecify a long-running agent task. Keep the task contract explicit:

• Define acceptance tests before asking for implementation.
• Require a short plan before edits on high-risk repositories.
• State which tools and directories are allowed.
• Ask the agent to report uncertainty rather than fabricate an API.
• Require a final test command and a concise changed-file summary.

For agent mode, keep approval boundaries outside the model’s discretion. Use repository permissions, sandboxing, branch protection, and CI checks as enforcement layers. A model change should not silently broaden what an agent can write, execute, or publish.

Teams already using AI coding agents with context files should review their instructions for model-specific workarounds. If the workflow uses plugins or MCP, compare its tool contract with the migration test rather than assuming the same tool calls will be produced.

Enterprise policy changes deserve their own review

GitHub’s August 26 changelog says the global model policy is generally available and is rolling out through September 1. Previously unconfigured and new generally available models can inherit the global policy. Explicit choices are preserved. That makes the policy useful, but the “delegate to default policy” state can also hide a future change from teams that expected a static allowlist.

Create a policy review record with:

• The enterprise or organization scope.
• The default policy value.
• Explicit exceptions and their owners.
• Models excluded because of data retention or open-weight status.
• The date the policy was checked.
• The person responsible for the next review.

For organizations operating custom agent infrastructure, connect this review to your broader agent governance and zero-trust controls. The goal is not to freeze the model catalog; it is to make changes observable and intentional.

What to do on September 1

Use a staged response rather than waiting for a developer to report a broken workflow:

Before the cutoff:

1. Freeze the evaluation fixture and save baseline outputs where policy permits.
2. Update model presets, docs, examples, and automation.
3. Confirm the selected replacement is visible to every affected user group.
4. Run smoke tests on chat, completion, code review, and agent workflows.
5. Tell developers what to do if a model disappears from an existing session.

After the cutoff:

• Watch failed agent sessions and unusual diff sizes.
• Compare test-failure categories with the baseline, not just aggregate pass rates.
• Track support tickets by replacement model and client surface.
• Remove obsolete defaults only after the first production review window.

Common failure modes

“The replacement is documented but missing in the picker”

Check plan eligibility, organization policy inheritance, enterprise restrictions, and client versions. A policy may explicitly disable the model even while the catalog lists it.

“The agent now edits too much”

Treat this as a regression. Tighten the task contract, add file-scope constraints, require a plan, and enforce permissions outside the prompt. Do not solve a governance problem by asking the model more politely.

“The new model is more expensive or slower”

Measure the complete task, including retries and review time. A cheaper request that requires multiple corrections may be more expensive operationally. Keep cost and latency as separate dimensions so a quality improvement does not hide a budget regression.

“Our old benchmark passed, but production feels different”

Your fixture may not represent repository context, tool failures, code review, or long-running sessions. Add real anonymized tasks and test the surfaces your team actually uses.

“We need the old model for a historical comparison”

Keep archived outputs and dates, but do not depend on an unavailable model for a current workflow. Separate reproducibility records from active configuration.

FAQ

Does every Copilot user need to change a setting?

No. The impact is greatest for users and automations that explicitly select a retiring model. Administrators still need to verify replacement availability and policies, and teams should update shared instructions and presets.

Is Claude Sonnet 4.6 available after the deadline?

GitHub’s changelog says it remains available to individual subscribers on annual plans. The listed retirement still applies broadly, so enterprise teams should migrate unless their documented plan and surface qualify for an exception.

Should we choose the suggested alternative without testing it?

No. GitHub provides suggested alternatives, not a guarantee of identical behavior. Test representative tasks and select a supported model based on your quality, latency, cost, and governance requirements.

Does this change affect MCP tools?

The retirement notice covers Copilot experiences, while tool behavior depends on the client and workflow. If your agent uses MCP, include tool discovery, authorization, error recovery, and approval behavior in the regression suite. Existing MCP security threat-modeling practices remain relevant regardless of which model is selected.

Conclusion

GitHub’s September 1 Copilot model retirements are manageable if treated as a dependency migration rather than a model-picker chore. Inventory explicit references, enable replacements through policy, evaluate real tasks, update agent contracts, and monitor the rollout. The safest default is not “newest model wins”; it is “supported model plus evidence from our own workload.”

Sources and visual credits

• GitHub Changelog: Upcoming August 2026 model deprecations in GitHub Copilot — primary source for the retirement list, date, alternatives, and annual-plan exception.
• GitHub Docs: Supported AI models in GitHub Copilot — official model availability and compatibility reference.
• GitHub Changelog: Global model policy generally available — primary source for policy states and rollout behavior.
• GitHub public roadmap issue #1308 — independent GitHub product-operations record of the retirement initiative.

Visual credits: The model replacement table and both Mermaid diagrams are original editorial visuals created for this guide from the cited GitHub documentation and roadmap. No product screenshot or benchmark number is presented as original research.

Related reading

Continue exploring related AI engineering and developer tooling topics:

• GitHub Copilot Code Review for Bot PRs: A Safe Adoption Guide
• GitHub Copilot’s Global Model Policy: An Administrator’s Guide to the August 2026 Rollout
• agent-device: Give AI Coding Agents a Mobile App Feedback Loop