速率限制

速率限制是服务给请求、token 或并发数量设置的时间窗口上限。它保护共享资源不被一小段突发流量耗尽；当窗口快满或已经满了，服务会让请求排队、等待或返回 429，而不是继续无限接收。

• QUOTA WINDOW 记录一个时间段内已经消耗多少请求或 token，以及还剩多少容量。
• 接近上限时，客户端应该减速、排队或退避；立即重试只会继续撞上同一个闸门。
• 429 和 Retry-After 描述的是容量控制信号，不代表模型回答质量差；窗口重置后仍可按策略继续。

速率限制回答的是‘现在能不能再接收一份请求’，而不是‘模型能不能回答这个问题’。服务可以在模型正常、网络正常时，因为单位时间内的请求数、token 数或并发数达到上限而返回 429。

• 把 429 当成内容错误去改提示词，通常不能解决容量窗口已经满的问题。
• 把 429 当成普通失败并立刻循环重试，会制造更多请求，让限制持续更久。

客户端要读取 Retry-After 或采用指数退避，并在等待期间排队、取消不必要请求；服务端则通过窗口和配额保护所有调用者共享的稳定性。

拆开一次受限请求，可以看到请求闸门、配额窗口、接近上限提示、429 退避和窗口重置；它们共同说明限制如何保护系统。

• REQUEST GATE 是请求进入限制器的入口，服务在这里决定是否消耗当前窗口的容量。
• QUOTA WINDOW 说明限制按什么时间段和额度计算；80% USED 是风险信号，不是内容评分。
• 429 / RETRY-AFTER 告诉客户端暂时不能继续，并给出或暗示下一次安全尝试的时间。
• WINDOW RESET 让配额恢复；客户端应在恢复后再继续，而不是在窗口内持续撞击闸门。

请做一个 Rate Limit 教学示例：让 GET /chat 进入 60 秒、10 次请求的配额窗口，仪表从正常上升到 80% USED；超过后显示 429 TOO MANY 和 Retry-After: 12s，客户端进入 QUEUE → WAIT → RETRY；窗口重置后恢复发送。请明确速率限制保护系统稳定性，不等于模型质量限制，不要做成 Agent Loop、Harness、TTFT/TPS 或 Token 成本账单的布局。支持共享重播、Anatomy 键盘操作、暗色主题和 390px、320px 窄屏。