[Bug]: All models gated behind a retired "Gemini Code Assist for individuals" eligibility check - verdict differs between two accounts at the same location

Antigravity CLI Version

1.2.2

Environment Context

OS: Windows 11 Home 25H2, 10.0.26200 (Build 26200), 64-bit
Shell: PowerShell 7.6.5 (also reproduces under Windows PowerShell 5.1 and Git Bash - shell-independent)
Terminal Emulator: Windows Terminal 1.24.11911.0 (also reproduces non-interactively via --print)
Runtime Version: Antigravity CLI (agy) 1.2.2; Antigravity IDE 1.107.0, quality stable, commit ecfbad74d93962fc8ca485d93ab9b4f3d4cb6cf8, built 2026-08-13
Hardware Details: Intel Core i7-1360P (12C/16T), 32 GB RAM, x86_64. Residential ISP, single IPv4 egress, no routable IPv6, HTTP_PROXY/HTTPS_PROXY unset.

Auth: consumer Google account (personal Gmail, not Workspace). Two independent consumer accounts were tested - referred to below as Account A and Account B.

Steps to Reproduce

Sign in to Antigravity with a consumer Google account (Account A).
Run any Gemini model non-interactively:
agy --model gemini-3.8-flash-low -p "say OK"
-> error: FAILED_PRECONDITION (code 400): User location is not supported for the API use.
Run the same prompt on a non-Gemini model, same session, same account, same IP:
agy --model claude-sonnet-4-6 -p "say OK"
-> returns OK normally.
Re-run step 2 against the production Cloud Code backend instead of the default:
CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com agy --model gemini-3.8-flash-low -p "say OK"
-> the location error is gone; returns RESOURCE_EXHAUSTED (code 429) instead.
Sign out, sign in with a second independent consumer account (Account B) on the same machine, repeat step 2.
-> a different error, and now every model fails, including claude-sonnet-4-6:
Your current account is not eligible for Gemini Code Assist for individuals because it is not currently available in your location.

Tip: set AGY_CLI_MODEL_API_MAX_RETRIES=0 to skip the retry backoff and surface the error immediately.

Expected Behavior

Antigravity should not gate its own models behind the eligibility rules of Gemini Code Assist for individuals - a product retired on 2026-06-18 whose documented migration target is Antigravity itself (https://developers.google.com/gemini-code-assist/resources/available-locations).

And whatever gate does apply should be consistent: the same verdict for two consumer accounts at the same location, and the same verdict across backends for one account.

Actual Behavior / Error Screenshots

Every request is gated by an eligibility check for "Gemini Code Assist for individuals", a product that stopped serving requests on 2026-06-18 and whose stated migration path is Antigravity. Antigravity appears to still enforce the retired product's location eligibility gate.

Two independent consumer accounts, same machine, same IP, minutes apart:

	Account A	Account B
Eligibility check	passes	blocked - "not eligible for Gemini Code Assist for individuals because it is not currently available in your location"
Gemini, default backend (`daily-cloudcode-pa`)	`400 FAILED_PRECONDITION` - "User location is not supported for the API use"	eligibility error
Claude (`claude-sonnet-4-6`), default backend	`200` OK	eligibility error
Gemini, production backend (`cloudcode-pa` via `CLOUD_CODE_URL`)	`429 RESOURCE_EXHAUSTED` - no location error	eligibility error

Two distinct problems are visible:

The gate is account-scoped, not region-scoped. Two consumer accounts on the same machine and IP get different verdicts. Account A is served normally on non-Gemini models; Account B is refused every model. A location-based restriction should not differ between two accounts at one location.
Account A's failure is inconsistent across backends. The same account and IP produce a location precondition failure on the daily backend, but a plain quota error with no location complaint on production.

Verbatim transcript, Account A (AGY_CLI_MODEL_API_MAX_RETRIES=0):

$ agy --version
1.2.2

$ agy --model gemini-3.8-flash-low -p "say OK"
error: FAILED_PRECONDITION (code 400): User location is not supported for the API use.

$ agy --model gemini-3.6-flash-low -p "say OK"
error: FAILED_PRECONDITION (code 400): User location is not supported for the API use.

$ agy --model gemini-3.1-pro-low -p "say OK"
error: FAILED_PRECONDITION (code 400): User location is not supported for the API use.

$ agy --model claude-sonnet-4-6 -p "say OK"
OK

$ CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com agy --model gemini-3.8-flash-low -p "say OK"
error: RESOURCE_EXHAUSTED (code 429): Resource has been exhausted (e.g. check quota).

$ CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com agy --model claude-sonnet-4-6 -p "say OK"
error: RESOURCE_EXHAUSTED (code 429): Resource has been exhausted (e.g. check quota).

Verbatim transcript, Account B, same machine, same IP, minutes later:

$ agy --model gemini-3.8-flash-low -p "say OK"
error: Your current account is not eligible for Gemini Code Assist for individuals because it is not currently available in your location.

$ agy --model claude-sonnet-4-6 -p "say OK"
error: Your current account is not eligible for Gemini Code Assist for individuals because it is not currently available in your location.

$ CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com agy --model gemini-3.8-flash-low -p "say OK"
error: Your current account is not eligible for Gemini Code Assist for individuals because it is not currently available in your location.

Secondary bug: eligibility check hard-fails on an IPv6-only avatar fetch

On a machine with no routable IPv6, the first run after signing in fails outright:

error: Eligibility check failed: failed to get profile picture:
Get "https://lh3.googleusercontent.com/a/...=s96-c":
dial tcp [2404:6800:4005:826::2001]:443: connectex: A connection attempt failed ...

The eligibility check resolves the avatar URL to IPv6 only with no IPv4 fallback, blocking the entire session on a cosmetic asset. Subsequent runs get past it.

Things ruled out

Not a VPN, proxy or geo-IP spoofing artifact. Egress is a single plain residential IPv4 (verified against an IP geolocation service), no IPv6 route, HTTP_PROXY/HTTPS_PROXY unset. Whatever the correct location verdict is, it is applied inconsistently: two accounts at one location get different answers, and one account gets different answers from two backends.
GOOGLE_CLOUD_PROJECT has no effect. Setting it does not populate the quota project - applyAuthResult still logs quotaProject= (empty). The CLI appears not to forward it as x-goog-user-project.
Not fixed by switching accounts. The second consumer account is refused more broadly, not less.
Not fixed by updating or re-authenticating. agy update reports no version newer than 1.2.2; signing out and back in via the IDE changes nothing.
Not CLI-only. The same failure occurs in the Antigravity IDE agent, consistent with a shared backend route.

Workaround

For Account A only: non-Gemini models (claude-sonnet-4-6, claude-opus-4-6-thinking) work on the default backend. There is no workaround for Account B - every model is refused at the eligibility gate. Forcing the production backend with CLOUD_CODE_URL removes the location error but yields 429, so it is evidence rather than a workaround.

Logs & Configurations

From agy --log-file ./agy.log --model gemini-3.8-flash-low -p "say OK" (Account A):

server_oauth.go:192] applyAuthResult: email=<redacted>, authMethod=consumer, quotaProject=
http_helpers.go:299] URL: https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
http_helpers.go:299] URL: https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
server.go:1145]      Conversation using project ID: default-cli-project
server.go:2091]      Backend project ID updated dynamically to: default-cli-project
errorreport.go:224]  agent executor error: generating and executing:
                     FAILED_PRECONDITION (code 400): User location is not supported for the API use.

Note quotaProject= is empty, matching the account-provisioning reports where the backend fails to associate a Cloud Project ID and surfaces the failure as a location error.

The log line for Account B has the identical shape (authMethod=consumer, quotaProject= empty), so the two accounts are not distinguishable by anything visible client-side.

Error IDs:

10373e5b-4364-422f-b901-ec8dcee4abda-1
c86d1bcc-388c-4969-89a2-f0eed172c1fd-1

No custom configuration: no proxy env vars, GOOGLE_CLOUD_PROJECT unset (and ignored when set), default backend host, no MCP servers configured for these runs.

@omempty

Hi @omempty, The errors you are seeing (not currently available in your location and FAILED_PRECONDITION: User location is not supported for the API use) are server-side account and regional eligibility restrictions enforced by Google's backend services, not a bug in the Antigravity CLI client. Because this repository is strictly for CLI client bugs and feature requests, we cannot resolve account-level or regional availability restrictions here. For account eligibility or regional support questions, please reach out on the Antigravity Forum

Adding a data point to this issue with what I believe is the decisive evidence: the server returns a tier for my account, yet every gated call is still rejected. This is a different account from the two in the original report, on the same machine and the same network egress.

Environment

Antigravity IDE 2.14.0 and Antigravity CLI 1.2.5 on Windows 11. Both reproduce the same failure with the same account, so this is not IDE-specific.
Account type: personal / consumer (authMethod=consumer), not Workspace.
Account registered country/region: United States 鈥?verified at https://policies.google.com/terms while signed in as this exact account.
This account was previously associated with China. A region change was submitted through https://policies.google.com/country-association-form and Google approved it in August 2026; the Terms of Service page has shown "United States" since then.
Network egress tested from four different locations, all of which are on the supported list in the Antigravity FAQ: United States (Los Angeles), Singapore, Japan (Tokyo), Taiwan (Taipei). The result is identical in all four, which matches the guidance that this check uses the account's home region rather than the current IP.

The core problem

(1) The server evidently grants this account a tier. The CLI TUI header displays:

3143***@qq.com (Antigravity Starter Quota)

The literal string Antigravity Starter Quota does not exist anywhere in the client binary 鈥?I scanned the 187 MB agy.exe, and only internal constants such as GCP_GE_FRONTLINE_STARTER_TIER are present, alongside (*License).GetTierDisplayName and SelectLicenseRequest.tier_display_name. So this tier display name is returned by the server, i.e. the account does hold a licence.

(2) Yet every call that goes through the eligibility gate is denied:

$ agy models
<lists all models successfully>

$ agy -p "Reply with exactly: OK"
error: Your current account is not eligible for Gemini Code Assist for individuals
because it is not currently available in your location.
Error ID: 6f6d3d66-8ec4-4d46-9292-b4dcf9cd80fe-1-1008

$ agy -p "Reply with exactly: OK" --model claude-sonnet-4-6
<identical error>

$ agy -p "/usage"
error: /usage failed: retrieving quota summary: failed to retrieve user quota summary:
PERMISSION_DENIED (code 403): Your current account is not eligible for Gemini Code Assist
for individuals because it is not currently available in your location.

In the IDE, both generation and conversation-title generation fail with the same 403.

So: generation, quota summary and title generation are all gated; model availability is not. All models are affected, Gemini and Claude alike.

This is not a stale local token

I deleted the shared credential (cmdkey /delete:gemini:antigravity), signed out of both the IDE and the CLI, and re-authenticated from scratch through the browser flow, explicitly choosing this account. After re-authentication the TUI resolved and displayed the Antigravity Starter Quota tier 鈥?and the 403 was completely unchanged.

This is not the preview backend

Forcing the production endpoint via CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com produces an identical 403, and the log confirms the request actually went to the production host:

applyAuthResult: email=3143***@qq.com, authMethod=consumer, quotaProject=
URL: https://cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
"message": "Your current account is not eligible for Gemini Code Assist for individuals
            because it is not currently available in your location.",
"status": "PERMISSION_DENIED",

Note that quotaProject= is empty in every run.

IDE log (%APPDATA%\Antigravity\logs\language_server.log) 鈥?the Set* calls fire immediately after the loadCodeAssist response, and all three values are empty:

14:40:13.225  http_helpers.go:296]    URL: https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
14:40:14.690  http_helpers.go:296]    URL: https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
14:40:15.036  auth_provider.go:1057]  [AuthProvider] SetProjectID called with projectID: ""
14:40:15.036  auth_provider.go:1065]  [AuthProvider] SetLocation  called with location: ""
14:40:15.036  auth_provider.go:1073]  [AuthProvider] SetUserTier  called with userTier: "", tierDisplayName: ""

trajectory_id: 4fb916bd-4a5b-4309-97ec-683a7c15a93f

What I have already ruled out

Not a stale token or local cache 鈥?full credential deletion and fresh re-authentication, as above.
Not the daily/preview backend 鈥?identical result on the production endpoint.
Not IP or geography 鈥?four supported-country egress IPs give the same result.
Not a missing subscription 鈥?the Plans documentation states that users not on AI Pro/Ultra still receive a baseline quota, and this account does resolve a tier.
Not model-specific 鈥?Claude is denied exactly like Gemini.
Not IDE-specific 鈥?the official CLI reproduces it without the IDE.

Hypothesis

The account holds a valid licence 鈥?the server even returns its tier display name 鈥?but the eligibility check that gates generation and quota queries appears to evaluate Gemini Code Assist for individuals, the consumer product Google retired in June 2026, and rejects this account, surfacing the rejection as a location error. Since the account's associated region was changed CN 鈫?US and approved in August 2026, the most likely cause is a stale region / eligibility (or never-refreshed provisioning) record left behind by that region change, in whatever service backs v1internal:loadCodeAssist.

Requests

Please re-provision or refresh the entitlement for this account, or tell me which specific field this check evaluates so I can verify it from the account side.
Separately, please consider a distinct error message for the retired-product case. In my case the location wording sent me down a long path of testing VPN regions, exit IPs and proxy rules, even though the account's location is valid and on the supported list.

Happy to provide the full account identifier privately if that helps; the Error IDs and trajectory_id above should be enough to locate the account.

language_server.log

Reproduced on agy 1.2.6.

Default backend:
Gemini 3.8 Flash Low -> FAILED_PRECONDITION 400: User location is not supported
Claude Sonnet 4.6 -> OK

Production backend:
CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com
Gemini 3.8 Flash Low -> RESOURCE_EXHAUSTED 429

Logs:
authMethod=consumer, quotaProject=
daily-cloudcode-pa.googleapis.com
Conversation using project ID: default-cli-project

I can reproduce exactly the same account-scoped behavior described in this issue.

Environment:

Antigravity Desktop 2.15.0 on macOS
Antigravity CLI 1.2.7
Personal Gmail consumer account
Google Terms country: United States
Google Payments profile: United States
Age verification: no verification required
Gemini API on this account/project has previously been activated and is still working

Network tests:

US egress tested
Japan egress tested
Taiwan residential ISP (Chunghwa Telecom AS3462) tested
No IPv6 leakage observed

Default backend:
https://daily-cloudcode-pa.googleapis.com

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

Claude Sonnet 4.6 works normally on the same account, device and network.

CLI authentication log:
authMethod=consumer, quotaProject=

When forcing:
CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com

the location error disappears and changes to:
RESOURCE_EXHAUSTED (429)

Therefore this does not appear to be an actual geographic restriction. It appears to be an account-level Antigravity / Cloud AI Companion eligibility or provisioning issue on the daily backend.

Recent trace IDs:
0xbab6f3a142286d97
0xe5627c6397ebbce
0x3dfeec1bd331a570

CLI Error ID:
49b7ba90-5f06-4a1c-91c7-a48efcdb9881-1

Production endpoint Error ID:
da32127c-24c2-4af6-9be8-27b8b2226cfc-9

Could the Antigravity consumer entitlement / eligibility state for this account be checked or reprovisioned?

Additional reproduction on Antigravity IDE 2.5.5 (macOS, Apple Silicon):

Consumer Google account; email intentionally omitted.
Gemini 3.8 Flash Medium fails in Agent mode with:
FAILED_PRECONDITION (400): User location is not supported for the API use.
Claude Opus 4.6 (Thinking) works in the same IDE session.
A local HTTP proxy was configured and ordinary Google connectivity succeeds, but Gemini Agent still fails.
No account switching or credential deletion was involved.

This appears to match the account/backend eligibility or daily-cloudcode-pa routing behavior described here. Could maintainers confirm whether this is a server-side entitlement/provisioning issue and whether there is a supported Gemini backend or fix?

I have intentionally omitted email, IP address, local paths, screenshots, and error IDs. I can provide sanitized diagnostics if needed.

I can reproduce the same issue on Antigravity CLI 1.2.10.

Environment:

OS: Linux VM running on VMware
Antigravity CLI: 1.2.10
Account: Google AI Pro
Google account country/version: Taiwan
Proxy path: Linux VM -> HTTP proxy on Windows -> Clash Party
Egress location: Japan
Egress IP is stable across repeated requests (10/10 requests returned the same IP)

The network/proxy path has been verified carefully.

Gemini consistently fails

Command:

agy --model gemini-3.8-flash-low -p "say OK"

Result:

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

Recent Error ID:

b2cc1451-476c-4bc4-8d6d-e9ec52b41fe7-1

Claude works normally under exactly the same conditions

Using the same:

Google account
Linux VM
proxy
Japan egress IP
Antigravity CLI session

Claude Opus 4.6 works successfully.

So this does not appear to be a general account authentication issue or a general connectivity issue.

The Gemini backend is definitely going through the proxy

Clash Party shows active connections from Antigravity to:

daily-cloudcode-pa.googleapis.com

through the selected Japan proxy node.

I also verified the traffic using tcpdump.

During the failing Gemini request, I observed traffic from the Linux VM to the configured Windows proxy, but no direct outbound TCP 443, TCP 5228, or UDP 443 connections from the Linux VM to public Google IP addresses.

Therefore this does not appear to be the HTTPS_PROXY bypass issue described in #875.

antigravity.google is reachable normally

Through the same proxy path:

curl -I -x http://:7892 https://antigravity.google/

returns HTTP 200 successfully.

The Antigravity website and Google services are reachable without TLS errors.

The most interesting result: changing CLOUD_CODE_URL changes the error

With the default backend:

daily-cloudcode-pa.googleapis.com

Gemini returns:

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

But when I run:

AGY_CLI_MODEL_API_MAX_RETRIES=0
CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com
agy --model gemini-3.8-flash-low -p "say OK"

the location error disappears completely and the result becomes:

RESOURCE_EXHAUSTED (code 429): Resource has been exhausted.

This is reproducible on the same:

account
machine
CLI version
proxy
Japan egress IP

The only changed variable is CLOUD_CODE_URL.

This strongly suggests that the location/eligibility result differs between:

daily-cloudcode-pa.googleapis.com

and:

cloudcode-pa.googleapis.com

for the same account and network.

Since Claude works normally and the production Cloud Code backend no longer reports the location error, this appears to be specific to Gemini eligibility/location handling on the daily-cloudcode backend.

Please let me know if there are any additional logs, trace IDs, or diagnostics I can provide.

I can reproduce this issue on Antigravity CLI 1.2.11 on Ubuntu 24.04.

Environment:

Host: VM-0-3-ubuntu
Public IPv4: 43.165.168.103
Cloudflare location: JP
No HTTP_PROXY or HTTPS_PROXY variables
Google AI Pro consumer account
Google account region change to the United States was approved

Reproduction:

Gemini 3.8 Flash (High): FAILED_PRECONDITION (code 400)
Gemini 3.1 Pro (Low): FAILED_PRECONDITION (code 400)
Claude Sonnet 4.6: works normally in the same session, account, host and network

Re-authentication, model switching and updating to CLI 1.2.11 did not help.

Error ID: fd349827-10f3-4818-911b-aeaa11b6ee70-1
Error ID: 080b43c0-511c-409e-a5ae-4abadc0895df-1

I have also submitted the report through /feedback.

Please check the backend Gemini eligibility, region and entitlement/provisioning state for this account, and advise whether a server-side resynchronization is required.

+1, same issue here.

Antigravity IDE on Linux (Ubuntu)
Consumer Google account (personal Gmail), Google AI Pro subscription active
Account was working normally, then I changed my Google account email — after that, every sign-in attempt fails with:
"There was an unexpected issue setting up your account. Your account is not eligible for Gemini Code Assist for individuals at this time."
Subscription is confirmed active on one.google.com (Google AI Pro, 5TB plan)
Verified the OAuth callback itself now works correctly (fixed a local xdg-mime/protocol-handler issue), but the eligibility check still fails server-side regardless of that.

Reproduced on Antigravity CLI 1.2.14.
Environment:

OS: Linux
Antigravity CLI: 1.2.14
Consumer Google account
Egress location: Tokyo, Japan
Egress IP is from AWS Tokyo (AS16509 Amazon.com, Inc.)
Gemini Web works normally with the same Google account
Results:
agy --model claude-sonnet-4-6 -p "say OK"

Result:
OK

Gemini on the default backend:
agy --model gemini-3.8-flash-low -p "say OK"

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

Error ID:
f189d08a-bea5-4f9c-8823-e8980bed25b9-1

The same test with the production Cloud Code endpoint:
CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com
agy --model gemini-3.8-flash-low -p "say OK"

Result:
RESOURCE_EXHAUSTED (code 429):
Resource has been exhausted (e.g. check quota).

Error ID:
521efddf-4b43-4642-b36a-9f72eaf1862a-9

This is reproducible with the same account, machine, CLI session, and network. Claude Sonnet 4.6 works normally, Gemini Web works normally, and changing only CLOUD_CODE_URL removes the location error and changes it to a quota error.
This still reproduces on CLI 1.2.14, so it appears to be specific to Gemini eligibility/location handling on the default daily-cloudcode-pa.googleapis.com backend rather than a general authentication or connectivity issue.
Please let me know if additional logs or diagnostics would help.

Environment:

macOS
Antigravity CLI 1.2.14
Google AI Ultra account
Network egress: supported region
Local HTTP proxy configured

Reproduction:

agy --model gemini-3.8-flash-low -p "say OK"

Result:

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

Relevant log lines:

Backend project ID updated dynamically to: default-cli-project
applyAuthResult: email=<redacted>, authMethod=consumer, quotaProject=
URL: https://daily-cloudcode-pa.googleapis.com/v1internal:loadCodeAssist
URL: https://daily-cloudcode-pa.googleapis.com/v1internal:fetchAvailableModels
Conversation using project ID: default-cli-project
FAILED_PRECONDITION (code 400): User location is not supported for the API use.

I verified that both normal traffic and explicitly proxied traffic use the same egress location in a supported region.

I also explicitly passed proxy variables to Antigravity:

HTTPS_PROXY=http://127.0.0.1:7890 \
HTTP_PROXY=http://127.0.0.1:7890 \
agy --model gemini-3.8-flash-low -p "say OK"

The result is still:

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

However, when switching the backend:

AGY_CLI_MODEL_API_MAX_RETRIES=0 \
CLOUD_CODE_URL=https://cloudcode-pa.googleapis.com \
HTTPS_PROXY=http://127.0.0.1:7890 \
HTTP_PROXY=http://127.0.0.1:7890 \
agy --model gemini-3.8-flash-low -p "say OK"

the error changes to:

RESOURCE_EXHAUSTED (code 429): Resource has been exhausted (e.g. check quota).

Claude works normally on the same machine, account, and network:

agy --model claude-sonnet-4-6 -p "say OK"

Result:

OK

This suggests the issue may be related to the daily-cloudcode-pa.googleapis.com Gemini eligibility / provisioning path for consumer accounts, rather than the local proxy configuration or actual geographic location.

One potentially relevant detail is:

authMethod=consumer, quotaProject=

with fallback to:

default-cli-project

This may indicate an account entitlement or quota-project provisioning issue.

Another data point for the "Account B" / every-model-gated case.

ENVIRONMENT
agy 1.4.2 (also reproduced on 1.4.1 - rolled back, identical result)
Linux, consumer Google account, single residential egress
Two independent consumer Gmail accounts tested - both refused

SYMPTOM
Every model is refused at the eligibility gate, not just Gemini:
gemini-4-argon, gemini-3.8-flash, claude-opus-5-5,
claude-sonnet-5-5, gpt-oss-120b -> all the same
RESOURCE_EXHAUSTED (code 429): Resource has been exhausted
(e.g. check quota). usage: total_tokens: 0
So this is Account B in the table above - no model works, so the
non-Gemini workaround does not apply.

VERSION-INDEPENDENT

agy update -> already latest (1.4.2)
Downloaded the 1.4.1 linux x64 release, ran it side by side ->
identical 429, identical 0 tokens. Not a 1.4.2 client regression.

LOG SIGNATURE (matches the report)
applyAuthResult: email=..., authMethod=consumer, quotaProject= (empty)
loadCodeAssist -> fetchAvailableModels -> streamGenerateContent -> 429
The CLI never calls v1internal:onboardUser, so no quota project is
ever attached. fetchAvailableModels SUCCEEDS, so the OAuth token is
valid - auth is not the problem.

CROSS-CHECK: the Antigravity IDE on the same machine works
Same box, same ~/.gemini home, same day: the Antigravity IDE signed in
at 11:01 and its cloudcode log shows
POST v1internal:loadCodeAssist
POST v1internal:fetchAvailableModels
POST v1internal:onboardUser <-- the step the CLI skips
and then streamGenerateContent returned real responses at 11:02 with
no 429.

This is the part I would most like clarified: if the gate is
account-scoped as the triage above says, why does the IDE on the same
account and machine generate normally while the CLI is refused every
model? Either the IDE resolves a different account/entitlement, or the
CLI is failing the provisioning step (no onboardUser / empty
quotaProject) that the IDE completes.

ALREADY RULED OUT LOCALLY (all reproduced, all null)
re-login (both accounts), killing all agy processes, clearing the
project cache, agy --new-project, resetting the onboarding cache,
switching models across families, and rolling back to 1.4.1.

ASK
Confirm whether the CLI should call onboardUser for a consumer account,
and if so what makes it skip it. Otherwise name the account/regional
eligibility change refusing these accounts so we know what to wait for
or appeal.

Navigation Menu

Repository navigation

[Bug]: All models gated behind a retired "Gemini Code Assist for individuals" eligibility check - verdict differs between two accounts at the same location #1016

Antigravity CLI Version

Environment Context

Steps to Reproduce

Expected Behavior

Actual Behavior / Error Screenshots

Secondary bug: eligibility check hard-fails on an IPv6-only avatar fetch

Things ruled out

Workaround

Related

Logs & Configurations

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug]: All models gated behind a retired "Gemini Code Assist for individuals" eligibility check - verdict differs between two accounts at the same location #1016

Description

Antigravity CLI Version

Environment Context

Steps to Reproduce

Expected Behavior

Actual Behavior / Error Screenshots

Secondary bug: eligibility check hard-fails on an IPv6-only avatar fetch

Things ruled out

Workaround

Related

Logs & Configurations

Activity

chandrashakherkamasani commented on Sep 16, 2026

Jiayze commented on Sep 17, 2026

yeahjack commented on Sep 18, 2026

hwhuang-git commented on Sep 19, 2026

humorouslove commented on Sep 24, 2026

Some0neChen commented on Sep 24, 2026

BridgeX-ai commented on Sep 25, 2026

ahmedhamdy09 commented on Sep 26, 2026

qinzhengze commented on Oct 2, 2026

dragonjia commented on Oct 2, 2026

hawkinle commented on Oct 19, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions