Antigravity Gemini: opaque "User location is not supported" 400 from datacenter egress — add actionable hint (region/proxy-url)

[sweetcornna]

Summary

Antigravity Gemini requests fail with HTTP 400:

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

while Antigravity Claude and Codex work with the same credential. The error is egress-region based, not request-shape based, and the message is opaque enough that users spend a long time chasing it as a bug. This is a request to make the failure actionable (and ideally document it). It is not a request-shape bug in CLIProxyAPI.

Environment

• CLIProxyAPI v7.2.36; also current main.
• Provider: Antigravity, models gemini-3-flash-agent, gemini-3-flash, gemini-pro-agent, gemini-3.1-flash-lite.
• Host: US datacenter/hosting IP (AS for a hosting provider).

Evidence (decisive isolation)

Raw requests to daily-cloudcode-pa.googleapis.com/v1internal:generateContent with a freshly-refreshed token from the same account:

Variation	Result
body with injected project (current CLIProxyAPI behavior)	400 User location is not supported
body without project	400 (same)
egress via native datacenter IP	400
egress via a different-region proxy (residential/edge IP)	200 OK (both generateContent and streamGenerateContent)

So:

• The injected project is not the cause (both 400) — i.e. a "strip project for Gemini" change does not fix it (verified). geminiToAntigravity injecting project is harmless here.
• The discriminator is purely the egress region/IP. Datacenter/hosting IPs are rejected even when they geolocate to an otherwise-supported country; the official Antigravity desktop client works because it runs from a residential IP.
• Antigravity Claude/Codex are unaffected because they don't hit the Gemini regional gate.

Resolution that works today

CLIProxyAPI already supports per-auth proxy-url. Routing the affected Antigravity credential through an egress in a supported region (e.g. a SOCKS proxy whose outbound is a WARP/residential interface) makes Gemini return 200 through CLIProxyAPI unchanged. So the platform can already work around this — users just have no signal that egress is the lever.

Request

1. Actionable error/hint (small, safe): when the Antigravity upstream returns a 400 whose body contains User location is not supported, append/log a hint that this is an egress-region restriction and that a per-auth proxy-url in a supported region resolves it. The original upstream message is preserved.
2. Docs: a short note under Antigravity setup that Gemini is region-gated on the egress IP and how to point a credential at a supported-region proxy-url.

I have a minimal patch for (1) (detection helper + hint appended in newAntigravityStatusErr, with tests, original message preserved) and will open a PR referencing this issue.

[blackboxs777]

However, using the exact same node, the Antigravity desktop client works fine, but CLIProxyAPI doesn't.

[luispater]

Thanks for the detailed report.

CLIProxyAPI should only forward and translate information returned by the upstream provider. It should not append additional English hints or return other non-upstream information in provider error responses.

Because this request asks CLIProxyAPI to append an explanatory hint to the Antigravity upstream error, we are closing it as not planned.