antigravity-acp 1.0.0 filters oauth-personal model catalog to Gemini only

[tiezbro]

Summary

The public ACP Registry build of antigravity-acp currently advertises only Gemini models under oauth-personal, even when the same signed-in Antigravity account can list and execute Claude 4.6 and GPT-OSS 120B through the official Antigravity IDE/CLI.

This reproduces by driving the Registry binary directly over NDJSON; no Paseo proxy or model-catalog transformation is involved.

Affected Registry entry:

• Registry version: antigravity-acp 1.0.0
• Agent build: agy_acp_server_20260818_01_RC01
• Tested platform: Linux x86_64
• Tested binary SHA-256: 46b5925100903a23e0ec7da8b8a218c224494dfffeb3fd30fcd84e91acbc8b07
• Verified: 2026-08-28

Reproduction

1. Start the binary distributed by antigravity-acp/agent.json.
2. Send initialize with protocolVersion: 1.
3. Authenticate with methodId: "oauth-personal".
4. Send session/new with a valid cwd and mcpServers: [].
5. Inspect the model config option returned by session/new.
6. Send session/set_config_option with configId: "model" and value: "claude-sonnet-4-6".

Observed model catalog: 11 Gemini model IDs only.

Observed model-selection error:

-32602 Model 'claude-sonnet-4-6' is not available for the current authentication method.

gpt-oss-120b-medium is rejected in the same way. The legacy session/set_model method reaches the same result.

Control result using the same account:

agy models

returns 14 entries, including:

claude-sonnet-4-6
claude-opus-4-6-thinking
gpt-oss-120b-medium

The CLI can execute these models successfully.

Source-level finding in the distributed binary

The distributed PAR contains its Python source. In
acp_server/model_selection.py, the CCPA fetchAvailableModels parser explicitly drops every non-Gemini model:

# Only include models that start with "gemini".
if not ccpa_id.startswith("gemini"):
    continue

server.py::_apply_session_model then validates model IDs against that filtered catalog and raises -32602 before constructing the agent or forwarding the model ID to the CCPA inference path. This makes the error message look like an authentication/backend rejection even though the immediate rejection is local to the ACP server.

The result was unchanged across four initialize variants, including standard clientCapabilities, a full capability set, and Zed-like clientInfo. AGY_ACP_DEFAULT_MODEL, session/set_model, and session/set_config_option do not bypass the filtered catalog.

Registry coverage gap

The Registry protocol matrix currently reaches session/new: Authentication required for this agent and therefore never inspects the authenticated model catalog. Manifest validation and unauthenticated handshake tests can pass while this behavior remains undetected.

Expected outcome / questions

Could the Google publisher please confirm whether Gemini-only ACP exposure is intentional?

• If it is a defect, please publish an updated official agent build without the unconditional non-Gemini filter and update antigravity-acp/agent.json.
• If it is intentional, please document that the ACP surface does not have model parity with the Antigravity IDE/CLI and clarify the misleading current authentication method error.
• If practical, please add provider-owned authenticated coverage for the model catalog and model selection path.

Full protocol observations, evidence grading, ruled-out client parameters, and remaining unknowns:

https://github.com/tiezbro/paseo-agy-acp/blob/main/docs/research/google-antigravity-acp-model-catalog-investigation.md

cc @cynthialong0-0, author of the original Registry submission in #542.

[tiezbro]

Follow-up from an isolated, non-deployed verification against a local copy of the exact RC01 artifact. No token, account identifier, prompt body, or modified Google artifact was recorded or distributed.

Raw CCPA catalog is complete

With the ACP User-Agent and the same oauth-personal state, the unfiltered fetchAvailableModels response contains all 14 model IDs, including:

• claude-sonnet-4-6
• claude-opus-4-6-thinking
• gpt-oss-120b-medium

The third-party entries also include provider metadata and limits. For example, Claude is identified as Anthropic Vertex with a 64,000 output-token limit, and GPT-OSS as OpenAI Vertex with a 32,768 output-token limit. This directly rules out a separate raw backend entitlement as the reason for the 11-model ACP catalog: the unconditional local Gemini filter removes entries that CCPA did return to this ACP surface.

Removing the filter alone is not sufficient

After allowing the three IDs through the local model-selection guard, the RC01 ACP request path still produced invalid third-party requests because it builds every target through GeminiAPIEndpoint and forwards the SDK's Gemini-shaped body unchanged.

The isolated compatibility changes required for a successful minimal path were:

1. Allow the three raw CCPA model IDs through _apply_session_model.
2. Clamp generationConfig.maxOutputTokens to the CCPA-advertised model limit.
3. Convert tool schemas from the SDK's parametersJsonSchema field to the CCPA-compatible parameters field and recursively remove the unsupported $schema keyword.
4. Add deterministic paired IDs to Gemini functionCall / functionResponse history so the Anthropic conversion can produce linked tool_use / tool_result blocks.
5. For GPT-OSS, remove unsupported Gemini generation fields and keep the advertised 32,768 output-token limit.

End-to-end results

All results used the official RC01 ACP server code, official localharness_external, official OAuth/CCPA proxy path, and an isolated workspace:

• claude-sonnet-4-6: set_config_option -> prompt -> end_turn -> exact PATCHED_ACP_OK.
• claude-opus-4-6-thinking: set_config_option -> prompt -> end_turn -> exact PATCHED_ACP_OK.
• gpt-oss-120b-medium: set_config_option -> prompt -> end_turn; final answer contained PATCHED_ACP_OK (the ACP stream also exposed the model's thought text).
• Claude tool round trip: the model selected view_file, the host read an isolated file whose contents were not in the prompt, the tool result was fed back, and the final answer exactly matched TOOL_PROOF_9c4e7a31.
• GPT-OSS tool round trip also read and returned the same unknown marker.

This confirms that the account/backend can execute all three models through the ACP CCPA route. RC01 is missing both catalog exposure and provider-specific request compatibility. A Google-published update is still preferable to downstream patching because the current artifact is proprietary and the required compatibility logic belongs next to the provider metadata already returned by CCPA.

[tiezbro]

One correction and additional result from a cleaner isolated rerun:

• Instead of deleting the Gemini filter for every future unknown model, I changed the parser to retain only the three non-Gemini IDs that were both present in the raw CCPA response and covered by the compatibility profile.
• session/new then returned the native 14-item catalog reliably; the earlier timeout was not reproducible and should not be treated as a catalog-size limitation.
• I restored server.py byte-for-byte to the official RC01 preimage. Claude selection and inference still succeeded because _apply_session_model dynamically re-reads the now-complete catalog. A separate static three-model whitelist patch is therefore unnecessary.
• An unknown/non-entitled model ID still fails locally with -32602, so the dynamic entitlement guard remains intact.
• Claude Sonnet and GPT-OSS each completed two sequential tool rounds in one session. Claude also completed a warm session/resume; the resumed response still advertised 14 models, retained claude-sonnet-4-6 as the current value, and completed another tool round.
• GPT reasoning and final output are already separated as agent_thought_chunk and agent_message_chunk; the earlier combined output came from a diagnostic probe recursively concatenating every text field.

The minimal technical scope is now clearer: the catalog parser and provider-specific request compatibility in the internal CCPA loopback proxy. The official server.py model-validation logic can remain unchanged. No modified Google artifact has been deployed or distributed.

The local production-engineering plan is documented here, while an upstream Google build remains the preferred distributable fix:
https://github.com/tiezbro/paseo-agy-acp/blob/main/docs/design/official-kernel-third-party-model-production-plan.md

[tiezbro]

Status update from the Paseo adapter that sits in front of this same official kernel.

paseo-agy-acp 2.2.0.0 ships the local opt-in described in the earlier comments: pin/unpack the RC01 artifacts already on the host, apply the request-shape transforms (catalog ∩ entitlement, tool JSON Schema, paired tool-call ids, GPT-OSS generation config), and point production at a stable wrapper. The default path is unchanged: official ACP remains Gemini-family only until you opt in.

Live Paseo sessions after opt-in completed on claude-opus-4-6-thinking and gpt-oss-120b-medium (text turns; sequential tools and warm resume were checked on a maintainer host). We still do not distribute Google's .par.

This does not replace an official Google build that drops the Gemini-only filter and ships provider-shaped requests. Until that exists, Paseo users who already have those ids in raw CCPA can use:

https://github.com/tiezbro/paseo-agy-acp/releases/tag/v2.2.0.0
https://github.com/tiezbro/paseo-agy-acp/blob/main/docs/operations/official-kernel-compat-runbook.md

Community project, not official Paseo or Google support.