AI 编程套餐额度看板搭建教程:用 Docker 聚合 Codex、Kimi Code、千问等平台用量

如果你同时订阅多个AI编程平台,每天查余额很麻烦。本文教你用Docker部署一个自托管的coding-plan-dashboard看板,聚合Codex、Kimi Code、千问等平台用量,在一个页面掌握所有配额与重置倒计时

AI 编程套餐额度看板搭建教程:用 Docker 聚合 Codex、Kimi Code、千问等平台用量 的技术主题封面图

为什么需要聚合看板?多平台订阅的日常痛点

如果你同时订阅了 Codex、MiniMax、火山方舟、Kimi Code、LongCat、千问 AI 和 Google AI 这些编程套餐,应该体验过那种“每天打开七个标签页挨个查余额”的烦躁。每个平台的配额查询入口都不一样:MiniMax 要去控制台找 Token Plan 页面,火山方舟的 CodingPlan 和 AgentPlan 藏在控制台的不同位置,Kimi Code 的订阅统计在一个不起眼的接口里,LongCat 的额度在付费中心的 Token 包页面,千问的 TokenPlan 在数据接口里,Google AI 还得走一套 OAuth 流程。

这种零散的查询方式不仅浪费时间,还容易漏查。你可能在写代码中途突然发现某个工具额度用完了,工作节奏被打断。问题在于你并没有一个统一的视角去掌握所有平台的剩余量。如果你也有类似的烦恼,那么下面这个自托管看板可能就是你要找的解决方案。如果你还在考虑订阅哪些平台,可以参考我们之前的 AI 编程工具推荐 2026 文章,里面详细对比了各平台的优缺点。

适合谁?不适合谁?

AI 编程套餐额度看板搭建教程:用 Docker 聚合 Codex、Kimi Code、千问等平台用量 的控制台操作场景图

适合人群:已经订阅或计划订阅两个以上 AI 编程套餐的开发者,每天需要多次查看各平台剩余额度,想要在一个页面里一眼掌握所有配额,并且对数据隐私有要求,愿意用 Docker 自己部署一个本地看板。典型的用法是:你同时开着 Codex、Kimi Code 和千问,想快速知道哪个额度快用完了、该切换到哪个账号去。

不适合人群:如果你只用一个 AI 编程平台(比如只用 Codex),或者你不在乎多花一两分钟手动查余额,那这个看板对你来说意义不大。另外,如果你对 Docker 命令行完全不熟悉、也不想折腾,建议直接用各平台官网的查询页面,没必要专门搭一个容器。

什么时候推荐部署:当你发现每天为了查额度要开 5 个以上的标签页,或者某个平台的配额重置时间总是记错,又或者你给团队采购了多个账号、分配额度变得很麻烦——这时候就该动手了。

coding-plan-dashboard 看板能做什么?核心功能一览

AI 编程套餐额度看板搭建教程:用 Docker 聚合 Codex、Kimi Code、千问等平台用量 的服务器与网络架构说明图

coding-plan-dashboard 是一个开源的配额看板项目,用 Docker 一条命令就能启动。它把多个 AI 编程平台的配额聚合在一个深色页面上,每个平台一张独立卡片,显示使用百分比、彩色进度条和实时重置倒计时。

支持的平台

  • Codex(含 NewAPI 代理通道)
  • MiniMax
  • 火山方舟(CodingPlan / AgentPlan)
  • Kimi Code
  • LongCat
  • 千问 AI
  • Google AI(Gemini 系列)

页面顶部还有四个汇总卡片:账号数、总限额、已用总量和最近刷新时间。右上角有一个锁图标(表示数据仅局域网可访问)和一个“刷新可用数据”按钮。

多账号管理

如果你一个平台有多个账号(比如火山方舟的多个子账号),每个账号会显示独立的子卡片,百分比和重置时间各自分开,不会混在一起。

数据持久化

每次拉取后结果会缓存到本地 JSON 文件中,容器重启后先显示缓存再静默刷新,不会出现白屏等待。

NewAPI 代理通道

对于通过 NewAPI 中转使用 Codex 的用户,可以直接导入 NewAPI 的中转地址,跳过官方接口的 401 报错。

部署前置条件与注意事项

在看开始部署之前,请确认你的环境满足以下条件,否则后续步骤可能会卡住。

硬件要求

  • 一台 Linux 服务器、树莓派、NAS 或者任何能跑 Docker 的设备。
  • 建议内存至少 512MB(低配 VPS 例如 RackNerd 的入门方案也能跑)。128MB 内存的设备不保证稳定运行,实际体验可能很慢。
  • 磁盘空间:项目本身很小(几个文件),但缓存数据会随时间增长,预留 1GB 足够。

软件要求

  • Docker Engine 版本 20.10+(推荐最新稳定版)
  • Docker Compose v2(通常随 Docker 一起安装,如果单独安装请确认 docker compose 命令可用)

网络要求

  • 确保设备能正常访问 GitHub(或配置了国内镜像源),因为需要 git clone 拉取源代码。
  • 默认端口 8080,请确保该端口没有被占用。如果被占用,可以修改环境变量 PORT

安全提醒

看板默认没有任何认证机制,强烈建议只在局域网内使用。如果需要在公网访问,请自行在前方加一层反向代理(如 Nginx)和 HTTP 基本认证。在部署之前,你还可以参考站内的 VPS 安全加固指南 来提升整体安全性。

一步一步部署看板(Docker Compose 方式)

部署过程分为五步,非常简洁:

  1. 克隆仓库
   git clone https://github.com/your-repo/coding-plan-dashboard.git

(具体仓库地址请以项目 README 为准)

  1. 进入目录并创建 data 子目录
   cd coding-plan-dashboard && mkdir data

如果需要修改端口或添加环境变量,可以编辑这个文件。例如将 8080 改为 9090

  1. 编辑 docker-compose.yml(可选)
  1. 启动容器
   docker compose up -d

打开浏览器,输入 http://<你的机器IP>:8080

  1. 访问看板

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

整个项目只有三个核心文件:index.html(前端)、server.py(后端)、docker-compose.yml(编排)。容器启动后没有外部 CDN 依赖,所有资源都是自包含的。如果你对 Docker 不太熟悉,可以阅读站内的 Docker 部署开源项目教程 作为补充。

验证看板是否正常运行

部署完成后,不要急着导入 curl,先确认看板本身工作正常:

  1. 在浏览器中打开 http://<你的机器IP>:8080,应该能看到一个深色背景的空白看板页面(还没有卡片)。
  2. 页面顶部显示“汇总”区域,有四个卡片:账号数、总限额、已用量、刷新时间,初始值应该为 0。
  3. 右上角有一个锁图标和一个“刷新可用数据”按钮。
  4. 如果看到这些内容,说明前端渲染正常。
  5. 如果你导入了一个平台的 curl 后卡片没有出现,请检查容器日志(docker logs coding-plan-dashboard)看是否有报错。

如果页面完全空白或报错,常见原因包括:端口映射错误、防火墙没有开放 8080 端口、容器没有运行(docker ps 检查)。

导入平台配额接口:curl 命令的获取与粘贴

这是看板的核心操作。你需要从浏览器的开发者工具里复制每个平台的配额 API 请求,然后粘贴到看板页面底部的输入框中。

具体步骤

  • 在浏览器中登录该平台,打开开发者工具(F12),切换到 Network 面板。
  • 找到配额相关的请求(通常包含 usage、plan、quota 等关键字),右键点击该请求,选择“复制” → “复制为 cURL (bash)”。
  • 回到看板页面,把这段 curl 命令粘贴到文本框中,点击“导入”。

服务器会自动根据 URL 识别平台归属(例如 chatgpt.com/backend-api/wham/usage 归类为 Codex),然后用 Python 标准 HTTPS 库重新发起请求,结果缓存到本地。

常见错误:复制了不完整的 curl 命令,缺少 Cookie 或 Authorization 头部,导致导入后没有数据。如果你使用的是 NewAPI 中转 Codex,请导入 NewAPI 提供的 /api/channel/{channelId}/codex/usage 地址,而不是官方地址。

导入成功后,页面上会出现对应平台的卡片,显示使用百分比和倒计时。

多账号管理与数据缓存机制

如果你有多个账号,只需重复导入不同账号的 curl 命令即可。看板会自动为每个平台下的每个账号生成独立的子卡片。例如火山方舟中导入多个子账号,每个子账号都有一张卡片显示使用百分比和重置时间。

数据缓存路径

  • data/snapshot.json:概览数据
  • data/results.json:每个账号的 API 原始响应缓存

容器重启后,先显示缓存数据,然后在后台静默刷新最新数据,用户不会看到空白页。你也可以手动点击右上角的“刷新可用数据”按钮强制刷新。

安全建议

data/ 目录的权限设置为 700(仅 owner 可读写),不要把凭证文件提交到 Git 仓库。

安全边界:为什么凭证安全且建议局域网使用

很多用户担心粘贴 curl 命令会泄露 API 密钥。这个看板在安全方面做了几层防护:

  • 不执行 shell curl:导入的 curl 被 Python 解析后用标准 HTTPS 库重新请求,不存在命令注入风险。
  • 域名白名单:服务器只允许向预设平台域名发起请求(如 chatgpt.comwww.minimaxi.comconsole.volcengine.com 等),不能向任意地址发 HTTPS 请求。
  • 凭证本地存储:所有响应和凭证保存在 data/ 目录,权限 700。默认没有认证,所以请确保仅受信任的设备能访问。如果需要在公网使用,务必加一层反向代理和认证。

可以把这个看板想象成你家客厅的智能中控面板——放在家里(局域网)安全,挂在小区门口(公网)就危险了。

回滚方案

如果你更新了代码或配置导致看板无法正常使用,可以快速回退到上一个可用版本:

  1. 使用 Git 回滚:进入项目目录,执行 git log 查看最近的提交记录,然后 git checkout <上一个正常版本的 commit id> 回到旧版本。
  2. 重建容器:执行 docker compose down 停止容器,然后 docker compose up -d 重新启动。数据目录中的缓存文件不会丢失。
  3. 完全删除:如果想彻底移除这个看板,执行 docker compose down -v(删除数据卷)并删除项目目录即可。

注意:回滚前建议先备份 data/ 目录下的 JSON 文件,以防丢失已导入的凭证信息。

常见问题与排错指南

看板页面空白:检查容器是否正常运行(docker ps),端口映射是否正确,防火墙是否开放。

导入 curl 后无数据:检查 curl 命令是否完整(包含认证头部),该平台 API 是否被限流,域名是否在白名单内。

端口冲突:修改 docker-compose.yml 中的 PORT 环境变量,然后重启容器。

更新版本:进入项目目录执行 git pull 拉取最新代码,然后 docker compose down && docker compose up -d 重建容器。

接口变更:如果某个平台修改了配额 API 地址,可以关注项目的 GitHub Issue 区,通常作者会很快更新适配。

总结与行动建议

这个开源看板用一条 docker compose up -d 命令解决了多个 AI 编程套餐配额管理的痛点:你不再需要每天开七个标签页手动查余额,所有信息一屏展示,支持多账号,数据缓存不丢失,安全机制也相对可靠。

部署后的第一个操作:导入你最常用的一个平台(比如 Codex)的 curl 命令,确认卡片出现并显示正确百分比。然后依次导入其他平台的 curl,每导入一个就看看卡片是否正常。全部导入完,你会发现“啊,原来还剩这么多额度”。

如果你还缺一台跑这个看板的服务器,可以考虑 CloudConeRackNerd 的低价 VPS,年付方案通常只要几十块钱。

最后提醒几句:各平台的接口地址可能随时间变化,导入时请确认 curl 命令的正确性;建议将看板部署在局域网内,不要暴露到公网;如果对编程感兴趣,可以自行扩展这个看板支持更多平台,但要注意保持安全边界。

原创文章,作者:kp51,如若转载,请注明出处:https://www.kepu51.com/vps-review/1078.html

(0)
上一篇 2026年7月25日 11:10
下一篇 2026年8月10日 11:33

相关推荐