GitHub Copilot Retirements Show Why a Fallback Model Is Temporary

GitHub plans to retire six models across Copilot Chat, inline edits, ask mode, agent mode, and code completions on September 1, 2026. The product remains Copilot, but a workflow that depends on one of those model names may not behave the same after the catalog changes.

The practical response is not to replace six strings and hope. Inventory each place a retiring model controls behavior, confirm that the proposed replacement is available for the same plan and client, replay representative tasks, and keep a second supported fallback. Finish that gate by August 31. GitHub’s changelog names September 1, while its public roadmap describes the lineup changing on August 31. Treating the earlier date as the internal deadline removes an avoidable timezone and rollout-boundary gamble.

One fallback needs extra attention. GitHub originally directed Raptor Mini users to MAI-Code-1-Flash. Its current retirement table now schedules MAI-Code-1-Flash for retirement on September 10, only nine days later, with MAI-Code-1.1-Flash as the next suggestion. A durable migration must evaluate that second hop now.

The retirement map is already account-dependent

GitHub’s July 31 notice gave this September 1 mapping. The current documentation has since narrowed both Opus alternatives to Opus 5 and added the later MAI-Code retirement.

Retiring model	Current documented alternative	Migration boundary to record
Gemini 3.1 Pro	Gemini 3.6 Flash	Provider stays Google, but the suggested model moves from a reasoning-oriented Pro model to Flash; replay complex edit-and-test tasks rather than assuming equivalent behavior.
Claude Opus 4.5	Claude Opus 5	Check policy enablement, client support, task quality, latency, and credit use.
Claude Opus 4.6	Claude Opus 5	Do not transfer an Opus 4.6 evaluation score to Opus 5 without rerunning it.
Claude Sonnet 4.5	Claude Sonnet 5	Retest tool use, structured responses, code edits, and review behavior on the surfaces the team actually uses.
Claude Sonnet 4.6	Claude Sonnet 5	Individual annual subscribers retain Sonnet 4.6 under GitHub’s stated exception; that account-specific exception is not an organization-wide migration plan.
Raptor Mini	MAI-Code-1-Flash, then MAI-Code-1.1-Flash	The first suggested replacement retires September 10. Test the longer-lived second hop if it is available to the account and client.

This is a catalog map, not a compatibility guarantee. GitHub says model availability depends on the Copilot plan and client, and organization or enterprise owners can enable or restrict specific models. Some newer alternatives also require minimum IDE or extension versions. An administrator seeing a model in one personal picker does not prove that every developer, editor, or organization policy can use it.

The replacement may also alter the budget. GitHub’s pricing reference prices input, cached input, and output tokens by model and converts them into AI credits. On August 26, it listed Raptor Mini at $0.25 per million input tokens and$2 per million output tokens, MAI-Code-1-Flash at $0.75 and$4.50, and MAI-Code-1.1-Flash at $0.20 and$1.20. Those figures are a dated planning input, not a permanent rate; record the page and review date beside the migration result.

Behavior dependencies outlive model strings

A repository search for the six names is useful, but it finds only recorded dependencies. The model can also be selected or restricted in interfaces and policies outside the codebase.

Build one inventory that covers:

• organization and enterprise model policies, including who can enable the alternative;
• saved user and workspace choices in each IDE or Copilot surface;
• CLI scripts or wrappers that pass a model name;
• extensions, internal tools, or routing logic that expect a particular model;
• prompt suites, agent instructions, tool schemas, and structured-output parsers tuned against its behavior;
• evaluation fixtures whose baseline is labeled only “Copilot” rather than with the model, client, and date; and
• runbooks, screenshots, training material, and support responses that tell users which model to choose.

For each dependency, record the surface separately. A candidate that passes a chat benchmark has not cleared inline completion, ask mode, agent mode, or a code-completion acceptance test. Independent coverage of the retirement makes the same operational point: the cutoff spans the product’s entry points, so a team needs more than one model-picker check.

Replacement quality depends on the workflow

GitHub’s own model comparison sorts models by broad task strengths and warns that models differ in quality, latency, and cost. Use that page to shortlist candidates. Use a frozen, representative task set to decide whether one can replace the retiring model in a particular workflow.

The relevant comparison is not whether two models produce identical wording. It is whether the replacement produces the same accepted outcome in the surface that matters: a patch builds, tool arguments validate, protected files stay untouched, and a reviewer can approve the result within a reasonable correction budget. Chat, inline completion, ask mode, and agent mode can reach different conclusions about the same candidate.

That makes GitHub’s broad model-comparison page a shortlist, not a migration result. Account plan, organization policy, client version, repository, tools, latency, retries, and human correction all belong to the observed behavior. The Raptor-to-MAI sequence adds a time dimension: a replacement can acquire its own deadline before the first migration is complete.

A fallback should fail visibly and remain replaceable

There are three reasonable outcomes for a dependency. Migrate when a supported candidate passes the gate. Hold the workflow when no candidate meets an essential quality, policy, security, or cost boundary. Remove the explicit dependency when Copilot’s automatic selection is acceptable and reproducibility does not require a named model.

Automatic selection is not a disguised pin. GitHub says it chooses according to availability and task complexity, so it can reduce catalog-maintenance work while also making the underlying model less stable as an experimental variable. Keep an explicit candidate for regulated, benchmarked, or tightly validated workflows where knowing the model is part of the evidence.

After September 1, the retired model is no longer a useful rollback target for affected accounts. The operational rollback is the second supported model, the previous non-AI path, or a visible pause—not a stale name left in a configuration file. For Raptor Mini users, this is why MAI-Code-1-Flash alone is insufficient: a fallback scheduled to disappear on September 10 is a bridge, not a destination.

The broader lesson is smaller than “newer models are better.” Copilot is a stable product name over a changing model portfolio. Teams that version the model, surface, policy, task set, and fallback together can absorb that change without mistaking GitHub’s suggestion for proof that their workflow still works.

The MCP roadmap analysis applies the same released-versus-planned distinction to protocol changes. The llama.cpp stable-versus-nightly analysis shows why immutable versions and workload evidence matter for local model upgrades too.

Sources

1. GitHub Changelog: Upcoming August 2026 model deprecations in GitHub Copilot
2. GitHub public roadmap: Copilot August 2026 model deprecations
3. GitHub Docs: Supported AI models in GitHub Copilot
4. GitHub Docs: AI model comparison
5. GitHub Docs: Models and pricing for GitHub Copilot
6. Tech Bytes report on the Copilot model deprecations