S3DAT NEWS
· 7 stories RSS s3dat.com

GitHub sets a December deadline for six Copilot models

GitHub announced on November 13 that six Copilot models will be deprecated on December 14. The notice creates a migration deadline for teams whose coding workflows depend on a specific model.

Spec sheet

Platform
GitHub Copilot
Listed retirements
6 models
Deadline
14 December 2026
Kimi K3 replacement
To be announced

What does retirement change?

The notice covers chat, inline editing, agent and ask modes, and code completions. It pairs five retirements with suggested alternatives. Individual annual Copilot subscribers retain Haiku 4.5. The same date therefore does not mean identical changes for every subscription.

Does appearing in the picker mean a migration is finished?

Hydrogen illustrates the difference between access and readiness. GitHub introduced it on November 13 for Pro, Pro+, Max, Business and Enterprise customers. Distribution is gradual across editors, the command line, coding agent, app and other supported surfaces. Billing follows provider list prices under usage-based billing. Business and Enterprise administrators manage its model policy; default enablement applies unless the global default is off or the model is explicitly disabled. These controls determine whether someone can select a model. They do not test the output of a particular repository task.

Why does data review belong in the same migration?

Fable 5.2 has a separate requirement in its November 9 release notice. Its organization policy starts disabled, and enabling it acknowledges data retention for safety classifiers. Anthropic retains prompts and outputs for that purpose, not model training. Eligible enterprises can obtain a temporary zero-retention exemption through the calendar year while Enterprise Frontier Safeguards rolls out. GitHub directs eligibility questions to account teams. Even approved organizations must still enable the policy. A model change can therefore involve both an administrator and the person responsible for data handling.

What would a small migration test look like?

Consider a hypothetical team with ten repeatable repository tasks: four bug fixes, three test additions and three documentation changes. Running each once with the old model and once with a candidate produces twenty attempts. The team records completed tasks, failed tests, elapsed time and billed usage separately. A model that finishes more tasks might still need more review on one category. Keeping the same inputs makes those differences easier to inspect. This is an example test design, not a reported benchmark or a promise that ten tasks represent an entire codebase.

Can changing one default settle every policy?

GitHub’s October 22 feature-default rollout preserved explicit administrator choices. Eligible unconfigured feature settings received the selected default once; later changes to that default did not rewrite policies already set. Preview features remained opt-in. That announcement concerned feature and client controls, whereas the November model notices describe model-specific policies. Treating these as separate records avoids confusing a platform-wide preference with the actual state of a replacement. The useful migration record joins the model name, allowed surfaces, data decision and test result in one place.

Claim check

  • Confirmed GitHub lists six December retirements, with an annual-plan exception for Haiku 4.5. [1]
  • Company claim GitHub says Hydrogen improves instruction following over Gemini 3.8 Flash. [2]
  • Unclear The retirement notice describes default enablement broadly, while Fable 5.2’s release notice requires explicit activation. The notice does not resolve that policy exception. [3]

Sources