一个端点，
所有模型。

限流与配额

四档，独立计算

⚠️ 模型那一档按 key 计数，不按账号：每个终端用户一把子钥，各自享有 100 次/分钟， 不会互相挤占。

一次流式调用算一次，与持续时长和帧数无关，计数发生在鉴权时刻。

超限的响应

返回 429 并带 Retry-After（秒）。⚠️ 额度用尽是 403 不是 429：429 表示 「过快，稍后重试」，客户端会退避重试，而额度用尽再等也不会恢复。完整对照见错误码。

调高阈值

四档均可按账号单独调高，无需发版，改完即时生效。

申请时给出三项：哪一档、目标阈值、峰值形态（持续高峰还是短时爆发，一次爆发约多少秒）。 平台据此配置并回复确认。

上限取决于当时的容量，不是固定数字。提供预估峰值后，平台会明确答复能否承接，无需等到 触发 429 之后再处理。

子钥数量

不限制账号下的子钥数量。 一万把是实测过的规模（认证、按 external_id 定位、列表首页、 深翻页四条路径均为索引命中）。没有上限，因此也没有对应的错误码。

⚠️ 有上限的是单次列表请求返回的行数：GET /v1/keys?limit= 默认 100、最大 200， 传更大的值不报错，会被压到 200。翻页用 next_cursor（见母钥）。

熔断与恢复

这一组是可观测性参数，不是可用率承诺（平台不提供 SLA 数字，产品页已说明）。

恢复判据是探测成功，不是等够时间：冷却结束后由主动探测确认，通过即放回候选。因此一次 上游抖动的影响上限是「一个冷却周期 + 一轮探测间隔」。

⚠️ 熔断状态跨实例共享（走 Redis），不是每个实例各自判断，否则同一个故障渠道会被每个 实例各撞 5 次。

并发与超时

• 不单独限制并发连接数，上述每分钟请求数即为实际上限。
• 连接上游超时 10 秒，无法建立连接视为本次尝试失败，走故障转移。
• 读超时 300 秒，且是「两帧之间」的间隔上限，不是整段响应的总时长：一个持续十分钟的 长回答不会被掐断，一个停顿超过 5 分钟的上游会。
• 默认不限制单次请求的上游尝试次数：该模型配置了几条路由，就最多尝试几次。仅在账号 单独配置了上限时才会截断，被截断的候选在调用详情中记为 never tried。