2026-06-02 更新：CPA-Manager 已进入 Plus 主线，推荐升级

CPA Manager Plus 已经发布首个正式版。后续新功能、部署文档和主要维护都会以 Plus 为主，旧 CPA-Manager 仍然可以继续作为历史版本使用，但新部署和长期使用都建议直接升级到 Plus。

Plus 正式版发布帖：

Plus 项目地址：

迁移指南：

为什么推荐升级到 Plus？

CPA-Manager 最开始主要是为了解决一个很明确的问题：CPA 移除内置用量统计后，如何把请求监控和账号巡检能力补回来。

Plus 在这个基础上继续往前做了一层，不只是换了个名字，也不只是多了几个 v1.0.0 的功能点，而是把整体定位调整成了一个更完整的 CPA 运维后台。

简单来说：

旧 CPA-Manager 更像是“把 CPA 的统计和巡检补回来”；CPA Manager Plus 更像是“给 CPA 做一个长期可用的管理和运维控制台”。

Plus 主要升级点包括：

• 部署边界更清楚：区分「完整 Docker / Manager Server」和「CPA 托管控制面板」两种模式，避免把面板和 Usage Service 混在一起理解。

• 登录方式更合理：完整 Docker 方案使用 Manager Admin Key 登录，CPA Management Key 会在服务端加密保存。

• 统计能力更完整：请求级事件持久化到 SQLite，并支持更多维度的聚合、筛选和查看。

• 监控中心更实用：可以按账号、模型、渠道、API Key 等维度拆解请求情况，更方便排查异常请求和失败来源。

• 首页更像仪表盘：可以集中看到请求趋势、健康状态、Token、费用估算和失败情况。

• 成本分析更细：支持模型价格、Token 费用估算、缓存 token 等统计。

• Codex 巡检更完整：除了浏览器本地巡检，也支持服务端巡检、定时任务、历史记录和清理建议。

• 数据能力更强：支持 SQLite 持久化、用量导入导出、旧数据迁移和 API Key 别名。

• 运行方式更多：除了 Docker 镜像，也提供 Windows、macOS、Linux 原生包。

• 后续维护方向更明确：Plus 会作为推荐主线版本继续维护。

哪些用户建议升级？

新部署用户建议直接使用 CPA Manager Plus，不再从旧 CPA-Manager 开始。

已经在使用旧 CPA-Manager 的用户，也建议迁移到 Plus。迁移后可以保留旧用量数据，同时获得更清晰的部署边界和后续主线更新。

如果你需要长期监控账号池、排查失败请求、统计模型 / 渠道 / API Key 用量，建议使用 Plus 的完整 Docker / Manager Server 方案。

如果你只是想改 CPA 配置，不需要历史统计、模型价格、API Key 别名和服务端巡检，也可以继续使用 CPA 托管面板方案。不过面板仓库仍然建议改成 Plus，这样后续可以继续拿到新面板更新。

迁移提醒

从旧 CPA-Manager 迁移前，请先备份旧的 /data 目录，至少要包含：

usage.sqlite
usage.sqlite-wal
usage.sqlite-shm

Plus 首次启动后会新增 data.key。之后备份时不能只备份 SQLite 文件，也必须同时备份 data.key，否则加密保存的配置可能无法恢复。

另外需要注意，完整 Docker / Manager Server 方案的登录凭证会从原来的 CPA Management Key 变为 Manager Server 管理员密钥。CPA Management Key 仍然需要填写，但它会由 Manager Server 加密保存，用来连接你的 CPA 实例。

节前开源了 CPA-Manager，并在社区里做了一次简单宣传。没想到收到了不少佬的认可，也有不少佬在使用过程中提出了建议，所以专门开一贴，用来集中收集大家比较迫切的需求，同时同步后续开发进度。

先上运行截图

为什么会有这个项目？

我自己一直在使用 CPA，最早是从反重力入坑的。

官方面板本身已经覆盖了基础管理能力，但我实际使用时一直有几个痛点：请求情况不够直观、账号池里每个账号的消耗不好观察、出问题后不容易快速定位是哪个模型、哪个渠道、哪个账号在异常。

后来也试过一些社区二开面板和其他项目，但始终觉得还差一点，不完全是我想要的形态。再加上 OpenAI 开始收紧 free 账号额度后，我更迫切地需要知道号池里每个账号到底用了多少、还有多少、什么时候该禁用或清理。

所以最后干脆自己做一个更符合自己使用习惯的 CPA 管理面板，CPA-Manager 就这样诞生了。

CPA-Manager 是什么？

CPA-Manager 是一个基于 CLI Proxy API 官方管理接口二开的管理和监控面板。

它保留 CPA 原本的管理能力，同时补上了我自己比较需要的几类能力：

• 请求监控和用量统计
• Codex 账号巡检
• 可选的 Usage Service 持久化统计服务

项目完全开源，后续也会持续维护。

部署方式

目前推荐按入口区分两种主要用法：

• CPA 控制面板方案：继续使用 CPA 托管的 /management.html

  • 入口：http://<cpa-host>:8317/management.html
  • 适合已有 CPA 部署，保留 CPA 自动载入面板的使用方式
  • 如需请求监控，再单独部署 CPA-Manager Usage Service，并在「配置面板 → CPA-Manager 配置」中填写 Usage Service 地址

• 完整 Docker 方案：使用 CPA-Manager Usage Service 托管面板和统计服务

  • 入口：http://<host>:18317/management.html
  • 首次 setup 填写 CPA 地址和 Management Key
  • setup 完成后，新浏览器只需要输入 Management Key，会自动使用服务端保存的 CPA 连接

Docker 镜像：

docker run -d \
  --name cpa-manager \
  --restart unless-stopped \
  -p 18317:18317 \
  -v cpa-manager-data:/data \
  seakee/cpa-manager:latest

完整 Docker 方案不包含 CPA 本体，CPA 仍需单独运行。首次 setup 时 CPA 地址可填写：

• Docker Desktop 访问宿主机 CPA：http://host.docker.internal:8317
• 同一 compose 网络：http://cli-proxy-api:8317
• 远程 CPA：https://your-cpa.example.com

推荐 CPA 版本：>= v6.10.8

如果要使用持久化请求统计，需要启用 CPA 用量发布：

usage-statistics-enabled: true

也可以在 CPA-Manager 初始化或保存 CPA-Manager 配置时启用请求监控，面板会自动调用 CPA Management API 打开该开关。

CPA-Manager 常见问题与解决方案

参考这里#23

这个帖子想收集什么？

希望大家可以集中反馈：

• 目前最想要的功能
• 哪些页面用起来不顺手
• Docker / Usage Service 部署是否有坑

我会根据反馈频率、实现复杂度和实际使用价值来排优先级，并在这个帖子里同步开发节点。

TODO List

• 支持多 CPA 实例配置、切换和数据隔离。

• 增加服务端 Codex 定时 / 随机巡检能力。(已在CPA-Manager-Plus 中实现)

• 持久化 Codex 巡检历史记录并支持查询。(已在CPA-Manager-Plus 中实现)

• 在 Codex 巡检结果中显示认证 JSON 文件名。

• 配额管理新增搜索、排序、Codex 套餐等级识别与 Codex 区块前置。

• 提供 Windows / macOS / Linux 原生运行包。

• 增加 CPA-Manager 自身版本更新检查。

• 完成 Usage Service 数据持久化。

• 完成请求统计数据导出和导入。

• 完成 HTTP 采集优先和 RESP fallback。

• 完成监控中心分页、筛选和模糊搜索。

• 完成监控中心 Codex 账号额度查询。

• 完成系统页 CPA-Manager 前端版本和 CPA API 版本展示。

• 持久化 CPA-Manager 配置。

• API Key 维度筛选

反馈格式建议

请注意按照下面的格式来反馈，有些佬上来就一张截图，没有说明是怎么操作的，是怎么配置的，是否按照文档指引完成部署的。这样的属于无效反馈，不能让我分析是什么原因，因此也无法做出有效的回应。

需求类型：功能 / 优化 / Bug / 部署问题
使用场景：
期望效果：
当前问题：
补充说明：

项目地址：

GitHub：GitHub - seakee/CPA-Manager: This is a WebUI interface based on CLI-Proxy-API, designed to simplify configuration modifications and runtime status monitoring. · GitHub

感谢各位佬之前的反馈和支持。这个项目最开始只是为了解决我自己的使用痛点，如果也能帮到更多正在维护 CPA 账号池的佬，那就很值得继续做下去。

同时如果对佬们有帮助，欢迎点个 Star，也欢迎提 issue 或 PR。

更新日志

感谢佬的奉献！

那个巡检的功能，有没有可能设定在一段时间内，比如 6 个小时，它随机时间段巡检？我觉得这样可能可以避免短时内同一 ip 大量请求多个账号带来的 401

Zhsing (Zhsing) 2026 年5 月 6 日 02:27 3

可以加多搜索框吗？有时候想看某个账号的情况，一个一个找

wya (wya) 2026 年5 月 6 日 02:30 4

佬，这个有导入之前的数据的功能吗？我好像没找到导入的入口

MarkHk (Mark) 2026 年5 月 6 日 02:44 5

看看可不可以把我之前自己搞的那个优先级批量自动设置加进去啊
用户可以根据分组设置，比如team > plus > free
然后自动根据各组里的账号数量分配优先级序号
优先级序号的排序方式: 分组优先级 > 额度刷新时间最近的账号 > 额度剩余最少的账号 > 账号名称排序

windows上配置了面板地址，为什么一直显示404啊？是不支持吗

PhilFan 2026 年5 月 6 日 02:49 7

支持支持！
CPA 确实管理查找多个账号有点不方便诶

Walden1 2026 年5 月 6 日 03:29 8

佬,render部署的cpa,本地部署的manager统计是空的

seakee 2026 年5 月 6 日 04:26 9

curl -H "Authorization: Bearer $CPA_KEY" http://<usage-service>:18317/status 

superlei (🍉) 2026 年5 月 6 日 05:20 10

巡检后 401的账号直接删除吗 佬，能不能不删除啊？

Syl 2026 年5 月 6 日 05:23 12

让子弹飞一会:tieba_001谁的星星多我就选谁

现版本缺少了对每个key的请求调用情况统计，这个我觉得可以加上

这个需要部署独立的后台服务才能用，用docker部署的那个

ftper (噩梦之塔) 2026 年5 月 6 日 06:39 16

明白了，谢谢佬。我去部署下试了下，在ClawCloud Run部署失败，

seakee 2026 年5 月 6 日 06:39 17

seakee 2026 年5 月 6 日 07:01 18

如果你在巡检配置中配置巡检完成后自动执行建议操作那么巡检完后就自动删除了，如果没有巡检完成后自动执行建议操作，那么就可以手动管理

darkkid 2026 年5 月 6 日 07:33 19

keyzal (二师兄) 2026 年5 月 6 日 14:05 20

账号汇总和实时更新有实时数据，但是面板上面的面板数据固定不变动