可能是最好用的CPA管理工具
- 内容介绍
- 文章标签
- 相关推荐
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
先感谢 LinuxDo 佬友 @jingtai123：
【CPA】Codex 401账号清理与额度耗尽停用脚本 开发调优找不到是哪个佬写的脚本改的。。。 修改内容与功能 新增了 api-call 主动探测。 全量探测，等同于CPA中的 配额管理 刷新，本次脚本运行只会完整探测一遍 默认是关闭的，只有加 --enable-api-call-check 才会跑，且只跑一遍 api-call探测方式： 一批同时探测 9 个，整批跑完以后，随机等待 5 到 10 秒，再继续下一批。这样比一个个串行扫。 额度耗尽的…
这个项目是在他的脚本思路基础上继续二开整理的。它主要以codex的认证文件为例。我主要补了 Web 控制台、配置保存、日志查看、报告摘要、systemd 部署支持、优化了额度用尽之后的管理逻辑，让它更适合长期挂着跑，也更方便日常维护。
GitHub：
GitHub - KJ20051223/CLIProxyAPI-cleaner: CLIProxyAPI-cleaner: a lightweight cleanup script...
CLIProxyAPI-cleaner: a lightweight cleanup script plus web dashboard for auth-file account management, reporting, and service control.
项目定位
CLIProxyAPI-cleaner 是一个面向 CPA / auth-file 管理场景 的轻量工具，包含两部分：
- 清理脚本主程序
- 可视化 Web 控制台
把原来偏脚本化、偏手工的流程，整理成一套更容易部署、观察和维护的日常实用方案。
Web 首页
image1229×897 127 KB
清理脚本运行逻辑
脚本整体思路是：拉取账号列表 → 分类判断状态 → 执行对应处理 → 记录状态 → 生成报告 → 定时进入下一轮。
1. 先获取 auth-file 列表
每轮开始时，脚本会先从管理端接口拉取当前 auth-file / 账号列表。
如果接口返回异常或者数据结构不对，就会直接报错退出当前轮，避免后面误操作。
2. 对账号做第一轮分类判断
脚本会根据账号当前返回的状态信息做初步分类。这里核心是几类情况：
- 可用账号
- 401 / 认证失效类账号
- 额度耗尽类账号
- 已经禁用的账号
- 不可用但暂时不直接处理的账号
脚本内部会通过一些规则和错误特征去识别，比如：
401unauthorizedinvalid_grantrefresh_token_reusedusage_limit_reachedquota429billingrate limit
也就是说，它不是只看一个字段死判断，而是结合状态码和错误信息一起归类。
3. 结合 /api-call 主动探测再做一轮修正
除了基础状态判断，脚本还支持用 /api-call 做一轮主动探测。
这一层的目的，是把“表面状态”和“真实调用结果”结合起来，减少误判。
比如有些账号：
- 表面上看着还行，但真实调用已经报 401
- 表面上没明显坏，但实际已经额度耗尽
- 还有些账号需要进一步探测才能知道是不是值得继续留着
所以这一步会把一部分账号重新归类成：
- delete_401
- quota_exhausted
- ok
- 其他待观察状态
这也是为什么脚本比“只看面板状态”更有用一点。
4. 对 401 / 认证失效账号执行清理
如果判定为 401 / 认证失效，脚本会进入删除逻辑。
处理方式大概是：
- 先尽可能备份相关 auth-file
- 再调用管理接口删除对应文件 / 账号
- 删除成功后写入本轮结果
- 删除失败则记录失败原因，留在报告里
这里不是无脑删，它会尽量保留备份路径和响应结果，方便后面排查。
5. 对额度耗尽账号先禁用，而不是立刻删
如果判定为 额度耗尽，脚本默认不是直接删除，而是：
- 先把账号标记为 disabled
- 同时把这个账号写入本地状态文件
- 记录下它什么时候被禁用、下一次什么时候做 revival 检查
这个设计的考虑很简单：
很多额度号不是“彻底死了”，而是“当前不能用，但过一段时间可能恢复”。
所以对这类账号，脚本走的是：
先禁用 → 等待窗口期 → 再做 refresh / revival probe
6. 本地状态文件负责“记住这些额度号后面怎么处理”
脚本会维护一个状态文件，用来记录这些被禁用账号的后续处理节奏。
状态文件里大概会记：
- 账号名
- 最近一次错误原因
- 什么时候进入禁用状态
- 下一次 revival 检查时间
- refresh / probe 的结果
这样脚本在下一轮跑的时候，不是“重新从零开始想”，而是能接着上一次的状态继续走。
7. 到了时间窗口后，进入 revival 流程
对已经因为额度问题被禁用的账号，等到了设定的等待周期以后，脚本会进入 复活检查流程。
这一段逻辑大概是：
- 读取 auth-file 内容
- 尝试做 token refresh
- refresh 成功后，再做一次实际 probe
- 根据 probe 结果决定后续动作
可能出现几种结果：
情况 A：refresh 成功，probe 也正常
那就说明账号恢复了，可以重新启用。
脚本会：
- 把账号从 disabled 改回可用
- 清掉本地状态里的追踪信息
- 在报告里记成“复活成功启用”
情况 B：refresh 成功，但 probe 后还是额度耗尽
说明账号暂时还是不行。
脚本会：
- 保持 disabled
- 重新安排下一次 revival 检查时间
- 继续留在状态文件里
情况 C：refresh 失败，而且失败原因像 401 / token 已废
这种账号通常就没必要继续留了。
脚本会：
- 备份
- 删除
- 从状态文件里清掉
情况 D：读取 auth-file 或处理过程中出错
那就先记错误，延后到下一轮再检查，避免一次异常直接把账号误删。
8. 可用账号会顺带清理旧状态
如果某个账号原本曾经被记录成额度耗尽，但后面重新变成可用状态，脚本会顺手把它在状态文件里的旧记录清掉。
也就是说，状态文件不是只增不减，而是会随着账号恢复情况动态清理。
9. 每轮都会生成报告
每次执行结束后，脚本都会输出结构化报告，里面会带上：
- 本轮 run_id
- 配置摘要
- 结果列表
- 汇总统计
- 当前状态快照
一般会看到这些统计项：
- 检查总数
- 可用账号数
- 额度账号已禁用数
- 已删除 401 数
- refresh 成功数
- refresh 失败数
- 复活成功启用数
- 复活仍限额数
- 删除失败数
- 禁用失败数
这个报告会被 Web 控制台拿来做摘要展示，所以页面上能直接看到“删了几个 401、禁了几个额度号、复活了几个”。
10. 支持单次执行，也支持循环运行
脚本既可以：
- 只跑一轮
- 也可以按固定间隔持续循环跑
如果是循环模式，就会按设定的 interval 周期，不断重复：
检查 → 分类 → 处理 → 记录 → 报告 → 等下一轮
所以它更适合挂成一个长期服务，而不是一次性脚本。
Web 控制台负责什么
Web 控制台本身不负责核心判定逻辑，它更像是脚本的一个操作面板。
主要作用是：
- 保存配置
- 启停 / 重启 cleaner 服务
- 查看 cleaner 日志
- 查看 Web 日志
- 展示最近报告摘要
- 做简单的状态观察
也就是说，核心逻辑在清理脚本里，控制台负责管理和可视化。
目前有的功能
- 清理脚本主逻辑
- Web 控制台
- 配置保存
- 一键启动 / 停止 / 重启 cleaner
- 一键 dry-run
- cleaner / web 日志查看
- 最近报告摘要展示
- systemd + Nginx 部署
- 默认中文 README + 英文 README
- MIT License
适用场景
这个项目比较适合下面这些情况：
- 本来就在跑类似清理脚本
- 不想每次都手工敲命令
- 想把参数配置、日志、报告集中管理
- 想让服务稳定长期跑着
- 想把这类脚本整理成一个可以分享和复用的小项目
当前状态
目前它还是偏 实用型 项目，优先解决真实使用场景中的问题。
不是特别追求大而全，但已经能比较顺手地跑起来了。
后面如果有时间，可能还会继续补这些东西：
- 更完整的报告筛选能力
- 多用户 / 权限控制
- 更顺手的部署体验
如果有佬友也在折腾类似需求，欢迎讨论，或者直接拿去改。
网友解答：--【壹】--：
感谢佬，期待docker
--【贰】--：
已更docker
--【叁】--：
控制台可以设置 复活环节是默认12h查一次 注册机可以去看冰佬的
--【肆】--：
期待docker版本
--【伍】--：
我没3级…被禁言过6个月…
--【陆】--：
感谢大佬
--【柒】--：
感谢分享~~
--【捌】--：
那我什么时候有空搞一下
--【玖】--：
改一下配置即可 仓库有写
--【拾】--：
仅支持 Codex 还是 Claude 都支持
--【拾壹】--：
已经更新了
--【拾贰】--：
同期待！
--【拾叁】--：
应该合并到cpa里
--【拾肆】--：
更新了docker
--【拾伍】--：
感谢大佬的分享
--【拾陆】--：
合并不知道会不会有各种奇奇怪怪的bug呢 不如就这样
--【拾柒】--：
谢谢分享
--【拾捌】--：
谢谢分享
--【拾玖】--：
查额度可不建议频繁查吧
还有我想知道好用的注册机哪有= =！
本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：
- 我的帖子已经打上 开源推广 标签： 是
- 我的开源项目完整开源，无未开源部分： 是
- 我的开源项目已链接认可 LINUX DO 社区： 是
- 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是
- 以上选择我承诺是永久有效的，接受社区和佬友监督： 是
以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出
先感谢 LinuxDo 佬友 @jingtai123：
【CPA】Codex 401账号清理与额度耗尽停用脚本 开发调优找不到是哪个佬写的脚本改的。。。 修改内容与功能 新增了 api-call 主动探测。 全量探测，等同于CPA中的 配额管理 刷新，本次脚本运行只会完整探测一遍 默认是关闭的，只有加 --enable-api-call-check 才会跑，且只跑一遍 api-call探测方式： 一批同时探测 9 个，整批跑完以后，随机等待 5 到 10 秒，再继续下一批。这样比一个个串行扫。 额度耗尽的…
这个项目是在他的脚本思路基础上继续二开整理的。它主要以codex的认证文件为例。我主要补了 Web 控制台、配置保存、日志查看、报告摘要、systemd 部署支持、优化了额度用尽之后的管理逻辑，让它更适合长期挂着跑，也更方便日常维护。
GitHub：
GitHub - KJ20051223/CLIProxyAPI-cleaner: CLIProxyAPI-cleaner: a lightweight cleanup script...
CLIProxyAPI-cleaner: a lightweight cleanup script plus web dashboard for auth-file account management, reporting, and service control.
项目定位
CLIProxyAPI-cleaner 是一个面向 CPA / auth-file 管理场景 的轻量工具，包含两部分：
- 清理脚本主程序
- 可视化 Web 控制台
把原来偏脚本化、偏手工的流程，整理成一套更容易部署、观察和维护的日常实用方案。
Web 首页
image1229×897 127 KB
清理脚本运行逻辑
脚本整体思路是：拉取账号列表 → 分类判断状态 → 执行对应处理 → 记录状态 → 生成报告 → 定时进入下一轮。
1. 先获取 auth-file 列表
每轮开始时，脚本会先从管理端接口拉取当前 auth-file / 账号列表。
如果接口返回异常或者数据结构不对，就会直接报错退出当前轮，避免后面误操作。
2. 对账号做第一轮分类判断
脚本会根据账号当前返回的状态信息做初步分类。这里核心是几类情况：
- 可用账号
- 401 / 认证失效类账号
- 额度耗尽类账号
- 已经禁用的账号
- 不可用但暂时不直接处理的账号
脚本内部会通过一些规则和错误特征去识别，比如：
401unauthorizedinvalid_grantrefresh_token_reusedusage_limit_reachedquota429billingrate limit
也就是说，它不是只看一个字段死判断，而是结合状态码和错误信息一起归类。
3. 结合 /api-call 主动探测再做一轮修正
除了基础状态判断，脚本还支持用 /api-call 做一轮主动探测。
这一层的目的，是把“表面状态”和“真实调用结果”结合起来，减少误判。
比如有些账号：
- 表面上看着还行，但真实调用已经报 401
- 表面上没明显坏，但实际已经额度耗尽
- 还有些账号需要进一步探测才能知道是不是值得继续留着
所以这一步会把一部分账号重新归类成：
- delete_401
- quota_exhausted
- ok
- 其他待观察状态
这也是为什么脚本比“只看面板状态”更有用一点。
4. 对 401 / 认证失效账号执行清理
如果判定为 401 / 认证失效，脚本会进入删除逻辑。
处理方式大概是：
- 先尽可能备份相关 auth-file
- 再调用管理接口删除对应文件 / 账号
- 删除成功后写入本轮结果
- 删除失败则记录失败原因，留在报告里
这里不是无脑删，它会尽量保留备份路径和响应结果，方便后面排查。
5. 对额度耗尽账号先禁用，而不是立刻删
如果判定为 额度耗尽，脚本默认不是直接删除，而是：
- 先把账号标记为 disabled
- 同时把这个账号写入本地状态文件
- 记录下它什么时候被禁用、下一次什么时候做 revival 检查
这个设计的考虑很简单：
很多额度号不是“彻底死了”，而是“当前不能用，但过一段时间可能恢复”。
所以对这类账号，脚本走的是：
先禁用 → 等待窗口期 → 再做 refresh / revival probe
6. 本地状态文件负责“记住这些额度号后面怎么处理”
脚本会维护一个状态文件，用来记录这些被禁用账号的后续处理节奏。
状态文件里大概会记：
- 账号名
- 最近一次错误原因
- 什么时候进入禁用状态
- 下一次 revival 检查时间
- refresh / probe 的结果
这样脚本在下一轮跑的时候，不是“重新从零开始想”，而是能接着上一次的状态继续走。
7. 到了时间窗口后，进入 revival 流程
对已经因为额度问题被禁用的账号，等到了设定的等待周期以后，脚本会进入 复活检查流程。
这一段逻辑大概是：
- 读取 auth-file 内容
- 尝试做 token refresh
- refresh 成功后，再做一次实际 probe
- 根据 probe 结果决定后续动作
可能出现几种结果：
情况 A：refresh 成功，probe 也正常
那就说明账号恢复了，可以重新启用。
脚本会：
- 把账号从 disabled 改回可用
- 清掉本地状态里的追踪信息
- 在报告里记成“复活成功启用”
情况 B：refresh 成功，但 probe 后还是额度耗尽
说明账号暂时还是不行。
脚本会：
- 保持 disabled
- 重新安排下一次 revival 检查时间
- 继续留在状态文件里
情况 C：refresh 失败，而且失败原因像 401 / token 已废
这种账号通常就没必要继续留了。
脚本会：
- 备份
- 删除
- 从状态文件里清掉
情况 D：读取 auth-file 或处理过程中出错
那就先记错误，延后到下一轮再检查，避免一次异常直接把账号误删。
8. 可用账号会顺带清理旧状态
如果某个账号原本曾经被记录成额度耗尽，但后面重新变成可用状态，脚本会顺手把它在状态文件里的旧记录清掉。
也就是说，状态文件不是只增不减，而是会随着账号恢复情况动态清理。
9. 每轮都会生成报告
每次执行结束后，脚本都会输出结构化报告，里面会带上：
- 本轮 run_id
- 配置摘要
- 结果列表
- 汇总统计
- 当前状态快照
一般会看到这些统计项：
- 检查总数
- 可用账号数
- 额度账号已禁用数
- 已删除 401 数
- refresh 成功数
- refresh 失败数
- 复活成功启用数
- 复活仍限额数
- 删除失败数
- 禁用失败数
这个报告会被 Web 控制台拿来做摘要展示，所以页面上能直接看到“删了几个 401、禁了几个额度号、复活了几个”。
10. 支持单次执行，也支持循环运行
脚本既可以：
- 只跑一轮
- 也可以按固定间隔持续循环跑
如果是循环模式，就会按设定的 interval 周期，不断重复：
检查 → 分类 → 处理 → 记录 → 报告 → 等下一轮
所以它更适合挂成一个长期服务，而不是一次性脚本。
Web 控制台负责什么
Web 控制台本身不负责核心判定逻辑，它更像是脚本的一个操作面板。
主要作用是：
- 保存配置
- 启停 / 重启 cleaner 服务
- 查看 cleaner 日志
- 查看 Web 日志
- 展示最近报告摘要
- 做简单的状态观察
也就是说，核心逻辑在清理脚本里，控制台负责管理和可视化。
目前有的功能
- 清理脚本主逻辑
- Web 控制台
- 配置保存
- 一键启动 / 停止 / 重启 cleaner
- 一键 dry-run
- cleaner / web 日志查看
- 最近报告摘要展示
- systemd + Nginx 部署
- 默认中文 README + 英文 README
- MIT License
适用场景
这个项目比较适合下面这些情况：
- 本来就在跑类似清理脚本
- 不想每次都手工敲命令
- 想把参数配置、日志、报告集中管理
- 想让服务稳定长期跑着
- 想把这类脚本整理成一个可以分享和复用的小项目
当前状态
目前它还是偏 实用型 项目，优先解决真实使用场景中的问题。
不是特别追求大而全，但已经能比较顺手地跑起来了。
后面如果有时间，可能还会继续补这些东西：
- 更完整的报告筛选能力
- 多用户 / 权限控制
- 更顺手的部署体验
如果有佬友也在折腾类似需求，欢迎讨论，或者直接拿去改。
网友解答：--【壹】--：
感谢佬，期待docker
--【贰】--：
已更docker
--【叁】--：
控制台可以设置 复活环节是默认12h查一次 注册机可以去看冰佬的
--【肆】--：
期待docker版本
--【伍】--：
我没3级…被禁言过6个月…
--【陆】--：
感谢大佬
--【柒】--：
感谢分享~~
--【捌】--：
那我什么时候有空搞一下
--【玖】--：
改一下配置即可 仓库有写
--【拾】--：
仅支持 Codex 还是 Claude 都支持
--【拾壹】--：
已经更新了
--【拾贰】--：
同期待！
--【拾叁】--：
应该合并到cpa里
--【拾肆】--：
更新了docker
--【拾伍】--：
感谢大佬的分享
--【拾陆】--：
合并不知道会不会有各种奇奇怪怪的bug呢 不如就这样
--【拾柒】--：
谢谢分享
--【拾捌】--：
谢谢分享
--【拾玖】--：
查额度可不建议频繁查吧
还有我想知道好用的注册机哪有= =！