GitHub Copilot Model Deprecations: A November 16 Migration Gate

GitHub's October 15 deprecation notice gives Copilot operators one month to move workflows and integrations. The change reaches Copilot Chat, inline edits, ask and agent modes, and code completions. It affects three model routes:

The Claude Opus 4.8 retirement does not apply to individual annual Copilot subscribers. For Copilot Business and Enterprise, however, a model appearing in the selector only proves availability. It does not prove that the model preserves behavior, review burden, cost, or acceptance for your repository.

The migration unit is therefore not a model name. It is a route:

identity + surface + task class + repository + policy + model + acceptance gate

Retire and replace that whole route by evidence.

Start with the effective route, not the settings page

A settings export is necessary, but it is not the effective state. GitHub's Copilot policy documentation says enterprise policy is evaluated before organization policy. If a user receives access from multiple organizations in the same enterprise, the least restrictive setting usually applies, with exceptions. Across different enterprises, the most restrictive policy almost always applies. The Copilot app and Copilot CLI also have independent client policies.

Build an inventory with one row for every current route:

• retiring model and the experience that uses it;
• enterprise, organization, repository, team, and user scope;
• license source and any overlapping license;
• whether model access is explicit or delegated to the default policy;
• task class and repository set;
• client or integration that selects the model;
• acceptance suite, owner, and rollback route;
• last observed successful use.

Probe effective access with the same identity and client the workload uses. An administrator seeing Claude Opus 5.5 in an enterprise settings page does not prove that a developer with a different license source can select it in the IDE. A developer selecting a model in chat does not prove that an agent integration is routing to the same model.

GitHub says its active default availability policy automatically applies to new and unconfigured generally available models. A model that is explicitly disabled does not inherit that default. Neither do pre-GA models, open-weight models, or models outside GitHub's data-retention agreement. Record whether each replacement is explicitly enabled, explicitly disabled, or delegated. Do not write “enabled” when the real state is “currently inherited.”

Map replacements by task class

GitHub suggests one Claude replacement and two GPT alternatives. That is migration guidance, not an equivalence guarantee. The correct replacement may differ between completion, interactive edit, repository question, pull-request repair, and autonomous issue work.

Create a small route manifest instead of one global substitution:

routes:
  - task_class: bounded_inline_edit
    current_model: gpt-5.6-terra
    candidate_models:
      - gpt-6-luna
      - gpt-6.1-sol
    acceptance_suite: inline-edit-v4
    owner: developer-platform
    rollback: supported-baseline

  - task_class: cross_repository_agent_task
    current_model: claude-opus-5
    candidate_models:
      - claude-opus-5.5
    acceptance_suite: cross-repo-agent-v2
    owner: agent-platform
    rollback: supported-baseline

The labels are illustrative. Use the identifiers exposed by your Copilot client or integration and your own task taxonomy. The important move is to keep a bounded edit separate from a multi-step agent job. Combining them in one average can let a cheap completion win conceal an expensive agent failure, or let one strong agent result justify unnecessary cost across routine edits.

For GPT routes, the existing accepted-patch routing method is the right starting point. Luna belongs in the bounded candidate lane. GPT-6.1 Sol belongs in the hard-task candidate lane. That is a test order, not a universal routing claim.

Run a repository migration eval

Choose a representative set of completed tasks for each route. Freeze the repository commit, relevant instruction files, client version, tool permissions, network policy, reasoning setting when exposed, and acceptance suite. Run the retiring model while it is still available, then run each candidate under the same harness.

The gate should join four kinds of evidence:

1. Repository result: tests, static checks, build, policy checks, and prohibited-file checks.
2. Human disposition: accepted, accepted after changes, rejected, or abandoned.
3. Work required: review time, rework, retries, and incident handling.
4. Route economics: usage or premium-request accounting, latency, and any separate Actions or infrastructure cost your workflow creates.

Do not publish a generic pass-rate threshold and pretend it fits every codebase. Set the minimum result for each task class before looking at the candidates. A security-sensitive repository may require every seeded policy violation to be caught. A routine migration may prioritize deterministic test completion and a low rework burden. A cross-repository agent route may need correct handoff and cleanup even when the patch itself passes.

Compare outcomes at the terminal state. “The agent produced a diff” is not an accepted result. “The chat answered” is not evidence that the answer survived a repository check. Reconcile the patch at the commit, the tests in the trusted runner, and the human disposition in the review system.

Canary the policy and the workload together

Enable a candidate for a bounded organization or team, then route only the task class it passed. A useful canary receipt contains:

• change identifier and timestamp;
• enterprise and organization scope;
• actor who changed the model policy;
• explicit or delegated enablement state;
• task-class manifest version;
• repository and commit;
• effective client and model observed at execution;
• acceptance-suite version and result;
• human disposition and owner;
• observed usage, review, and rework;
• rollback action and its latest test.

GitHub's Copilot audit-log guide says the enterprise audit log records Copilot plan, policy, setting, license, and GitHub-hosted agent activity. It does not include local client prompts. The log retains events for 180 days, and GitHub recommends streaming it to a SIEM for longer history.

That means the GitHub audit event can prove who changed the policy, but it cannot prove which prompt, repository state, model response, or local result passed your gate. Join the policy event to your own execution receipt. Preserve only the client data your governance permits, but keep enough identifiers to reconstruct the route and terminal outcome.

Cut over before the comparison disappears

Schedule the production cutover early enough to observe normal work before November 16. The runbook should be explicit:

1. Freeze the current route inventory and eval set.
2. Enable replacement candidates in the intended policy scope.
3. Confirm effective access with real pilot identities and clients.
4. Run matched repository evaluations and record terminal outcomes.
5. Promote only the passing task classes to a bounded canary.
6. Observe cost, review, rework, and rollback behavior.
7. Cut over the remaining approved scope and remove stale explicit pins.
8. Reconcile policy state and integrations after GitHub removes the retired models.

GitHub says no action is required to remove the old models after deprecation. That does not make your migration automatic. An integration with an explicit model pin may fail, fall back, or present a client-specific error. GitHub's announcement does not promise one universal behavior for stale pins, so test the exact client and integration before the deadline.

For teams that value a longer support horizon, GitHub currently designates GPT-5.3-Codex as both its base and long-term-support model for Business and Enterprise. GitHub's LTS documentation says an LTS model is supported for one year from designation. That makes it a continuity candidate worth evaluating. It does not make it the correct replacement for every Claude or Terra task class.

The rollback also needs a supported destination. “Switch back to Claude Opus 5” stops being a rollback on November 16. Qualify a supported baseline for every route, keep its policy available, and test the change with the same identity and client used by the canary.

The November 16 decision record

The final record can be compact. For each retired route, retain:

This is enough to answer the questions that matter after the old selector entry disappears: what moved, why this model received this work, what passed, who accepted it, what it cost, and how the team can reverse it.

GitHub Copilot model deprecation FAQ