# GitHub Copilot Model Retirements: What to Change Before December 14

Six models are scheduled to leave Copilot, but the replacement list does not settle access, cost or workflow compatibility.

By Paras Madan | 2026-11-15

GitHub plans to retire six Copilot models on December 14, 2026. Teams should test replacement access now, rather than discover a policy problem on retirement day.

## Which Copilot models are retiring?

The [official retirement notice](https://github.blog/changelog/2026-11-13-upcoming-deprecation-of-selected-github-copilot-models-in-december/) applies across Copilot experiences, including chat, inline edits, agent modes and completions.

| Retiring model | GitHub’s suggested alternative |
| --- | --- |
| Claude Fable 5 | Claude Fable 5.2 |
| Claude Haiku 4.5 | Claude Haiku 5.5 |
| Gemini 3.8 Flash | Gemini 4 Hydrogen |
| Gemini 4 Argon | Gemini 4 Carbon |
| Grok 4.6 | Grok 4.7 |
| Kimi K3 | Not yet announced |

Haiku 4.5 remains available to individual Copilot subscribers on annual plans. That exception does not describe a blanket extension for every account.

These are Copilot retirement dates. Do not infer that the same models disappear from their original providers’ APIs on December 14.

## Check policy access before changing team instructions

For Business and Enterprise, alternatives follow default model enablement unless administrators disable that default or the model. Otherwise, enable them through model policies. No manual removal of retired models is required.

That makes access a separate migration step from choosing a replacement. Ask a normal team member to open the model selector in the client they actually use. An administrator seeing a model in their own setup is a weaker check than the intended user completing a task with it.

The [supported-model reference](https://docs.github.com/en/copilot/reference/ai-models/supported-models) distinguishes plan availability, client support and minimum IDE or extension versions. Check all three before treating a missing model as a provider outage. Some entries remain marked TBD, so do not invent a minimum version where GitHub has not specified one.

## Test the workflow, not just one impressive answer

Use a small, repeatable task from a non-sensitive test repository. For example, ask the old and proposed replacement models to fix the same deliberately failing input-validation test on separate clean branches. Keep the task description, starting commit and permitted tools the same.

Inspect whether each result passes the relevant tests, changes unrelated files or needs additional instructions. Record the client, selected model, elapsed time and usage shown by your account. This is a proposed acceptance check, not a benchmark I have run or evidence that one listed replacement is better.

GitHub’s reference also notes that extended context and higher reasoning settings can increase AI-credit consumption. Leave those settings unchanged during the first comparison. Otherwise, you may attribute a different resource budget to the model itself.

**A suggested replacement is a migration candidate, not a promise of identical behaviour or cost.** Update shared instructions only after the replacement works for the people and task types that depend on them.

## What should Kimi K3 users do?

For Kimi K3, pick an available candidate for evaluation, but label it as your team’s choice rather than an official successor. Keep the decision reversible until GitHub supplies more detail.

A useful migration record needs only the old model, candidate, affected clients, policy owner and acceptance result. For a team using several models, that small record is more valuable than replacing every model name in a document and assuming the work is finished. The deadline should end a tested transition, not start one.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical teams turn product changes and developer workflows into clear, useful technical stories.

[Book a 30-minute call](https://cal.com/paras-madan/30min)