[Bug]: Plus 订阅额度消耗异常 (周总 + 5h) + 消耗数据查询延迟一天

反馈：Plus 订阅额度消耗异常 + 消耗数据查询延迟

反馈人：Plus 订阅用户
反馈时间：2026-06-08
使用模型：MiniMax-M3
使用入口：网页 Chat、少量 API 裸调

---

一、现象

我的 Plus 订阅最近消耗速度明显比预期快：

• 周总额度不耐用
• 5h 滚动窗口额度也很快耗尽

关键点：这种"不耐用"是从今天（2026-06-08）突然开始的，之前没有这么夸张。
但因为数据查询延迟一天（详见第三节），我无法自查具体原因。

---

二、我的猜测（仅供 MiniMax 团队排查参考，不一定对）

由于问题今天突现，我倾向于认为是 MiniMax 侧今天有变更（不是我的工作负载变化）。可能方向：

1. M3 模型本身变更：定价 / 路由 / 系统提示词调整
2. 网页 Chat 后端：可能今天推送了某功能，导致 token 消耗增加（例如 context 注入变长、多轮改写逻辑变化等）
3. 缓存策略调整：cache miss 变多 → input token 虚高
4. 路由抖动：reasoning token 或 tool-call 相关的隐藏消耗异常

---

三、最大痛点：消耗数据查询延迟一天

我连自己今天用了多少额度都看不到 — 这让我：

• 无法判断是哪些 session / 哪些任务拉高了消耗
• 无法判断是 M3 模型变化还是我自己的使用变化
• 反馈给你们的时候只能靠"感觉"，没有数据支撑

强烈希望 MiniMax 加快消耗数据的查询延迟：

• 至少做到 T+0 准实时（或当日内可见）
• 提供 今日消耗 breakdown（按 session / 按任务）让我自己定位

这其实是一个比"消耗快"更严重的问题 — 透明度缺失让用户无法自助排查。

---

四、改进建议

1. 优先：消耗数据从 T+1 缩到 T+0 或 T+实时
2. 次优：提供"今日消耗 breakdown"，按 session / 任务拆分
3. 长期：Plus 订阅的额度计算逻辑更透明（哪些算 input、哪些算 output、cache 怎么折算、reasoning 是否单独计费）

---

谢谢！

No repository files, tests, or entry points are mentioned; start by locating the Plus quota-accounting and usage-data systems. Done would require identifying the cause of the sudden consumption change and addressing the requested T+0 visibility with session or task breakdowns.