[Idea] First-class subscription quota windows (5-hour / weekly / monthly) for Coding Plan providers

[nanami-0713]

Context

More and more DSH instances are pointed at subscription plans (GLM Coding Plan, Kimi, …) instead of pay-as-you-go API keys. These plans don't meter like API bills: they use rolling windows — 5-hour, weekly, monthly / billing period — with provider-specific semantics: unused quota doesn't carry over, plan changes reset the clock, and the API side still prices by model × pricing era × peak/off-peak.

DSH's usage accounting today is request- and session-scoped (token-meter, session stats). The plan window exists nowhere in the product — so users find out about limits only when a call dies with 429/403, and per #3338 / #5715 those failures aren't even classified clearly when they do.

Proposal: treat quota windows as first-class

1. Quota model in provider config — per provider: window kinds (5-hour rolling / weekly / monthly / billing period), limits, and reset semantics.
2. Per-window aggregation + UI — a badge and settings-dashboard progress bar per window; warnings at configurable thresholds (e.g. 80% / 95%).
3. Pre-flight guard for long work — before a multi-subagent turn or a long autonomous run, estimate cost against the remaining window budget, and optionally pause at a threshold instead of dying mid-turn.
4. Adapter interface for provider data — provider quota/balance APIs differ far too much for core to own them all, but core can own the window semantics + UI, and let plugins feed per-provider data into the same surface.

Why core, not only plugins: window aggregation needs request-time hooks (model routing, subagent fan-out) that plugins can only observe after the fact — and every budget/dashboard plugin would benefit from one shared notion of "the window I'm spending against".

Reference implementation

I maintain dsh-usage (npm: @hsinsekai-nanami/dsh-usage), which implements GLM/Kimi adapters with 5-hour/weekly/monthly progress badges, per-request pricing by model × pricing era × peak/off-peak, and session + global dashboards. Happy to contribute the window/adapter design if this direction interests the team.

Related: #5624 (expose per-session token/cost in a documented form — still unanswered), #1280 (simulating vendor subscription quotas), #3338, #5715.

---

中文版

• 背景：越来越多 DSH 实例接的是订阅制 Coding Plan（GLM、Kimi 等）而非按量计费 API key。订阅额度按滚动窗口计量——5 小时/周/月/订阅周期，且各家语义不同：额度不结转、套餐变更重置时钟、API 侧还叠着模型×涨价时代×峰谷计价。
• 现状缺口：DSH 的用量统计停留在请求/会话级，订阅窗口在产品里不存在——用户只有在被 429/403 打断时才知道额度见底，而这类报错的分类目前还是乱的（429 with insufficient_quota is classified as terminal QUOTA and never retried, breaking gateway/relay API users #3338 / [bug] 403 quota exhaustion shown as "API key is invalid": every AUTH-coded failure swallows the real message #5715）。
• 提议：① provider 配置里声明窗口种类/上限/重置语义；② 徽标 + 设置页看板按窗口展示进度，80%/95% 阈值告警；③ 长 task（多 subagent、长自主运行）启动前对照剩余额度做预检，可选项"到阈值即暂停"而不是中途暴毙；④ 核心拥有窗口语义 + UI，插件经适配器接口喂数据——各家 API 差异太大，不该由核心全包。
• 为什么该进核心：窗口聚合需要请求时钩子（模型路由、subagent 扇出），插件只能事后观察；一个共享的"当前窗口"概念能让所有预算/看板类插件受益。
• 参考实现：dsh-usage（npm @hsinsekai-nanami/dsh-usage）已实现 GLM/Kimi 适配器、5 小时/周/月进度条与逐请求计价，愿意贡献窗口/适配器设计。