给 Codex/Claude/Gemini 账号池装一个驾驶舱：CPA-Manager 项目介绍

(Updated: )

如果你经常折腾 Codex CLI、Claude Code、Gemini CLI，或者手里维护着不止一个 AI 编程账号，大概率会遇到一个很现实的问题：

账号多了以后，真正麻烦的不是“怎么接上去”，而是“怎么知道它们现在还好不好用”。

哪个账号额度快满了？哪个账号已经 401 失效了？今天请求量多少？哪个模型最烧 token？如果一个个去看日志、翻配置、试请求，很快就会从“自动化提效”变成“人工巡检上班”。

最近看到一个挺实用的小项目：CPA-Manager。它不是新的大模型代理，也不是另起炉灶的一套网关，而是给 CLIProxyAPI 配的一套 Web 管理面板，重点补上了两个很刚需的能力：请求监控和 Codex 账号巡检。

项目地址：

先说 CPA 是什么

这里的 CPA，不是广告行业里的 Cost Per Action。

在这个语境里，CPA 指的是 CLI Proxy API，也就是 CLIProxyAPI 这个项目。

你可以把它理解成一个面向 AI 编程工具的“统一代理网关”。它能把 Codex、Claude Code、Gemini CLI、OpenAI-compatible API 等不同来源的账号、API Key、OAuth 登录，统一接到一个本地或服务器端服务里。

客户端只需要连 CPA 暴露出来的统一接口，背后到底走哪个账号、哪个上游、哪个模型，由 CPA 按配置和路由规则处理。

这件事的价值在于：很多 AI 编程工具本来各有各的认证方式、协议格式和模型入口。CPA 做的是把这些差异收口，让你可以用一个代理层统一管理。

CPA-Manager 是干什么的

CPA-Manager 的定位很清楚：它是 CLIProxyAPI 的 Web 管理中心。

也就是说，它不负责真正转发模型请求，不保存模型推理逻辑，也不是账号池本体。它通过 CLIProxyAPI 的 Management API 读取和修改运行状态，给你一个可视化界面。

官方 README 里对它的描述大致是：配置管理、提供商配置、认证文件、OAuth、配额、使用统计、运行时监控、日志和系统工具，都集中到一个界面里。

这次让我觉得有意思的，是它当前分支新增的两块能力。

第一块是 请求监控中心。

它会聚合 CLIProxyAPI 后端的 /usage、auth-files、openai-compatibility 等数据，展示请求量、成功率、失败来源、模型排行、Token 构成、延迟、RPM/TPM，以及估算花费。

如果你在跑多账号、多模型、多客户端，这个页面会比单纯看日志直观很多。你能快速知道：今天到底是谁在消耗额度，哪个模型请求最多，失败集中在哪个渠道。

第二块是 Codex 账号巡检。

这块更偏运维。它可以批量检查 Codex 认证池里的账号，判断哪些账号已经失效、哪些账号额度耗尽、哪些之前禁用的账号可以恢复启用。

巡检结果会给出建议动作，比如：

  • delete：接口返回 401，账号大概率失效，建议删除
  • disable：额度达到阈值，建议暂时禁用
  • enable：之前被禁用，但现在恢复健康，建议重新启用
  • keep：状态正常，保留

对于有一批 Codex 账号池的人来说，这个能力很实用。它把“人工试账号”的动作变成了批量探测和批量处理。

它的工作原理

从代码看，CPA-Manager 的前端是 React + TypeScript + Vite。它主要调用 CLIProxyAPI 的 /v0/management 管理接口。

真正有意思的是巡检逻辑。

CPA-Manager 会先通过管理接口拿到认证文件列表，也就是 CPA 后端维护的 auth files。然后它筛出 provider 为 codex 的账号，并读取每个账号对应的 auth_index。

接下来，它不是在浏览器里直接拿 token 去请求 OpenAI，而是调用 CPA 后端的通用管理接口：

1
POST /v0/management/api-call

这个接口可以让后端“代替管理端”发起一次 HTTP 请求。请求里可以带上某个 auth_index，后端会找到对应账号，并把请求头里的 $TOKEN$ 替换成该账号的真实 token。

Codex 巡检探测的目标地址是：

1
https://chatgpt.com/backend-api/wham/usage

也就是说，它实际是在问 ChatGPT/Codex 后端：这个账号现在的 usage 和 rate limit 状态是什么。

返回之后，CPA-Manager 会解析里面的额度窗口。它会区分 5 小时窗口和周窗口，重点看周额度是否达到阈值。如果周额度满了，就建议禁用；如果只是 5 小时额度满但周额度仍可用，一般不会直接禁用。

这个设计比较聪明，因为短窗口额度和长周期额度的处理策略不一样。短窗口满了，等一等可能就恢复；周额度满了，继续分配请求就会造成更多失败。

为什么这个项目值得看

我觉得 CPA-Manager 的价值，不在于界面多复杂，而在于它补上了 AI 账号池运维里最容易被忽视的一环：可观测性。

当你只有一个账号时，额度、失败、延迟都可以靠感觉。

但当你开始维护多个 Codex、Claude、Gemini 账号，甚至给不同客户端、不同模型做路由时，“靠感觉”就不够了。你需要知道真实的运行状态：

  • 账号是否还活着
  • 哪些账号正在消耗额度
  • 哪些账号应该临时下线
  • 请求失败是不是集中在某个模型或上游
  • 当前使用量大概对应多少成本

这些信息如果散落在日志、配置文件和手工测试里，就很难形成判断。CPA-Manager 把它们集中到一个 Web UI 里，运维效率会高很多。

适合谁用

这个项目比较适合几类人：

第一类，是已经在用 CLIProxyAPI 的用户。CPA-Manager 可以直接作为管理面板补充进去。

第二类，是有多账号 AI 编程需求的人。比如你同时使用 Codex、Claude Code、Gemini CLI，希望把它们统一代理、统一监控。

第三类，是在做 AI coding relay、账号池调度、团队内部网关的人。你未必直接拿它上线，但它的管理接口设计、巡检逻辑、usage 聚合方式都值得参考。

如果只是单账号、轻度使用，那它可能有点重。毕竟 CPA 这一套东西本来就是为“多客户端、多账号、多模型路由”准备的。

使用时要注意什么

这类项目一定要重视安全边界。

CPA-Manager 连接的是 CLIProxyAPI 的 Management API，管理密钥能访问配置、认证文件、日志、使用统计，甚至能对账号执行禁用、启用、删除等操作。

如果你开启远程管理，一定要确认：

  • 管理密钥足够强
  • 管理端口没有裸露在公网
  • 只在可信设备和网络里打开面板
  • 账号 token、auth files、usage 数据都按敏感信息处理

换句话说，它是一个很方便的驾驶舱，但驾驶舱不能随便给人开门。

总结

CPA-Manager 做的事情可以用一句话概括：

它给 CLIProxyAPI 加了一个更好用的 Web 运维面板，尤其强化了请求监控和 Codex 账号池巡检。

如果你正在用 CPA 管理 Codex、Claude、Gemini 这类 AI 编程工具，它能帮你从“配置能跑”进一步走到“状态可见、账号可管、问题可定位”。

项目本身不神秘，但方向很实在：AI 工具越来越多，账号和额度越来越碎，最终大家都需要一个统一代理层，也需要一个能看清代理层运行状态的面板。

这类工具，可能不会让模型更聪明，但会让使用模型的人少掉很多无意义的排查时间。

项目地址再放一次：