Model suggestions go stale: use Claude aliases and read agy's live model list

[astetic-dev]

Problem

The model field's suggestion list is a hardcoded snapshot that ages out of date with every model release. Claude Fable is the current example: it is not in the list, so it looks unsupported — even though typing claude-fable-5 in the field already works today (the field is free text and build_command passes --model through verbatim).

src/main.js:

const CLAUDE_MODELS = {
  "Claude Opus 4.8": "claude-opus-4-8",
  "Claude Sonnet 4.6": "claude-sonnet-4-6",
  "Claude Haiku 4.5": "claude-haiku-4-5",
};

This maps a display name onto a pinned model ID, so every entry is frozen to one generation. The agy list has the same problem and is already two releases behind: it lists Gemini 3.5/3.1 but not the 3.6 line, and misses both Claude entries agy now offers.

Fix, per agent

Neither half needs a hosted registry or an API key — the CLIs already provide the answer.

1. claude — suggest aliases, not pinned IDs

claude --model accepts an alias that resolves to the newest model in that line. From claude --help:

Provide an alias for the latest model (e.g. 'fable', 'opus', or 'sonnet') or a model's full name (e.g. 'claude-fable-5').

Verified against the installed CLI — fable, opus, sonnet, haiku, default and opusplan are all accepted. Suggesting aliases makes the list correct by construction: a new model shows up without an app update, because the resolution happens CLI-side.

• Replace the claude suggestions with the alias set.
• Keep the display-name→ID map as a legacy lookup in resolveModelArg() only, so projects saved with "Claude Opus 4.8" keep launching.
• Free text stays supported, so pinning an exact ID remains possible; say so in the field hint.

2. agy — read the live list

agy models prints the available models, one label per line, which is exactly the string agy's --model expects. Current output:

Gemini 3.6 Flash (High/Medium/Low)
Gemini 3.5 Flash (High/Medium/Low)
Gemini 3.1 Pro (High/Low)
Claude Sonnet 4.6 (Thinking)
Claude Opus 4.6 (Thinking)
GPT-OSS 120B (Medium)

• New Tauri command list_agent_models(agent) that runs the subcommand through the existing resolve_program() (so the cmd/bat shim path from Launch fails when Claude Code is installed via npm (claude.cmd, no claude.exe) #40 keeps working), with CREATE_NO_WINDOW, null stdin and a wall-clock timeout.
• Frontend caches the result per agent and refills the datalist; on any failure (agy not installed, offline, timeout) the built-in list stays, so nothing regresses.
• Applies to both datalists: the launch form and the per-row list in the projects editor.

Acceptance

• Fable is selectable from the launch form without typing an ID.
• claude suggestions contain no pinned model IDs; a saved project holding an old display name still launches.
• agy suggestions come from agy models and include the 3.6 line.
• With agy absent from PATH the field still works and shows the built-in list.
• Unit test for the output parser (pure helper, in the spirit of Refactor: split lib.rs and main.js into modules; add unit tests for pure helpers #82).

[astetic-dev]

Findings while implementing (branch feat/92-live-model-suggestions):

claude — done. Aliases verified against the installed CLI: fable, opus, sonnet, haiku, default and opusplan are all accepted. Suggestions are now aliases; the old display-name map is kept as a legacy lookup so projects saved before this keep launching.

agy — parked on a blocker. agy models output depends on whether stdout is a terminal:

stdout	output
terminal	Gemini 3.6 Flash (High)
piped (how Taurus would call it)	gemini-3.6-flash-high

So the command returns slugs, while the built-in list — and the value --model has been fed until now — uses labels. Worse, agy accepts an unknown --model without an error: agy -p --model definitely-not-a-real-model runs fine and silently falls back to the default model. --log-file writes nothing, and the model's own claim about which variant it is isn't evidence. There is therefore no external signal that tells us which form --model actually honours, and guessing wrong fails silently — the worst failure mode for a launcher.

list_agent_models and the frontend plumbing (cache, refill-on-arrival, fallback) are implemented and tested, but held behind an empty LIVE_MODEL_AGENTS set, so agy keeps its built-in list for now. Adding "agy" to that set is the entire remaining change once the form is confirmed in a real agy session.

[astetic-dev]

Correction to the note above: my command-line probes could not have shown anything, and I should flag why so nobody repeats them.

agy -p --model X discards the flag. From agy's own log (~/.gemini/antigravity-cli/log/cli-*.log):

printmode.go:113] Print mode: starting (promptLength=7, model="", conversationID="")

model="" no matter what was passed, so all three probes (slug, label, deliberate garbage) ran on the default model and looked identical. Combined with agy not erroring on an unknown model, there is no signal at all from print mode.

The reliable check is the log line agy writes when a session starts:

model_config_manager.go:272] Propagating selected model override to backend: label="Gemini 3.5 Flash (Medium)"

That line has previously been observed carrying the label, which is why the built-in list uses labels and why keeping them is the safe default for now. Settling whether slugs are also accepted needs one interactive launch (i.e. from Taurus, not -p) with a slug in the model field, then reading that log line: if it says label="Gemini 3.6 Flash (Low)" the slug resolved, if it names the default it did not.

Unrelated but worth recording: agy models returned a list while the same run logged Failed to poll FetchAvailableModels: … You are not logged into Antigravity, so its output can be cached rather than live.

[astetic-dev]

Settled: slugs are accepted, so the live list is enabled.

Measured in an interactive session (print mode was useless, see above):

$ agy --model gemini-3.6-flash-low
Antigravity CLI 1.1.8 — Gemini 3.6 Flash (Low)

# process:  agy  --model gemini-3.6-flash-low
# its log:  model_config_manager.go:272] Propagating selected model override
#           to backend: label="Gemini 3.6 Flash (Low)"

agy resolves the slug to its own label internally, so feeding it the piped agy models output is correct.

One earlier attempt through Taurus produced a false negative worth recording: the launch reported the default model, but the agy process had been started with no --model at all (agy.EXE, no arguments) — the model field was empty at Start, so nothing had been tested. Checking the child process's command line before reading the log is what caught it. Note the field empties by design when the Agent dropdown is switched or the project card is re-selected.

Both parts of this issue are now on feat/92-live-model-suggestions: aliases for claude, live list for agy, 14 unit tests plus an opt-in test that calls the real CLI.