GitHub Copilot Is Retiring Four Models: A Practical Migration Plan

Four Copilot models are approaching retirement

GitHub plans to remove four models from GitHub Copilot on October 2, 2026: Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code and Claude Opus 4.7. The notice, published on September 3, describes a scheduled change, not one that has already taken effect. Teams therefore have a short but useful migration window in which both the current configuration and its successor can be inspected.

The scope is broader than a model picker in chat. GitHub explicitly lists Copilot Chat, inline edits, ask mode, agent mode and code completions, and asks customers to update workflows and integrations before the deadline. Any team that has standardized prompts, repository instructions, automated routines or operating guidance around one of the retiring models should treat this as a workflow change. Waiting for the old choice to disappear turns a controlled comparison into an emergency cutover.

GitHub suggests Gemini 3.8 Flash for users of Gemini 3.5 Flash or Gemini 3.6 Flash, Kimi K3 for Kimi K2.7 Code, and Claude Opus 5 for Claude Opus 4.7. These are migration directions, not claims of equivalence. A newer model may interpret instructions differently, produce a different style of patch, take longer on a task or require more review. Even where published token rates match, the number of tokens and tool calls needed to complete an accepted task may not.

The practical response is not to rank the model names in the abstract. It is to locate every dependency, confirm that the proposed destination is actually available to the people and clients involved, and replay representative work before changing the default.

Start with an inventory of dependencies

A visible, manually selected model is the easiest case. Less obvious dependencies deserve more attention. A model can be selected by an individual, established as an organizational default, enforced by an enterprise owner, inherited through default availability, or chosen indirectly through Auto. Documentation and runbooks may also tell developers to pick a particular model even when no software setting enforces that choice.

Build an inventory around real usage rather than around a single administration page. For each affected workflow, record:

• the Copilot experience it uses: Chat, inline edits, ask mode, agent mode or code completions;
• whether the model is explicitly selected, supplied as a default or chosen through Auto;
• the governing enterprise and organization policy;
• the client and extension version used by the developer;
• any repository instructions, reusable prompts, integration steps or support documentation that assume the old model;
• a named owner who can approve the replacement and verify the change.

Check both sides of the configuration. An administrator may see a model permitted in policy while a developer cannot select it in the client. Conversely, a model visible to one tester may be unavailable to colleagues on another plan, client or inherited policy. The user-facing selector is therefore an essential check, not a cosmetic confirmation after the administrative work.

This matters especially for the proposed Kimi migration. GitHub classifies Kimi K3 as an open-weight model. For Copilot Business and Enterprise, open-weight models are disabled by default independently of the general Default availability setting. They can be explicitly enabled when no other restriction prevents it. A team that merely replaces “Kimi K2.7 Code” with “Kimi K3” in its runbook may discover on cutover day that the destination was never allowed.

Separate policy, default and actual selection

Three concepts that look similar in a dashboard can have different operational effects. Policy determines whether a model may be used. A default determines what starts a new conversation in the supported surfaces. Explicit selection can override a default where policy and the interface permit it. Auto introduces a further decision layer by selecting among eligible models according to availability, system health and task complexity.

Since September 2, enterprise-managed settings have allowed Copilot Business and Enterprise administrators to set any available model as the default for new conversations and to override that default by enterprise team. GitHub lists this capability as generally available in the Copilot app, Copilot CLI and VS Code. That list should not be casually extended to other clients. A default configured correctly for a new VS Code chat also says nothing by itself about an existing conversation, a pinned workflow or a different Copilot experience.

For every item in the inventory, write down the effective chain: who permits the model, who chooses the default, whether the user can override it, and what the interface reports as actually used. This prevents a common migration error in which an administrator changes a default and assumes all traffic has moved.

Verify availability before evaluating quality

GitHub’s live model reference currently marks both the retiring models and the suggested alternatives as generally available. General availability does not mean universal availability. Access can vary by Copilot plan and client, and GitHub’s tables can change. A valid test begins only after the intended user can select or receive the new model in the same environment where the work will occur.

Client versions are part of that check. GitHub describes its minimum-version table as tentative. As of the research snapshot on September 6, some Gemini 3.8 Flash entries remained to be determined, while the table listed VS Code 1.131 for Kimi K3 and VS Code 1.128.0 for Claude Opus 5. Teams should consult the current table rather than encode those values permanently in a migration guide. Update the IDE or extension where necessary, then confirm the model in the interface used for the test.

Auto can be included as a candidate, but it should not be mistaken for a drop-in replacement for a pinned model. Its choice depends on the customer’s plan and policies as well as changing service conditions and task complexity. In supported interfaces, the model actually used can be inspected. Capture that information during testing; otherwise results attributed to “Auto” cannot be reproduced or meaningfully compared.

Replay work that the team actually accepts

A useful evaluation set is small enough to review carefully and broad enough to expose differences. Select completed, non-sensitive tasks that represent the team’s normal use: explaining unfamiliar code, making a constrained edit, adding tests, tracing a defect, refactoring across files and carrying out a tool-using agent task. Include cases where repository instructions or established prompts matter.

Preserve the starting state for each case. Give the retiring model and its proposed successor the same repository revision, relevant context, instructions and acceptance criteria. A historical task can be replayed without pretending the generated answer was used in production. The purpose is to compare behavior under controlled conditions, not to manufacture a benchmark victory.

Record outcomes at the level that matters to engineering:

• whether the result satisfies the stated acceptance criteria;
• whether tests pass and the patch remains within scope;
• serious omissions, unsupported claims or invented details;
• elapsed response time under comparable conditions;
• the amount of human correction and review required;
• token or AI-credit use where the product exposes it;
• whether an agent stopped safely, used tools appropriately and left a reviewable change.

GitHub’s documentation notes that models differ in quality, relevance, latency, hallucination tendency and suitability for particular tasks. That is product guidance, not an independent benchmark of a team’s repository. Local replay supplies the missing evidence. It may also show that different successors suit routine edits and complex analysis, making a single universal default less useful than task-based guidance.

Treat price as an input, not an answer

The pricing page provides useful reference points, but it cannot predict the invoice or the cost of an accepted change. In GitHub’s September 6 snapshot, prices per million tokens were listed as follows:

• Gemini 3.5 Flash: $1.50 input, $0.15 cached input and $9 output;
• Gemini 3.6 Flash and Gemini 3.8 Flash: $0.75 input, $0.075 cached input and $3.75 output;
• Kimi K2.7: $0.95 input, $0.19 cached input and $4 output;
• Kimi K3: $3 input, $0.30 cached input and $15 output;
• Claude Opus 4.7 and Claude Opus 5: $5 input, $0.50 cached input, $6.25 cache write and $25 output.

GitHub values one AI credit at $0.01. Code completions and next edit suggestions do not consume AI credits. The eventual cost still depends on the plan, product feature, input and output volume, cache behavior and the path a model takes through a task. Matching rates for Claude Opus 4.7 and Claude Opus 5 do not demonstrate matching consumption. Kimi K3’s higher listed rates likewise do not reveal the cost per accepted task without measured usage and review effort.

Use the replay to compare complete outcomes. A cheap response that requires several retries and a large manual rewrite may cost more in practice than a more expensive response accepted after one review. Conversely, a capable model may be unnecessary for a narrow, repetitive edit. Keep the published rates and locally observed usage separate so that later price changes do not invalidate the behavioral results.

Move through a canary, not a fleet-wide switch

Once a successor meets the acceptance bar, expose it to a limited group or a bounded set of repositories. A useful canary includes developers who perform the workflows represented in the replay and who can report specific regressions. It should last long enough to encounter normal work, but it should have a clear decision date well before October 2.

Before starting, define the fallback. That may be another permitted model, Auto for selected interactive work, or a temporary manual process. Auto should be tested like any other option because its model pool changes and it cannot guarantee the behavior of a pinned model. The retiring model can remain a comparison point during the migration window, but it is not a fallback after retirement.

Track operational signals during the canary: failed acceptance criteria, out-of-scope edits, review time, latency, usage where available and incidents requiring a model change. Avoid pooling unrelated tasks into one satisfaction score. A regression in agent mode can be hidden by strong results in simple chat unless the experiences are evaluated separately.

If the canary succeeds, update the effective setting and the human instructions together. Change enterprise or organization policy where required, establish the intended default only on supported surfaces, revise reusable prompts and runbooks, and tell users how to verify the selected model. Existing conversations and manually pinned choices may not follow a new default, so the rollout message should distinguish “available,” “default” and “currently in use.”

Verify the cutover from the user’s seat

The final check belongs in the real client, under the identity and policy path of an affected user. Start a new conversation where defaults apply, inspect the displayed model, run a known lightweight task and confirm that the result arrives through the intended experience. Repeat this for material differences in team policy, plan or client version.

After October 2, the retired models do not need to be removed manually. The important cleanup is elsewhere: stale documentation, pinned references, screenshots, onboarding material, integration assumptions and dashboards that still group results under an obsolete configuration. Confirm that fallbacks are available and that support staff know what evidence to request when a user reports different behavior.

A concise migration record should retain the inventory, policy approvals, client-version checks, replay cases, observed results, canary decision and post-cutover verification. It should also note when pricing and availability were checked because both are live product information. That record turns the next model retirement from a search through scattered settings into a repeatable engineering change.