Hi Antigravity Team,
I am writing to report a critical issue regarding token quota management that has rendered the IDE completely unusable for me, impacting multiple registered users on the same machine.
This appears to be a bug where a “quota exhausted” state is being applied at the device or session level, rather than being isolated to the specific user account, as expected in an IDE that supports account switching.
The Issue:
I have two distinct, registered user accounts configured within Antigravity.
- Account A: I was actively working using Account A until I legitimately exhausted its allocated token quota. I received the expected notification and the IDE features associated with that account were disabled.
- Account B: I subsequently logged out of Account A completely and logged into Account B. Crucially, Account B was unused prior to this login.
The Problem:
Upon logging into Account B, which should have had a fresh, unused quota, I found that its quota was immediately displayed as exhausted. No prompts were sent, no operations were performed. The “quota exhausted” state from Account A’s session was instantly and erroneously applied to Account B.
Why This is Critical:
This behaviour (whether it’s an aggressive device fingerprinting mechanism, a shared local session cache bug, or an IP-based block) completely breaks the concept of multi-user support within the IDE. It effectively enforces a rigid device ban that propagates across users, preventing legitimate work even when an unused, valid quota account is available.
It seems to be linked to the recent, widely-reported bugs regarding the “7-day lockout” after minimal usage, but with the added complexity of cross-account synchronization of the blocked state.
Environment/Context (Important for Debugging): - Usage Context: My Account B was fresh and should not have been near any individual limits.
I have already submitted internal feedback via the IDE, including system logs, which should document that no activity occurred on Account B before the quota-exhausted state was applied.
Can someone from the team provide an update on when a fix for this flawed device fingerprinting/shared cache bug will be implemented?
Thank you.