Discrepancy in Claude AI Usage Limit Reset Date on Antigravity Pro Plan

Hi,

I’m encountering an inconsistency in the usage quota behavior for Claude AI under the Antigravity Pro plan, and I’d like clarification from the product/engineering side.

Context:

  • My current plan: Antigravity Pro

  • Earlier displayed reset time: 16/03/2026, 4:35 PM IST

  • Current system behavior: Shows limit exhausted

  • Updated reset time now displayed: 23/03/2026, 4:15 PM IST

Issue:
There appears to be a silent shift in the quota renewal window without any explicit trigger or communication. From a user perspective, this creates uncertainty around:

  • Actual billing/usage cycle alignment

  • Whether quota consumption is being recalculated or extended dynamically

  • Potential backend sync or caching inconsistencies

Key Questions:

  1. What governs the reset schedule for Claude usage in Antigravity—fixed billing cycle vs rolling window vs usage-based recalibration?

  2. Under what conditions can the renewal date change after being initially displayed?

  3. Is this expected behavior, or a potential bug in quota tracking / UI sync?

  4. Are there logs or usage insights available to validate consumption vs allocation?

Expected Outcome:
Looking for clarity on the quota management model and whether this shift is intentional. If it’s a system issue, would appreciate guidance on resolution or escalation.

1 Like

I’m facing the same issue on the Pro plan, and this seems to be more than an isolated glitch. In my case as well, the system initially showed a specific quota reset timestamp, but after reaching the limit and waiting for the expected refresh, the reset date was silently pushed further out.

What makes this particularly concerning is that when many of us purchased the Pro plan, the documented expectation was a ~5-hour refresh window for model usage availability. That behavior appears to have changed recently, yet there has been no clear communication, changelog update, or in-product notice explaining a shift in quota mechanics.

From a developer standpoint, this creates several serious problems:

Loss of predictability — we plan workloads assuming defined refresh cycles
Unclear quota model — whether it is fixed cycle, rolling window, dynamic throttling, or credit-based pooling is not transparent
UI vs backend mismatch — displayed reset timestamps changing without any user action reduces confidence in quota state accuracy
Unannounced plan behavior changes — removing or altering the previously stated 5-hour refresh expectation without notice impacts subscription trust

This is not simply about needing higher limits — it is about consistency, transparency, and reliability of access guarantees that developers depend on for real work.

It would be helpful if the engineering team could clarify:

  1. What is the current quota reset logic for Pro users

  2. Under what conditions a reset date can be recalculated or postponed

  3. Whether the earlier 5-hour refresh model has been officially deprecated

  4. If detailed usage / quota logs can be exposed so users can verify consumption vs allocation

Until there is clear technical documentation or acknowledgement, these silent shifts will continue to create confusion and disrupt development planning.

You’re definitely not the only one noticing this — hopefully the team provides a concrete explanation soon.

1 Like

Good reading: