A model selector can show a suggested replacement while your team's pinned workflow still names the old model. The picker changed; the workflow may not have. Rerun a real task before signing off.
GitHub's Copilot changelog schedules selected model deprecations for October 19, 2026, across Copilot chat, inline edits, ask and agent modes, and completions. It lists suggested alternatives and calls out model availability for Business and Enterprise organizations: default enablement can apply, but an admin or global policy can disable an alternative. This is a Copilot-specific notice, not a retirement announcement for those models everywhere. Nor is a suggested alternative a promise that your prompts, integrations, costs, or outputs will behave the same way.
GitHub also argues that repository instructions, skills, and hooks can stay with a workflow even when the model changes. That's a design argument, not evidence that a particular switch is safe. For a rehearsal, hold that context fixed and see what the new choice does.
Check what is pinned before touching settings
Start where your team actually selects a model: individual Copilot settings, organization policy, and any workflow or integration that names one. Record the existing choice, its owner, and where it is configured. Before planning a run, check which alternative your organization allows. A teammate's model picker doesn't tell you what your own policy permits.
If you don't have permission to inspect an organization setting, ask the admin to confirm it. Don't infer that a changed picker updated every pinned choice. The changelog tells you what GitHub plans to remove; it doesn't audit your setup for you.
Rehearse one task with the same boundaries
Pick a small task you know how to inspect, such as adding an error state to a form. This is a proposed test, not a report of one I ran. Write down the acceptance conditions before changing the model: the error appears on failed submission, focus reaches the error message, the success path still works, and your project's required checks run.
Use the same repository revision, committed instructions, permitted tools, and required checks for both runs. Work in separate branches or clean worktrees so the first run cannot leak changes into the second. If the old option is still available under your policy, run the task once with each choice. If it is not, use a saved baseline diff and check output, and label the comparison accordingly. A historical result is not a controlled head-to-head run.
A simple record is enough:
Task: add form submission error state
Repo revision / instructions: <record the same values for each run>
Model choice / policy: <record the configured choice and whether it was allowed>
Permissions: <record allowed tools and approvals>
Checks: <required checks and actual pass / fail / not-run results>
Review: <diff, behavior check, unresolved issues, reviewer decision>
Those are fields to fill in, not a sample result. Review the diff against the acceptance conditions. Run the real test and build commands your repository requires; inspect the form behavior and focus path if those are part of the task. Keep not run distinct from pass. A convincing explanation in the agent transcript does not turn an unrun check green.
Know when to stop
If policy blocks the alternative, pause the pinned workflow and ask for an authorized choice rather than routing around the setting. If the output misses the error state, changes unrelated files, or leaves a required check failing, the model's availability is beside the point. Rework the task, review the new diff, and run the checks again. If you cannot run them, keep a manual path for the work until you can verify it.
This rehearsal doesn't measure general model quality. One task can expose a local incompatibility or give you enough evidence to approve that particular workflow; it cannot guarantee equivalent latency, cost, or behavior for every task. Repeat the exercise for materially different pinned workflows rather than treating one green run as a blanket approval.
I'd keep the task, the fixed context, the actual check output, and the review decision together. Otherwise the team has a new model name in settings and no record of what that change did to the work.
Source notes
- GitHub Copilot model deprecation notice — planned date, affected Copilot experiences, suggested alternatives, and organization-policy caveat. The notice was read in same-day discovery and briefing; a fresh direct fetch was blocked at drafting time.
- GitHub on portable agent context and developer control — vendor framing for repository context, skills, hooks, and oversight; not evidence of model equivalence. The article was read in same-day discovery and briefing; a fresh direct fetch was blocked at drafting time.
Top comments (0)