Repository navigation
Description
Before submitting
- 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 modelswith 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:
gemini-4-argon-high Gemini 4 Argon (High)
gemini-4-argon-medium Gemini 4 Argon (Medium)
gemini-4-argon-low Gemini 4 Argon (Low)
gemini-3.8-flash-high / medium / low
...
Impact
Major degradation or frequent failure
Version or commit
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.tspinsANTIGRAVITY_RELEASE_VERSION = "1.3.0"and downloadshttps://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.parcontainsgemini-3.8-flash-*but nogemini-4-argonstring, so the ACP session never advertises it.- No newer ACP release exists yet:
agy-acp-server-1.3.1..1.3.5-darwin-arm64.zipall return 404 ondl.google.com, and the ACP Registry entryantigravity-acpis still1.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.
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