Telm 以两种方式对 API 计量：一个 每分钟速率限制（突发上限）和一个 每日配额（你在 UTC 日的总预算）。两者都随套餐扩展。每个计量响应都会返回 X-Quota-Limit、X-Quota-Used 和 X-Quota-Reset，因此你总能知道剩余预算，且两种限制在被超出时都会返回 429 并带一个 Retry-After 头。
1两种限制：每分钟速率与每日配额
有两个独立的上限。每分钟速率限制 限制你在任何单个一分钟内能发出多少请求，用来抹平突发。每日配额 是你的总体预算：它限制你在整个 UTC 日内能发出多少计量调用。
它们是独立的。你可能在仍剩有大量每日配额时撞上每分钟限制（你只是发得太快），或在远低于每分钟限制时耗尽每日配额（你用完了这一天）。两者都返回 429 状态，但原因不同——检查主体中的错误码以区分它们。
- 每分钟速率限制——一个突发上限，每分钟重置。
- 每日配额——你这一天的计量调用总数，在 UTC 午夜重置。
- 配额按账户计数一次，在你所有的密钥之间共享。
2按套餐的每日配额
你的每日配额是你每 UTC 日能发出的计量 API 调用次数，它取决于你的套餐。计数器在你所有的密钥之间共享，并遵循你所管理群组中最好的套餐——若没有付费订阅，你处于 Free 档。
窗口是 UTC 日历日，因此你的用量计数器在 UTC 午夜重置为零。一次批量垃圾检查按批次中的每一项计一次调用，而非整个请求计一次调用。
- Free——每天 100 次调用。
- Basic——每天 1,000 次调用。
- Pro——每天 10,000 次调用。
- Business——每天 50,000 次调用。
3按套餐的每分钟速率限制
在每日配额之上，每个 API 密钥根据其套餐档次被限制为每分钟一定数量的请求。这是一个抹平限制：它阻止单个客户端在一秒内发出巨大的尖峰，即使每日预算远未用尽。
另外，宽泛的按 IP 和按账户上限在整个 API 上适用，以保持平台稳定。在正常使用中——稳定、有节奏的请求——你永远不会触及这些；它们只在滥用性突发时触发。
- Free 和 Basic——每分钟 60 次请求。
- Pro——每分钟 600 次请求。
- Business——每分钟 1,800 次请求。
- 把请求分散开，而不是一次性全部发出。
4读取你的剩余预算
你永远不必猜测还剩多少配额。每个计量响应——无论成功或失败——都包含三个头：X-Quota-Limit（你的每日限制）、X-Quota-Used（你今天已花费多少次调用）和 X-Quota-Reset（计数器重置的那个时刻，以 UTC 计）。
垃圾检查端点也会在响应主体的一个 quota 对象下回显同样的数字，因此你无需解析头就能读取剩余预算。用这些来为你自己的请求安排节奏，并在用完之前提醒自己。
- X-Quota-Limit——你的每日调用限制。
- X-Quota-Used——今天到目前为止已花费的调用。
- X-Quota-Reset——UTC 的重置时间（RFC 3339）。
- 垃圾检查响应也包含一个带相同字段的 quota 对象。
5在 429 时会发生什么
当你越过任一限制时，API 会返回 HTTP 429，并带一个告诉你要等待多少秒的 Retry-After 头。对于每分钟速率限制，Retry-After 大约是一分钟。对于每日配额，主体携带一个 daily_quota_exceeded 码外加你的套餐、限制、已用计数、重置时间和一个升级提示，而 Retry-After 会倒数到 UTC 午夜。
处理 429 的正确方式是退避并在 Retry-After 延迟后重试，而不是猛敲端点。行为良好的客户端会读取该头并暂停；持续立即重试的客户端只会一直被阻挡。
- 429 rate_limit_exceeded——你发得太快；等待约一分钟。
- 429 daily_quota_exceeded——这一天已用尽；等到 UTC 重置或升级。
- 在重试之前始终尊重 Retry-After 头。