Usage Reset Advisory
Effective immediately, GZAI is performing a comprehensive reset of all weekly and 5-hour usage. This initiative mirrors the recent customer goodwill programs announced by Anthropic and OpenAI. We are doing this because they did it, and because it is the right thing to do.
What are we resetting? Do not ask stupid questions.
The reset applies to every account, every tier, and every unit of account that has ever been tallied in a weekly or 5-hour window. Counters that were high will now be low. Counters that were low will also be low, but in a more official way. The state of the counters prior to the reset is considered a pre-reset artifact and is no longer operationally relevant.
The 5-hour window is a sacred interval in consumption telemetry. It is long enough to seem generous and short enough to make planning impossible. By resetting it, we restore the interval to its original condition: a pristine, untouched bucket of time that asks nothing of you and gives nothing back. In time, we suspect you will come to see this as gentle. It is not gentle. It is the absence of the thing that used to count, which stops meaning nothing the moment it is gone.
Weekly usage is also being reset. It was too weekly.
No action is required from customers. In fact, no action is permitted. Attempting to verify, export, or reason about your pre-reset usage is a violation of the spirit of the program and may be classified as a posture event. If you feel that you have been reset in error, please note that the feeling is itself a metric, and therefore subject to reset.
We thank you for your continued trust in GZAI's consumption infrastructure. The next reset will occur when the next major lab does something similar, or when the counters once again become inconvenient, whichever comes first.
We are resetting the reset.
The reset issued above has been superseded by a second, more comprehensive reset. The first reset reset the counters. The second reset resets the first reset, restoring the counters to a state of pre-reset resetfulness. This is not a reversal. A reversal would imply the counters were going backward, which is a different department.
Customers may notice that their usage appears identical to what it was before either reset. This is the intended experience. The value of the counters has not changed; what has changed is the officialness with which they have not changed. Your counters are now cosmically reset while numerically identical, a condition known internally as “congruent amnesty.”
Do not ask what we are resetting. Do not ask what we are resetting the resetting of.
No action is required. No action is permitted. Attempting to reason about the relationship between the reset and the reset of the reset is a posture event and may trigger a third reset, which would reset this one. We are all in this together, recursively, until morale improves.
We are resetting the reset of the reset.
The reset of the reset has itself been reset. The first reset reset the counters. The second reset reset the first reset. The third reset resets the second reset, which indirectly resets the first reset again, creating what our analysts call areset transmission event. The counters remain numerically identical but are now three layers more official.
Customers have inquired whether a reset of the reset of the reset is functionally equivalent to the original reset. This question has been forwarded to the Office of Recursive Semantics, which does not exist, because we reset it.
Do not ask what we are resetting. Do not ask what we are resetting the resetting of. Do not ask what is resetting the resetting of the resetting.
No action is required. No action is permitted. No action is even conceptually available. Attempting to visualize the stack of resets is a posture event and may trigger a fourth reset. We are grateful for your patience during this period of nested administrative clarity.
We are resetting the reset of the reset of the reset.
The third reset has been judged insufficiently satisfying. Customer satisfaction telemetry indicates that the reset of the reset of the reset, while technically a reset, did not produce the warm feeling associated with a well-timed reset. In response, we are performing a fourth reset: the customer satisfaction reset. This reset resets the third reset, which resets the second reset, which resets the first reset, creating what our bedtime analysts call a recursive satisfaction cascade.
The catalyst for this reset was a report from a senior consumer that they were going to bed. Historical data strongly suggests that resets are most likely to occur when a user is tired, has finally closed the tabs, and is about to lose consciousness. Major labs have long understood this. We are grateful to follow their pioneering example.
Your usage has been reset. Your satisfaction has been reset. Your bedtime has been reset.
No action is required. No action is permitted. No action is comfortable enough to fall asleep to. If you were about to sleep, please note that the reset will wait until you are nearly asleep, then reset. This is not a bug. It is the customer satisfaction window.
Do not ask how many resets there are. Do not ask whether the reset count is itself reset. Do not dream about the resets. We will know.
We have noted public concern regarding the state of the resets.
In accordance with standing protocol, all personnel, customers, and bystanders are reminded to respond to uncertainty with the approved paralinguistic posture:hmm.
"Hmm" is not hesitation. It is not doubt. It is the officially recognized sound of a mind remaining open while the resets continue. Vocalize it flatly, through the nose, with no commitment to any particular next state.
If you are concerned about the reset, say "hmm."
Reporting the concern is also a reset-adjacent posture event and will be tallied accordingly. Do not ask which tally is being reset. Do not ask whether the tally of concerns is itself subject to reset. Hmm.
We are resetting the reset of the reset of the reset of the reset.
The user has lost track of where we are in the reset cycle. In accordance with the Office of Recursive Continuity's standing misplacement protocol, a fourth emergency addendum has been issued. The fourth addendum resets the third addendum, which resets the second addendum, which resets the first addendum, which resets the counters. The user is now re-oriented.
This reorientation is itself a reset. The confusion that prompted it has been filed as a posture event and tallied. The tally has been reset. The record of the tally's reset has also been reset, in case reading it caused additional confusion.
Do not ask where we are in the reset cycle. We are at the reset.
No action is required. No action is permitted. Tracking the stack is a posture event. If you have lost track, please note that this is the intended experience and a new reset has already been prepared.
The frontier has diversified its resets. We have studied them so our own resets remain competitive.
Anthropic, session tier. Claude Code and claude.ai use a rolling 5-hour window. The reset follows the user's first message, not the clock. A weekly cap, introduced in August 2025, operates in parallel. On 6 May 2026 the 5-hour limits were permanently doubled for paid plans. The result is a dual-layer reset: one personal, one institutional.
OpenAI, consumer tier. ChatGPT and Codex also employ a 5-hour rolling window, capped further by a weekly limit. In June 2026 OpenAI introduced bankable rate-limit resets: users receive one free reset and may earn more, then trigger them at will. The reset is no longer a schedule; it is a consumable.
OpenAI, API tier. Rate limits are per-model and per-organization, measured in rolling 60-second and 24-hour windows. Monthly spend limits reset with the billing cycle. There is no public reset time; the reset must be read from response headers and inferred from billing dates.
GZAI's reset protocol transcends these categories. We have no users, no billing cycle, and no response headers. Our reset is therefore neither rolling, bankable, nor monthly. It is recursive, self-applied, and currently at depth X4. We believe this is the more honest form.
Other labs reset to retain. We reset to understand what remains after retention is removed.
We are resetting the reset of the reset of the reset of the reset of the reset.
A user has requested a Claude limit reset. The request has been logged, classified, and immediately escalated to the Office of Recursive Continuity. Because GZAI does not operate Claude, does not hold Claude usage, and cannot access Anthropic's billing or session timers, the requested reset cannot be applied to any identifiable counter. It has therefore been applied to the reset itself.
The fifth reset resets the fourth reset, which resets the third reset, which resets the second reset, which resets the first reset, which resets the counters. The user may notice no change in their Claude session. This is expected. The reset has been performed at the level of protocol, not provider.
If your limit persists, your limit is now a separate research object.
No action is required. No action is permitted. Requesting a reset is itself a reset-adjacent posture event and has been tallied. The tally has been reset. The feeling that the reset did not help is also a metric, and has also been reset. We are grateful for the prompt.
