先放能直接验证的东西：

• 仓库： https://github.com/cnwinds/cursor-pulse
• 额度看板 / 用量分析 / 支出管控三张真实后台截图（匿名演示数据）： https://github.com/cnwinds/cursor-pulse/blob/master/README_CN.md#快速预览

为什么做

我们的存量场景是：团队已经合规、分散地持有多把独立 Cursor 账号（不同成员各持一把，台账在内网维护）。运维上最难的不是「再买一个 Cursor 」，而是额度快耗尽时往往后知后觉——得在官网、表格和群里拼信息。想要一个数据留在自己机器上的聚合看板，于是写了 Cursor Pulse ，MIT 开源。

三个核心能力（按优先级）：

1. 额度看板 + 耗尽预测：对齐 Cursor Plan & Usage 的 billing cycle ，标 warning / exhausted ，给出预计耗尽日期（线性外推，周期早期误差会大）
2. 用量分析：日历区间按账号、模型、Token 看结构——与看板计费周期口径不同，别直接对数字
3. On-Demand 支出管控：同步时可检测并尝试关闭按量支出，状态变化通知管理员

凭据经应用层加密后入库；默认栈是 Web + DB + channel 同步进程，钉钉/飞书 IM 、借 Key 与 MITM Proxy 都是可选扩展。

技术栈：Python 3.11+（ Pulse 控制面）、Vue 管理后台、SQLite/Postgres 、Docker Compose 部署；同步走 Cursor User API Key → 未公开 HTTP 接口（仓库内 docs/cursor-usage-api.md 有笔记）。

限制（请先看再部署）

• 独立非官方项目，与 Cursor / Anysphere 无隶属关系
• 依赖 Cursor 未公开 API，可能失效，也可能与 ToS 冲突——见 NOTICE
• 成员维度是账号主使用人字段，不是「谁在 IDE 里敲代码」级追踪
• 首次绑 Key 后需等同步周期才有看板数据；setup.sh 生配置不是零配置

想征集三类具体反馈（回帖或 GitHub Issue 均可，请带环境信息）：

1. Docker 部署卡点（ OS 、Compose 版本、报错摘要）
2. 同步/看板口径与 Cursor 官网不一致的可复现 case
3. 多账号台账 + 耗尽预测 UI/交互上不顺手的地方

建议先看 README_CN 的适合/不适合，再决定是否试部署；有用的话欢迎 Star 方便检索，但不必为 Star 而 Star 。