一边灰度 GPT-6.2 Astra，一边给 ChatGPT Classic 判了死缓

OpenAI 这两天在同时做两件事：一件是往前推——下一代模型 GPT-6.2 Astra 被发现已经进了灰度测试；一件是往后收——陪伴用户两年多的 ChatGPT Classic 桌面应用被正式通知停服。

一分钟速览

• 部分 Codex 用户的用量统计里出现了独立模型标识「gpt-6.2-astra」
• 有账户截图显示 Astra 已占其模型调用量的 19.8%，记录集中在 10 月 31 日
• OpenAI 官方 API 目录、更新日志、公告均未确认该型号
• ChatGPT Classic 将于 2027 年 1 月 30 日停止服务，聊天记录随账号迁移
• 新版桌面端把 Chat、ChatGPT Work、Codex 三合一，Classic 是被合并掉的那一支

灰度测试的证据链：用量统计里多了一行

最先发现异常的不是官方发布，而是用户的账单页面。多名 Codex 用户在使用量分析页面看到一个新条目，标识为「gpt-6.2-astra」，与现有的模型条目并列。TestingCatalog 汇总的截图里，有一个账户的该模型调用占比达到 19.8%，记录主要集中在 10 月 31 日。

这类现象在 OpenAI 的历史上并不罕见。灰度或 A/B 测试时，后台把一部分请求路由到新模型，前台界面仍显示旧名称，只有计费和统计系统会老老实实记下真实模型 ID。所以用量页面往往比发布公告更早泄密。

但也要注意边界：截至目前，OpenAI 的 API 模型目录、更新日志和公开公告都没有这个型号，官方也没有给发布时间。这意味着它可能只是内部评估用的小流量通道，也可能是在为正式发布做容量摸底，两者在数据上看起来一样。

为什么是 Codex 先看到

如果只选一个场景先上新模型，Codex 是最合理的选择。代码任务有客观的判定标准——能不能跑通、有没有通过测试、改动是否最小，这些都能自动验证，不需要人来主观打分。对模型团队来说，这是最容易拿到高质量信号的场景。

更现实的理由是算力。代码任务的上下文长、输出结构化程度高，对推理效率的要求和聊天完全不同。先在 Codex 上灰度，可以在相对可控的负载下观察新模型的稳定性、延迟和成本曲线，再决定要不要推到 ChatGPT 主站。

ChatGPT Classic 的退场：一次产品线收口

另一条消息就没那么兴奋了。OpenAI 已通知仍在使用 ChatGPT Classic 的用户：该旧版桌面应用将于 2027 年 1 月 30 日停止服务。用户打开应用会看到停用提示，点横幅可以跳到新版下载页；官方强调完整聊天记录会随账号迁移，老对话在新应用里能继续。

这其实是今年 7 月就埋下的伏笔。当时 OpenAI 把桌面版 Codex 升级成全新的 ChatGPT 桌面应用，里面塞进三块：Chat（聊天）、ChatGPT Work（工作）、Codex（编程），更新后保留原有 Codex 任务和项目，也可以在设置里选回 Codex 图标。原来的 ChatGPT 应用，就是被打包成 Classic 的那一个。

给了一年多的过渡期，说明 OpenAI 清楚桌面端是重度用户的入口，硬切会流失。但方向很明确：不再有”聊天应用”和”编程应用”的区分，只有一个按任务类型分区的统一客户端。

一进一退背后的产品逻辑

把两条消息放在一起看，OpenAI 正在收敛自己的入口。模型侧，Astra 通过灰度悄悄铺量，用真实流量验证能力；产品侧，把并行的多个客户端合并成一个，减少用户在选择上的摩擦。

这套打法和它在 10 月底把 Chat 与 Work 合并到同一页面的动作是一脉相承的。对用户来说，”我该打开哪个 App”这个问题正在被系统接管；对 OpenAI 来说，入口越少，模型路由和算力调度就越容易做，成本也越可控。

趋势洞察

第一，模型发布正在从”发布会模式”转向”渗透模式”。用户先在用，公告后发，甚至可能永远不发——版本号只出现在用量统计里。这对评测生态是个挑战：基准测试追不上灰度速度。

第二，客户端整合会成为行业常态。当模型能力足够泛化，按场景切分的独立 App 就是历史包袱，微软、谷歌都在做同样的收口。

第三，Classic 的停服日期定在 2027 年 1 月，留出的窗口比一般产品下线长得多。这既是给用户的缓冲，也说明 OpenAI 对旧客户端的维护成本还能承受一段时间。真正的信号不是哪天关，而是它已经不再迭代。