Rate-limit status updates now fire whenever any usage window changes, not just the coarsest one.
What's wrong with this entry?
The utilization tracker now remembers what it last emitted for each of the three windows and emits a status change whenever any one of them differs, rather than on the coarser previous condition. The overage header name became a shared constant used in both places it is compared.
lastEmittedWindowParts
Strings lifted out of the shipped bundle, so the claim above can be checked against them.
Related
Other releases about the same thing. Found by shared names or similar wording; neither means one caused the other.
-
v2.1.234
Rate-limit prompts resolve model aliases to the model that actually answers
Both mention rate limit
-
v2.1.234
Quota rejections feed a new auto-resume controller
Both mention rate limit
-
v2.1.239
Spend and rate limit notices say when the limit resets
Both mention rate limit