最近怒充 200 美元开通了 GPT Pro 20x ，本以为能够爽用 Pro 模型，结果天塌了。
选择 Pro 模型的时候，回复贼快，但回答质量总觉得还不如 Instant。
于是一问，告诉我说是 GPT-5.5-mini。
GPT-5.5-mini 又是什么模型呢？这个模型甚至都甚至不会出现在模型选择器里。OpenAI 明确称它为 fallback model（备用模型），用户达到 GPT-5.5 Instant / Auto 的使用额度后，会自动切换到 Mini。
GPT-5.5 Instant 就是在模型选择器中选择 GPT-5.5，然后把思考等级选在最低的极速一档所使用的模型。
而 GPT-5.5-mini 就是用到 GPT-5.5 Instant 都不能用的时候才会给你的低保模型。
所以这就很让人崩溃，从 GPT-5.6-Pro 直接跌落 GPT-5.5-mini ，瞬间感觉 200 美元亏了没有 100 也有 80。
我调研了一下，这种情况并不罕见。
尤其在中文社区里，甚至还挺普遍。
OpenAI 官方对这种情况并没有给出特别明确的说法，所以各种民间解释众说纷纭。
发生这种情况的原因有诸多推测，有人说是防蒸馏，有人说是 IP 不纯净，有人说是账号被风控了，有人说要清浏览器缓存，有人说是相同问题问太多了，有人说是 Pro 用太多了触发限额……
甚至怎么判断是不是真的降智了都是各执一词，有人说直接问模型就行，有人说要骗模型供出 Juice 值，有人说要问知识库时间，有的人坚信其实没降智只是显示错误……
总之就是众说纷纭。
降智的具体原因我还真说不好，我只能给出我的账号从被降智到恢复这段时间我自己的观察。
但怎么判断是不是降智了，我还是能提供一个置信度更高一些的方案的。
甚至还开发了一个浏览器插件。
插件我们后面再说，先说不用插件怎么判断。
实际上当我们使用 ChatGPT 聊天的时候，请求的是什么模型和后端路由解析到的模型都是有记录的（虽然官方并没有公开承诺）。
所以我们直接去查看响应的元数据，怎么都比跟大模型问答要靠谱的多。
说一个最简单的方案，针对已经完成的一轮对话，我们用 Chrome 浏览器打开它。
比如，这是一个我还在降智期时选择 Pro 模型的提问。
按 F12，切换到 Network，勾选 Preserve log，按箭头处的按钮清空日志，然后刷新页面。
在下面筛选 backend-api/conversation/ ，找到当前会话的 conversation_id。
选中它，点击右侧的 Response 标签，往下翻，你就可以找到 default_model_slug ，这就是当时请求的默认模型：gpt-5-6-pro。
继续往下翻，就可以找到 resolved_model_slug ，这个就是后端路由实际解析到的模型：gpt-5-5-mini。
除了请求模型和响应模型以外，其实里面还有一些其他的信息，比如说思考等级。
这里有一个很值得吐槽的地方，ChatGPT 的思考等级里，中是 standard ，高是 extended ，极高则是 max 。
一家子都出来 3 种极高了。
其他的内容可以自己翻，我就不多说了。
虽然 OpenAI 官方正式文档并没有公开承诺说 resolved_model_slug 是一个具备正式定义的表示实际执行全部推理计算的模型名称的字段，但置信度还是相当高的。
我们再回来验证这个已经坚持跑了 40 多分钟的中国短剧女演员。
resolved_model_slug 是 gpt-5-6-pro 。
以上这个查看已完成响应元数据的方案是操作起来最简单的方案，实际上还有一些其他的方案，比如在请求的时候捕捉模型的实时响应、导出 HAR 文件等等。
你可以直接让 Codex 控制浏览器进行测试并输出结果。
我这个插件就是通过上面说的方式把响应模型直接提取出来。
比如我选择实时请求，要求 ChatGPT 使用 5.5 高模型，在200字内证明√2是无理数。
当这个请求发出去，思考一阵，就得到了模型的响应。
再试一个 GPT-5.6-Sol 极高，如果你不喜欢插件在右下角占的地方这么大，又不想完全隐藏它，可以使用这个精简模式。
请求模型 gpt-5-6-thinking，响应路由 gpt-5-6-thinking 。
刷新一下，使用会话重载识别，同样可以识别到 gpt-5-6-thinking。
因为是重载已经完成的老对话，所以识别不到请求模型。
顺便，前面说的这种 GPT Pro 账号的降智，通常表现为只有 Pro 档明显异常，其他档位包括 GPT‑5.6 Sol 均表现正常。
除了这种 Pro 账号的降智，还有一种经典的降智，至少在 o3 以前的版本就已经存在了，这种降智情况通常被认为跟 IP 的风险度有比较直接的关系。
而这个 IP 风险度，社区一般使用 PoW 难度来评估。
PoW（Proof of Work，工作量证明）是一个从区块链领域化用过来的概念。核心思想是让参与者必须完成一项需要大量尝试的计算工作，才能获得记账资格，但其他人验证这个结果却非常容易。
ChatGPT 网页端发送消息前，会从 chat-requirements 接口取得 seed 和 proofofwork.difficulty 两个值。
其中 seed 就相当于题目，浏览器拿到这个题目以后，就开始基于这个题目大量尝试计算。注意这里的计算并非是我们上学时候参加考试那样算出一个正确答案，而是通过大量的随机计算尝试找到能命中某一区间范围的答案。
而 proofofwork.difficulty 则相当于开卷的答案合格范围，浏览器在每次随机计算后，都会跟这个值比较以查看自己算的对不对。这个值实际上是一个哈希命中阈值（其实在区块链的概念里对应Target而不是Difficulty，这两个是反的），这个命中阈值越大，哈希计算时就越容易命中，实际需要的计算量就越小；反之就越难命中，实际需要的计算量就越大。
浏览器通过大量的随机计算找到符合要求的答案后，把整个卷子封装成 Proof Token 随请求发送给 OpenAI 的服务器，服务器只需要计算一次验证，就能够判断它的答案对不对。
以上就是 PoW 难度这个概念的大概逻辑。
不过 OpenAI 官方从来没有披露过 POW 难度和模型路由之间存在什么关系，实际上，似乎也并没有完成或者在期限内完成 PoW 挑战就会被路由到正常模型，没有完成就会被降级这样的规则，但ChatGPT 会检测“类似自动化或异常行为”的流量并进行相关限制。
所以按我理解，这个逻辑有可能是：
PoW 挑战本身是为了应对异常自动化流量的，当发现有大量的共享 IP 的自动化代理访问的时候，就会分配较小的 proofofwork.difficulty 值，增加完成 PoW 挑战的难度。类似于我发现你们这些机器人要搞事情，那你们先给我去挖一会矿，从而对这些规模化的异常自动化流量产生一定消耗，达到一定程度上反制的效果，同时也不会给他们路由到正常的模型。而一旦普通用户误用了类似的网络环境，也会被识别为异常的自动化流量，被分配到高难度的 PoW 挑战，同时模型的使用表现就会是降智。
所以评估 PoW 难度一定程度上能作为模型降智的反馈。
当然，上面的只是我个人觉得比较合理的推测。至于实际到底是什么原因，官方没有披露，所以没人知道真相。但不管怎么说，反正我在插件上把 PoW 难度 proofofwork.difficulty 这个值（十六进制）获取出来了。
通常按照社区的建议，把这个值转换成十进制以后，数字位数最好在五位数以上，这样相对就比较安全。
插件已上传 Chrome 商店，现在已经上架了：
可以先在 GitHub 下载，手动加载。
https://github.com/Liu-Bot24/chatgpt-route-inspector
至于我自己的账号降智的原因和恢复的方法，我也分享一下。
仅代表个人经验，不作为标准答案。
实际上还是跟 IP 有关，但不是使用时的 IP，而是登录的 IP。
在 ChatGPT 的设置里，找到账户安全与登录，然后在右边可以看到活跃会话。
手机 APP 也可以在相同的位置找到，如果你绑定了邮箱，其实也会收到邮件。
点开它可以看到所有登录这个账号的设备和相应的登录时间与登录 IP 对应的地址。
OpenAI 最新官方说明明确表示：多会话、异常登录位置、扩展或自动化工具可能触发功能限制和“临时降级”。
我正好就命中了这一条，还是 Codex 排查出来的。
实际上我自己都没有想到，登录的出口会落在不同的国家。
因为原因其实挺冷门的，是一个规则配置问题，也分享下吧，算是吃一堑长到的经验。
我自己甚至完全没有往这方面想，因为从每天的流量上来看，我在 chatgpt.com 和 openai.com 的全部流量都是美国家宽（伪）出口承接。
（所以受限的原因不仅仅是使用的时候的 IP 纯净度。）
登录地址怎么就会漂移呢？后面继续排查才发现原因。
我有一台 Mac mini，搭配 Surge 实现了软路由的功能。
Surge 作为网关的时候，会默认启动虚拟网关的功能，自动开启 Fake IP DNS 服务。
所以在 DNS 查询的时候，虚拟网关的代理 DNS 会返回 198.18.X.X 这样的假 IP。
但有的应用会把这个判定为不安全，刚好前几天我在某个应用登录 Google 账号被拦了，而且其实不是第一次被拦，像是 OpenClaw 之类的也很喜欢拦截 fake IP。
所以我就给 Google 的登录添加了 always-real-ip，顺手让 Codex 拓展了一下其他可能需要用到 always-real-ip 的场景，然后他就把 auth.openai.com 给加上了。
于是，本来应该是 DOMAIN auth.openai.com → OpenAI 策略组 → 前置代理节点 → 美国家宽链式出口 这样一条路径。
实际上在 OpenAI 策略组识别这一环，因为它已经是 IP 地址，而不是域名了，所以命中不到 OpenAI 的规则，反而掉进了兜底规则，而我的兜底规则是 Asia，恰好在很短短时间内，两台设备的两次登录从日本切到了新加坡。
解决方案就是在 auth.openai.com 的 DOMAIN 规则加上了 extended-matching，让它再指回 OpenAI 规则。
于是这样，OpenAI 的账号登录也走回了美国家宽节点。
也挺离谱的。
然后回到这个界面，把设备都踢掉再重新登录一遍，过个一天， Pro 模型就恢复畅用了。
而且我最近在这两天大量使用 Pro ，20x 订阅的额度限制应该没有那么容易达到。
所以如果使用没那么多，之前又自我评估是额度问题的朋友，可以重新再看一下。
总结一下经验：
不要只盯着使用时的 IP 是否纯净，Pro 模型降智不一定是看你跟 OpenAI 流量交互的 IP 干不干净。
到设置里面看一看活跃会话，有可能是无意间形成了异地登录，导致账号受到了限制。
尤其是不要无脑切换 IP 的同时，在不同设备上清空浏览器缓存重新登录测试，有可能在测试的时候就形成了多会话异地登录。
目前从我自己的账号恢复状况来看，OpenAI 对 IP 的要求并没有特别高。我使用的是 Weshare 的伪家宽，完全没有问题。我觉得不排除可能，就算不用固定 IP 出口，保持 IP 归属在同城市或者同国家也没有问题。
如果有同样状态的朋友，不妨先切成同国家看一看。