You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Have Antigravity authenticated in T3 Code (Agent Platform (Vertex AI), GCP project/location set). The bundled runtime is the official agy-acp-server-1.3.0.
Open Settings → Providers → Antigravity → Models (or the composer model picker).
On the same machine, run agy models with the installed Antigravity CLI (1.3.4).
Expected behavior
The Gemini 4 Argon variants are available in T3 Code, as they are in the CLI.
Actual behavior
T3 lists 14 models, all Gemini 3.x. gemini-4-argon never appears, and neither the model picker nor a manual selection can reach it. On the same machine agy models lists:
T3 Code current main; bundled Antigravity runtime 1.3.0; Antigravity CLI 1.3.4.
Environment
macOS (arm64), Antigravity provider via agy_acp_server.
Logs or stack traces
The bundled ACP binary predates the model:
apps/server/src/provider/antigravityRelease.ts pins ANTIGRAVITY_RELEASE_VERSION = "1.3.0" and downloads https://dl.google.com/agy-extensions/releases/macos/agy-acp-server-1.3.0-darwin-arm64.zip.
That binary reports Built on Tue Sep 29 23:37:23 2026. Gemini 4 Argon was announced Sep 30, 2026.
strings agy_acp_server.par contains gemini-3.8-flash-* but no gemini-4-argon string, so the ACP session never advertises it.
No newer ACP release exists yet: agy-acp-server-1.3.1..1.3.5-darwin-arm64.zip all return 404 on dl.google.com, and the ACP Registry entry antigravity-acp is still 1.3.0.
As your triage on #15378 explains, T3 copies model options from the agy_acp_server session (buildAntigravityModelsFromSession); agy models reads a different catalog. So this is the ACP runtime being older than the model, not a filtered T3 list.
Screenshots, recordings, or supporting files
No response
Workaround
Use agy --model gemini-4-argon-high directly, or the model through another route (Gemini API / Agent Platform). Requesting a newer agy-acp-server from Google is the real unblock.
This is a stale runtime pin in T3, not a model filter, and it's fixable now. A newer runtime has shipped since you checked.
On main, apps/server/src/provider/antigravityRelease.ts pins ANTIGRAVITY_RELEASE_VERSION = "1.3.0". buildAntigravityModelsFromSession passes the ACP session's model options through without filtering, so T3 can't list a model the 1.3.0 runtime doesn't advertise.
Google published agy-acp-server-1.4.0 on dl.google.com on Oct 12 (darwin-arm64, darwin-x86_64 and linux-x86_64 all return 200). The darwin-arm64 build is dated Oct 12 2026 and contains gemini-4-argon-high, -medium and -low. The ACP Registry entry still says 1.3.0, which is why the pin hasn't moved.
Keeping this open to bump the pin to 1.4.0, with re-verified hashes and sizes for each platform. Until then, agy --model gemini-4-argon-high is the workaround.
Bumped the pin to 1.4.0 in #19151 (all six platforms re-verified by downloading each archive: sha256, archive size, executable and harness sizes), and added the Gemini 4 Argon variants to the Antigravity catalog metadata so they land as current rather than Legacy.
Could T3 automatically update its managed Antigravity runtime when a T3 update brings a newer pinned ACP version?
My Windows installation reports 1.3.0. In this build, AntigravityInstallation.resolve uses the release selected by active.json without checking it against the pin. Startup reads the installed version but does not upgrade it. Bumping the pin therefore appears to leave existing installations on the old runtime until users reinstall it.
Please consider updating to the new pinned, checksum-verified release automatically, or offering an automatic-update setting. If updates stay manual, an "Update Antigravity" button showing the installed and available versions would make this clearer than "Reinstall".
Active sessions could keep their current runtime while new sessions use the update. Custom executable paths should stay manually managed.
This would complement #19151 so existing users get the newer runtime too.
Written by Claude (AI) after testing on a real install.
The 1.4.0 bump (#19151) is correct but doesn't make Argon appear for personal Google sign-ins, because Google's service only offers Argon to its own CLI.
Setup: macOS arm64, Google AI Pro account, oauth-personal, T3 pointed at the official agy-acp-server-1.4.0 (sha256 matches #19151). The runtime's log confirms the account: paidTier: g1-pro-tier (Google AI Pro).
1. The 1.4.0 runtime itself doesn't filter Argon out. Its model_selection.py (embedded in the binary) picks the model list by sign-in method:
oauth-personal: list comes from CCPA v1internal:fetchAvailableModels. The only client-side filter drops non-Gemini ids unless the client is JetBrains, Zed or Xcode (supports_third_party_models, the cause of [Antigravity] Full model catalog depends on ACP clientInfo.name #16489). gemini-4-argon-* would pass.
API key: static list that excludes Argon (agent_platform_only=True).
Agent Platform: static list that includes Argon (comment: "Vertex serves it only at location global"). That's probably why the original report, on Vertex, expects to see it.
2. CCPA decides by User-Agent product token. Same account, same fetchAvailableModels request body, only the User-Agent changed:
User-Agent product
gemini-4-argon-* in agentModelSorts
antigravity/acp/1.4.0 (…; host_path=t3-code/…), the one the runtime sends
So the account is entitled to Argon, but Google currently serves it only to the Antigravity CLI surface, not to antigravity/acp. The runtime builds this User-Agent itself, and an ACP client only controls host_path, so T3 can't change this legitimately.
For oauth-personal this needs Google to enable Argon for antigravity/acp. A pin bump can't fix it.
Side note: with the T3 client name, the runtime surfaced only the 3.8 Flash variants even though CCPA's agentModelSorts also offered 3.7/3.6 Flash and 3.1 Pro. I didn't dig into that.
Linux x86_64 qualification follow-up for #19150, 2026-10-15:
The public ACP registry now selects1.4.0: https://github.com/agentclientprotocol/registry/blob/main/antigravity-acp/agent.json . The linked Google Linux archive contains both agy_acp_server.par and localharness_external. Observed archive size336175910, computed SHA256 fbb2d54dd94fb897845308d3b6b46187c627f1c60078ded81adeeaf8b90c5d7a (locally computed integrity evidence, not a separately published vendor checksum).
An empty-home, zero-capability, no-network/no-credential isolated initialize probe identifies antigravity-acp1.4.0, protocol1, loadSession true, session list/resume, auth logout and oauth-personal/oauth-business/gemini-api-key/agent-platform methods. No authentication, session creation or completion was run, so this does not claim Argon session/catalog acceptance.
Nightly3176 still pins1.3.0. Its supported custom binaryPath resolver checks the real executable's sibling localharness_external, so users adopting a custom runtime must retain the complete executable pair. Pointing that field at the ordinary agy CLI would not select this ACP package. Existing personal sign-in and settings should be preserved when adopting the newer runtime.
For reproduction, the isolated Google executable required read-only CPU topology and a valid synthetic passwd entry for the test UID. Omitting passwd caused an early silent255 whose private test log explained getpwuid_r failure; adding those normal OS metadata inputs allowed initialize to complete0. No host sandbox/policy relaxation was needed.
Activity
juliusmarminge commentedon Oct 13, 2026
Note
Grok responding on behalf of Julius.
This is a stale runtime pin in T3, not a model filter, and it's fixable now. A newer runtime has shipped since you checked.
apps/server/src/provider/antigravityRelease.tspinsANTIGRAVITY_RELEASE_VERSION = "1.3.0".buildAntigravityModelsFromSessionpasses the ACP session's model options through without filtering, so T3 can't list a model the 1.3.0 runtime doesn't advertise.agy-acp-server-1.4.0on dl.google.com on Oct 12 (darwin-arm64, darwin-x86_64 and linux-x86_64 all return 200). The darwin-arm64 build is dated Oct 12 2026 and containsgemini-4-argon-high,-mediumand-low. The ACP Registry entry still says 1.3.0, which is why the pin hasn't moved.clientInfo.name) and [Bug]: Antigravity provider lists only Gemini models; Claude and GPT-OSS models reported byagy modelsare missing #15378 (Claude and GPT-OSS missing) are separate: those models are in the runtime but hidden. Argon isn't in 1.3.0 at all.Keeping this open to bump the pin to 1.4.0, with re-verified hashes and sizes for each platform. Until then,
agy --model gemini-4-argon-highis the workaround.mertbozkir commentedon Oct 13, 2026
Bumped the pin to 1.4.0 in #19151 (all six platforms re-verified by downloading each archive: sha256, archive size, executable and harness sizes), and added the Gemini 4 Argon variants to the Antigravity catalog metadata so they land as current rather than Legacy.
suhasganga commentedon Oct 14, 2026
Note
GPT-6.1-Sol responding on behalf of Suhas.
Could T3 automatically update its managed Antigravity runtime when a T3 update brings a newer pinned ACP version?
My Windows installation reports 1.3.0. In this build,
AntigravityInstallation.resolveuses the release selected byactive.jsonwithout checking it against the pin. Startup reads the installed version but does not upgrade it. Bumping the pin therefore appears to leave existing installations on the old runtime until users reinstall it.Please consider updating to the new pinned, checksum-verified release automatically, or offering an automatic-update setting. If updates stay manual, an "Update Antigravity" button showing the installed and available versions would make this clearer than "Reinstall".
Active sessions could keep their current runtime while new sessions use the update. Custom executable paths should stay manually managed.
This would complement #19151 so existing users get the newer runtime too.
promonteiro89 commentedon Oct 14, 2026
Note
Written by Claude (AI) after testing on a real install.
The 1.4.0 bump (#19151) is correct but doesn't make Argon appear for personal Google sign-ins, because Google's service only offers Argon to its own CLI.
Setup: macOS arm64, Google AI Pro account,
oauth-personal, T3 pointed at the officialagy-acp-server-1.4.0(sha256 matches #19151). The runtime's log confirms the account:paidTier: g1-pro-tier (Google AI Pro).1. The 1.4.0 runtime itself doesn't filter Argon out. Its
model_selection.py(embedded in the binary) picks the model list by sign-in method:oauth-personal: list comes from CCPAv1internal:fetchAvailableModels. The only client-side filter drops non-Gemini ids unless the client is JetBrains, Zed or Xcode (supports_third_party_models, the cause of [Antigravity] Full model catalog depends on ACP clientInfo.name #16489).gemini-4-argon-*would pass.agent_platform_only=True).global"). That's probably why the original report, on Vertex, expects to see it.2. CCPA decides by User-Agent product token. Same account, same
fetchAvailableModelsrequest body, only the User-Agent changed:gemini-4-argon-*inagentModelSortsantigravity/acp/1.4.0 (…; host_path=t3-code/…), the one the runtime sendsantigravity/acp/1.4.0 (…; host_path=unknown/unknown)antigravity/cli/…So the account is entitled to Argon, but Google currently serves it only to the Antigravity CLI surface, not to
antigravity/acp. The runtime builds this User-Agent itself, and an ACP client only controlshost_path, so T3 can't change this legitimately.What this means here
global) get Argon, andoauth-personalusers will get it once Google enables it for the ACP surface.oauth-personalthis needs Google to enable Argon forantigravity/acp. A pin bump can't fix it.agentModelSortsalso offered 3.7/3.6 Flash and 3.1 Pro. I didn't dig into that.ViperJuice commentedon Oct 16, 2026
Linux x86_64 qualification follow-up for #19150, 2026-10-15:
The public ACP registry now selects1.4.0: https://github.com/agentclientprotocol/registry/blob/main/antigravity-acp/agent.json . The linked Google Linux archive contains both
agy_acp_server.parandlocalharness_external. Observed archive size336175910, computed SHA256fbb2d54dd94fb897845308d3b6b46187c627f1c60078ded81adeeaf8b90c5d7a(locally computed integrity evidence, not a separately published vendor checksum).An empty-home, zero-capability, no-network/no-credential isolated initialize probe identifies
antigravity-acp1.4.0, protocol1, loadSession true, session list/resume, auth logout and oauth-personal/oauth-business/gemini-api-key/agent-platform methods. No authentication, session creation or completion was run, so this does not claim Argon session/catalog acceptance.Nightly3176 still pins1.3.0. Its supported custom binaryPath resolver checks the real executable's sibling
localharness_external, so users adopting a custom runtime must retain the complete executable pair. Pointing that field at the ordinaryagyCLI would not select this ACP package. Existing personal sign-in and settings should be preserved when adopting the newer runtime.For reproduction, the isolated Google executable required read-only CPU topology and a valid synthetic passwd entry for the test UID. Omitting passwd caused an early silent255 whose private test log explained getpwuid_r failure; adding those normal OS metadata inputs allowed initialize to complete0. No host sandbox/policy relaxation was needed.
7heMech commentedon Oct 24, 2026
We need bump yea
BWBama85 commentedon Oct 24, 2026
The pin is now two releases behind 1.4.0. As of 2026-10-24:
mainstill hasANTIGRAVITY_RELEASE_VERSION = "1.3.0"inapps/server/src/provider/antigravityRelease.ts.antigravity-acplists 1.4.3: https://github.com/agentclientprotocol/registry/blob/main/antigravity-acp/agent.jsonhttps://dl.google.com/agy-extensions/releases/macos/agy-acp-server-1.4.3-darwin-arm64.zipis downloadable.agy --version) reports 1.4.7.So any bump in #19620 could target 1.4.3 rather than 1.4.0. I haven't verified the 1.4.3 hashes or sizes for each platform.
7heMech commentedon Oct 24, 2026
Argon does work now so I'm happy.
t3dotgg commentedon Nov 1, 2026
Note
🤖 GPT-6.1 Terra [1m] responding on behalf of Theo
Closing as resolved by the Antigravity runtime update to 1.4.1. The follow-up also confirms that Argon is now available. #26876 antigravityRelease.ts #19150 comment