限流与用量

限流模型

• 粒度:每把 key(不是每租户)——两把 key 各有各的额度;
• 算法:固定窗口 60 秒。窗口内计数到达上限即拒,窗口滚动后清零;
• 上限可配:签发 key 时设置(缺省 60 / 分钟,最大 100000);
• 0 = 不限流:把上限设为 0,该 key 的请求全部放行,没有任何速率限制。

触发限流时

返回 429「请求过于频繁」,并带 Retry-After 响应头(秒,向上取整、至少 1):

HTTP/2 429
Retry-After: 37

客户端正确姿势:读 Retry-After,等够再重发(指数退避亦可,但以该头为准更精确)。

语义细节(诚实说明)

• 限流计数存在边缘 KV,最终一致——高并发下窗口计数可能略有偏差,短时可能放过比上限略多的请求。这是「边缘可用性优先」的有意取舍,不要把它当成精确计费工具;
• fail-open:万一限流存储故障,平台选择放行而不是拒绝——你的服务不会因为我们的限流组件抖动而瘫掉;
• 限流只看 key,与 session_id、IP 无关。

用量统计

每次成功分派的 /v1/agent 调用记一条用量事件(agent_turn),按租户聚合:

• 控制台「用量」区:累计调用数 + 近 7 天逐日柱状图 + key 数;
• 记录是尽力而为的埋点:极端故障下可能漏记个别请求(不影响你的调用本身);
• 公测期间用量仅作展示,不产生任何费用。

配额建议