A weekly limit-reset offer only appears if the server says you're eligible; nothing is decided locally.
Client code for the weekly limit-reset offer exists but reflects server-supplied eligibility fields only.
What's wrong with this entry?
The client side of the weekly limit-reset offer parses a server-supplied status object and decides nothing itself: whether you are eligible and whether you are in the experiment are both server fields it only reflects. Malformed bodies are logged and ignored rather than failing the turn.
- Parsed fields include eligibility, an ineligible reason, experiment membership and arm, availability, next available time, weekly reset time and resets per week.
- Analytics properties are a fixed enumeration: surface, tier (for example
claude_max_20x), tenure bucket (under_14,14-29,30-89,90-364,365+), billing path, billing period and extra usage state. Anything unrecognised becomes"unknown". - Menu entries
juniper-tideandjuniper-tide-spentaccompany the flow.
[juniper-tide] ignoring a malformed status block:
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 usage limit
-
v2.1.236
Wrap-up hint near the usage limit is now per-plan and once per window
Both mention usage limit
-
v2.1.236
Visible notice when approaching the 5-hour usage limit
Both mention usage limit