没有，看过的，账号不降智，astra 都是正常的

juice 给的很低，如下 

gpt-6-astra 刚出来的就伴随着严重的 516 截断问题，可以看下面的按日统计，9月5日是 gpt-6-astra 开发给普通用户的第一天。 

如果你用 cpa 并且安装 keeper、cpamp 之类的，可以直接导出历史请求事件进行分析。 sub2api、new-api、cc-switch 以及其他类似工具应该也能导出记录。 如果你是本地直接登录账号使用的话，可以直接让 agent 帮你分析 ~/.codex 里面的日志。

这对比就好像拿大象和飞机对比谁的制冷效果好

但是不验证，Cyber Abuse 邮件警告两三次就被封号了，Pro 20x 账号今天被封了，损失惨重

> 本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容： > > 我的帖子已经打上 开源推广 标签： 是 > 我的开源项目完整开源，无未开源部分： 是 > 我的开源项目已链接认可 LINUX DO 社区： 是 > 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是 > 以上选择我承诺是永久有效的，接受社区和佬友监督： 是 > > 以下为项目介绍正文内容，AI生成、润色内容已

不是插件，就是导出历史请求数据然后让 codex 统计分析的

其实降智主要就是 516 导致的，那些说自己被路由到低级模型的说法没有什么根据。

前排随地大小睡。

快是快，不过老是断，就开一个对话，做着做着就busy了，继续又好了 ^-^

这就得去 X 上面问奥特曼或者 tibo，这个截断机制是 gpt-5.5 时代就有的。 ^-^

应该不是 bug，多半是 OpenAI 节省算力的一个机制。但实际体验是只要发生了截断，推理链条不完整，效果就会变得非常差。不完整的推理链条会导出特别离谱的结果，简单来说，实际使用过程中，推理被截断到 516 的效果可能还不如只推理 100 个 tokens 但是不被截断的效果好。

用 keeper 看的吗？keeper 的计算方法有问题，会显得很快。

有看到其他人的 TPS 吗？他们大概有多少？我从今天凌晨刚出来的时候就在用，那个时候 TPS 就只有十几二十了。

该不会只有画鹈鹕的能力提升了吧，其他提升的点到底在哪里，感受不到啊

当前就是这样设计的，通过 API Key 登录只能查看，不能修改任何配置。 > 支持 API Key 登录插件页面 > > 对于没有 CPA 管理密钥的拼车用户而言，可以使用 API Key 登录插件页面，查看个人订阅额度使用情况、请求事件等。值得注意的是，需要通过以下地址访问，才能使用 API Key 登录： > >``` > http(s)://<CLIProxyAPI 地址>/v0/reso

插件市场展示需要在 CLIProxyAPI-Plugins-Store 仓库里面提交 PR，我上周就提交了，但是没有被合并。实际上这个仓库已经有两周多没有被活动过了 ^-^ 

这是下一个待实现的目标，等实现后我回复你

这看着不像是 gpt 啊，怕是掺水掺多了。

> sse连接时每次消息来回应该都会走一次握手。假如首token延迟增加了1s并且这个测试有十轮思考或者工具调用，那就相当于总时间增加了10s 并非你说的这样，一次完整的流式响应只需要建立一次 http 连接

多半是 iCloud 隐藏邮件地址要被制裁了 号池都用 Outlook 别名邮箱和 iCloud 隐藏邮件地址，OpenAI 会察觉吧

实际情况是 TPS 升高了，因为 TPS=Tokens/(总延迟-TTFT)，总延迟和 Tokens 不变，TTFT 增大，TPS 自然就增大了。可以看下面的真实统计数据：  可以说 TP

由于 OpenAI 不会在推理过程中返回 reasoning tokens，真实的 TTFT 根本就无从计算。更新前后都只是估计，之前是估计的小了，现在是估计的大了。不过我也觉得现在要更合理一些，之前那个稳定 200ms 确实没有任何参考价值。

让 AI 分析了一下 CPA 源代码，发现新版本 CPA 的 TTFT 计算规则确实发生了一些变化，如下：  更具体的， v7.2.145 及更早的 CPA 版本会在收到任何事件时终止 TT

其实沉浸式翻译接入 DeepSeek 官方 API 用 DeepSeek V4 Flash 模型体验还挺好的，速度快（比 Codex 反代的 gpt-5.6-luna(low) 要快），而且用不了多少钱，充十块钱都能用老久

tibo 平等的惩罚每一个拖延症

这次重置是因为 plus 订阅恢复 5h 限额，要我说所有 pro 用户都应该向 plus 用户致敬，pro 用户是蹭的人家的重置

push 到 GitHub 上面，用 GitHub Action 做原生构建。