Record every place a model is selected

Start with the Copilot surfaces your developers use: GitHub.com, VS Code, JetBrains IDEs, Copilot CLI, the Copilot app, and Copilot cloud agent. GitHub's supported-model table lists availability by client and plan. Use that table instead of assuming that a model visible in one picker exists everywhere.

Build a small inventory that has an owner and a test path:

- workflow: pull-request review
  surface: copilot-cloud-agent
  current_model: Claude Sonnet 4.5
  replacement: Claude Sonnet 5
  policy_owner: platform-engineering
  validation: reviews/security-sensitive-prs

- workflow: local refactoring
  surface: vscode-chat
  current_model: Gemini 3.1 Pro
  replacement: Gemini 3.6 Flash
  policy_owner: developer-experience
  validation: refactors/typescript-service

Include saved team instructions, onboarding documents, screenshots, internal launchers, and scripts that tell users which model to choose. A hard-coded model name in documentation will continue sending people toward a retired option even if the application itself falls back safely.

Ask developers to report any model they select manually for a recurring task. Cloud agent exposes a model picker for supported models, while surfaces without a picker use Auto. A team can therefore have explicit selections and automatic routing in the same workflow.

Use GitHub's current replacement table

GitHub's retirement history gives these suggested moves:

The table identifies a migration target, but the substitute still needs testing on each task. Gemini 3.1 Pro and Gemini 3.6 Flash, for example, are different models. Compare the workflow's behavior under the replacement.

Keep the prompt, repository state, tools, permissions, and test inputs fixed during the first comparison. Changing the model and instructions together makes a regression difficult to attribute. The coding-agent evaluation guide explains how to compare the full sequence of edits and tool calls rather than grading only the final answer.

Check policy before telling users to switch

Copilot Business and Enterprise administrators can control model availability. At the enterprise level, a model can be Enabled for everyone, Disabled for everyone, or Optional so access can be granted to specific organizations or enterprise teams. An enterprise-level Disabled setting cannot be overridden by a team.

A technically supported replacement may therefore be missing for the people who need it. Enterprise owners should open AI controls, review the Copilot model list, and explicitly configure the intended alternatives. If access is delegated, confirm that the relevant organization or enterprise team has the model enabled.

Individual access also varies by Copilot plan and client. GitHub advises checking the supported-model table and the user's Copilot settings. Record the policy decision next to the workflow inventory so support staff can distinguish a retirement from a local access restriction.

The Copilot agent metrics guide can help identify active agent surfaces. Pair those usage totals with targeted evaluations of replacement behavior.

Test behavior that model changes can expose

Use representative tasks from the repository, including at least one failure case. Compare:

• whether the model follows repository and organization instructions;
• which files it reads and edits;
• tool selection, arguments, retries, and approval requests;
• structured output and patch validity;
• test execution and response to a failing test;
• latency, AI-credit use, and incomplete runs.

Review security-sensitive behavior separately. A replacement may interpret ambiguous tool instructions differently even when the final patch looks similar. Keep the same least-privilege tool policy during the comparison and inspect attempted actions as well as successful ones. The least-privilege checklist covers permission boundaries for agent tools.

For cloud agent tasks, test the reasoning level your team intends to use. GitHub exposes configurable reasoning only for models that support it. Higher levels may take longer and use more AI credits, so record the selected level with the model instead of treating it as an invisible preference.

Decide where Auto belongs

GitHub says Auto model selection chooses a model based on availability and to help reduce rate limiting. It is also used where a model picker is unavailable. Auto can reduce maintenance for general chat, but it does not provide a stable model identity for a workflow that has been validated against one named model.

Use named replacements for tasks whose behavior, cost, or approval evidence must be reproducible. Auto is better suited to workflows that already tolerate model variation and are evaluated continuously. ISH chat can compare the same prompt across models, while ISH API can provide a consistent application interface when teams need provider-independent model routing.

Finish the cutover before the picker changes

Move the replacement models through policy review, run the fixed evaluation set, and update internal guidance before September 1. Then search documentation and configuration repositories for all six retiring names. Keep the inventory as the release record, with the old model, replacement, policy state, evaluator result, owner, and completion date.

Verify the replacement in every supported client used by the team. A passing test in VS Code does not confirm availability in Copilot CLI or cloud agent. Close the migration when the model is enabled, selectable where applicable, and proven on the workflow that depended on it.

Sources

• GitHub Changelog: upcoming model deprecations
• GitHub Docs: supported AI models in Copilot
• GitHub Docs: changing the model for Copilot cloud agent
• GitHub Docs: managing model availability in an enterprise
• GitHub Docs: configuring access to AI models