[Bug]: 开了Codex 额度冷却处理，但是free号429 月额度用尽不会自动禁用。

[RubickMischief]

问题类型

自动禁用 / 自动恢复异常

部署方式

完整 Docker 方案

CPA 版本

v7.2.48

CPA Manager Plus 版本

v1.10.0

问题描述

① 开了Codex 额度冷却处理，但是free号429 月额度用尽不会自动禁用。
② 请求监控无禁用功能

复现步骤

Codex 额度冷却处理 已开启
429额度用尽不禁用 无主动禁用功能

关键配置

quotaCooldownEnabled ： true

/status 返回内容

日志

截图

No response

检查清单

• 我已经搜索过现有 Issues，没有找到重复问题
• 我已经确认敏感信息已经脱敏，例如 token、key、账号信息

[seakee]

感谢反馈。这个目前还不能直接判定为 bug，需要再补充几项信息。

Codex 额度冷却处理 不是“所有 Codex 429 都自动禁用”。当前逻辑只会处理请求监控中新采集到的 Codex 429，并且需要能识别到明确的 usage_limit_reached / quota window 已满信号，同时还要有未来的 reset 时间和对应 auth file 信息。普通 429、缺少 reset 时间、无法定位 auth file、collector 未运行或 CPA 管理接口 patch 失败时，都不会自动禁用。

另外，“请求监控”页面本身是只读汇总页，不提供直接禁用按钮是当前设计。手动处理入口通常在 Auth Files 或 Account Actions 页面。

麻烦补充以下信息，敏感内容可打码：

1. CPA Manager Plus 配置页里的“账号处理策略”截图，确认：
   • Codex quota cooldown
   • Auth issue queue
   • Auth issue auto-disable
   • Source / Config key / Environment variable
2. CPA 连接和 Collector 配置截图。
3. /status 返回内容，确认 collector 是否 running、是否有 lastError。
4. 请求监控中对应 429 记录的详情信息，至少需要看到 provider、auth file/auth index、错误类型或响应摘要。
5. Manager Server 日志中同一时间段包含这些关键词的行：
   • [automation]
   • [quota-auto-disable]
   • collector

如果补充后确认该 429 满足触发条件，但后台仍没有禁用或日志显示 patch 成功后状态未变化，再按真实 bug 继续排查。

[RubickMischief]

2026/07/02 00:34:35 [automation] runtime settings reloaded quotaCooldown=true accountActions=false accountActionsAutoDisable=false
2026/07/02 00:34:35 http PATCH /usage-service/account-processing-policy status=200 duration=3.32374ms remote=172.xx.xx.xx:40980
2026/07/02 00:34:38 [automation] runtime settings reloaded quotaCooldown=false accountActions=false accountActionsAutoDisable=false
2026/07/02 00:34:38 http PATCH /usage-service/account-processing-policy status=200 duration=3.794202ms remote=172.xx.xx.xx:40994
2026/07/02 00:34:38 [automation] runtime settings reloaded quotaCooldown=true accountActions=false accountActionsAutoDisable=false

2026/07/01 23:30:45 http GET /status status=200 duration=26.550588ms remote=172.xx.xx.xx:47532

unexpected EOF 我看有这个错误

[RubickMischief]

curl -sS -H "Authorization: Bearer <CPA_MANAGEMENT_KEY>" "<CPA_UPSTREAM_URL>/v0/management/auth-files" -o auth-files.json

io.ReadAll(io.LimitReader(res.Body, 1024*1024))
auth-files.json大小 1298kb 超过读取上限。

[RubickMischief]

#280

[seakee]

#280

已确认这不是单纯增大 authFilesResponseReadLimit 能彻底解决的问题。

这次触发点是 CPAMP 为了校验一个 auth file，需要拉取 CPA /v0/management/auth-files 的完整列表。你的环境里这个响应约 1298KB，超过了旧版本 1MiB 读取上限，因此 JSON 被截断并出现 unexpected EOF。把上限调到 8MiB 可以缓解当前样例，但 auth file 数量、状态字段和 recent requests 继续增长后仍可能再次触发。

我做了两阶段修复：

1. CPA 侧上游 PR：fix(management): filter auth files by name and auth index router-for-me/CLIProxyAPI#4083
   GET /v0/management/auth-files 支持按 name / auth_index 筛选，PATCH /v0/management/auth-files/status 支持可选 auth_index 校验。这样 CPAMP 后续可以让 CPA 服务端精确返回/修改目标账号，避免为了一个账号拉取完整列表，也避免同名 auth file 被误修改。

2. CPAMP 侧 PR：fix(manager-server): stream CPA auth file lookups #281
   当前先在 CPAMP 内部做兼容优化：不再一次性读取完整 auth-files 响应，而是流式扫描目标 auth file。请求 CPA 时会带上 name / auth_index，旧 CPA 会忽略这些参数但 CPAMP 仍能流式 fallback；等 CPA PR 合并并发布后，会自动利用 CPA 的服务端筛选能力。状态修改时也会携带 auth_index，新 CPA 可做服务端身份校验，旧 CPA 保持兼容。

所以 #280 的方向是有效缓解，但不是最终方案；我会用 #281 替代这类单纯调大读取上限的修复。

[RubickMischief]

#280

已确认这不是单纯增大 authFilesResponseReadLimit 能彻底解决的问题。

这次触发点是 CPAMP 为了校验一个 auth file，需要拉取 CPA /v0/management/auth-files 的完整列表。你的环境里这个响应约 1298KB，超过了旧版本 1MiB 读取上限，因此 JSON 被截断并出现 unexpected EOF。把上限调到 8MiB 可以缓解当前样例，但 auth file 数量、状态字段和 recent requests 继续增长后仍可能再次触发。

我做了两阶段修复：

1. CPA 侧上游 PR：fix(management): filter auth files by name and auth index router-for-me/CLIProxyAPI#4083
   GET /v0/management/auth-files 支持按 name / auth_index 筛选，PATCH /v0/management/auth-files/status 支持可选 auth_index 校验。这样 CPAMP 后续可以让 CPA 服务端精确返回/修改目标账号，避免为了一个账号拉取完整列表，也避免同名 auth file 被误修改。
2. CPAMP 侧 PR：fix(manager-server): stream CPA auth file lookups #281
   当前先在 CPAMP 内部做兼容优化：不再一次性读取完整 auth-files 响应，而是流式扫描目标 auth file。请求 CPA 时会带上 name / auth_index，旧 CPA 会忽略这些参数但 CPAMP 仍能流式 fallback；等 CPA PR 合并并发布后，会自动利用 CPA 的服务端筛选能力。状态修改时也会携带 auth_index，新 CPA 可做服务端身份校验，旧 CPA 保持兼容。

所以 #280 的方向是有效缓解，但不是最终方案；我会用 #281 替代这类单纯调大读取上限的修复。

great job!