7 个 AI 编程套餐，每天开 7 个标签页查额度？我写了个看板一屏搞定

先说结论

如果你同时订阅了 Codex、MiniMax、火山方舟、Kimi Code、LongCat、千问 AI、Google AI 等多家 AI 编程套餐，大概率体验过一种痛苦：每天要在 7 个不同网站、7 套不同的登录体系里反复查看"还剩多少额度"。我开源了一个自托管的配额看板 coding-plan-dashboard，一条 docker compose up -d 启动后，所有平台的额度百分比、重置倒计时、多账号信息全部聚合在一个深色页面上，打开浏览器就能看到。本文写作与截图时间为 2026 年 7 月 25 日。

为什么需要这个东西

2025 年下半年到 2026 年，AI 编程工具像雨后春笋一样冒出来。OpenAI 推出了 Codex，Anthropic 的 Claude Code 越来越普及，国内的火山方舟、Kimi Code、MiniMax、LongCat、千问 AI 也纷纷上线了面向编程场景的月度套餐。Google 的 Gemini 系列通过 Antigravity 等工具也进入了这个战场。

对于像我这样"哪个便宜用哪个、哪个额度没用完用哪个"的开发者来说，多平台订阅几乎不可避免。但问题来了——每家平台的配额查询方式都不一样：

• Codex 要登录 ChatGPT 后台看 /usage 页面；
• MiniMax 要去它的控制台找 Token Plan 页面；
• 火山方舟的 CodingPlan 和 AgentPlan 在控制台的不同位置；
• Kimi Code 的订阅统计藏在另一个接口里；
• LongCat 的额度在付费中心的 Token 包页面；
• 千问 AI 的 TokenPlan 在一个数据接口里；
• Google AI 的用量又是另一套 OAuth 流程。

这就像你同时在 7 家不同的健身房办了月卡，每次去之前都要打开 7 个 App 看"今天还能不能用"。不是不能用，就是烦。

它长什么样

先上图。这是我在局域网内部署的看板实际运行效果：

页面顶部有四个汇总卡片：账号数（我目前导入了 9 个账号）、总限额（800 次）、已使用量（470.022 次）和最近一次数据刷新时间。右上角有一个锁图标（表示数据仅局域网可访问）和一个"刷新可用数据"按钮。

往下滚动，每个平台一张卡片，左右两列排列：

以 Codex 卡片为例：它显示当前使用的是 NewAPI 代理通道，有 2 张可用的重置卡，最近一次重置到期时间是 2026 年 8 月 12 日；周额度已使用 90.0%，剩余 10.0%；右上角还有一个实时的重置倒计时——"重置等待 6 天 14 小时 51 分 24 秒"。MiniMax 那边则显示 5 小时窗口已使用 92.0%，进度条用渐变色标出了用量。

这种"一眼看完所有平台"的体验，就像把 7 家健身房的 App 合并成了一个统一的健康面板：你不用记住每家健身房的 App 密码，也不用在 7 个界面之间来回跳。一个页面，一目了然。

火山方舟区域更典型——我同时导入了多个账号的 CodingPlan 和 AgentPlan，每个账号独立一张子卡片，显示各自的使用百分比和重置时间。这就像一家人办了多张健身卡，面板上每张卡的状态分开显示，不会混在一起。

Kimi Code 和 LongCat 的卡片风格一致：百分比数字 + 彩色进度条 + 重置倒计时。LongCat 显示已使用 28.0%，而 Kimi Code 的多个账号分别显示 5.7%、10.2% 和 23.6%——多账号的好处在这里体现得淋漓尽致：当一个账号快用完时，看一眼就知道该切到哪个账号。

千问 AI 的 TokenPlan 和 Google AI（Gemini 3.5 Flash）也各有自己的卡片。Google AI 显示使用率 0.0%，因为它的 OAuth 刷新机制比较特殊，需要在环境变量里配置 OAuth 客户端凭证后才能正常拉取数据。

它是怎么工作的

整个项目的架构可以用一句话概括：你在浏览器里粘贴一段 curl 命令，服务器解析后用 Python 重新发请求，把结果缓存成 JSON，前端读取 JSON 渲染成卡片。

把它想象成一个"代取快递"服务：你把 7 家快递公司的取件码（curl 命令里的 Cookie、Token、Header）交给一个管家（server.py），管家每天帮你跑一圈，把每家快递的状态（额度百分比、重置时间）记在一张表上（snapshot.json），你只需要看这张表就行了。

具体流程：

1. 导入 curl：在页面底部的文本框里粘贴从浏览器开发者工具复制的原始 curl 命令。服务器根据 URL 自动识别是哪个平台——比如 URL 包含 chatgpt.com/backend-api/wham/usage 就归类为 Codex，包含 www.minimaxi.com 就归类为 MiniMax，以此类推。
2. 服务器重放请求：server.py 不会调用 shell 执行 curl，而是用 Python 的 HTTPS 库解析 curl 里的 Header、Cookie、请求体，然后重新发出请求。这意味着即使你的 curl 里带了 --proxy 或 --insecure 参数，服务器也能正确处理。
3. 结果持久化：每次刷新后的 API 响应会保存到 snapshot.json 和 results.json。容器重启后，页面先显示缓存快照，再静默刷新到最新数据——不会出现"白屏等加载"的情况。
4. 前端渲染：index.html 是一个完全自包含的单文件前端，没有任何外部 CDN 依赖。每个平台的卡片显示使用百分比（精确到小数点后一位）、彩色进度条和实时倒计时。

多账号和特殊平台支持

看板支持同一平台导入多个账号，每个账号有独立的标签、编辑、删除（需要二次确认）和拖拽排序功能。这对于"一个账号快用完就切另一个"的场景特别实用——你不用在浏览器里来回切 Cookie，看板上所有账号的状态一字排开。

火山方舟还支持一种"免 curl"的导入方式：直接在卡片上填写 Access Key 和 Secret Key，服务器用 HMAC-SHA256 V4 签名调用 GetCodingPlanUsage 或 GetAgentPlanAFPUsage 接口。这比每次从浏览器复制 curl 要稳定得多，因为 AK/SK 不会像浏览器 Cookie 那样过期。

Codex 还支持 NewAPI 代理通道：如果你的 Codex 是通过 NewAPI 中转的，可以导入 NewAPI 的 /api/channel/{channelId}/codex/usage 地址，服务器会自动跳过官方接口，避免 401 报错的噪音。

部署只需要 Docker

整个项目只有三个核心文件：index.html（前端）、server.py（后端）、docker-compose.yml（容器编排）。部署步骤如下：

# 1. 克隆仓库
git clone https://github.com/margrop/coding-plan-dashboard.git
# 2. 进入目录
cd coding-plan-dashboard
# 3. 创建数据目录
mkdir -p data && chmod 700 data
# 4. 启动
docker compose up -d
# 5. 浏览器打开 http://你的服务器IP:8080

就这五步。默认监听 8080 端口，如果被占用，改一下 docker-compose.yml 里的 PORT 环境变量即可。容器里的数据挂载到宿主机的 data/ 目录，包含四个 JSON 文件：

• requests.json：你导入的所有 curl 命令（含 Token / Cookie，视为机密）
• credentials.json：火山方舟的 AK/SK 配置
• snapshot.json：最新一次配额快照
• results.json：每个账号的 API 原始响应缓存

如果你用 Portainer 管理 Docker，也可以直接在 Portainer 里创建一个 Stack，把 docker-compose.yml 的内容粘贴进去，点 Deploy 就行。前提是本机上已经有 index.html、server.py 和空的 data/ 目录。

三个平台的一键部署脚本

下面三份脚本做的事情完全一样：从 GitHub 克隆仓库、创建数据目录、启动 Docker 容器。脚本不上传任何配置、不调用第三方服务、不依赖外部配置平台；它们需要你本机已经安装了 Docker Engine 和 Docker Compose v2。

• Windows 11 PowerShell 一键脚本
• Ubuntu 26.04 Bash 一键脚本
• macOS 26 Zsh 一键脚本

人工执行方式：下载对应脚本，在终端里运行即可。脚本会在当前用户 home 目录下创建 coding-plan-dashboard 文件夹并启动容器。

Agent 自动配置方式：把下面的提示词发给你的 AI 编程 Agent（Claude Code、Kimi Code、Cursor 等），它会自动下载并执行脚本：

请从 https://github.com/margrop/coding-plan-dashboard 克隆仓库，
在当前用户 home 目录下创建 coding-plan-dashboard 部署目录，
执行 docker compose up -d 启动容器，
然后告诉我访问地址。

安全性怎么说

这是我被问得最多的问题，也是做这个项目时最在意的部分。

服务器不会调用 shell 执行 curl。导入的 curl 命令被 Python 解析后，用标准 HTTPS 库重新发请求。不存在命令注入的风险。

域名白名单。服务器只允许向 chatgpt.com、www.minimaxi.com、console.volcengine.com、www.kimi.com、longcat.chat、cs-data.qianwenai.com 以及你手动配置的 NewAPI 地址发请求。不会向任意地址发 HTTPS 请求。

凭证本地存储。requests.json 和 credentials.json 保存在宿主机 data/ 目录里，权限设为 700（仅 owner 可读写）。不要把它们提交到 Git 仓库，也不要把备份文件传到公网。

建议仅局域网访问。默认 8080 端口没有任何认证机制，所以请确保只有受信任的设备能访问。如果你有公网暴露的需求，请自行在前面加一层反向代理和认证。

打个比方：这个看板就像你家客厅里的一个智能中控面板，它帮你查看各个房间的状态，但面板本身没有锁——所以你应该把它放在家里（局域网），而不是挂在小区大门口（公网）。

和其他类似工具的对比

社区里已经有一些类似的项目，比如 macOS 菜单栏工具 ai-quota，可以在状态栏显示 Codex 和 Claude Code 的用量；还有 AI Usage Monitor 这样的 Claude Code Skill，可以在终端里查看多平台额度。它们各有优势：

• ai-quota：macOS 原生体验好，但只支持 Codex 和 Claude Code，且仅限 macOS；
• AI Usage Monitor：集成在 Claude Code 里方便，但需要 cclimits 工具配合，且覆盖面有限；
• Kimi Code Usage MCP：专注 Kimi Code 一个平台，提供 MCP Server 和 VS Code 插件。

coding-plan-dashboard 的定位不同：它是一个平台无关、全聚合、自托管的 Web 看板。不挑操作系统（有浏览器就行），不挑 AI 编程工具（看的是配额，不是工具本身），支持 7 家平台且可以随时扩展。如果你只用一两家平台，上面那些轻量工具可能更顺手；但如果你像我一样"广撒网"，一个统一的看板会省掉大量切换成本。

常见问题

Q: 我的 curl 里有 Token，安全吗？

Token 会被明文存储在 data/requests.json 里，和你在浏览器 Cookie 里存 Token 的安全级别一样。服务器不会把 Token 发送到白名单以外的任何地址。但请确保 data/ 目录权限为 700，并且不要把备份文件上传到公网。

Q: 容器重启后数据会丢吗？

不会。所有导入的 curl 和配额快照都保存在宿主机挂载的 data/ 目录里。容器重启后页面会先显示上次的缓存快照，然后在后台静默刷新。

Q: 支持哪些平台？能不能扩展？

当前支持 Codex、MiniMax、火山方舟（CodingPlan + AgentPlan）、Kimi Code、LongCat、千问 AI、Google AI（Gemini 3.5 Flash / Antigravity）。新增平台需要在 server.py 里添加 URL 识别规则和解析逻辑，在 index.html 里添加对应的卡片渲染模板。项目的 AGENTS.md 里有详细的开发指引。

Q: 火山方舟的 AK/SK 方式比 curl 好在哪？

浏览器 Cookie 会过期，curl 命令里的 Token 也会失效。AK/SK 是长期凭证，只要不手动轮换就不会过期。而且 AK/SK 方式走的是 HMAC-SHA256 V4 签名，不需要依赖浏览器的登录状态，更稳定。

Q: 能部署到公网吗？

技术上可以，但强烈不建议。看板没有内置认证，任何人访问都能看到你的配额信息（虽然看不到 Token 原文，但能看到用量和账号标签）。如果一定要公网访问，请在前面加 Nginx / Caddy 反向代理并启用 Basic Auth 或 OAuth。

项目地址和贡献

项目完全开源，MIT 协议：

• GitHub 仓库：github.com/margrop/coding-plan-dashboard
• 问题反馈和 PR 欢迎在 GitHub Issues 里提
• 测试覆盖：node --test tests/parser.test.js 和 python3 -m unittest discover -s tests

如果你觉得这个项目有用，给个 Star 就是最大的鼓励。如果你在用某个我没覆盖到的平台，欢迎提 PR 或者 Issue，我可以加上。

最后说一句：AI 编程套餐越来越多，每家都在卷价格、卷模型、卷额度。但作为用户，我们真正需要的不是"更多套餐"，而是"更清楚地知道每个套餐还剩多少"。这个看板解决的就是这最后一步的信息整合问题。希望它也能帮到你。