不用打开五个后台页面，也能查 AI API 余额

一个词背后的三个不同问题

“额度”这个词其实包含三种完全不同的东西，搞混了，任务做到一半就会出意外。

预付余额是你已经充进去的钱，按请求逐笔扣减。它不会重置，只会减少，直到你再充值。DeepSeek 和 Moonshot 就是这样。

套餐额度是某个时间窗口内的一份配额：编码套餐每 5 小时、每周或每月给你一定量，窗口重置后重新补满。Kimi Code、MiniMax 的编码套餐和 Z.ai 的 GLM 编码套餐都是这样。

这里的百分比和余额的百分比不是一回事。假设窗口在周日晚上重置，那么周一 09:00 用到 90%，比周日 17:00 用到 90% 糟糕得多，因为离重置还差将近一周，而不是几个小时。

花费就是一把密钥到目前用掉了多少，不带上限。没有上限可以当分母时，它就是最直接的答案，OpenRouter 的不限额密钥正是这种情况。

各家提供商实际提供什么

DeepSeek 提供 GET https://api.deepseek.com/user/balance，用普通 API 密钥作为 bearer token 授权。返回 balance_infos[]，每种币种一行。

每行包含 total_balance（真正能花的部分）、topped_up_balance（你付费充值的额度）和 granted_balance（赠送额度），都是以货币整单位表示的十进制字符串。区分充值和赠送很重要，因为赠送额度通常最先过期。

Moonshot（Kimi 开放平台）在国际站的 api.moonshot.ai 和中国站的 api.moonshot.cn 上都响应 GET /v1/users/me/balance。返回 available_balance，同时有 cash_balance 和 voucher_balance。一把密钥只属于一个平台，拿到另一个平台上不能用。

基于它开发之前有一点要注意：响应里完全没有币种字段。币种是根据响应的主机推断的，中国站主机按 CNY，其他按 USD。这是推断，不是服务器明说的。

Kimi Code 是订阅，不是钱包。GET https://api.kimi.com/coding/v1/usages 返回 7 天的用量额度，以及更短的限流窗口。Kimi 官网上每月的“Total usage”总池来自另一个靠 cookie 认证的网页接口，所以只有 API 密钥拿不到这个数字。

MiniMax 使用以 sk-cp- 开头的编码套餐密钥。全球站调用 api.minimax.io 上的 GET /v1/token_plan/remains，中国站用 api.minimaxi.com。部分账号上，旧路径 /v1/api/openplatform/coding_plan/remains 仍然可用。返回的是每个窗口剩余的套餐容量，不是金额。

OpenRouter 有一个写在官方文档里、专门为此提供的接口：GET https://openrouter.ai/api/v1/key 返回当前密钥自己的 limit、limit_remaining 和 usage，单位都是 USD。如果密钥设了消费上限，你就能得到真正的百分比。

Z.ai（及其中国站 BigModel）在 api.z.ai 或 open.bigmodel.cn 的 /api/monitor/usage/quota/limit 上提供编码套餐额度。这个接口不在 Z.ai 公布的 API 参考里。它是 Z.ai 自家开源用量插件所调用的接口，属于厂商发布的客户端代码，而不是承诺稳定的接口，可能随时变动，不另行通知。

它的返回值还混了两个不同的池：套餐的 Token 或积分额度，以及另一个按月统计 MCP 工具调用（比如网页搜索）次数的额度。两者不能互换。把第二个当成第一个，很容易误以为套餐快用完了，其实没有。

自己动手查

其中两家根本不需要任何工具。它们都是带 bearer token 的普通 GET。curl -H "Authorization: Bearer $DEEPSEEK_API_KEY" https://api.deepseek.com/user/balance 能拿到 DeepSeek 的数字，curl -H "Authorization: Bearer $OPENROUTER_API_KEY" https://openrouter.ai/api/v1/key 能拿到 OpenRouter 的。

用 jq 过滤一下，再绑个别名，一分钟就能做成 shell 函数。只有一两家提供商时，这是个好办法。

规模一大，运维部分就撑不住了。每把密钥都得放在 shell 读得到的地方，通常是 dotfile 或导出的环境变量。你得记得去运行它，而且结果只和你上次运行的时间一样新。对于接口没有文档的提供商，你还要自己维护一个爬取脚本，而对方改了接口，不一定会写更新日志。

另一个免费办法是各家自己的后台页面。它永远是权威数字，还能显示 API 密钥看不到的内容：发票、赠送额度的到期日、按密钥拆分的明细。每月对账时用它最合适。

但它不适合回答“我做到一半会不会用完”这个问题。这个问题你一天要问十次，还希望不离开手头的事就能得到答案。

MXterm Pro 的 Token Meter 怎么处理它们

这六家都在 1.0.22 加进了 Token Meter。在设置 → Token Meter 里，每家提供商一行。

粘贴 API 密钥，如果提供商分区域，就选一个区域（Moonshot 国际站/中国站，MiniMax 全球站/中国站，Z.ai 全球站/中国站；Moonshot 和 Z.ai 的密钥只能在各自的区域使用）。之后这家提供商就会出现在弹窗里，显示它的余额、额度窗口或花费，并在后台刷新。弹窗列出你配置过的每家提供商，设置 → Token Meter 里可以把其中一家固定在顶部（默认是 Claude Code）。另见 Token Meter 页面和 Token Meter 文档。

标题栏里的那个小标签显示所有额度中最紧张的一个，颜色随接近程度变化。原因见第一节：余额或花费永远不算百分比，也不会变成进度条。如果没有任何额度，又没装 Claude Code 或 Codex，小标签就以金额显示最低的 USD 余额。

每一行都会标明读数有多旧，以及出了什么问题：密钥被拒绝、提供商无法连接、被限流，或响应无法读取。如果提供商无法连接或对检查限流，这一行会保留上次成功的读数，并标明这是上次的读数，不会把旧数字冒充当前值。密钥被拒绝或响应无法读取时，则显示对应的错误信息。

密钥存在哪里，什么永远不会发出去

下面是具体细节，因为“我们会安全存储”这种话没人能核实。

粘贴的密钥会放进操作系统自带的凭据存储。在 macOS 上，这是 MXterm 自己创建的一个 Keychain 条目，服务名为 MXterm Pro，账户为 account-usage.<provider>。Windows 版设计为使用 Windows 凭据存储，但那边尚未验证。当前版本不会把密钥写入应用自己的文件或浏览器存储。

粘贴密钥的输入框是有意做成非受控的。在点保存把密钥交给后端之前，密钥只存在这个 DOM 输入框里，别处都没有；交给后端后输入框会被清空。应用的状态里不保存它。

应用数据目录里还有第二个不含机密的文件 account-usage.json，每家提供商只记三件事：是否保存了密钥、密钥的最后四个字符和区域。标题栏每次加载都会读取它，所以应用不必读一次凭据存储，就知道你配置了什么。什么都没配置时，Token Meter 不会调用凭据存储，也不会发任何网络请求。

当前版本中，每把密钥只会发往它所属提供商的、写死的 HTTPS 主机。不跟随重定向，所以 bearer token 不可能被转到别的主机。也没有可以自行填写的基础 URL，没法把密钥指向别处。

错误文本是固定类别，不是原始响应：“凭据无效”“无法连接”“无法读取”或“被限流”。每个持有机密的类型在调试输出时都只打印 [redacted]。应用显示已保存密钥的唯一部分是 … 加最后四个字符，而且只有密钥足够长、四个字符不泄露信息时才显示。

它刻意不做什么

评价一个会读取凭据的工具，拒绝做什么和功能一样重要。下面这些都是明确做出的决定。

不使用管理密钥。 OpenRouter 的响应如果表明它来自管理密钥或 provisioning 密钥，会被当作无效拒绝，因为这类密钥能创建和删除 API 密钥。应用也从不调用账户额度接口，那个接口只接受管理密钥。

不读浏览器 cookie，也不读其他应用保存的凭据。 读取的凭据只有你粘贴的那些，以及仅对 Kimi 而言的 Kimi Code CLI 自己的 token 文件：只读不写，也不刷新，因为它属于那个 CLI。

有些工具在缺少设备 ID 文件时会自己创建。MXterm 不会，因为它不往别的程序的目录里写文件。如果这个文件不存在，CLI 这条路径就不可用，该提供商显示为未配置。

不狂刷接口。 每家提供商最多每五分钟查询一次。遇到 429 就暂停十五分钟。遇到 401 或 403 就一直暂停，直到你更换凭据，不会按定时器反复重试被拒绝的密钥。应用自己的轮询只在至少配置了一家提供商时才运行：保存了密钥，或存在 Kimi Code CLI 的凭据文件。

有自己的身份，但有一个例外。 应用用一个写明 MXterm 及其版本的 User-Agent 表明身份。MiniMax 的来源请求头带的是 MXterm 自己的名字，而 OpenRouter 完全不带归属请求头。

例外是 Kimi Code CLI 这条路径。那里发送的是 CLI 自己的 token，带着 CLI 的平台标识（X-Msh-Platform: kimi_code_cli）和它的设备 ID，同时附上 MXterm 的版本。

必须直说的一点

MXterm Pro 的解析是对照测试样例和文档示例编写、测试的，不是对照每家提供商真实抓取的响应。

所以如果提供商改了解析需要的字段名，这一行会显示“无法读取响应”，而不是一个错误的数字。这正是你希望的失败方式。尽管如此，也别把它当作记账来源。

钱必须准确的场合（发票、预算、拒付），请去厂商的后台。至于“这把密钥会不会在三个 Agent 同时跑的时候用完”，窗口角落里一个自动更新的列表更合适。