All Gemini models fail with false "User location is not supported" in Antigravity — AI Studio and Claude work normally

I am consistently getting the following error with all Gemini models in Antigravity:

HTTP 400 FAILED_PRECONDITION: User location is not supported for the API use.

However, Claude models in Antigravity work normally, and Gemini also works normally in Google AI Studio using the same Google account and network.

Environment

  • Windows x64

  • Antigravity 2.8.1

  • Google account Country version: United States

  • Current US exit:

    • 198.204.234.107

    • AS33387 Nocix

    • Kansas City, Missouri, US

Affected models

I tested all currently available Gemini options in Antigravity:

  • Gemini 3.1 Pro

  • Gemini 3.5 Flash

  • Gemini 3.6 Flash

  • Gemini 3.7 Flash

All return the same location-related HTTP 400.

Meanwhile:

  • Claude Sonnet 4.6 works normally

  • Claude Opus 4.6 works normally

  • Gemini works normally in Google AI Studio with the same account and network

Latest confirmed reproduction

Simple prompt:

1+1

Result after about 1 second:

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

Latest server-side identifiers:

  • UTC time: 2026-08-14 06:22:28

  • Trajectory ID: 955a098f-3e2a-4952-ab6d-2117721479..

  • Error ID: 955a098f-3e2a-4952-ab6d-2117721479c1-3

  • Cloud AI Companion Trace ID: c85350c1deacc2..

Troubleshooting already performed

I have done extensive A/B testing.

Network path

Antigravity language_server.exe is confirmed to route through Mihomo and the configured US exit.

For both failed Gemini requests and successful Claude requests:

  • destination is daily-cloudcode-pa.googleapis.com

  • traffic goes through 127.0.0.1:7890

  • the same Mihomo routing rule is used

  • the same US exit is used

I observed:

  • no Google IPv6 connection

  • no IPv6 leak

  • no DIRECT/bypass connection from Antigravity

  • normal DNS and TLS connectivity

Different US exit / ASN

I also reproduced the same issue using another completely different US exit:

  • 142.249.37.26

  • AS153371

  • Los Angeles, US

The second exit used a different IP and ASN, but Gemini still returned exactly the same location error.

Antigravity versions

I tested versions from 2.8.1 down to 2.5.0.

The same Gemini location error occurs on all tested versions.

Cloud Code endpoint

I also performed a temporary A/B test between:

  • daily-cloudcode-pa.googleapis.com

  • cloudcode-pa.googleapis.com

The production endpoint did not change the result. Gemini still returned the same location 400, while Claude continued to work.

Why this seems abnormal

The Google account Country version is United States, which is a supported Antigravity region.

The issue is specific to Gemini requests inside Antigravity:

  • same account + AI Studio Gemini → works

  • same Antigravity + Claude → works

  • Antigravity + every Gemini model → location 400

  • two different US IPs/ASNs → same result

  • Antigravity 2.5.0 through 2.8.1 → same result

This makes it look like a Cloud AI Companion / Antigravity Gemini region or eligibility check is rejecting the account/request incorrectly.

I have also submitted an in-app Bug Report with Antigravity server logs attached.

Could someone from the Antigravity team please check the latest Trace ID / Trajectory ID above and see which region or eligibility check is causing this rejection?

I have found a few other recent reports that appear to describe the same or very similar behavior, especially cases where Claude or AI Studio continue to work while Antigravity Gemini requests fail with the same User location is not supported error.

I have no particular domain knowledge, here, but after reading this, the first thing that comes to mind is: Google is cracking down on VPNs. I don’t see anything in the AG’s TOS, on this subject matter, but this is what this reads like. Antigravity is not available where you are, right?

Hello there.
There are two options to approach this issue.

Try to use a VPN that doesn’t reveal your real IP.
Then go to guest mode in google and create a google account there.
Then with that VPN on go and login to the account you have created.

Make sure your VPN is on.
Go to “https://policies.google.com/country-association-form?authuser=1&pageId=none”
Change the country to the one your VPN is connected to.
Wait a few hours for a respond By Google in your Email.
They mostly approve if your VPN is ON the whole time till you get the email.
Now your accounts region has been changed.
You’re good to go.

I recommend the second option since it has worked for many.

Have great day
-Artin

Thanks for the suggestions.

My Google account Country version is already set to the United States, so the country association option unfortunately does not seem applicable in my case.

I also considered testing with a newly created Google account, but Antigravity currently requires phone verification when I try to sign in with a new account, so I’m unable to perform a clean account-level A/B test at the moment.

Still, thanks for the ideas.

My previous problem was the same as yours. Everything is fine on my side now, and all functions have been restored. You can try updating to the latest version.

Hi @qingxuruogu,

Thank you for the detailed diagnostic breakdown.

Could you please update your Antigravity installation to the latest version and let us know if the issue is still reproducible on your end?

If you continue to experience any location errors after updating, please share your updated Trajectory/Error ID so we can investigate further.

I have the same issue on Windows with Google Antigravity 2.12.2.

Claude works normally in Antigravity, and Gemini works in Google AI Studio with the same Google account. However, every Gemini request inside Antigravity fails with:

HTTP 400 FAILED_PRECONDITION
“User location is not supported for the API use.”

I reset the local Antigravity profile and authentication state, tested different network configurations, and confirmed that the Cloud Code endpoint is reachable. The issue remains.

My Google Terms of Service page currently shows Ukraine as the account country/region.

Error details:

Trajectory ID: 13784fe0-9e2e-4733-9e59-ce8f2917c..
Trace ID: 0x763135b042766..
Timestamp: September 7, 2026, 09:30:46 UTC

The server response was:

{
“error”: {
“code”: 400,
“message”: “User location is not supported for the API use.”,
“status”: “FAILED_PRECONDITION”
}
}

Could this be an incorrect Cloud Code/Antigravity eligibility or account provisioning issue?

I can still reproduce this issue after updating Google Antigravity to version 2.13.0.

Environment:

  • Windows x64
  • Antigravity 2.13.0
  • Google Terms of Service Country version: United States
  • Claude Sonnet 4.6 works normally in the same Antigravity installation
  • Gemini requests fail with HTTP 400 FAILED_PRECONDITION: “User location is not supported for the API use.”

Network troubleshooting already performed:

  • Antigravity language_server.exe connects to daily-cloudcode-pa.googleapis.com
  • The connection is confirmed to go through Clash/Mihomo TUN and is not DIRECT
  • I tested Singapore, Japan, and United States proxy exits
  • All three produce the same Gemini location error
  • Claude continues to work normally under the same environment

The issue also reproduces in a newly created Gemini conversation after upgrading to 2.13.0.

Latest reproduction:

  • Trajectory ID: 66a3611c-355f-46de-b095-2f02c837...
  • Cloud AI Companion Trace ID: d82fef29ec68d..
  • UTC time: 2026-09-14 12:09:28

Server response:
HTTP 400 FAILED_PRECONDITION
User location is not supported for the API use.

Since the Google Terms country is United States, the request is routed through a supported-region exit, and Claude works normally in the same client, could the Antigravity team please check whether this account has an incorrect Gemini region/eligibility/provisioning state on the backend?

I can consistently reproduce this issue even after completely resetting the local Antigravity profile and signing out/signing back in.

My Google Account Terms country is Taiwan, and my current public IP is geolocated to Taiwan.

Test results:

  • Antigravity Claude works normally.
  • Antigravity Gemini consistently fails with HTTP 400 FAILED_PRECONDITION.
  • Google AI Studio Gemini works normally using the same Google account and network.
  • Resetting the local Antigravity profile and re-authenticating did not resolve the issue.

Latest reproduction:

  • UTC: 2026-10-01 07:21:57
  • Trajectory ID: `7a3481ad-7171-4bf7-8734-18f0c7516..
  • Cloud AI Companion Trace ID: 0x80a2be0faced5df3

Backend response:

HTTP 400 FAILED_PRECONDITION

User location is not supported for the API use.

Taiwan is listed as a supported region, and Gemini works normally in Google AI Studio with the same account. Could you please check whether there is an issue with the Antigravity Gemini account eligibility / regional provisioning state on the backend?

Please let me know if you need any additional logs or diagnostic information.

Same issue here, with even deeper client-side elimination completed — adding my case since it matches this thread exactly.

Environment

  • Windows x64, Antigravity 2.19.1 (fresh install of the latest version)
  • Google account Terms-of-Service country: United States — and I am a paying Pro subscriber
  • Egress: US IP (AS26042 FiberState), traffic confirmed proxied, no direct connection / IPv6 leak

Symptom — identical to the OP: 100% of Gemini requests inside Antigravity fail with

HTTP 400 FAILED_PRECONDITION: User location is not supported for the API use.

while Claude/GPT work normally in the same installation, and Gemini works in Google AI Studio with the same account and the same network.

Trigger timeline (important): the failure started mid-session during a long, high-output agent run. Everything worked fine before that run and has failed 100% since — which looks like a usage-triggered server-side flag rather than an actual geo issue.

Already eliminated client-side:

  1. Unauthenticated requests to daily-cloudcode-pa.googleapis.com from the same egress pass the region gate (they return 401 UNAUTHENTICATED, not the location error) — so the egress IP itself is fine
  2. Switched proxy exits; signed out/in; ran the Reset Onboarding equivalent
  3. Deleted the Windows Credential Manager entry gemini:antigravity that stores the OAuth tokens, wiped %APPDATA%\Antigravity and ~/.gemini completely, uninstalled and clean-installed 2.19.1 — a brand-new session with fresh credentials still fails identically
  4. Fails on both daily-cloudcode-pa.googleapis.com and cloudcode-pa.googleapis.com

Latest reproduction:

  • Trajectory ID: 84107ead-9770-4cd0-8b3b-*********** (Trace ID: 0xc41eb7f7******, 2026-10-03, on the fresh install)
  • Earlier: c23ae3b7-223e-48ec-b705-463f5964452f (0xc50120d18c54b5af), 55bf06d8-e20c-4b7e-b1e7-2f858f6b5365 (0x436e92257d2e9aaa), e8e57e42-3ef9-48f7-849f-121c85cceb56 (0x4fbdc86046f2c66f)

Could the team please check whether my account has an incorrect Gemini eligibility / regional provisioning / enforcement state on the cloudcode-pa backend? The “worked fine → broke mid heavy-session → never recovers” pattern strongly suggests a false-positive flag rather than an actual location problem. Happy to provide any additional diagnostics. Thank you!

Hi all,

Thank you for reporting the issue.

Could you please follow the below steps:

  1. Update to the Latest Version of Antigravity 2.0 (v2.19.1)
    Please update to the latest Antigravity 2.0 (v2.19.1) release from the official download page (see the Official Changelog).

  2. Connect Directly Without Cloud Datacenter Proxies or TUN Mode
    Gemini model endpoints actively validate your live egress IP ASN in addition to your Google Account country (whereas OAuth login and third-party model routing do not apply the same Gemini IP filter). Routing traffic through proxy clients (such as Clash or Mihomo TUN mode) or commercial cloud/VPS datacenter IP ranges (e.g., AS33387 Nocix, AS26042 FiberState) triggers these location policy blocks even when the exit node is in the US, Singapore, or Japan. Please disable all proxy clients, TUN adapters, and VPNs, and connect directly via a standard residential ISP in a supported region (note that for Ukraine, access is limited to supported territories).

  3. Disable IPv6 on Your Network Adapter & Test a Mobile Hotspot (For Direct Connections)
    If you are already on a direct residential connection in a supported region without a proxy or VPN, newly rotated ISP IPv6 blocks can be misclassified as out-of-region:

    • Windows: Open Control Panel > Network Connections > Right-click your Wi-Fi/Ethernet adapter > Properties > Uncheck Internet Protocol Version 6 (TCP/IPv6) > Click OK.
    • macOS: Go to System Settings > Network > Your Connection > Details > TCP/IP > Set Configure IPv6 to Link-local only.
    • Alternatively, connect your PC to your phone’s cellular hotspot to verify if your local ISP’s routing path is causing the block.
  4. Verify Your Google Payments Profile Country
    Even when your Google Terms of Service page shows a supported country, an active billing profile tied to an unsupported region can trigger a FAILED_PRECONDITION rejection on Gemini API calls. Visit Google Payments Settings, confirm your active payment profile’s Country/Region matches your supported location, and close any secondary profiles linked to unsupported regions—then sign out, restart Antigravity 2.0, and sign back in.

If the issue still persists, please reach out back to us.

Antigravity IDE 2.5.5 on Windows fails with the following Gemini models in a native empty IDE window:

  • Gemini 3.8 Flash Medium
  • Gemini 3.1 Pro Low

For each model, I sent one short text-only request asking for a fixed reply, with no tools or file access. Both requests terminated with:

HTTP 400 / FAILED_PRECONDITION
User location is not supported for the API use.

Request identifiers:

  • Gemini 3.8 Flash Medium: Error ID 66f34345-ec14-478b-9deb-536cf43810a5-4; Cloud AI Companion Trace ID 2e5e6441bc1c95bf.
  • Gemini 3.1 Pro Low: Error ID 3fe59132-568a-4421-b2aa-c421c5e76e42-5; Cloud AI Companion Trace ID 57711a4def*****

Could the team check the server-side location decision for these two requests?

I have the same issue on Windows 11 with Antigravity 2.26.0.

  • Claude works normally in Antigravity, but Gemini fails with FAILED_PRECONDITION (code 400): User location is not supported for the API use.

  • The failing endpoint is daily-cloudcode-pa.googleapis.com.

  • Reinstalling Antigravity did not fix the issue.

  • My language server logs show repeated failures, including one at October 25, 2026, 08:42:57 (UTC+08:00).

  • My IP address is geolocated by Google to California, USA, but Antigravity still returns the unsupported-location error.

  • The error occurs when Antigravity calls loadCodeAssist and fetchAvailableModels.

This makes me wonder whether the problem is caused by an incorrect location or eligibility check in Antigravity’s backend, rather than simply by the IP’s geolocation.

Could the Antigravity team investigate the location/eligibility check and clarify whether this is an expected restriction or a backend/account provisioning bug?

Has anyone found a confirmed fix or received an official response from the Antigravity team?

Trace ID from an earlier failed request: 0x7009a281d610***

Hi @jiangy_yao and @Ant_S,

When loadCodeAssist and fetchAvailableModels on daily-cloudcode-pa.googleapis.com return HTTP 400 FAILED_PRECONDITION: User location is not supported for the API use, the backend does not rely solely on your current IP geolocation.

Unlike Claude requests or Google AI Studio, Antigravity’s Gemini endpoints also validate your Google Account’s associated Country version on the Google Terms of Service page (What is Google Antigravity’s geographical availability?) as well as your account’s 18+ age verification status (Why can’t I sign in with my personal Google Account?, Why is my age unverified?).

If the country listed at policies.google.com/terms does not match a supported region, you can submit an update through the country association form.

Please also check the following for your setups:

  1. Update from Antigravity IDE v2.5.5 (@jiangy_yao) and Antigravity App v2.26.0 (@Ant_S) to the current latest releases—Antigravity IDE v2.6.0 and Antigravity App v2.28.1 (Download, Changelog). Also note for @jiangy_yao that Gemini 3.1 Pro has been retired on consumer plans, so please test with Gemini 3.8 Flash or Gemini 4 Argon (Choose a model).
  2. If the location error still occurs on a direct connection after updating to the latest release, please reply here with the country shown on your [Google Terms of Service](https://policies.google.com/terms) page and whether the same error occurs in the Antigravity CLI so we can look into it further.