[Antigravity] Full model catalog depends on ACP clientInfo.name

[tuananh4865]

Problem

With Antigravity ACP 1.3.0, the model catalog returned by the same authenticated Antigravity profile depends on the ACP clientInfo.name.

This is not a regression where updating ACP changed an existing 18-model T3 catalog down to 11 models. With the normal T3 identity, the raw ACP 1.3.0 runtime advertises 11 models. The 18-model catalog only appears when the client identifies itself as zed.

The additional models are the same Claude 5.5 and GPT-OSS variants also exposed by the Antigravity/agy CLI path.

Reproduction

Environment:

• macOS arm64
• Antigravity ACP 1.3.0
• OAuth personal authentication
• Same local Antigravity profile/account for all runs
• ACP protocol v2
• Same cwd
• session/new with mcpServers: []

Run A:

{
  "method": "initialize",
  "params": {
    "protocolVersion": 2,
    "clientInfo": {
      "name": "t3-code",
      "version": "0.0.46"
    },
    "clientCapabilities": {}
  }
}

Result after authentication + session/new:

• 11 model options
• Gemini models only

Run B changes only the client name:

{
  "clientInfo": {
    "name": "zed",
    "version": "0.0.46"
  }
}

Result after authentication + session/new:

• 18 model options
• The same 11 Gemini models plus:
  • Claude Opus 5.5 Low / Medium / High
  • Claude Sonnet 5.5 Low / Medium / High
  • GPT-OSS 120B Medium

Both runs use the same raw antigravity-acp 1.3.0 binary, same OAuth profile, same cwd, same protocol, and same session parameters. The only changed input is clientInfo.name.

Additional control runs with vscode, jetbrains, and a random ACP client name still returned 11 models. Both zed and Zed returned 18.

Controlled selection test

The difference is not cosmetic UI/catalog behavior.

With clientInfo.name = "t3-code", forcing:

claude-sonnet-5-5-low

through session/set_config_option is rejected by the raw ACP server with JSON-RPC error -32602:

Model 'claude-sonnet-5-5-low' is not available for the current authentication method.

The error response lists exactly the 11 Gemini models as available.

With the same OAuth profile and clientInfo.name = "zed", the same model switch succeeds. A real session/prompt using claude-sonnet-5-5-low completed with stopReason = end_turn and returned the expected test response.

So the extra 7 models are actually enabled by a Zed-specific path in ACP 1.3.0; they are not being injected only into T3's UI.

Expected behavior

T3 Code should have a supported way to receive the full Antigravity model catalog available through the provider/CLI integration without impersonating another ACP client implementation.

If Google intentionally gates Claude 5.5 / GPT-OSS availability by client identity, it would be useful to document the supported T3 client identifier / allowlist / capability-negotiation path, or coordinate a provider-side change.

Notes

• I am not proposing that T3 hard-code clientInfo.name = "zed"; that would misidentify the client.
• I am not proposing that T3 hard-code these models into model-manifest.json. The catalog should remain dynamic and come from Antigravity.
• mcpServers: [] is a separate compatibility detail. Omitting mcpServers causes ACP 1.3.0 to reject session/new with -32602 Field required; current T3 already supplies this field, and it is not what unlocks the extra models.
• feat(server): bump Antigravity ACP agent to 1.3.0 #15746 correctly updates the managed runtime to ACP 1.3.0. This issue is about client-identity-dependent model availability in that runtime, not about the runtime version bump reducing the catalog.