Antigravity account keeps getting banned? Here's the real fix

You connect an Antigravity account, code for a day, and then it happens: every request comes back with a 403 and the message "Verify your account to continue." You verify on Google, it works for a few hours, and the ban returns.

If you route across several Antigravity accounts, the pattern is worse — one by one they all fall into a 24-hour cooldown, and your router keeps throwing real requests at accounts that Google has already flagged. This post explains why that happens and how kRouter v0.5.93 fixed it.

Why a flat 24-hour cooldown makes it worse

When Antigravity returns a 403 Verify your account, most routers do the sensible-looking thing: they mark the account unavailable for 24 hours, then put it back in rotation.

The problem is that Google's anti-abuse layer does not cool off on a fixed 24-hour clock. Once an account is flagged, the flag often stays hot for days. So here is the loop a naive router creates:

1. Account hits a 403. Router locks it for 24 hours.
2. 24 hours later, the lock expires. The account rejoins the pool.
3. The very next request goes to that account. Google's flag is still active. 403 again.
4. Router locks it for another 24 hours. Go to step 2.

You never recover the account, and every cycle burns a real user request — sometimes mid-conversation, which crashes your agent.

What kRouter does instead: exponential backoff

kRouter treats a repeat ban as a signal that the account needs more time, not the same amount. Each consecutive account-lock multiplies the cooldown:

1st ban  →  24h   (1×)
2nd ban  →  48h   (2×)
3rd ban  →  4 days (4×)
4th ban  →  7 days (7×)
5th+     →  14 days (14×)

A banCount is tracked per connection. The moment the account returns a single successful reply, the streak resets to zero — so one bad day never dog-houses a healthy account forever.

This is the difference between an account that thrashes in a daily ban loop and one that gets left alone long enough for Google's flag to actually clear.

Chronic-ban detection

After three consecutive locks, kRouter marks the connection chronicallyBanned and surfaces a red "chronic ban ×N" badge on the connection card. That badge is the honest signal you actually want: this account is not coming back on its own — swap it or verify it manually.

Without it, you are left guessing why one account in your pool never seems to route. With it, you can see at a glance which accounts to retire.

The other half: never trip the ban in the first place

Backoff is recovery. The better fix is not tripping Google's anti-abuse layer at all. kRouter's Antigravity integration was hardened at the byte level to avoid the loadCodeAssist enum bug that triggers the ban in many third-party tools — that story is in Use Antigravity through kRouter without getting your Google account banned.

Together, the two fixes mean:

• Fewer bans, because the request shape matches what Google's own client sends.
• Faster recovery when a ban does happen, because cooldowns back off instead of looping.
• A clear signal when an account is genuinely dead.

Multi-account fairness, too

The same release fixed a related complaint: with Round Robin turned on, one Gmail account was doing all the work while the others sat at 0% used. That was conversation stickiness — a feature that keeps upstream prompt cache warm — silently overriding the user's explicit round-robin choice.

kRouter now checks your per-provider strategy first: if you toggled Round Robin, it distributes traffic across all your accounts instead of pinning to one. If you leave it on the default Zenith strategy, prompt-cache stickiness stays on. You get the behaviour you actually asked for.

Try it

kRouter is one command:

npx @sifxprime/krouter@latest

Connect your Antigravity accounts, turn on Round Robin if you want even spread, and let the backoff engine handle the bans. See the Providers guide for the full connection flow.