两周前，我们发了一篇《GPT 账号降智自救记录》，介绍怎么用 sub2api 的分叉版本、打开「Excel／BPS 协议」，把降智的账号救回来。
今天我们收回那篇文章的建议。
更正说明： 9 月 30 日那篇文章推荐的 sub2api 分叉版、Excel／BPS 通道，以及让 Codex 连接自建网关的配置，我们不再推荐，也请不要照做。文章发出的当天晚上，这个账号经 BPS 发出的请求就开始被 OpenAI 以「usage policy」为由返回 403；之后两周，这个曾经接过反代的账号反复出现降智迹象，换回官方客户端也一样。完整经过见第一、二节。
这两周，我们一边测试自己的两个账号，一边把社区里 sub2api、CLIProxyAPI（CPA）用户的报告翻了一遍。结论先放在前面：
- 不要把订阅接进任何「订阅转 API」的反代。 也就是把订阅登录凭据交给网关，再转成接口给别的程序、别的人调用：sub2api、CLIProxyAPI、号池、拼车都是这一类；cc-switch 的「订阅账号 + 本地路由」用法也是。OpenAI 已表示，将订阅转换成 API 流量后再向许多用户分发或共享，会被反欺诈系统标记。被标记之后具体会怎样，OpenAI 没有说；但社区里很多人报告的，不是封号，而是悄悄降智：往往没有明确提示，模型照常回复，只是变笨。
- 在我们的记录里，降智跟着账号走，不跟着工具走。 那个接过反代的账号出问题后，改用官方 Codex 程序直连，照样答错；换 IP、换模型都没有带来改善。从没接过反代的另一个账号，同一台电脑、同一条网络，在我们测过的时间里大多正常。
- 第三方 Agent 用订阅登录，OpenAI 说可以；我们仍然建议别这么用。 OpenClaw、OpenCode 这类工具，我们建议改用 API Key 按量计费，把订阅只留给官方客户端。
- 想要更好的界面、多账号管理，选「只启动官方 Codex、不在中间转发请求」的工具，比如 Orca。
- 已经出问题：先停掉所有反代，退出登录，然后静置。 测试是否恢复时，要「预热、等待、连续多题」，否则很容易被「假恢复」骗过去。
示意图：同一份订阅，直连与绕路。中间环节越多，出问题时越难说清是哪一环。
一、先认错：我们两周前的建议是错的
9 月 30 日那篇文章的核心，是让请求改走 OpenAI 为「ChatGPT for Excel」准备的接口（BPS），绕开降智的原生通道。当天中午，直接发往 BPS 的测试请求确实答对了糖果题，画出来的鹈鹕也像样。但效果并不稳定：当天下午，经同一通道运行的 Codex 命令行连续三次答错。
更大的问题出在当天傍晚。18:33 起，OpenAI 对这个账号的 BPS 请求返回 403，原文是 This request was blocked by our usage policy.（这个请求被我们的使用政策拦截）。收到 403 后，网关自动关闭了 BPS，此后经这个网关发出的请求，全部回到了原来那条降智的通道；随后的自动恢复探测连续失败了大约 30 次，到深夜依然是 403。
一条靠「以另一个客户端的身份发请求」换来的通道，只维持了几个小时。 那篇文章说过，403 是这个通道上风险的第一个信号——它当天就来了。需要说明的是：我们确认的是 BPS 调用被使用政策拦截，没有证据表明整个账号被封禁，也不能确认这次 403 和之后的降智有因果关系。
为什么「Excel／BPS 救账号」这条路不要走
如果你看过那篇文章，想照着试试，请先看完这几条：
- 它本质上是伪装。 BPS 是 OpenAI 给「ChatGPT for Excel」这个第一方产品准备的接口。把 Codex 的请求包装成 Excel 插件的调用发过去，就是让一个客户端冒充另一个客户端——这类做法，很容易被视为规避保护措施。
- 它当天就被拦截了。 我们的账号在启用 BPS 的当天晚上就收到 403「usage policy」。提供 BPS 功能的那个 sub2api 分叉，自己的管理界面里就有一个「BPS 403疑似被封」的标签；它的 issue 讨论里，也有用户报告部分账号调用 BPS 一直返回同样的 403。
- 它不一定有效。 同一天下午，经 BPS 运行的 Codex 命令行，在我们的测试里连续三次答错。
- 旧文介绍的，是经反代改走 BPS 的做法。 按那套配置，要先把订阅接进 sub2api 网关，再让 Codex 连接这个网关——也就是这篇文章劝你不要做的那件事。
如果你已经照那篇文章配置过，建议这样撤回：
- 在 sub2api 分叉的账号设置里关闭「Excel／BPS 协议」，停用网关里的这个订阅账号，把订阅从网关里删除。
- 先备份 Codex 的配置目录（默认是
~/.codex；设置过CODEX_HOME的，检查对应目录），再删掉指向自建网关的 provider 和 profile 配置（新版本的 profile 可能在单独的文件里），撤销顶层的model_provider和启动参数里的网关地址，并清除网关专用的 Key 环境变量。 - 在同一个配置目录下运行
codex logout，再用codex login以 ChatGPT 账号重新登录，开一个新会话。此后只用官方默认的连接方式。 - 按第八节的方法静置和测试。
二、我们自己的账本：两个账号，两周数据
为了不再凭感觉判断，我们在手动测试之外，又写了一个自动探针：用官方 codex 命令行程序定时问账号糖果题（题目原文见上一篇）。目前账号 A 每小时一次，账号 B 每天两次；早期还有一部分测试是在反代上做的。
我们把 21 定为通过答案。健康时，账号通常答 21，推理 token 多在 800–1,900；出问题时，多半答 29，推理 token 多在 200–600，而且经常正好停在 516。两组 token 数有重叠，不能单独当作判据。这道题本身也有歧义：如果理解成「不能按形状挑、只能盲摸」，29 也说得通。所以单看一次答案，证明不了降智；我们看的是同一道题、同一套设置下，同一个账号前后表现的突变，以及两个账号之间的差别。
账号 A 就是接过反代的那个；账号 B 是另一个订阅，从来没有接入过任何反代。
数据：VilaVPN 内部测试。单一题目、两个账号，属于小样本观察，不代表 OpenAI 的官方结论。
几个关键观察：
- 接过反代的账号，回到官方客户端也一样。 10 月 9 日 14:05，反代上的探针再次出现异常；当天约 18:30 起，账号 A 不经任何反代、直接用官方
codex程序答题，也开始答 29，最后一次失败记录在 10 月 12 日 22:22。 - 同一时间，没接过反代的账号是正常的。 10 月 11 日凌晨，账号 B 在同一台电脑、同一条网络、同一个模型下，严格测试 12 题全对，推理 token 800–1,445；几分钟前，账号 A 用同样的方法连错 6 题。
- 换 IP 没有改善。 9 月 30 日在反代的原生通道上做过对照：原出口 0/10，换到 WARP 后 2/10（只有换 IP 后的头两次答对），换回原出口 0/5，轮换 IPv6 地址池 0/5。
- 换模型没有改善。 10 月 10 日凌晨，账号 A 用官方程序直连，依次换了 7 个模型、都开最高推理强度，21 次全错；同一时间账号 B 答对。
- 切断反代也没有立刻好转。 10 月 10 日凌晨，我们关掉反代、退出账号 A 的所有登录。之后将近三天，它依然答错。10 月 12 日深夜我们停掉了所有测试，让账号完全静置。13 日下午再测，先在一个较轻的模型上 12 题全对；参考模型的测试一度因容量报错中断，17:27–17:55 也完成了 12 题全对。截至 10 月 14 日 16:45，之后的测试日志没有再出现答错；容量报错另行记录。停反代、退出登录、停测这几件事叠在一起，我们无法确定是哪一项起了作用。
也要把不利于我们结论的数据摆出来：账号 B 在 10 月 9 日傍晚也短暂异常过几个小时，和账号 A 同时；两个账号也都偶尔遇到 “Selected model is at capacity”。所以并非所有异常都能归因于反代，OpenAI 服务端本身的状态也在变化。我们能说的是：接过反代的那个账号，一出问题就是好几天，官方客户端也救不回来；没接过反代的账号，那次异常几个小时就恢复了。
三、不只 sub2api：社区里的 CPA 报告，以及 cc-switch
我们自己用过 sub2api，也用过 CLIProxyAPI，但在用 CLIProxyAPI 的那段时间没有做系统测试；cc-switch 我们没有用过。社区里的报告讲的是相似的故事。以下均为用户自述，外界无法核验；「答错题」和「容量报错」是两种不同的症状，表中分开写：
| 日期 | 来源 | 工具 | 用户描述 | 后来 |
|---|---|---|---|---|
| 2026-06-20 | CLIProxyAPI 讨论区 | CPA、OpenCode、Codex SDK | 作者称同一账号、无额外网络代理：只有官方 Codex CLI 答对 21，其余答 29，推理卡在 516 | 单人测试；同帖也有人得出不同结果 |
| 2026-09-13 | LINUX DO | 先 sub2api，后 Hermes | 鹈鹕画得「无敌抽象」；官方 Codex 客户端约一小时未复现，回到 Hermes 后再次出现 | 未提供长期对照 |
| 2026-09-17 | LINUX DO | CPA，后改用 CC Switch 管理登录 | 一周多的容量报错加质量问题；停用 CPA、退出会话后缓解。两个账号重新接入 CPA 高并发使用后，又出现容量报错 | 不接 CPA 的账号保持正常 |
| 2026-09-17 | 同一帖 #11 | sub2api，自用、并发 1 | 只给自己用，仍出现异常，作者怀疑与 sub2api 有关 | 发帖时未恢复 |
| 2026-09-18 | 同一帖 #81 | CPA | 退出登录、关闭 CPA | 等待 24 小时以上后恢复使用，未说明是否做过对照测试 |
| 2026-10-07（10-09 更新） | LINUX DO | CPA | 降智超过一个月；停用 CPA、静置两天后好转；9 日重新接入 CPA 再测出现异常，但作者后来表示可能前一天已异常，当晚网页测试又正常 | 原因未确定 |
这几个工具做的事情不完全一样，判断时要看你实际怎么用：
- sub2api： 自我定位是「订阅配额分发」网关，中文介绍直接写着「支持拼车共享」。它的 README 自己就警告：使用本项目可能违反上游服务条款，作者不对封号负责。
- CLIProxyAPI（CPA）： 把 Codex 等工具的订阅登录包装成兼容 OpenAI 格式的 API。按我们核对的版本，它的默认配置在转发 Codex 请求时，会设置官方 Codex 风格的 User-Agent 和 Originator 请求头。这是对实现行为的描述，不代表 OpenAI 已认定其违规。
- cc-switch： 本职是帮你切换 Claude Code、Codex 等工具的配置文件；只做这件事，或者只给 API Key 做路由时，它不是订阅反代。但它的 Accounts（Beta）功能可以登录 ChatGPT 账号，再通过本地路由把订阅当作 provider 接给其他工具——这就进入了「订阅转接口」的范围。它的 README 也写着：在官方客户端之外使用订阅，可能违反服务条款，请自行评估风险。
公平地说，也有人用 CPA 很久一切正常。但问题在于：你没法提前知道自己是哪一种；而出问题时，往往也没有明确的提示告诉你。
四、为什么是「悄悄」降智
OpenAI 的立场其实写得很清楚。
2026 年 8 月 21 日，Codex 负责人 Tibo Sottiaux 在 X 上写道：他们调查用户反映的额度异常时发现，很多受影响的用户在用 sub2api；把订阅转换成 API 流量、再供许多用户使用或共享，不是 OpenAI 支持的用法，这类用法会被反欺诈系统标记。两天后他又回复了一句：“We don’t support sub2api.” OpenAI 的使用条款也禁止共享账号、禁止规避速率限制和其他保护措施。
被标记之后会怎样，OpenAI 没有公开，也从未确认存在「悄悄降智」。它的帮助中心只说过，账号若出现违规迹象或可疑信号，模型访问可能被临时限制。有用户在 OpenAI 的 Codex 仓库贴出客服回复：「某些模型或功能的访问可能被临时限制」，而他说产品界面上并没有提示。
所以「降智」最折磨人的地方在于：它不报错。 模型照常回复，只是推理变浅、答案变差。你很难分清是模型今天状态不好、服务器太忙，还是账号已经被标记。
类似下面这样的帖子，这几天在 X 上随处可见：
Codex 又又又崩了？
这几天一直没完没了地重连，任务跑一半直接断掉，然后卡在 Reconnecting。
一直重复这个循环，根本没法正常干活。
— Vincent (@Vincent_AINotes) 2026 年 10 月 14 日
帖子里的截图，是一连串 “Selected model is at capacity”。我们不知道这位用户的账号状态，也不知道他是否用过任何反代；而且他发帖的 10 月 13 日和 14 日，OpenAI 状态页上都记录了 Codex 性能下降的事故，这些现象和服务故障相符；我们不能据此判断他遇到问题的具体原因，更不能判断他的账号状态。但这正是问题所在：作为用户，从屏幕上很难分清「服务器在出故障」和「账号被区别对待」。遇到这种情况，大多数人的反应都是「Codex 又崩了」，等一等、重试一下。服务器故障时，这样做没错；可如果哪天是账号被标记了，用户从屏幕上同样看不出来。
可以确定的是，反代的流量——多个下游、全天候、高并发、改写过的请求头——和一个人在终端里写代码，看起来完全不同。
五、第三方 Agent：官方允许，不等于稳妥
这一节要说得更小心一些，因为 OpenAI 的公开态度是允许的。
同一篇 X 发文里，Tibo 也写道：通过「使用 ChatGPT 登录」（Sign in with ChatGPT），在官方客户端或 Pi、OpenCode 等开源客户端里用自己的订阅，完全没问题。OpenAI 也为第三方应用提供了正式的订阅登录方式；OpenClaw 的文档同样写着支持 ChatGPT／Codex 订阅登录。我们不声称这些工具会被封号或惩罚，也没有测试过 OpenClaw、OpenCode 的当前版本。
但我们仍然建议：订阅只留给官方 Codex，OpenClaw、OpenCode 这类工具改用 API Key。这是我们的选择，理由有三条：
- 同样叫「用 ChatGPT 登录」，背后可能是两种做法。 一种是 OpenAI 为第三方应用提供的正式登录流程，应用会以自己的身份出现；另一种是直接借用 Codex 自己的登录凭据，再让请求看起来像官方客户端发出的。作为用户，你通常看不出手里的工具走的是哪一种。
- 出了问题，变量太多。 上面那组 6 月的测试里，同一个账号只有官方 CLI 答对；9 月也有用户报告，官方客户端约一小时没问题，换回第三方 Agent 就复现。这些是个人观察，不是定论；但一旦出问题，你很难分清是工具的原因，还是账号已经被标记。
- 使用模式更像「服务」，而不是「一个人」。 OpenClaw 这类常驻助手接在聊天软件上，带定时任务、全天在线。这和账号共享不是一回事，但它产生的流量，离「一个人在终端里写代码」更远。这一条是我们的推测。
API Key 按量计费，本来就是为程序调用设计的：费用取决于实际用量，使用政策和账号安全规则同样要遵守，但它避开了「订阅转接口」的政策争议。我们自己也已经关掉了反代。
六、官方客户端也会降智——但它是最干净的基线
用官方客户端，不等于永远不会降智。OpenAI 的 Codex 仓库里，就有用户报告：用官方桌面版请求 gpt-6-astra，返回的却是 gpt-5.6-luna。我们的账号 B 也短暂异常过，也遇到过容量报错；官方客户端用户报告容量报错的也不少。
但官方客户端有一个反代给不了的东西：变量最少。 出了问题，你知道不是工具改写了请求，不是网关替别人跑了流量，也不是什么插件冒充了谁。你可以用 /feedback 提交带编号的反馈，OpenAI 能对照后台排查；可以拿同一道题去对照另一个账号。反代一旦介入，这一切都说不清了。
七、想要更好用？选「只启动官方 Codex」的工具，比如 Orca
很多人用反代或第三方工具，并不是想薅羊毛，只是想要更好的界面、并行任务和多账号切换。这些需求，不一定要经过反代。
示意图：三种用法的风险对比。订阅留给官方客户端，第三方工具用 API Key。
我们自己在用的是 Orca（开源，GitHub，MIT 许可）。它是一个桌面端的 Agent 工作台，按官方文档的说法，它做的事情是启动你电脑上已经安装好的官方 codex 程序，放在终端面板里运行：
- 不做模型请求的反代。 在我们核对的 Codex 终端模式里，Orca 不改写接口地址，也不在中间转发模型请求。
- 登录交给 Codex 自己。 默认账号直接使用你原来的
~/.codex；额外的账号各有一个独立的目录（CODEX_HOME），用官方的codex login登录，凭据由 Codex 自己保存和刷新。 - 多账号、多任务。 并行跑多个任务、在账号之间切换，都不需要反代。
我们的探针，就是用 Orca 为账号 A 准备的账号目录，加上原版 codex 程序运行的（在 Orca 之外调用）。也要如实说明：Orca 会管理账号目录和配置，并用你的登录凭据向 ChatGPT 查询用量，显示在它的额度面板上，所以不能说它完全不接触登录。它是第三方软件，请保持更新、自行评估。VilaVPN 与 Orca 没有任何合作关系。
不管用什么工具，可以用下面五个问题快速判断它是不是在做「订阅反代」：
- 它运行的是官方
codex程序本身，并且没有被改成连接第三方网关吗？是，风险最低。 - 它要你把接口地址改成第三方网关或本地端口吗？配的是订阅登录而不是官方 API Key，那就是反代。
- 它要你上传、导入或共享登录凭据（如
auth.json）吗？要，不要用。 - 它的介绍里有「拼车」「号池」「共享」「订阅转 API」吗？有，不要用。
- 它会让请求「看起来像官方客户端」吗？会，不要用。
八、已经出问题了，怎么办
以下是我们的实际做法，不保证对每个账号都有效：
- 立刻停掉所有反代和自动化流量。 把订阅从所有网关、号池和第三方工具里撤出来，在各个工具里分别退出登录或撤销授权；Codex 命令行可以用
codex logout。ChatGPT 网页「设置 → 安全」里的「退出所有设备」可以清理网页会话，但不保证 Codex 命令行或第三方保存的凭据也一起失效。之后只在官方客户端重新登录。 - 静置。 我们的账号在停掉测试、静置到第二天下午后恢复；社区里也有人在 24 小时以上之后恢复使用。恢复时间因人而异，也有人始终没有恢复。
- 用正确的方法测试，别被「假恢复」骗了。 我们踩过两个坑：
- 关掉 Codex 的记忆（memories）功能再测。 我们遇到过模型从旧记忆里读到上次的答案 21，造成假通过。
- 先问一题预热，等一段时间，再连续多问几题。 降智的账号在闲置之后，头一两次请求经常是正常的：我们见过一次答对，六分钟后连续三次答错。我们现在的做法是：预热一题，等 6 分钟，再每隔 60 秒问一题、最多 12 题，任何一题答错或报错都算不通过。这只是我们的探针，不是官方诊断方法。
- 换 IP、换模型、开快速模式，在我们的测试里都没有带来稳定改善（换 IP 和快速模式是在反代上测的，换模型是在官方程序直连下测的）。
- 用
/feedback提交反馈，留下编号，方便 OpenAI 对照后台排查。 - 不要「换一个反代」或「换一种伪装」。 我们两周前就是这么做的，结果是当天晚上的 403。
九、这和 VPN 有什么关系
我们是一家 VPN 公司，连写三篇 GPT 降智，是因为太多人把降智怪到 IP 头上，而我们自己也在这件事上交了学费。
我们的立场没有变：网络的归网络，账号的归账号。 在我们这次的测试里，换 IP 没有带来稳定改善，这和前两篇整理的社区证据一致；而频繁更换登录地点，反而可能触发 OpenAI 的可疑活动提醒。VilaVPN 提供 IPLC／IEPL 专线连接和晚高峰优化，实际延迟和抖动请以你自己的设备、线路和使用时段测试为准。账号层面的限制由服务方判定，我们解不了，也不承诺「换线路治降智」。也请先确认你所在的地区在服务的支持范围内，并遵守其条款和当地规定。
如果你正在排查类似问题，欢迎联系我们交流；如果你想检验一条网络在晚高峰的真实表现，可以来了解并尝试 VilaVPN。
订阅是给一个人用的。把它交给反代，省下的是一点钱，押上的是你自己的账号。
资料核对日期：2026 年 10 月 14 日。文中社区报告均为用户自述，引用时已注明；OpenAI 官方表态以原文链接为准，OpenAI 从未确认存在「悄悄降智」。我们的数据来自两个账号、单一题目的测试，属于小样本观察，不能证明反代导致了异常。sub2api、CLIProxyAPI、cc-switch、OpenClaw、OpenCode、Orca 均为第三方软件，与 OpenAI 和 VilaVPN 无关。本文为 VilaVPN 产品博客，包含产品介绍。
