[GH-ISSUE #22] [Feature] Add claude-sonnet-4-6-thinking + make /v1/models dynamic from Antigravity model catalog

kerem commented

2026-02-27 15:37:57 +03:00

Owner

Originally created by @DarKWinGTM on GitHub (Feb 19, 2026).
Original GitHub issue: https://github.com/NikkeTryHard/zerogravity/issues/22

Summary

Please add support for claude-sonnet-4-6-thinking and make model listing dynamic from Antigravity catalog, instead of relying on fixed/hardcoded model maps.

Why

Current behavior on deployed proxy shows a fixed subset in /v1/models:

opus-4.6
opus-4.5
gemini-3-pro
gemini-3-pro-high
gemini-3-pro-low
gemini-3-flash

claude-sonnet-4-6-thinking is not listed.

If Antigravity updates/expands model availability, static maps can drift and users miss valid models.

Investigation

Model list can be derived dynamically from the local Antigravity language-server catalog RPC:

Dynamic model catalog fetch path

Endpoint:
- POST /exa.language_server_pb.LanguageServerService/GetCascadeModelConfigData
Request style:
- JSON body
- connect-protocol-version: 1
- optional csrf header (if runtime provides one)
Response parsing target:
- clientModelConfigs[]
- canonical model id from modelOrAlias.model
- map label/alias variants to canonical IDs

Existing behavior pattern

Use dynamic runtime catalog as primary source when LS backend is available
Keep a minimal hardcoded baseline as fallback when runtime discovery fails

This pattern avoids model drift and removes the need to manually update fixed lists whenever upstream model availability changes.

Request

Add/alias support for claude-sonnet-4-6-thinking.
Rework /v1/models (and Anthropic model list endpoint if applicable) to use dynamic Antigravity catalog as source of truth.
Keep hardcoded map only as fallback safety net when upstream catalog fetch fails.

Suggested acceptance criteria

GET /v1/models includes claude-sonnet-4-6-thinking when available upstream.
New upstream model additions appear automatically without code changes.
If catalog fetch fails, service still returns fallback model list with clear log warning.
Anthropic-compatible model listing endpoint remains consistent with OpenAI-compatible list.

Info Diagram (desired flow)

Client → /v1/models
  → Fetch runtime model catalog from Antigravity/LS
      (GetCascadeModelConfigData / equivalent source)
  → Parse model IDs + aliases
  → Build OpenAI/Anthropic model list response
  → Return dynamic list

Fallback path:
Catalog fetch fails
  → use minimal hardcoded baseline
  → log warning

Originally created by @DarKWinGTM on GitHub (Feb 19, 2026). Original GitHub issue: https://github.com/NikkeTryHard/zerogravity/issues/22 ## Summary Please add support for `claude-sonnet-4-6-thinking` and make model listing dynamic from Antigravity catalog, instead of relying on fixed/hardcoded model maps. --- ## Why Current behavior on deployed proxy shows a fixed subset in `/v1/models`: - `opus-4.6` - `opus-4.5` - `gemini-3-pro` - `gemini-3-pro-high` - `gemini-3-pro-low` - `gemini-3-flash` `claude-sonnet-4-6-thinking` is not listed. If Antigravity updates/expands model availability, static maps can drift and users miss valid models. --- ## Investigation Model list can be derived dynamically from the local Antigravity language-server catalog RPC: ### Dynamic model catalog fetch path - Endpoint: - `POST /exa.language_server_pb.LanguageServerService/GetCascadeModelConfigData` - Request style: - JSON body - `connect-protocol-version: 1` - optional csrf header (if runtime provides one) - Response parsing target: - `clientModelConfigs[]` - canonical model id from `modelOrAlias.model` - map label/alias variants to canonical IDs ### Existing behavior pattern - Use dynamic runtime catalog as primary source when LS backend is available - Keep a minimal hardcoded baseline as fallback when runtime discovery fails This pattern avoids model drift and removes the need to manually update fixed lists whenever upstream model availability changes. --- ## Request 1. Add/alias support for `claude-sonnet-4-6-thinking`. 2. Rework `/v1/models` (and Anthropic model list endpoint if applicable) to use dynamic Antigravity catalog as source of truth. 3. Keep hardcoded map only as fallback safety net when upstream catalog fetch fails. --- ## Suggested acceptance criteria - `GET /v1/models` includes `claude-sonnet-4-6-thinking` when available upstream. - New upstream model additions appear automatically without code changes. - If catalog fetch fails, service still returns fallback model list with clear log warning. - Anthropic-compatible model listing endpoint remains consistent with OpenAI-compatible list. --- ## Info Diagram (desired flow) ```text Client → /v1/models → Fetch runtime model catalog from Antigravity/LS (GetCascadeModelConfigData / equivalent source) → Parse model IDs + aliases → Build OpenAI/Anthropic model list response → Return dynamic list Fallback path: Catalog fetch fails → use minimal hardcoded baseline → log warning ```

kerem

2026-02-27 15:37:57 +03:00

closed this issue
added the
wontfix
label

kerem commented

2026-02-27 15:37:58 +03:00

Author

Owner

@DarKWinGTM commented on GitHub (Feb 19, 2026):

Additional context:

claude-sonnet-4-6-thinking is a newly added model that came after Opus 4.6 in the Antigravity model lineup. This is exactly why dynamic model discovery is important: newly introduced models should appear automatically in /v1/models without requiring manual hardcoded updates.

@DarKWinGTM commented on GitHub (Feb 19, 2026): Additional context: `claude-sonnet-4-6-thinking` is a newly added model that came after Opus 4.6 in the Antigravity model lineup. This is exactly why dynamic model discovery is important: newly introduced models should appear automatically in `/v1/models` without requiring manual hardcoded updates.

kerem commented

2026-02-27 15:37:58 +03:00

Author

Owner

@NikkeTryHard commented on GitHub (Feb 19, 2026):

Response

Thanks for the detailed writeup!

Re: claude-sonnet-4-6-thinking — this is already available as sonnet-4.6 in the proxy. Both opus-4.6 and sonnet-4.6 are thinking models. Just use sonnet-4.6 as the model name.

Re: Dynamic model catalog — we investigated this and decided against it. Here's the reasoning:

The LS catalog (GetCascadeModelConfigData) returns labels and model IDs but NOT the protobuf enum numbers we need to build the binary request. Without those, we can't actually route to the model. Each new model still requires reverse-engineering the enum value from extension.js.
More LS interaction = more fingerprint surface. The proxy's core philosophy is "LS as dumb relay" — we send a dummy message, MITM the outbound request, and replace it with real content. Adding runtime catalog polling means extra RPCs that the real webview doesn't make outside of startup, which is a detection vector.
Maintenance tradeoff doesn't justify the complexity. New models get added maybe once every few weeks. Adding a line to models.rs with the new enum value takes 30 seconds. Building a dynamic discovery system that still can't work without manual enum mapping anyway doesn't save any real effort.

When new models appear upstream, we'll add them manually — it's a one-liner per model. PRs welcome if you spot a new model before we do.

Available models:

Name	Label
`opus-4.6`	Claude Opus 4.6 (Thinking)
`sonnet-4.6`	Claude Sonnet 4.6 (Thinking)
`opus-4.5`	Claude Opus 4.5 (Thinking)
`gemini-3-pro`	Gemini 3 Pro (High)
`gemini-3-pro-high`	Gemini 3 Pro (High)
`gemini-3-pro-low`	Gemini 3 Pro (Low)
`gemini-3-flash`	Gemini 3 Flash

Closing as won't-fix for the dynamic catalog part. The specific model (sonnet-4.6) is already supported.

@NikkeTryHard commented on GitHub (Feb 19, 2026): ## Response Thanks for the detailed writeup! **Re: `claude-sonnet-4-6-thinking`** — this is already available as `sonnet-4.6` in the proxy. Both `opus-4.6` and `sonnet-4.6` are thinking models. Just use `sonnet-4.6` as the model name. **Re: Dynamic model catalog** — we investigated this and decided against it. Here's the reasoning: 1. **The LS catalog (`GetCascadeModelConfigData`) returns labels and model IDs but NOT the protobuf enum numbers** we need to build the binary request. Without those, we can't actually route to the model. Each new model still requires reverse-engineering the enum value from `extension.js`. 2. **More LS interaction = more fingerprint surface.** The proxy's core philosophy is "LS as dumb relay" — we send a dummy message, MITM the outbound request, and replace it with real content. Adding runtime catalog polling means extra RPCs that the real webview doesn't make outside of startup, which is a detection vector. 3. **Maintenance tradeoff doesn't justify the complexity.** New models get added maybe once every few weeks. Adding a line to `models.rs` with the new enum value takes 30 seconds. Building a dynamic discovery system that still can't work without manual enum mapping anyway doesn't save any real effort. When new models appear upstream, we'll add them manually — it's a one-liner per model. PRs welcome if you spot a new model before we do. **Available models:** | Name | Label | |---|---| | `opus-4.6` | Claude Opus 4.6 (Thinking) | | `sonnet-4.6` | Claude Sonnet 4.6 (Thinking) | | `opus-4.5` | Claude Opus 4.5 (Thinking) | | `gemini-3-pro` | Gemini 3 Pro (High) | | `gemini-3-pro-high` | Gemini 3 Pro (High) | | `gemini-3-pro-low` | Gemini 3 Pro (Low) | | `gemini-3-flash` | Gemini 3 Flash | Closing as won't-fix for the dynamic catalog part. The specific model (`sonnet-4.6`) is already supported.

kerem commented

2026-02-27 15:37:58 +03:00

Author

Owner

@NikkeTryHard commented on GitHub (Feb 19, 2026):

Thanks for the precious feedback tho!

@NikkeTryHard commented on GitHub (Feb 19, 2026): Thanks for the precious feedback tho!

kerem commented

2026-02-27 15:37:58 +03:00

Author

Owner

@DarKWinGTM commented on GitHub (Feb 19, 2026):

Response

Thanks for the detailed writeup!

Re: claude-sonnet-4-6-thinking — this is already available as sonnet-4.6 in the proxy. Both opus-4.6 and sonnet-4.6 are thinking models. Just use sonnet-4.6 as the model name.

Re: Dynamic model catalog — we investigated this and decided against it. Here's the reasoning:

The LS catalog (GetCascadeModelConfigData) returns labels and model IDs but NOT the protobuf enum numbers we need to build the binary request. Without those, we can't actually route to the model. Each new model still requires reverse-engineering the enum value from extension.js.

More LS interaction = more fingerprint surface. The proxy's core philosophy is "LS as dumb relay" — we send a dummy message, MITM the outbound request, and replace it with real content. Adding runtime catalog polling means extra RPCs that the real webview doesn't make outside of startup, which is a detection vector.

Maintenance tradeoff doesn't justify the complexity. New models get added maybe once every few weeks. Adding a line to models.rs with the new enum value takes 30 seconds. Building a dynamic discovery system that still can't work without manual enum mapping anyway doesn't save any real effort.

When new models appear upstream, we'll add them manually — it's a one-liner per model. PRs welcome if you spot a new model before we do.

Available models:

Name Label
opus-4.6 Claude Opus 4.6 (Thinking)
sonnet-4.6 Claude Sonnet 4.6 (Thinking)
opus-4.5 Claude Opus 4.5 (Thinking)
gemini-3-pro Gemini 3 Pro (High)
gemini-3-pro-high Gemini 3 Pro (High)
gemini-3-pro-low Gemini 3 Pro (Low)
gemini-3-flash Gemini 3 Flash
Closing as won't-fix for the dynamic catalog part. The specific model (sonnet-4.6) is already supported.

Thank you for explain about model mapping.

@DarKWinGTM commented on GitHub (Feb 19, 2026): > ## Response > Thanks for the detailed writeup! > > **Re: `claude-sonnet-4-6-thinking`** — this is already available as `sonnet-4.6` in the proxy. Both `opus-4.6` and `sonnet-4.6` are thinking models. Just use `sonnet-4.6` as the model name. > > **Re: Dynamic model catalog** — we investigated this and decided against it. Here's the reasoning: > > 1. **The LS catalog (`GetCascadeModelConfigData`) returns labels and model IDs but NOT the protobuf enum numbers** we need to build the binary request. Without those, we can't actually route to the model. Each new model still requires reverse-engineering the enum value from `extension.js`. > 2. **More LS interaction = more fingerprint surface.** The proxy's core philosophy is "LS as dumb relay" — we send a dummy message, MITM the outbound request, and replace it with real content. Adding runtime catalog polling means extra RPCs that the real webview doesn't make outside of startup, which is a detection vector. > 3. **Maintenance tradeoff doesn't justify the complexity.** New models get added maybe once every few weeks. Adding a line to `models.rs` with the new enum value takes 30 seconds. Building a dynamic discovery system that still can't work without manual enum mapping anyway doesn't save any real effort. > > When new models appear upstream, we'll add them manually — it's a one-liner per model. PRs welcome if you spot a new model before we do. > > **Available models:** > > Name Label > `opus-4.6` Claude Opus 4.6 (Thinking) > `sonnet-4.6` Claude Sonnet 4.6 (Thinking) > `opus-4.5` Claude Opus 4.5 (Thinking) > `gemini-3-pro` Gemini 3 Pro (High) > `gemini-3-pro-high` Gemini 3 Pro (High) > `gemini-3-pro-low` Gemini 3 Pro (Low) > `gemini-3-flash` Gemini 3 Flash > Closing as won't-fix for the dynamic catalog part. The specific model (`sonnet-4.6`) is already supported. Thank you for explain about model mapping.

Rows
Columns

[GH-ISSUE #22] [Feature] Add claude-sonnet-4-6-thinking + make /v1/models dynamic from Antigravity model catalog #18

Summary

Why

Investigation

Dynamic model catalog fetch path

Existing behavior pattern

Request

Suggested acceptance criteria

Info Diagram (desired flow)

Response

Response