最烦的不是额度用完，是不知道还剩多少。你正在赶一个 deadline，前一句话还好好的，下一句话突然被拒：“额度已用尽”。用完了哪一条？今天的还是这个月的？大模型的那份额度是不是单独算的？什么时候回来？以前这些问题得去网页后台翻，现在 PR #142308（2026 年 10 月 22 日合入）把它搬进了终端。

先分清两种计费方式

Hermes 过去熟悉的模型是“额度点数”（credit balance）：充一笔，用一点，扣到零为止。而有些订阅是按用量窗口（usage-window）算的——“今天”“这周”“这个月”，外加一条单独给大模型的 allowance；它不是余额，是配额，到点重置。

这两种东西的差别决定了界面怎么设计：余额是一条数，配额是一组进度条。所以这次改动没有去猜任何档位逻辑，而是把服务端发来的东西照着画出来。

服务端说有几条，界面就画几条

额度数据的来源有两个，形状相同：

• Portal 账号快照里的 usage_window.gauges；
• API 响应头 x-nous-credits-window-gauges（在被 402 拒绝的响应上也带着）。

每条 gauge 有一个 scope 字段，说明“这条额度满了会挡住什么”：

• scope: all —— 满了挡住所有付费模型（天/周/月以及以后新加的任何一条都可能是这个 scope）；
• scope: top_tier —— 满了只挡网关标记为 top tier 的那些模型。

免费模型永远不受影响：它不消耗任何 allowance。这条规则写死在 agent/plan_limits.py 的开头，因为选择器里的“用完了”提示、限制卡片上的建议、以及那个一键切换按钮，必须用同一套判断，否则三处会互相打脸。

agent/usage_gauges.py 里还有一句注释值得原样记住：Hermes 只为它认识的 id 保留自己的措辞（因为要翻译、要适配不同界面），其他 id 直接显示服务端给的 label。也就是说，服务端新加一条 allowance，不需要等 Hermes 发版。

/usage 里长什么样

/usage 本来就是“这次会话花了多少 token、多少钱、跑了多久”，现在在支持窗口计划的账号上会多出一组进度条：一条 allowance 一条，显示已用百分比和距离重置还有多久。

在桌面端，同样的数据出现在 Settings → Billing，以 gauge 的形式展示；旁边多了一个开关 “Keep going on credits”——它决定某条 allowance 用完之后，要不要自动动用到充值的 credits。这个开关其实就是 Portal 上 Billing → Topup 里那个账号设置，桌面端只是把它做成了同一个开关的另一个入口。改它需要这个终端具备 Remote Spending（billing:manage）权限；没有权限时，点一下会直接走审批流程，界面停在“你请求的位置”，审批通过后自己生效，不会再让你点第二次。

模型选择器开始标价签

窗口计划下，选择器里列出的模型全是“已包含”的，所以显示单价没意义——它改成给每个模型打一个词：Free、Small、Medium、Large。这个词是网关按调用方在 /v1/models 的 usage_level 字段发下来的，Hermes 只负责翻译成界面文字。

配套的几件事：

• 计划推荐的模型排在最前面，其他模型归到 “Other models”（消息平台上的选择器只是把推荐的排前面，不分组）；
• 某条 allowance 用完时，选择器只说一次、并告诉你什么时候重置；它挡住的模型在支持的平台上会变灰；
• 选 Large 模型会给一次性提示：这会多消耗你的月度大模型额度。

其他账号（credit-grant、按量付费、免费版）在这个模块里什么都不会多出来——这条路径对他们是完全不变的。

被拒的时候，说清楚三件事

额度撞线时的报错，以前是一个笼统的“额度用尽”。现在它会说：哪条 allowance 用完了、什么时候重置、以及现在还能用什么——从计划的推荐模型里按顺序挑最多两个还能跑的，在已经有按钮的平台上渲染成按钮，其他地方就写成一句话。

还有一条设计决定，值得所有 agent 产品抄：Hermes 永远不会自己换模型。撞到用量窗口上限时，它不会走 fallback 链偷偷换一个模型继续，而是把选择权交回给你——你自己挑一个还能用的，或者等重置。fallback 链是给“这个 provider 挂了”准备的，不是给“你超配额了”准备的。

渠道上有两个细节：已经支持按钮的平台（Telegram / Discord / Slack 之类）会给一个“一键切到可用模型”；消息平台上的充值引导会指向 Portal，而不是 /topup——因为在一个群聊里，一个按钮就能花掉群主的钱。

最后是凭据池（credential pool）：被额度挡住的只有那个模型，不是整个凭据。也就是说，一个凭据下别的模型照样能用，池子不会因为一条 allowance 满了就把一整把 key 全部拉黑到重置为止。

兼容性与边界

官方在 PR 里把边界写得很明确：

• 不是窗口计划的账号，每一条代码路径都和以前一样；
• 用量窗口的响应头和拒绝码只对 Nous 路由生效，别的上游服务无法触发这套界面；
• 纯增量：没有删除任何既有 config、API 或 CLI 行为。

目前的状态

PR #142308 于 2026 年 10 月 22 日合入 main（改动 200+ 文件，含 TUI、桌面、网关与 CLI 的渲染和测试），最近一次正式发布是 10 月 21 日的 v0.22.4，所以这套能力现在还在 main 上，会随下一个版本进稳定通道。

顺带区分几个容易混的东西：/usage reset 是给 Codex 计划兑换 banked reset 的（那篇在这里），Resetwatch 是第三方桌面插件、把 14 个平台的剩余额度做成一屏卡片（这里），而这次讲的是官方对“用量窗口计划”本身的支持。想弄清模型清单和选择器的其它行为，看 hermes model 命令参考。