A limit-reset offer can now interrupt your current turn, but only if the server sends one.
A /limit-reset action and interrupt path are wired in, driven entirely by a server-fetched status block.
What's wrong with this entry?
A new interrupt reason is threaded through the turn abort paths so the limit-reset offer can stop work in progress, and a new command kind entry marks /limit-reset as an action. The status block driving it is fetched from the server, so whether it ever appears depends on what the server returns.
- The reason joins three interrupt/abort classification switches, and the two menu states join the queue-state switch.
- Status fetches that return a fieldless or non-object body are warned about rather than treated as data.
- A limits comparison now also checks that the stored reset time matches the wall reset time.
[juniper-tide] status fetch returned a fieldless or non-object body (in-band error)
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.236
Extra-usage panel now shows for team and enterprise accounts
Both mention limit usage
-
v2.1.236
Wrap-up hint near the usage limit is now per-plan and once per window
Both mention limit usage
-
v2.1.236
Visible notice when approaching the 5-hour usage limit
Both mention limit usage