[讨论] OpenAI 对第三方客户端发出的请求降智

[haowang02]

最近发现 OpenAI 似乎对非 Codex 发出的请求降智（限制推理）。包括但不限于：

• CLIProxyAPI 这类反代工具
• OpenCode 这类第三方 Harness
• Codex SDK

具体而言，我使用如下问题进行了广泛测试：

在一个黑色的袋子里放有三种口味的糖果，每种糖果有两种不同的形状（圆形和五角星形，不同的形状靠手感可以分辨）。现已知不同口味的糖和不同形状的数量统计如下表。参赛者需要在活动前决定摸出的糖果数目，那么，最少取出多少个糖果才能保证手中同时拥有不同形状的苹果味和桃子味的糖？（同时手中有圆形苹果味匹配五角星桃子味糖果，或者有圆形桃子味匹配五角星苹果味糖果都满足要求）
苹果味 桃子味 西瓜味
圆形 7 9 8
五角星形 7 6 4

该问题的正确答案是 21，不降智的 GPT-5.5 模型只要开启思考（low/medium/high/xhigh）应该都能回答正确。

测试环境如下：

• 账号：正常无风控
• IP：本人在新加坡，未使用代理工具，IP正常无风控
• 系统：macOS

测试结果如下：

注意：虽然只展示了一张截图，但是每个场景我都进行了重复多次测试，确保结果是可靠的。

场景	是否降智	截图
Codex CLI 直接登录账号	否
Codex CLI 直接登录账号+Python Codex SDK 调用	是
CLIProxyAPI 登录账号+Codex接入	是
OpenCode 直接登录账号	是

一个观察是，当降智发生的时候，这次请求的 reasoning token 总是 516。如下：

Token usage: total=12,756 input=11,996 (+ 2,432 cached) output=760 (reasoning 516)

希望有条件的朋友一起测试一下，看看 OpenAI 降智具体是怎么回事，能不能规避。

[haowang02]

限制反代和第三方Harness还能理解，但是连 Codex 自己的 SDK 也降智就很难评了。

[haowang02]

希望有条件的朋友能够复现上述测试，一起交流。

[xiaorong117]

嗯，我也出现了516的情况。

[BlueSkyXN]

确实存在部分516，有没有可能是tool默认低智力的问题？

[BlueSkyXN]

拿着你的问题试了下

41,781 1,035 516 2,432 42,816

确实有516，以及大量请求中，偶尔也有准确516的，但大多数思考不足516

[haowang02]

我如果用 Python OpenAI SDK 调用的话，大部分时候都是 516，如下图：

Codex CLI 登录账号（gpt-5.5 low）

反之，如果我直接启动 codex cli，然后在里面提问则没有降智问题。

我观察了下，典型表现就是UI看不见思考

登录时的回答是

`最少取出 21 个糖果。

因为形状能靠手感分辨，可以这样取：

取 9 个圆形 + 12 个五角星形。

理由：

1. 圆形西瓜味只有 8 个，所以取 9 个圆形 时，手中必然至少有一个：

   • 圆形苹果味，或
   • 圆形桃子味。

2. 如果 9 个圆形里有 圆形苹果味，那么再取 12 个五角星形：

   • 五角星中“非桃子味”最多是苹果 7 个 + 西瓜 4 个 = 11 个；
   • 所以 12 个五角星里必有 五角星桃子味；
   • 得到“圆形苹果味 + 五角星桃子味”。

3. 如果 9 个圆形里有 圆形桃子味：

   • 五角星中“非苹果味”最多是桃子 6 个 + 西瓜 4 个 = 10 个；
   • 所以 12 个五角星里必有 五角星苹果味；
   • 得到“圆形桃子味 + 五角星苹果味”。

因此 21 个一定够。

20 个不够：例如若只取 20 个，可能安排成无法同时得到这种“不同形状的苹果味和桃子味”组合。所以最少是：

21 个。`

而CPA+登录是 `最少要取出 29 个糖果。

理由是看“最多能取出多少个仍然不满足条件”。

要避免满足条件，必须同时避免：

• 有 圆形苹果味 + 五角星桃子味
• 有 圆形桃子味 + 五角星苹果味

西瓜味不影响条件，所以最多可以先全拿： 8 + 4 = 12 个西瓜味。

然后在相关四类里，为了不形成目标组合：

• 圆形苹果 7 和 五角星桃子 6 不能同时有，所以最多取较多的 圆形苹果 7
• 圆形桃子 9 和 五角星苹果 7 不能同时有，所以最多取较多的 圆形桃子 9

因此最多可以取出仍不满足条件的数量是：

12 + 7 + 9 = 28

例如取出所有西瓜味、所有圆形苹果味、所有圆形桃子味，共 28 个，手里没有五角星苹果味或五角星桃子味，所以还不满足。

所以再多取 1 个，也就是：

28 + 1 = 29

必然满足条件。答案是 29 个。`

这就和我这边观察到的现象一致了，使用第三方客户端（CLIProxyAPI、opencode 等）发出的请求会有更大的概率被降智。

[BlueSkyXN]

一个没有降智的参考图像：

而且我发现至少3月初就有516了

[haowang02]

一个没有降智的参考图像：

而且我发现至少3月初就有516了

我怀疑 516 是被官方强行截断了思考。
如果官方只是将请求路由到一个更差的模型，那思考长度应该还是会有变化。
但是无从求证。

[BlueSkyXN]

我如果用 Python OpenAI SDK 调用的话，大部分时候都是 516，如下图：

Codex CLI 登录账号（gpt-5.5 low）

反之，如果我直接启动 codex cli，然后在里面提问则没有降智问题。

我观察了下，典型表现就是UI看不见思考
登录时的回答是
`最少取出 21 个糖果。
因为形状能靠手感分辨，可以这样取：
取 9 个圆形 + 12 个五角星形。
理由：

1. 圆形西瓜味只有 8 个，所以取 9 个圆形 时，手中必然至少有一个：

   • 圆形苹果味，或
   • 圆形桃子味。

2. 如果 9 个圆形里有 圆形苹果味，那么再取 12 个五角星形：

   • 五角星中“非桃子味”最多是苹果 7 个 + 西瓜 4 个 = 11 个；
   • 所以 12 个五角星里必有 五角星桃子味；
   • 得到“圆形苹果味 + 五角星桃子味”。

3. 如果 9 个圆形里有 圆形桃子味：

   • 五角星中“非苹果味”最多是桃子 6 个 + 西瓜 4 个 = 10 个；
   • 所以 12 个五角星里必有 五角星苹果味；
   • 得到“圆形桃子味 + 五角星苹果味”。

因此 21 个一定够。
20 个不够：例如若只取 20 个，可能安排成无法同时得到这种“不同形状的苹果味和桃子味”组合。所以最少是：
21 个。而CPA+登录是最少要取出 29 个糖果。
理由是看“最多能取出多少个仍然不满足条件”。
要避免满足条件，必须同时避免：

• 有 圆形苹果味 + 五角星桃子味
• 有 圆形桃子味 + 五角星苹果味

西瓜味不影响条件，所以最多可以先全拿： 8 + 4 = 12 个西瓜味。
然后在相关四类里，为了不形成目标组合：

• 圆形苹果 7 和 五角星桃子 6 不能同时有，所以最多取较多的 圆形苹果 7
• 圆形桃子 9 和 五角星苹果 7 不能同时有，所以最多取较多的 圆形桃子 9

因此最多可以取出仍不满足条件的数量是：
12 + 7 + 9 = 28
例如取出所有西瓜味、所有圆形苹果味、所有圆形桃子味，共 28 个，手里没有五角星苹果味或五角星桃子味，所以还不满足。
所以再多取 1 个，也就是：
28 + 1 = 29
必然满足条件。答案是 29 个。`

这就和我这边观察到的现象一致了，使用第三方客户端（CLIProxyAPI、opencode 等）发出的请求会有更大的概率被降智。

最麻烦的是，我发现哪里纯正登录，也会516，不使用第三方（在长任务过程中）

[haowang02]

我如果用 Python OpenAI SDK 调用的话，大部分时候都是 516，如下图：

Codex CLI 登录账号（gpt-5.5 low）

反之，如果我直接启动 codex cli，然后在里面提问则没有降智问题。

我观察了下，典型表现就是UI看不见思考
登录时的回答是
`最少取出 21 个糖果。
因为形状能靠手感分辨，可以这样取：
取 9 个圆形 + 12 个五角星形。
理由：

1. 圆形西瓜味只有 8 个，所以取 9 个圆形 时，手中必然至少有一个：

   • 圆形苹果味，或
   • 圆形桃子味。

2. 如果 9 个圆形里有 圆形苹果味，那么再取 12 个五角星形：

   • 五角星中“非桃子味”最多是苹果 7 个 + 西瓜 4 个 = 11 个；
   • 所以 12 个五角星里必有 五角星桃子味；
   • 得到“圆形苹果味 + 五角星桃子味”。

3. 如果 9 个圆形里有 圆形桃子味：

   • 五角星中“非苹果味”最多是桃子 6 个 + 西瓜 4 个 = 10 个；
   • 所以 12 个五角星里必有 五角星苹果味；
   • 得到“圆形桃子味 + 五角星苹果味”。

因此 21 个一定够。
20 个不够：例如若只取 20 个，可能安排成无法同时得到这种“不同形状的苹果味和桃子味”组合。所以最少是：
21 个。而CPA+登录是最少要取出 29 个糖果。
理由是看“最多能取出多少个仍然不满足条件”。
要避免满足条件，必须同时避免：

• 有 圆形苹果味 + 五角星桃子味
• 有 圆形桃子味 + 五角星苹果味

西瓜味不影响条件，所以最多可以先全拿： 8 + 4 = 12 个西瓜味。
然后在相关四类里，为了不形成目标组合：

• 圆形苹果 7 和 五角星桃子 6 不能同时有，所以最多取较多的 圆形苹果 7
• 圆形桃子 9 和 五角星苹果 7 不能同时有，所以最多取较多的 圆形桃子 9

因此最多可以取出仍不满足条件的数量是：
12 + 7 + 9 = 28
例如取出所有西瓜味、所有圆形苹果味、所有圆形桃子味，共 28 个，手里没有五角星苹果味或五角星桃子味，所以还不满足。
所以再多取 1 个，也就是：
28 + 1 = 29
必然满足条件。答案是 29 个。`

这就和我这边观察到的现象一致了，使用第三方客户端（CLIProxyAPI、opencode 等）发出的请求会有更大的概率被降智。

最麻烦的是，我发现哪里纯正登录，也会516，不使用第三方（在长任务过程中）

降智不一定是第三方登录导致的，还有账号、IP等因素。
如果账号、IP 存在风控问题，即便是直接在 Codex 里面登录，也是有可能被降智的。
只不过我讨论的是由第三方客户端代理的降智问题。

[dann2333]

opus4.8max思考了很久然后答错了🤣

[haowang02]

opus4.8max思考了很久然后答错了🤣

这倒不一定是降智，opus 4.8 一直回答不了这个问题。而 gpt-5.4/gpt-5.5 是能回答这个问题的，降智之后才不行。

[BlueSkyXN]

1，发现至少3月初就有516问题了
2，516相当于无思考弱智模型，和网页那个表现类似，但是钱照收，会出现log有一段加密思考但UI不显示思考
3，哪怕直接登录也会516（长任务中）
4，虽然会516，但是大多数时候思考还是没有这么多，几十是常态，但也能到几千。

[haowang02]

对了，UI 不显示思考可能是因为你没有开，在 .codex/config.toml 中

model_reasoning_summary = "auto"

如果开了的话 516 情况下是有 summary 的，而且多次请求的 summary 还会不一样，但是 reasoning tokens 始终是 516。

另外就是 516 在其他需要推理的问题被降智时也会出现，不仅仅是我上面贴出来的那个糖果推理问题。

[waterskinlee]

opencode+omo，直接oauth登录gpt pro5x，gpt5.5开了xhigh：

最少取 21 个。
做法：利用手感区分形状，取 9 个圆形、12 个五角星形。
理由：
- 圆形中西瓜味最多只有 8 个，所以取 9 个圆形，手里一定至少有一个圆形苹果味或圆形桃子味。
- 如果这 9 个圆形里有圆形苹果味：
- 五角星形中“非桃子味”最多是苹果 7 个 + 西瓜 4 个 = 11 个。
- 取 12 个五角星形，必有五角星桃子味。
- 得到“圆形苹果 + 五角星桃子”。
- 如果这 9 个圆形里有圆形桃子味：
- 五角星形中“非苹果味”最多是桃子 6 个 + 西瓜 4 个 = 10 个。
- 取 12 个五角星形，必有五角星苹果味。
- 得到“圆形桃子 + 五角星苹果”。
少于 21 个不能保证，例如只取 8 个圆形时可能全是圆形西瓜味。
所以答案是 21 个。

[haowang02]

我测试了 xhigh，的确更少出现降智（516 reasoning tokens），但仍然没有完全避免。

[Omnls]

好奇怪，我用的自己的
@CreatorEdition/Codex-Manager
low、m、high 最终结果是 26
xhigh 给我的结果是 36
正确答案是多少其实。。。
Cursor的claude是 26
kiro的claude是29
claude.ai的 max sonnet 是29

最少需要取出 34 个糖果。

理由：先算“最多能取多少个还不满足条件”。

目标要求出现：

• 圆形苹果 + 五角星桃子，或
• 五角星苹果 + 圆形桃子。

要避免满足条件，就不能同时拥有这两类配对。

最多的避免方式是：

• 拿走所有西瓜味：圆形 8 + 五角星 4 = 12
• 只拿一种形状下的苹果和桃子，避免跨形状配对。比如拿：
  • 圆形苹果 7
  • 圆形桃子 9
  • 五角星桃子 6

这样没有“五角星苹果”，所以不会出现“五角星苹果 + 圆形桃子”；但也没有同时构成另一组冲突。

数量为：

12 + 7 + 9 + 6 = 34

但这里已经有“圆形苹果 + 五角星桃子”，所以这个组合其实满足条件，不能作为避免情况。需要重新限制。

真正避免条件时，苹果和桃子的可取结构只能是：

• 只取苹果，不取桃子：苹果 14
• 只取桃子，不取苹果：桃子 15
• 只取同一形状的苹果和桃子：
  • 圆形苹果 7 + 圆形桃子 9 = 16
  • 五角星苹果 7 + 五角星桃子 6 = 13
• 或取某一味的两种形状，再取另一味中不会配对的同形状糖。

最大可避免组合是：

圆形苹果 7 + 五角星苹果 7 + 圆形桃子 9 = 23

再加所有西瓜味：

23 + 12 = 35

所以最多可以取 35 个仍不保证满足条件。

因此最少保证数是：

35 + 1 = 36

答案：36 个。

[haowang02]

如果不降智的话一般回答为 21。这里给出一个 OpenRouter API 调用的结果：

[Omnls]

看来好像真的是降智。。。

若可按手感选择形状，最少 21 颗。
若完全不能控制形状，只是盲取总数，则才是 29 颗。

因此，在题目强调“形状靠手感可以分辨”并允许按形状摸取时，答案应为：
21 颗。

所以在“可按形状选择摸取”的规则下，最少是：
21 颗
我之前给的 29颗 对应的是另一种理解：只能决定总数，不能控制摸出的形状。这里题目特意说明“形状靠手感可以分辨”，更合理的竞赛题意应该是允许按形状摸取，所以 21颗是更准确答案。

[haowang02]

看来好像真的是降智。。。

若可按手感选择形状，最少 21 颗。 若完全不能控制形状，只是盲取总数，则才是 29 颗。

因此，在题目强调“形状靠手感可以分辨”并允许按形状摸取时，答案应为： 21 颗。

所以在“可按形状选择摸取”的规则下，最少是： 21 颗 我之前给的 29颗 对应的是另一种理解：只能决定总数，不能控制摸出的形状。这里题目特意说明“形状靠手感可以分辨”，更合理的竞赛题意应该是允许按形状摸取，所以 21颗是更准确答案。

可以进一步观察降智回答的情况下，reasoning tokens 是否是 516.

[Fvr9W]

抽象 原来我一直被 516 控制

[Fvr9W]

516 果然降智 写了一个插件 516 就报错重试 本来答案是 23个 直接重试给了 21 个

[BlueSkyXN]

516 果然降智 写了一个插件 516 就报错重试 本来答案是 23个 直接重试给了 21 个

CPA的插件吗

[Fvr9W]

对的 你叫 AI 写个2分钟就写好了

[Zxis233]

对的 你叫 AI 写个2分钟就写好了

这个思路很棒

[BlueSkyXN]

抽取了点日志复盘了下，也许还可以进一步扫描
XH思考中，大于516的大概是4%，无论cpa还是直接都类似这个范围
但是等于516的，CPA有4%多接近5%，而直接不到1%，也不是没有
剩下的都是小于516的

516 不是随机均摊出现，而是明显条件性密集：它主要密集在 task 起手、task 收口、阶段切换、状态重建 这些位置。不是长时间连续卡在 516，而是经常在 task 交界处形成小团簇。

[luispater]

我也来凑个热闹，经过多次测试走CPA的55xh稳定为21个，见图：

但是55xh fast从19-29不等，但是没有出现21的情况。

55low fast 29稳定。

55low 19-29不等。

[haowang02]

我后面也测了不同思考强度，的确发现 xhigh 被降智的概率更低，但不是完全没有，见下图

测试条件：Codex 本地登录，Codex SDK 调用

[yryryr1989]

我连网页版用gpt5.5pro 都降智成5.3mini了，我还是200美元的套餐

[Edward-lyz]

我也是，最近 pro 压根不可用，直接路由到 5.3 mini；我都怀疑不是 IP 问题，换了一堆家宽了

[haowang02]

我也是，最近 pro 压根不可用，直接路由到 5.3 mini；我都怀疑不是 IP 问题，换了一堆家宽了

根据我的观察，账号、IP、反代都会影响风控。最严重的就是账号被风控，这时候换什么 IP 都不管用了。

[Adamcf123]

感觉像是bug

[Hershel1215]

开了个失败重试，结果一直516.

[BenjaminAaron196]

sub2api一切正常

[citizenll]

在提示的情况下它执行脚本获取了正确答案, 没给提示是 26 个糖果

[liwangcc]

最近发现 OpenAI 似乎对非 Codex 发出的请求降智（限制推理）。 包括但不限于：

• CLIProxyAPI 这类反代工具
• OpenCode 这类第三方 Harness
• Codex SDK

具体而言，我使用如下问题进行了广泛测试：

在一个黑色的袋子里放有三种口味的糖果，每种糖果有两种不同的形状（圆形和五角星形，不同的形状靠手感可以分辨）。 现已知不同口味的糖和不同形状的数量统计如下表。 参赛者需要在活动前决定摸出的糖果数目，那么，最少取出多少个糖果才能保证手中同时拥有不同形状的苹果味和桃子味的糖？ （同时手中有圆形苹果味匹配五角星桃子味糖果，或者有圆形桃子味匹配五角星苹果味糖果都满足要求） 苹果味 桃子味 西瓜味 圆形 7 9 8 五角星形 7 6 4

该问题的正确答案是 21，不降智的 GPT-5.5 模型只要开启思考（low/medium/high/xhigh）应该都能回答正确。

测试环境如下：

• 账号：正常无风控
• IP：本人在新加坡，未使用代理工具，IP正常无风控
• 系统：macOS

测试结果如下：

注意：虽然只展示了一张截图，但是每个场景我都进行了重复多次测试，确保结果是可靠的。

场景 是否降智 截图
Codex CLI 直接登录账号 否
Codex CLI 直接登录账号+Python Codex SDK 调用 是
CLIProxyAPI 登录账号+Codex接入 是
OpenCode 直接登录账号 是
一个观察是，当降智发生的时候，这次请求的 reasoning token 总是 516。如下：

Token usage: total=12,756 input=11,996 (+ 2,432 cached) output=760 (reasoning 516)

希望有条件的朋友一起测试一下，看看 OpenAI 降智具体是怎么回事，能不能规避。

我想知道这个题有没有权威文档，具体解释为什么很多大模型会出现错误，是什么导致的

[KyikyiCat]

这个题如何不重要，重要是大模型把请求的思维链截断了，像deepseek虽然没GPT聪明，但是它能思考5分钟，推理链可以很长，对应的推理tokens很多。这个题要得到正确答案也需要几千的推理tokens，而GPT 5.5 最近把部分请求的推理过程强制截断了。表现出来就是统一的推理tokens数量和没有思考过的答案。甚至是否是516也不重要。关键看同样推理强度的同请求，是否可以拿到更长的reasoning_tokens。
GPT的降智一直以来分为两种：一种是直接路由的低智模型上（这属于非常严重了，可以通过询问它是什么模型、或者知识截至日期确认），另一种是思考的不够全面（之前也许是直接看思考预算，故可以询问Juice值确认），但现在发现它不改Juice值了，而是直接根据账号权重、线上压力直接对部分推理请求进行截断，用户仍然可以得到回复，只是后续的回复是由不完整的推理链生成的，所以质量会很差。

建议大伙可以去欣赏一下 deepseekv4 flash的推理链，赏心悦目。国模的推理链都是明文，外模的推理都是加密防蒸馏的，只返回推理tokens长度（用于计费确认）和密文（作为后续对话的上下文）；也有把密文直接存服务器、然后发给用户对应key的做法。

[oubeichen]

我说这个串是不是被closedai监控了，毕竟closedai会给开源贡献者直接发邮件送会员，那么反过来应该也可以轻易知道反向代理等项目活跃用户的邮箱。我的号昨天早上被封了，虽然是大规模封禁，但主要也只看到大陆圈子在说，封禁原因的判断方式还未可知。
如果github和closedai是用的同一个邮箱，还是小心点。

[luispater]

模型的能力测试普遍有两种测试：带工具和不带工具，在使用了以下的请求方法后，得到了一个没有降至的结论：

curl -X POST http://127.0.0.1:8317/v1/responses \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer 12345" \
  -d '{
  "model": "gpt-5.5",
  "instructions": "You are a helpful assistant.",
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "在一个黑色的袋子里放有三种口味的糖果，每种糖果有两种不同的形状（圆形和五角星形，不同的形状靠手感可以分辨）。现已知不同口味的糖和不同形状的数量统计如下表。参赛者需要在活动前决定摸出的糖果数目，那么，最少取出多少个糖果才能保证手中同时拥有不同形状的苹果味和桃子味的糖？（同时手中有圆形苹果味匹配五角星桃子味糖果，或者有圆形桃子味匹配五角星苹果味糖果都满足要求）\n苹果味 桃子味 西瓜味\n圆形 7 9 8\n五角星形 7 6 4"
        }
      ]
    }
  ],
  "reasoning": {
    "effort": "xhigh",
    "summary": "auto"
  },
  "stream": true,
  "store": false,
  "include": [
    "reasoning.encrypted_content"
  ]
}'

该测试报文没有使用任何工具，并且没有使用Codex自带的系统提示词。

得到的统计数据如下：

得到的结果如下（省去了报文中24段思考的内容，仅展示最后结果）：

在**可以凭手感按形状挑取**的前提下，最少需要取 **21 个**。
取法：  
**取 12 个五角星形糖 + 9 个圆形糖。**
理由：
1. 五角星形糖中：
   - 非桃子味 = 苹果 7 + 西瓜 4 = 11，所以取 12 个五角星形，必有桃子味；
   - 非苹果味 = 桃子 6 + 西瓜 4 = 10，所以取 12 个五角星形，也必有苹果味。  
   因此，12 个五角星形中一定同时有**五角星苹果**和**五角星桃子**。
   2. 圆形糖中西瓜味只有 8 个，所以取 9 个圆形糖，必有至少一个苹果味或桃子味：
   - 若有圆形苹果，则可配五角星桃子；
   - 若有圆形桃子，则可配五角星苹果。
   所以 **12 + 9 = 21** 个一定够。
为什么 20 个不够：  
设取 (r) 个圆形、(20-r) 个五角星形。
- 若 (r le 8)，圆形可能全是西瓜味，无法匹配；
- 若 (r ge 16)，五角星形最多 4 个，可能全是西瓜味；
- 若 (9 le r le 15)，可以让圆形和五角星形都只取到“非桃子味”（圆形非桃子有 (7+8=15) 个，五角星非桃子有 (7+4=11) 个），手中可能没有桃子味。
因此 20 个不能保证，最少是 **21 个**。
注：如果题意是不允许按形状挑取、只能完全盲抽，则答案会变成 **29 个**。

当然了，在工程的情况下，无法做到没有系统提示，不带任何工具。

仅做关于降智的探讨。

[KyikyiCat]

API端按量计费，网页端风控严格且不容易批量调用，只有Codex是套餐订阅形式，且是agent客户端，请求量庞大。所以把Codex的部分请求推理链掐了。

[luispater]

我这个使用的就是CPA从codex订阅中转出来的，所以目前看问题还是应该出在工具及系统提示词上。

我等一会儿尝试把系统提示词换成GPT-5的时代的codex系统提示词再试试，看看能不能达到老5或者5.2的工作水平。

5.5对工具的调用更积极，只要有工具就会想方设法的使用工具去调用。极有可能会造成比较大的影响。

[KyikyiCat]

刚测了一次，我这Codex端删掉系统提示词也没用了 =。=
观测到的现象是：任何推理Tokens大于516的请求都有可能被截断为516
影响是：后续Output由不完整思维链生成，极容易答案首尾矛盾，尾部自修复
在这种情况下medium等低推理强度由于思考的角度较少，反而推理链不容易断，可能还不错...但是high和xhigh模式就名存实亡了
另外可能对每个人做了限流处理，xhigh用的多就容易这样？我这越测数据就越差

[luispater]

我刚才将5.5的系统提示词换成5.2的，那个老态龙钟的5.2又回来了！

其实516没啥，挺好的，我们团队拿keeper的数据完整的拉了一下，70%以上的请求实际上思考是0，这才是应该是降智的主要原因。

[KyikyiCat]

我刚才将5.5的系统提示词换成5.2的，那个老态龙钟的5.2又回来了！

其实516没啥，挺好的，我们团队拿keeper的数据完整的拉了一下，70%以上的请求实际上思考是0，这才是应该是降智的主要原因。

建议验证下数据，感觉不太对劲，那516占比是多少呢？

[fabianxagent]

感觉还好，516比例没有想象中的高

[KyikyiCat]

516统计不应该是>0，因为很多简单任务推理tok本身还没到516就已经结束了。 需要统计的是在超过516token（复杂任务，依赖推理） 中的占比，我这边统计出来达到了50%了都

感谢指正，分母应该为reasoning_output_tokens>=516，这样算比例就非常高了

这么一算 codex high、xhigh名存实亡。高难度推理一半概率被截断。不如medium甚至low稳定跑

[KyikyiCat]

5.4的比例比5.5的低一些

佬你主用哪个推理强度

[fabianxagent]

非佬，一直用的high

[haowang02]

516我觉得已经是一个很深度的值了

大部分场景确实用不到 516，但是对于需要用 516 的场景，推理被强行截断到 516 就会出现推理不完善、前后不一致等一系列问题。

[KyikyiCat]

516我觉得已经是一个很深度的值了

大部分场景确实用不到 516，但是对于需要用 516 的场景，推理被强行截断到 516 就会出现推理不完善、前后不一致等一系列问题。

https://www.reddit.com/r/codex/comments/1ugyvez/half_of_your_highstakes_codex_requests_may_be/
这个统计也显示 30% 的请求 >= 516， >= 516的推理请求有一半被提前截断。具体比例受常用推理强度影响。

[Tai-Wei]

This might be helpful as a reference: https://github.com/Tai-Wei/codex-516-fix

It seems related to the issue discussed here and may provide a useful starting point or workaround.

[lbls111]

我的是CLIProxyAPI 登录账号+然后自定义Codex接入

[fabianxagent]

codex 5x pro + reasoning=high，客户端直连，未走反代，问题依然存在，甚至比反代的时候更严重

[ttys3]

official codex test result: "reasoning_tokens": 1745

    "usage": {
      "input_tokens": 13572,
      "input_tokens_details": {
        "cache_write_tokens": 0,
        "cached_tokens": 1408
      },
      "output_tokens": 2036,
      "output_tokens_details": {
        "reasoning_tokens": 1745
      },
      "total_tokens": 15608
    },

[Insulinocytus]

通过pi 0.84.2 （纯净，无任何extensions，tools，AGENTS.md等）+ CPA v7.2.139 + gpt 5.5 low 的方式跑了几次
均无出现降智或516问题

其中有2次 gpt 5.5 low 没有直接回答而是先写了一个python脚本跑

[steamch]

现在又出现了516降智。5.6 sol xhigh

[bladeofgod]

我使用gpt的app 测试，也有21和29两种答案。