Three Copilot model retirement dates in about six weeks is enough to call it a pattern. GitHub retired four models on October 2, six more on October 19, and has three scheduled for November 16. If your engineering is done by a vendor or a nearshore team, someone has to own the Copilot model governance checklist, and the contract should say who.
This post covers what changed, what the new policy API gives you, and the checks we would ask a vendor team to run before the next retirement lands.
What GitHub retired, and what is still scheduled
The October 2 notice covered Gemini 3.5 Flash, Gemini 3.6 Flash, Kimi K2.7 Code and Claude Opus 4.7, across all Copilot experiences: Chat, inline edits, ask and agent modes, and completions. The October 19 notice covered Gemini 3.7 Flash, GPT-5.5, GPT-5.4, GPT-5.4 mini, GPT-5 mini and Grok 4.5, and GitHub scopes that one to “most” Copilot experiences.
Next up on November 16: Claude Opus 4.8, Claude Opus 5 and GPT-5.6 Terra. Opus 4.8 stays available to individual subscribers on annual plans, which does not help a company account.
One detail matters for anyone who planned migrations from the warning notices. The suggested replacement moved between announcement and retirement. The September 3 notice pointed Opus 4.7 users to Claude Opus 5, while the final notice says Claude Opus 5.5. The September 18 notice named GPT-5.6 Sol, GPT-5.6 Luna and Grok 4.6; the October 19 notice names GPT-6.1 Sol, GPT-6 Luna and Grok 4.7. Treat the replacement list as provisional until the retirement date.
Why vendor teams feel this first
GitHub’s notices tell users to update workflows and integrations to supported models. They also say that where default model enablement is on, Business and Enterprise accounts get the suggested alternatives switched on automatically, unless an admin turned off the global default or disabled the model. That sentence hides a handoff problem. The admin who disabled a model last spring may work for the client. The developers whose prompts, agent configs and review habits depend on it may work for the vendor.
Add the enterprise teams preview, which evaluates model access with a least-restrictive strategy: if any one enterprise team grants a user a model, that user has it everywhere. Mixed client and vendor staff in the same enterprise make that rule worth a deliberate review.
What the model policy API changes
On October 19 GitHub made GET and PATCH endpoints generally available for Copilot model policies at four levels: enterprise, enterprise teams, agent apps and organization. Enterprise policies can delegate control to organizations, or to teams and apps.
The REST reference adds the practical details. PATCH takes a models array of model_name and policy_state pairs, and setting optional removes a stored policy. Reads need read_enterprise_ai_controls and writes need write_enterprise_ai_controls. The docs also warn that responses report policy state and editability, not a final access decision for a given user, so a green response is not proof that a developer can use the model.
The consequence is simple: model access can live in a repository instead of a settings page. That makes it reviewable, diffable and auditable by both sides of a vendor relationship.
A governance checklist for the vendor team
What follows is my recommendation, not something GitHub prescribes.
- Inventory model names. Grep prompts, agent instructions, CI scripts and internal docs for every model name in use. Keep the list in version control with an owner per entry.
- Pin explicitly. Where a tool lets you choose a model, choose it by name in config rather than relying on a picker default. A retired default fails quietly.
- Treat policy as code. Export current policies through the GET endpoints, commit them, and apply changes through PATCH from a reviewed pull request. Record
default_availabilityand any delegation settings. - Calendar the retirements. Subscribe to the changelog, then open a ticket for each announced date with a named owner. November 16 is the next one.
- Test the replacement, not the warning. Re-run a fixed set of representative tasks against the final alternative once the retirement notice confirms it.
- Review delegation boundaries. If you use enterprise teams mode, list which teams grant which models and who can change them, given the least-restrictive evaluation.
Contract clauses worth adding
Most outsourcing agreements say nothing about AI tooling versions. A short addendum can close the gap:
- The vendor keeps a current model inventory and shares it on request.
- The vendor acknowledges retirement notices within an agreed number of business days and states the migration plan.
- Policy changes go through the client’s repository or change process, with the API token scoped to the minimum permission.
- Quality checks must pass on the replacement model before it becomes the default for client work.
- The agreement says who pays for rework if a retirement lands mid-sprint.
Where to start this week
Pull the policy export for one enterprise or organization and compare it to what your vendor believes is enabled. The differences are your first backlog. If you want a second pair of hands on that review, talk to the Luby team.