核心用法
minimax-usage 是一个轻量级额度监控工具，通过调用 MiniMax 官方 API 查询账户剩余请求数与重置时间。基础用法直接执行脚本输出格式化信息；高级用法结合 --threshold 参数实现条件触发——仅当剩余比例低于设定阈值时才产生输出，天然适配 cron 定时任务与 webhook 告警链路。
显著优点
1. 零侵入设计：纯 Bash 实现，依赖仅 curl 与 jq，无需额外运行时
2. 智能告警机制：--threshold 参数实现"静默-告警"状态切换，避免信息轰炸
3. Discord 原生格式：输出直接兼容 Discord webhook，无需二次解析
4. 时区友好：自动转换并显示美东时间（ET）重置点，降低跨时区心智负担
5. CI/CD 友好：退出码规范（阈值内无输出返回 0），便于流水线集成
潜在缺点与局限性
- 地域依赖：API 密钥需通过 MiniMax 官方渠道申请，国内用户可能存在网络延迟或合规审查
- 单一模型：当前仅支持查询 MiniMax-M1 模型额度，多模型账户需额外适配
- 无历史趋势：仅返回当前快照，不提供消耗速率分析或预测
- 环境敏感：依赖
MINIMAX_API_KEY环境变量，密钥泄露风险需用户自行管控 - 时区硬编码：重置时间固定显示 ET，非北美用户需 mental conversion
适合人群
- 依赖 MiniMax API 进行批量推理的开发者与中小团队
- 需要将额度监控集成到现有告警体系（PagerDuty/OpsGenie via Discord）的运维工程师
- 追求极简部署、拒绝重量级监控方案的个人用户
常规风险
| 风险类型 | 说明 | 缓解建议 |
|---------|------|---------|
| 密钥泄露 | 环境变量或脚本硬编码可能导致 API key 暴露 | 使用 secrets manager，cron 任务通过文件注入 |
| 误告警/漏告警 | 阈值设置过高导致频繁通知，或过低导致额度耗尽 | 结合历史消耗数据设定 15-25% 动态阈值 |
| API 限流 | 高频查询可能触发 MiniMax 速率限制 | cron 间隔建议 ≥15 分钟 |
| 单点故障 | 无备用渠道，API 宕机即监控失效 | 配合外部健康检查或 fallback provider |