Skip to content

[Bug]: Antigravity provider never lists Gemini 4 Argon (bundled ACP runtime 1.3.0 predates it) #19150

Closed

Description

@mertbozkir

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

  1. 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.
  2. Open Settings → Providers → Antigravity → Models (or the composer model picker).
  3. 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:

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.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.

Activity

  1. juliusmarminge commented on Oct 13, 2026

    @juliusmarminge
    Member

    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.

    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.

  2. added
    acceptedfeature request accepted
    bugSomething is broken or behaving incorrectly.
    via-triageFiled through npx t3 triage
    on Oct 13, 2026
  3. mertbozkir commented on Oct 13, 2026

    @mertbozkir
    Author

    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.

  4. suhasganga commented on Oct 14, 2026

    @suhasganga

    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.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.

  5. promonteiro89 commented on Oct 14, 2026

    @promonteiro89

    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 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 ❌
    antigravity/acp/1.4.0 (…; host_path=unknown/unknown) ❌
    antigravity/cli/… ✅ (listed first)

    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.

    What this means here

    • fix(server): pin Antigravity ACP runtime to 1.4.0 so Gemini 4 Argon is listed #19151 is still worth merging: Agent Platform users (location global) get Argon, and oauth-personal users will get it once Google enables it for the ACP surface.
    • 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.
  6. ViperJuice commented on Oct 16, 2026

    @ViperJuice

    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.

  7. added
    needs more infoInitial triage showed no bug. Awaiting more info
    and removed
    needs more infoInitial triage showed no bug. Awaiting more info
    on Oct 21, 2026
  8. 7heMech commented on Oct 24, 2026

    @7heMech

    We need bump yea

  9. BWBama85 commented on Oct 24, 2026

    @BWBama85

    The pin is now two releases behind 1.4.0. As of 2026-10-24:

    • main still has ANTIGRAVITY_RELEASE_VERSION = "1.3.0" in apps/server/src/provider/antigravityRelease.ts.
    • The ACP Registry entry for antigravity-acp lists 1.4.3: https://github.com/agentclientprotocol/registry/blob/main/antigravity-acp/agent.json
    • https://dl.google.com/agy-extensions/releases/macos/agy-acp-server-1.4.3-darwin-arm64.zip is downloadable.
    • Locally (macOS arm64), T3 Code's managed runtime reports 1.3.0 while the standalone Antigravity CLI (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.

  10. 7heMech commented on Oct 24, 2026

    @7heMech

    The pin is now two releases behind 1.4.0. As of 2026-10-24:

    • main still has ANTIGRAVITY_RELEASE_VERSION = "1.3.0" in apps/server/src/provider/antigravityRelease.ts.
    • The ACP Registry entry for antigravity-acp lists 1.4.3: https://github.com/agentclientprotocol/registry/blob/main/antigravity-acp/agent.json
    • https://dl.google.com/agy-extensions/releases/macos/agy-acp-server-1.4.3-darwin-arm64.zip is downloadable.
    • Locally (macOS arm64), T3 Code's managed runtime reports 1.3.0 while the standalone Antigravity CLI (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.

    Argon does work now so I'm happy.

  11. t3dotgg commented on Nov 1, 2026

    @t3dotgg
    Member

    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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    acceptedfeature request acceptedbugSomething is broken or behaving incorrectly.via-triageFiled through npx t3 triage

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions