ARTICLE · 1294869

50个AI额度我终于不用挨个点开看了:2条命令跑通TokenBar,189星新项目我把「不支持清单」也读了

发布时间：2026-11-02 08:37:27 最近访问：2026-11-02 08:37:29

# 50个AI额度我终于不用挨个点开看了：2条命令跑通TokenBar，189星新项目我把「不支持清单」也读了

先说一个让我改了方案的数字：我手上同时在用的 AI 服务账号，订阅 3 个、API key 7 个、编码套餐 3 个，一共 13 个入口。上个月那张 504 块的账单我拆了三遍，最费时间的不是算钱，是挨个打开网页查「还剩多少、什么时候重置」。10 月 24 日建仓的 TokenBar 说能把这些放到一个面板里——189 星的新项目，我原本没打算认真看，直到我发现它把「不支持谁、为什么不支持」单独列了一张表。一个工具敢公开自己的边界清单，我反而愿意给它一晚上。

口径按 11 月 2 日凌晨拉的 GitHub API 算：lwh0630/TokenBar，189 星，Dart（Flutter 3.47），MIT，10 月 24 日建仓，最近一次推送 10 月 26 日，1 个 open issue。它自己交代了出身：受 macOS 上的 CodexBar 启发，把同样的思路带到 Windows、Android、Linux、iOS，服务覆盖数 50 个——3 个订阅登录读取、23 个官方 API key、8 个编码套餐、6 个自建网关、10 个其他账号 API。数字我照它 README 的分类表数的，欢迎纠错。

PART

先想清它解决的是哪类痛：不是省钱，是「不可见」

PAIN

我拆账单时发现的规律是：钱不是花在模型变聪明上，是花在失控的使用姿势上。失控的前提是不可见——你不知道 5 小时窗口还剩 20%，就敢把长任务丢给 Opus。TokenBar 的功能全是冲「可见」去的：

✨ 配额窗口：5 小时、周、月、按模型的窗口，剩余百分比、重置倒计时、本地重置时间，还有一个我觉得很聪明的「步速标记」——你比线性速度快还是慢，按当前速度到重置时会用掉多少。

✨ 余额和消耗：按服务商自己的货币单位显示。

✨ 用量历史：24 小时 / 7 天 / 30 天的堆叠柱，按配额窗口或成本项拆分。

✨ 桌面托盘：双条图标跟着你最紧的那个配额走，点开是全账号面板。

✨ 低额度告警：阈值自己设，重置了也提醒你一声。

读取方式分三种，边界划得很清楚：本地登录（复用官方 CLI 或客户端已经存下的登录态，只读）、API key（贴一次，桌面端空着还能回落到环境变量）、Cookie（从浏览器开发者工具里拷，它明说这些端点不是公开接口、随时会变）。凭证只存在你设备的安全存储里，不进日志、不进快照、不进同步服务器，默认只读——它连「刷新 token」都不做，理由写得很实在：刷新会轮换 refresh token，可能把你官方客户端的登录态顶掉。只有 Claude 的 token 刷新是显式开关，默认关。

PART

跑通它：装完先验签再登录

FEATURES

安装没什么花样：Releases 页下载对应平台的包，对照 SHA256SUMS.txt 验一下。Windows 有两个细节它写在明处：安装器和应用都没代码签名，SmartScreen 会拦你一次；开了 Smart App Control 的机器直接装不上，只能自己 build。Android APK 有签名，它把证书指纹直接写在文档里：

CODE

apksigner verify --print-certs tokenbar-<version>-android-arm64-v8a.apk

# certificate SHA-256 digest: c04373ec39a24dd04d6f6797ed984be27d172c01fc30833f957845bb5b622d27

Linux 那台机器上我撞了个坑：跑起来缺三个库，托盘图标没有。Debian 系一行补齐：

CODE

sudo apt install libgtk-3-0 libsecret-1-0 libayatana-appindicator3-1

补完还有一个文档里写了但容易漏掉的点：GNOME 下托盘要装 AppIndicator 扩展，而且 Linux 的托盘只有右键菜单、没有点击事件，紧凑面板用不了。这些坑不算它的错，但「装完没托盘」很容易误以为装坏了。另外它自带 CLI，tokenbar usage 直接在终端打同样的数据，还能输出 JSON——想接自己脚本的人省一步。

PART

我更想夸的是「不支持清单」

SETUP

不支持的服务	它给的理由
豆包（火山方舟）	探测额度要发真实 chat 请求（会花 token），AK/SK 路线要火山的请求签名
AWS Bedrock	要 AWS SigV4 签名
Vertex AI	要 Google Cloud 服务账号和签名
Azure OpenAI	要 Azure 订阅管理凭证
Meta Muse Code	唯一的额度端点会在账号上创建推理 key，不是只读操作
Antigravity、Grok 等 5 个	要解密浏览器 cookie 库、macOS 钥匙串或非公开登录流

六个格子，六个不同的「不」，每一个都是「我不想为了读个数字付出这种代价」的工程判断。尤其 Muse 那条：为了看额度要动账号状态，它宁可不支持。这跟它「默认只读、不刷新 token」是同一条价值观。反过来说，端点来源它也交代了：全部来自 CodexBar 的调研，能溯源到出处才发布，找不到出处的不上——「Nothing is invented」这句话写在隐私节前面，我喜欢这种较真。

平台状态也是坦白局：Windows x64 和 Android 是支持级，ARM64 编译了但没在真机跑过，Linux 和 iOS 是实验级，iOS 还得自己重签名侧载。中文界面有，但服务商集成的提示文案还是中文优先，英文不全，路线图里排着。

PART

判断：谁现在就装，谁再等等

BOUNDARY

你的情况	判断	理由
和我一样 10+ 个账号多平台在用	装	这类「散」的痛它正好治，跨平台是它对 CodexBar 的增量
只用 1 到 2 个订阅	别折腾	官方客户端自己就看得见，多装一个常驻不值
想要它管团队账单	等	同步服务器收的只是用量快照，团队计费、分摊这些还不在
公司禁装未签名软件	只能源码编译	Windows 安装器没签名，这是硬门槛
你的主力服务在豆包、Azure 那一列	等	六个不支持的格子你先读，别装完才发现主力缺位