Error ID: e3b48e29-88f2-4282-b17f-e7f72ffeed0e-473

Google Antigravity
, ,
1

Error ID: e3b48e29-88f2-4282-b17f-e7f72ffeed0e-473
Identity: em****@gmailcom
Plan Transition: $49 → $99
Symptom: 150h lockout persisting across auth re-attaching; AGQ showing locked.
2

Hi @Emini_Prophet,

Welcome to the Forum,

Thank you for reporting this. Since you’ve already tried re-attaching your sign-in, please check the account and subscription side as described below, using the same personal Google Account you use in Antigravity, in a desktop browser:

If you need to keep working while this is sorted out, you can turn on AI credit overages (Plans | Google Antigravity Docs) or switch to another model available on your plan (Choose a model | Google Antigravity Docs).

If you’re still locked out after these steps, please reply with:

  • Which product you’re using (App, CLI or IDE) and its version
  • The exact lockout message (a screenshot of the error and the plan or quota screen is ideal)
  • Which plan you upgraded from and to and when
3

I found an easy solution and possible clue to RCA - because i have the AG IDE and non-IDE installed on same machine, there seemed to be a conflict. all i had to do was log out and back into the non-IDE version and the acct recgnized the subscription properly. then i had to log out and back in to the IDE version.

That tracks completely. Both the standalone CLI/desktop client and the IDE extension share the same underlying global auth cache under ~/.gemini/ (and local keyring/credential stores).

When two clients with different auth lifecycles touch the same shared session files simultaneously, a few distinct things happen:

  1. Shared Credential Store Contention: The non-IDE client held a stale token or an outdated entitlement state. Because both runtimes read from the same ~/.gemini/config/ path, the non-IDE client essentially kept refreshing or persisting an unentitled/pooled seat token.

  2. Race Conditions in State Deserialization: The parse error on startup (proto: syntax error (line 1:1): invalid value []) was almost certainly caused by one process truncating or writing an empty array/buffer to config.json while the other was reading or terminating mid-write.

  3. Re-authenticating Flushed the Stale Token: Logging out of the non-IDE tool wiped the shared cached session. Logging back in forced a fresh OAuth exchange directly with the backend billing/entitlements API, fetching the valid individual subscription claims. Then logging the IDE back in simply picked up and validated against that refreshed entitlement profile.

If this ever recurs after an IDE or background agent update, running a clean logout on both runtimes—or ensuring the non-IDE instance isn’t running a background daemon holding file locks—is definitely the quickest fix.