{"version":"2.1.280","anchor":"usage-limit-wait-tracking-added-to-rate-limit-store","canonical_anchor":"usage-limit-wait-tracking-added-to-rate-limit-store","heading":"Rate-limit tracker can now register and signal usage-limit waits","tier":"internal","area":"Rate Limits","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280\/e\/usage-limit-wait-tracking-added-to-rate-limit-store","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.280","markdown":"### Rate-limit tracker can now register and signal usage-limit waits\n\nThe rate-limit tracker gained a usage-limit-wait set and events so callers can register that they're waiting and be notified when that changes\n\n**Unclear.** The finding doesn't say what visibly changes for a user as a result of this tracking.\n\n**What**\n\nThe internal rate-limit\/subscription tracker gained a new way to track callers that are waiting on a usage limit:\n\n- A `usageLimitWaits` set and a `usageLimitWaitsChanged` event were added alongside the existing `statusChanged`, `overageInUse`, and `quotaRejected` signals, plus a helper that snapshots the current waiters as an array.\n\n- A public `beginUsageLimitWait(e)` method (and `emitUsageLimitWaitsChanged`) lets a caller register itself as waiting on a usage limit and be notified whenever the set of waiters changes.\n\n**Why**\n\nThis lets other parts of Claude Code know, in real time, when something is blocked waiting on a usage limit, so they can react (for example, showing a status message) instead of the wait being invisible.\n\n- Area: Rate Limits\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}