OpenAI 十月连发两张退役时间表：你的 vibe 项目还在调用明年 1 月、4 月就关掉的模型吗

一张时间表，两种截止日期

OpenAI 在 2026 年 10 月连发了两张模型退役时间表。第一张 dated 10 月 1 日：三个模型——gpt-5.1、gpt-5.3-codex、gpt-5.4-nano——将于 2027 年 4 月 1 日从 API 下线，官方给出的说法是“六个月通知期”；同一天，tts-1、tts-1-hd 和两个 gpt-4o-mini-tts 快照将于 2027 年 1 月 6 日下线，通知期“至少三个月”，统一指向 gpt-realtime-2.1-mini。第二张 dated 10 月 14 日：GPT-4o、GPT-4o mini、GPT-4.1、GPT-4.1 mini 的指定快照将于 2027 年 1 月 14 日下线，统一指向 gpt-6-luna。两张表加起来，2027 年 1 月就有两批模型要关，4 月还有一批。对于 vibe 项目来说，这不是远方的行业新闻：你项目里写死在配置、提示词、插件设置里的任何一个模型 ID，都可能正好在这张表上。

先把最容易误解的一点说清楚：被宣布“deprecated”不等于立刻不能用。按 OpenAI 自己在退役页上的定义，deprecation 是退役流程的开始，shutdown 才是访问终止的那一天。10 月 1 日的公告意味着你的调用今天还能跑，但 2027 年 1 月 6 日和 4 月 1 日这两个日期是硬截止——到了那天，调用会直接失败，而不是变慢或降级。把“还能跑”当成“不用管”，是这类新闻里最常见的误读。

逐条核对：你的项目到底中了哪一条

第一批，2027 年 1 月 6 日下线的是语音线：tts-1、tts-1-hd、gpt-4o-mini-tts-2025-03-20、gpt-4o-mini-tts-2025-12-15，替代品都是 gpt-realtime-2.1-mini。如果你做的是朗读、语音播报、语音助手类 vibe 项目，先去查的不是主模型，而是这四个语音 ID——它们最容易藏在某个不常看的配置文件里。第二批，2027 年 1 月 14 日下线的是 GPT-4 系列快照：gpt-4o-2024-08-06、gpt-4o-2024-11-20、gpt-4o-mini-2024-07-18、gpt-4.1-2025-04-14、gpt-4.1-mini-2025-04-14，替代品都是 gpt-6-luna；微调版本跟随其基础模型走同一张时间表，微调过的项目不能只改基础模型名就了事。第三批，2027 年 4 月 1 日下线：gpt-5.1（含快照 gpt-5.1-2025-11-13）和 gpt-5.3-codex 指向 gpt-6-sol，gpt-5.4-nano（含快照 gpt-5.4-nano-2026-03-17）指向 gpt-6-luna。

这里有一个专门针对 vibe coding 项目的陷阱：很多个人项目不是直接调 OpenAI API，而是通过某个封装、插件、网关或别人写好的模板调用模型。模型 ID 可能不在你的代码里，而在某个你很久没打开的后台设置、环境变量、第三方服务的模型选择器里。排查的方法不是凭记忆，而是把三类地方各 grep 一遍：代码仓库里的模型 ID 字符串、部署平台的环境变量、以及你实际在用的第三方工具的模型设置页。OpenAI 还提供了一个程序化核查口子：模型的 list 接口里有一个可选的 shutdown_date 字段，标明了每个模型已宣布的关停日期——把它写进你的健康检查里，比人工翻公告可靠。

换名字不是迁移：三个真正会翻车的地方

第一个翻车点是推理强度默认值变了。按第三方对这次退役的梳理，gpt-5.1 和 gpt-5.4-nano 默认不做推理（reasoning effort 为 none），而它们的替代品 gpt-6-sol 和 gpt-6-luna 默认是 medium。如果你只把模型 ID 一换就上线，同一个请求会突然开始产出推理 token——推理 token 按输出计费，账单和延迟都会变，而且输出风格也可能变。对 vibe 项目这意味着：换模型之后必须重新跑一遍你原来的代表性用例，对比输出质量、延迟和 token 消耗，而不是只看接口返回 200。

第二个翻车点是价格方向不一致。同样按上述梳理，gpt-5.1 换到 gpt-6-sol 时输入单价会上升，gpt-5.3-codex 换过去输出单价会下降约三成，gpt-5.4-nano 换到 gpt-6-luna 则会更便宜。GPT-4o 系列换到 gpt-6-luna 时，输入单价的落差更大。结论是：不能用“新模型更便宜”或“新模型更贵”一句话概括这次迁移，必须按你自己的输入输出比例和缓存比例单独算一笔账。特别是重度依赖缓存的 agent 循环，缓存读写的单价变化对总账的影响可能比输入单价更大。

第三个翻车点是“替代品”只是厂商推荐，不是等价保证。OpenAI 的退役页说得很直白：通知期的用途是让开发者“评估推荐的替代模型、测试应用行为、完成迁移”。评估和测试是你的工作，不是厂商的承诺。GPT-4o 的定位是通用旗舰，gpt-6-luna 的定位是“最高效的专注型高频任务模型”——定位措辞不同，本身就是一个信号：原来依赖 GPT-4o 通用能力的地方（比如开放式写作、复杂推理、长上下文理解），换过去之后要逐项回归，而不是默认通过。

为什么 OpenAI 敢在三个月内连关两批

我的判断是：这不是某一次清理，而是一条已经跑了大半年的流水线。同一张退役页上，2026 年 6 月 11 日就宣布了 GPT-5 和 o3 系列快照于 12 月 11 日下线，8 月 26 日宣布了转录模型于 2027 年 2 月 26 日下线，9 月 11 日宣布 gpt-5.4-cyber 于 10 月 1 日下线——注意最后这个只给了约 20 天，因为它属于有安全合规原因可加速的情形。10 月的这两张表只是这条流水线的最新两站。换句话说，模型退役在 OpenAI 这里已经从“偶发事件”变成了“常规运维”：你的项目应该默认每半年就会收到一次这样的通知，而不是每次都当成突发事故手忙脚乱。

还有一个值得注意的对比：OpenAI 给通用模型承诺至少六个月通知期，给专用变体至少三个月，给预览模型则可能只有两周左右。10 月 1 日的三个模型正好卡在六个月线上，10 月 14 日的 GPT-4 系列只给了约三个月——因为按 OpenAI 的分类口径，它们走的是另一条时间线。读公告时不要只看“给了几个月”，要看它落在哪个档位：档位决定了你下一次收到通知时可能只剩多少时间。对于 vibe 项目这种常常一个人维护、没有专职运维的情况，最务实的做法是把“模型退役”写进你自己的发布检查清单，而不是依赖厂商的邮件提醒——OpenAI 说它会邮件通知“正在使用该模型的客户”，但如果你是通过网关、封装服务调用的，邮件可能根本到不了你手里。

本周就能做完的迁移清单

第一步，48 小时内完成盘点：列出你项目里所有直接或间接调用的 OpenAI 模型 ID，标注每个 ID 的关停日期和推荐替代品，分不清的先标“待确认”而不是猜。第二步，按截止日期倒排：2027 年 1 月 6 日的语音线最先处理，因为它离今天最近，而且语音类功能一旦断线用户立刻能感知；1 月 14 日的 GPT-4 系列其次；4 月 1 日的 GPT-5 系列最后，但也要在 2026 年底前完成测试，别拖到 2027 年 3 月。第三步，每个替代品单独做一次回归：同一组提示词、同一组测试用例，对比输出、延迟、token 量和费用，记录推理强度默认值是否需要显式改回 none。第四步，把 shutdown_date 检查写进你的监控或健康检查，模型厂商下一次发公告时，你能在第一时间收到自己的告警，而不是在用户报错时才知道。第五步，微调项目单独列一支：确认微调版本是否跟随基础模型同一天关停，提前准备重新微调或改用基础模型加提示词的方案。

最后说一句对个人开发者不太中听但真实的话：模型 ID 写死在代码里，本质上是把产品的命运外包给了一张你控制不了的时间表。vibe 项目真正的护城河从来不是“用了哪个模型”，而是“换模型时要改几处、测几轮”。这轮退役潮过去之后，值得把模型 ID 抽成一个集中配置，加一层薄薄的抽象——下一次时间表再来的时候，你改的是一处配置和一轮测试，而不是满仓库 grep 和一场深夜抢修。

对照表：三批退役一次看清

为了排查时不用来回翻公告，这里把三批退役整理成一张对照表。第一批 2027 年 1 月 6 日：tts-1、tts-1-hd、gpt-4o-mini-tts-2025-03-20、gpt-4o-mini-tts-2025-12-15，全部指向 gpt-realtime-2.1-mini，公告日 2026 年 10 月 1 日。第二批 2027 年 1 月 14 日：gpt-4o-2024-08-06、gpt-4o-2024-11-20、gpt-4o-mini-2024-07-18、gpt-4.1-2025-04-14、gpt-4.1-mini-2025-04-14，全部指向 gpt-6-luna，公告日 2026 年 10 月 14 日，微调版本跟随基础模型同一天关停。第三批 2027 年 4 月 1 日：gpt-5.1 与快照 gpt-5.1-2025-11-13、gpt-5.3-codex 指向 gpt-6-sol，gpt-5.4-nano 与快照 gpt-5.4-nano-2026-03-17 指向 gpt-6-luna，公告日 2026 年 10 月 1 日。注意一个细节：同一批里不同模型的替代品并不相同，gpt-5.3-codex 和 gpt-5.1 虽然都指向 gpt-6-sol，但它们原来的用途不同——一个是代码专用变体，一个是通用模型——迁移测试的重点也应该不同：代码变体重点测代码任务，通用模型重点测对话与推理任务，不能拿同一套测试用例糊弄过去。

另外还有两条容易被忽略的附带信息。第一，OpenAI 的退役页同时说明，开发者在某些情况下可以向销售团队咨询“在关停日期之后继续使用专用容量”的可能性——这对个人 vibe 项目基本不适用，但对确实有大客户、不能断线的项目来说，是一条值得提前问的路，而不是等到 12 月才去打听。第二，退役页明确区分了三个词：deprecated（已宣布退役，流程已开始）、shutdown（访问终止）、legacy（不再更新，但尚未宣布退役）。你的项目依赖清单里应该同时有三列：已退役且有截止日期的、已标记 legacy 但尚未给日期的、以及当前主推的。只盯着第一列，等于只看已经着火的房间；第二列才是下一轮公告的候选名单。

vibe 项目最常见的五条调用链，一个一个查

第一条是直连调用：你的后端代码里直接写了模型 ID，这是最容易查的，grep 一下仓库就能列全。第二条是前端或移动端里的写死配置：有些 vibe 项目为了省事，把模型 ID 写进了前端常量、移动端配置文件，甚至写进了提示词模板的注释里——这些地方 grep 代码仓库时如果只搜后端目录就会漏掉。第三条是部署平台的环境变量：Vercel、Railway、Fly.io、Cloudflare Workers 这类平台上的环境变量面板，模型 ID 可能躺在那里，而不在仓库里；排查时要把每个部署平台的变量列表导出来对一遍。第四条是第三方封装与网关：你用的某个 AI 网关、某个“一次接入多模型”的服务，它的后台可能有自己的模型映射——你传给它的是一个别名，它再翻译成真实模型 ID，这种情况下你要在网关后台确认它映射到的是不是已退役的 ID。第五条是 agent 工具自身的默认模型：Claude Code、Codex、Copilot 这类工具的默认模型会随版本滚动，你的项目文档、演示视频、README 里写着的“默认用某某模型”可能已经过时——文档里的模型名虽然不直接导致线上故障，但会让新接手的人（包括三个月后的你自己）踩进同一个坑。

查完之后，建议把结果写成一张只有你自己看得懂也够用的依赖表，列的字段不用多：调用位置、模型 ID、关停日期、推荐替代品、测试状态、负责人（对个人项目来说负责人就是你自己，写上是为了提醒自己“这事没人会替你做”）。这张表以后每次收到模型厂商的公告时拿出来打勾，而不是每次都从零开始 grep。很多 vibe 项目的“技术债”不是代码写得丑，而是这种“只有一次性的排查”——做完一次就扔，下次公告来了又要重做一遍。

如果错过了截止日期，会发生什么

最直接的后果是调用失败：到了关停日期，模型端点不再接受该 ID 的请求，你的用户会看到功能报错，而不是“效果变差”。对语音类功能来说尤其明显：朗读按钮一点就报错，用户会立刻认为是你的产品坏了，而不是某个上游模型退役了。其次是连锁反应：如果你的 agent 流程里某一步依赖已退役模型，整个流程会在中途断掉，而断掉的位置可能不是第一步——比如先跑摘要、再跑分类、最后跑生成，摘要用的模型没事，分类用的模型退役了，错误会出现在流程中间，排查时容易误判为“摘要出了问题”。第三是账单与配额上的意外：如果替代品的默认推理强度更高，迁移后即使功能正常，单次请求的 token 消耗也可能上升，月底账单会比预期高出一截；这就是为什么迁移测试里必须包含费用对比，而不是只看功能对不对。

还有一种更隐蔽的后果：缓存与快照失效。如果你对某些模型的输出做了缓存、做了评估集、做了提示词版本管理，换模型之后这些历史资产的参考价值会打折——旧模型的输出不能直接当成新模型的“标准答案”来回归对比。你需要为新模型重新建立一小套“黄金用例”：十到二十个你最在意的真实输入，人工确认新模型的输出是否可接受，然后把这套用例固化下来，作为以后每次换模型的回归基线。这套用例不需要大，但必须是真实的、来自真实用户的输入，而不是你随手编的测试句。

常见问题

问：我只是个小项目，用户不多，能不能等到 2027 年 3 月再处理 4 月那批？答：可以拖，但别拖到最后一周。迁移测试本身不需要很久，真正花时间的是“发现所有调用位置”和“等第三方网关更新映射”——这两件事都有排队时间，最后一周才开始，等于把主动权交给了别人的排期。问：替代品的价格以后还会变吗？答：会。模型定价本身就是会调整的，迁移时算的那笔账只是当时的快照，建议在依赖表里记下你算账时的单价和日期，下次复核时有个对照。问：我用的不是 OpenAI 官方 API，而是某个第三方封装，还需要管这事吗？答：更需要管。因为封装服务商的映射更新时间不由你控制，你要做的是两件事：向服务商确认它的映射时间表，以及给自己的项目准备一个“万一服务商没及时更新”的兜底——比如把模型 ID 抽成配置，服务商一更新你就能立刻切换，而不是改代码重新部署。

再提醒一次最关键的顺序：先盘点、再按 1 月 6 日、1 月 14 日、4 月 1 日的顺序迁移、每个替代品单独回归、最后把关停日期检查写进监控。模型退役不会因为你没看到公告就推迟，截止日期也不会因为你的项目还小就网开一面。把这轮迁移做完之后，你的项目会多出两样之前没有的东西：一张真实的模型依赖表，和一套可复用的黄金测试用例。这两样东西的价值不在这轮迁移里，而在下一轮公告来的时候——到那时你会发现，别人还在满仓库 grep，你只需要打开表、跑一轮测试、改一处配置。这种差距，就是个人项目在模型快速迭代的年代里活下去的方式。