Antigravity CLI intermittently rejects Gemini requests with false “User location is not supported

Google Antigravity
1

Product: Google Antigravity CLI
CLI version: 1.1.10
OS: macOS
Network egress observed: Singapore, AS21859 (Zenlayer Inc)
Account authentication: OAuth succeeds normally

Issue:
Gemini requests in Antigravity CLI intermittently fail with:

FAILED_PRECONDITION (code 400): User location is not supported for the API use.

The CLI UI only shows:
Agent execution terminated due to error.

This is not a stable account or network failure. The same authenticated CLI process, same machine, and same network
can alternate between successful streaming responses and the 400 location error within seconds.

Reproduction:

  1. Start agy and authenticate successfully.
  2. Select Gemini 3.6 Flash (High).
  3. Send a trivial prompt such as: hi
  4. The request frequently fails before generation with the location 400 error.
  5. In the same session, switch to Claude Sonnet 4.6 (Thinking).
  6. Claude succeeds repeatedly.
  7. Switch back to Gemini 3.6 Flash (High); the location 400 returns almost immediately.

Evidence from one session:

  • Between 16:53:44 and 17:15:20, with Claude Sonnet 4.6 selected:
    47 successful streamGenerateContent responses, 0 location errors.
  • After switching back to Gemini 3.6 Flash at 17:15:25:
    5 requests failed with the location error within about 35 seconds, while only 2 streaming requests succeeded.
  • Both IPv4 and IPv6 egress checks report the same location/provider: Singapore / AS21859 Zenlayer Inc.
  • OAuth authentication succeeds before these failures.

This strongly suggests inconsistent region/IP eligibility handling in the Gemini/Antigravity backend path, rather
than an invalid local authentication state. The same account also works from another Windows machine.

Example CLI Error IDs:

  • 5e406aa4-696f-49c0-bea0-7a84336fff1b-3
  • 5e406aa4-696f-49c0-bea0-7a84336fff1b-7

Please investigate why the Gemini route intermittently classifies the same authenticated client and egress as
unsupported, while the Claude route remains stable.