GitHub Copilot 于 10-19 正式退役六个模型，同日开放模型策略 REST API：第三方传闻结案，本站 10-16 的「不予采信」判断被推翻

常青入口：GitHub Copilot 工具卡 · 全部模型参数与定价 · AI 编程工具评测 · AI 概念百科

要点速览

• 2026-10-19，GitHub 官方发布退役公告，六个模型当天停用：Gemini 3.7 Flash、GPT-5.5、GPT-5.4、GPT-5.4 mini、GPT-5 mini、Grok 4.5。
• 官方写明这批是 2026-09-18 公告的（"These deprecations were announced on September 18, 2026"）——不是临时决定。
• 覆盖范围用词是 "most" 不是 "all"：官方原文 "across most GitHub Copilot experiences (including Copilot Chat, inline edits, ask and agent modes, and code completions)"。与 10-02 那批（"all GitHub Copilot experiences"）和 11-16 那批（"all"）的措辞不同，本站不对差异作推断。
• 同日模型策略 REST API 转正：企业、企业团队、Agent apps、组织四个层级的 GET / PATCH 端点 GA。
• 本站 2026-10-16 的判断被推翻：当时在 Copilot 工具卡里写下「第三方汇总站称另有 6 个模型将于 10-19 退役……不予采信」。官方公告证明第三方是对的、本站漏检了。 详见下文「本站的一次漏检」。

退役名单与官方建议替代

官方同时给出的两条操作口径：

1. 不需要手动移除旧模型——"No action is required to remove the deprecated models."
2. Copilot Enterprise 管理员可能需要放行替代模型："Copilot Enterprise administrators may need to enable access to alternative models through their model policies in Copilot settings." 管理员可在自己的 Copilot 设置里确认策略已开启；开启后才会出现在 VS Code 与 github.com 的模型选择器里。

对开发者的含义：写死模型 ID 的脚本、CI 配置与内部工具，这一轮必须复查。这是 2026 年 Copilot 第三次退役动作（10-02 四个、10-19 六个、11-16 三个），累计 13 个模型在六周内下线。把模型 ID 硬编码进流水线，等于把可用性绑在厂商的时间表上。

模型策略 REST API 转正：把"能不能用哪个模型"变成可编程

同一天，另一条 changelog 把模型策略做成了 API：

• GET 与 PATCH 均 GA。
• 企业策略可以下放模型控制权：在 organization mode 下下放给组织，在 enterprise teams mode 下下放给团队与 apps。

这两条放在一起才完整：退役动作要求管理员"去模型策略里放行替代模型"，而同一天官方正好把模型策略变成可编程的。企业管理员不需要再点控制台，可以直接用 PATCH 批量放行——这在 13 个模型集中退役的窗口期是刚需，不是巧合。

本站的一次漏检（以及修正后的判据）

发生了什么：2026-10-16 本站复核 Copilot 退役事项时，读到第三方汇总站称"另有 6 个模型将于 10-19 退役"。本站当时核对了自己已知的 2026-10-02 官方 changelog 条目，发现其中只有 4 个模型、没有这一批，于是判定"不予采信"，并列入待核实。

官方公告证明这个判断错了：六个模型确实在 10-19 退役，且官方写明这批是 9-18 就已经公告的。

错在哪：不是"不该怀疑第三方"，而是取证方式不对。本站当时是在已知的那一批官方条目里找，找不到就否定；正确做法是按 changelog 日期索引去检索是否存在 9-18 前后发布的另一份公告。"我没看到"和"它不存在"是两件事，本站把前者当成了后者。

修正后的判据：

1. 退役 / 定价 / 版本这类有明确生效日的存疑信息，先按日期去官方 changelog 索引检索，不要只复核已经拿到的那一份条目。
2. 对第三方的否定要留可撤回的写法。此前的"不予采信"是硬否定，被证伪后只能整段重写；改成"截至 X 日本站未取得官方公告，若 X 日当天官方发布则以官方为准"，同样表达怀疑，但证伪时只需追加一句结案。
3. 同一厂商连续多次发布同类公告时，默认存在多份独立条目。GitHub 在六周内发了三份退役公告，名单互不重叠——以为"看到一份就是全部"本身就是错的。

本次已在 GitHub Copilot 工具卡中把该段落改为显式结案并保留原判断的痕迹，不做静默修改。

AI 之家 观点

第一，Copilot 正在把"模型选择权"从开发者手里收走，再以策略的形式还给管理员。 六周内下线 13 个模型，同时上线模型策略 API——这两件事是一套动作：厂商负责快速换血，企业负责用策略兜住自己的流水线。对个人开发者是坏事（你选的模型可能随时消失），对企业是中性（有 API 就能批量治理）。

第二，"most" 这个用词值得盯。 前两批公告都写 "all GitHub Copilot experiences"，这批写 "most"。官方没解释差异，本站也不替它解释——但如果你在某些 Copilot 入口里还能看到已退役模型，这不是幻觉，建议按"该入口可能不在本批范围内"处理，同时别依赖它。

第三，本次最大的收获其实是一条方法论。 本站做内容核对时最容易犯的错，不是信了假消息，而是用"已核实的那一份"去否定"还没核实的那一份"。核实范围的边界不等于事实的边界——这条适用于所有"待核实"结论，不只是 Copilot。

判断建议：① 今天就 grep 一遍仓库与 CI 里的模型 ID，命中上表六个的立刻换；② 企业管理员用新的 PATCH 端点批量放行 GPT-6.1 Sol / GPT-6 Luna / Gemini 3.8 Flash / Grok 4.7，别等同事报"模型不见了"；③ 关注 2026-11-16 那批三个（Claude Opus 4.8 / Opus 5 / GPT-5.6 Terra），其中 Opus 4.8 对个人年付订阅者有豁免。

待核实

• "most" 与 "all" 的覆盖范围差异：官方未解释，本站不作推断。
• 2026-09-18 的原始公告条目：本批 10-19 条目写明"announced on September 18, 2026"，本站未取得 9-18 那份条目的原文（github.blog/changelog 列表为 JS 渲染），因此不对 9-18 公告的名单是否与 10-19 执行名单完全一致作断言。
• 模型策略 API 的 PATCH 请求体字段结构：官方 changelog 只给端点与"GET and PATCH"，未给 schema，需查 REST API 文档。
• Agent apps 层级具体指哪些 app：官方未枚举。
• 11-16 那批是否会有进一步调整：截至本次复核无新公告。

来源

• GitHub Copilot models deprecated on October 19, 2026（GitHub 官方 changelog，2026-10-19，一手核对）
• Copilot model policy API for enterprise, orgs, and teams（GitHub 官方 changelog，2026-10-19，一手核对）
• Upcoming deprecation of selected GitHub Copilot models in mid-November（GitHub 官方 changelog，2026-10-15）
• 延伸阅读：GitHub Copilot 工具卡、Copilot 11-16 退役与 HydraFusion Max 资讯、Gemini 3.8 Flash、Grok 4.7、GPT-6 Luna

口径说明：本文的退役名单、官方建议替代、"most GitHub Copilot experiences" 覆盖范围用词、"announced on September 18, 2026"、"No action is required to remove the deprecated models"、Enterprise 管理员需通过 model policies 放行替代模型的说明，以及模型策略 API 的四个端点路径与 GET/PATCH GA，均取自上述两条 GitHub 官方 changelog 原文，英文引号内为官方原句。2026-09-18 那份原始公告条目本站未取得原文，已列入待核实。