额度告警：让用户在被扣停之前知道

额度耗尽前给用户一个提醒，比额度耗尽后让他发现服务挂了要好得多。这是一个只需要几行代码就能做好的体验提升。

阈值提醒的实现很直接

在用量查询接口里返回「今日已用 / 每日额度 / 剩余」，客户端在超过 80% 时给一次提示。

网关的用量查询页应该一次性回答这三个问题，而不是让用户提工单。

实现上，调用明细按 (request_id, usage_id) 做唯一约束，避免结算重试导致重复落库。

把用量查询做成轮询而不是推送

对于大多数业务场景，每分钟轮询一次已经足够，成本也远低于引入推送通道。

一个起码的 .env + .gitignore 组合是底线；如果要同步给团队，用密钥管理工具，而不是共享文档。

同时记住：已经产生了上游用量的请求不要重放，那会让成本翻倍。

并发的告警和额度不同

额度是随时间线性消耗的，并发是瞬时的。并发接近上限时也要提醒，否则用户会看到「明明有额度却调不通」。

因为一个请求可能跑几十秒，几十个并发请求同时在跑，额度还没用完，服务就被并发上限卡住了。

评估套餐的时候，额度看总消耗、并发看峰值，两者要分开算。

赠送额度的到期也要提醒

福利额度到期未用部分清零，且不延长 Key 本身有效期。这类规则如果提前说清楚，能省掉大量争议。

所以续费时要保留：今日已用量、已兑换的额外额度、以及原到期时间的叠加规则。

到期后续费应该从付款核验成功的时刻重新计时，未激活的 Key 则累加待激活天数。

实操：在请求前做一次成本预估。

查询返回里已经有今日额度、剩余额度和状态，告警逻辑可以直接基于它写。

CHARS_PER_TOKEN = 3.2   # 粗略经验值，中英混排差异很大

def estimate_tokens(text: str) -> int:
    return int(len(text) / CHARS_PER_TOKEN) + 1

def estimate_cost(system: str, history: list[str], output_tokens: int) -> float:
    prompt_tokens = estimate_tokens(system) + sum(estimate_tokens(h) for h in history)
    return prompt_tokens / 1_000_000 * IN_PRICE + output_tokens / 1_000_000 * OUT_PRICE

# 这个估算只用来做「要不要截断历史」的粗筛，
# 精确计费永远以服务端返回的 usage 为准。

几个容易踩的坑

• 把「今日额度」「并发上限」「账户余额」当成同一个东西。
• 日/周/月窗口用的时区没说清楚，用户看到的数字和自己的记录对不上。
• 没有 Key 级限流，一个跑飞的脚本把共享额度吃完。
• 结算重试没有幂等约束，同一笔用量被记了两次。

小结

技术上的事大多不复杂，难的是把每个异常分支都想清楚。把这份清单存下来，下次排障会快不少。

文中的配置和示例都能在 https://aiminis.info/ 直接跑一遍，接入文档在 https://aiminis.info/docs/api-integration。