[diegosouzapw]

Summary

The API-Key-compatible / passthrough provider groups in ModelSelectModal are derived from the user's modelAliases map (fetched from /api/models/alias). AntigravityToolCard was the only CLI tool card that didn't fetch them or forward the modelAliases prop, so a custom OpenAI-compatible provider added in OmniRoute never surfaced in the Antigravity tool's model picker — routing a custom model to Antigravity from there was impossible.

The card now mirrors the pattern already used by every sibling tool card (Codex, Claude, Cline, Kilo, Droid, OpenClaw, HermesAgent).

Changes

• AntigravityToolCard.tsx: add modelAliases state, fetchModelAliases() call on expand, and forward the prop to <ModelSelectModal> (+16 / -0).
• tests/unit/ui/AntigravityToolCard-model-aliases.test.tsx: source-level parity test guarding the wiring (3 assertions: state, fetch call, prop on the modal). RED before fix, GREEN after.
• CHANGELOG.md: entry under [3.8.32] → 🐛 Fixed.

Test plan

• npx vitest run tests/unit/ui/AntigravityToolCard-model-aliases.test.tsx — 3/3 pass
• TDD RED verified: same tests fail (3/3) against the pre-fix file
• npm run typecheck:core — clean (exit 0)
• eslint AntigravityToolCard.tsx — 0 errors, 1 warning (pre-existing react-hooks/exhaustive-deps on the same useEffect; unrelated to this change)
• node scripts/check/check-docs-sync.mjs — PASS (41 locales validated)
• Manual smoke: open dashboard → CLI Tools → Antigravity → expand → verify custom OpenAI-compatible providers (e.g. user-added API key) now appear in the model picker

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[gemini-code-assist]

Code Review

This pull request integrates model aliases into the AntigravityToolCard component, allowing custom OpenAI- and Anthropic-compatible providers to appear in the model selection modal. It also introduces a corresponding unit test file to verify this integration. The review feedback highlights a potential issue in the fetchModelAliases function, where res.json() is called before verifying res.ok, which could lead to unhandled parsing errors if the API returns a non-JSON error response.

Important

The consumer version of Gemini Code Assist on GitHub is being sunset. Starting June 18, 2026, new organization installations will be blocked, and all code review activity will officially cease on July 17, 2026.
For more details on the timeline and next steps, please review the Help Documentation.

[gemini-code-assist]

In fetchModelAliases, res.json() is called before verifying if the response is successful (res.ok). If the server returns a non-JSON error response (such as an HTML error page from a gateway or proxy), calling res.json() will throw a parsing error.

To prevent this and maintain consistency with fetchStatus and loadSavedMappings in the same file, check res.ok before attempting to parse the response body.

Suggested change

	const fetchModelAliases = async () => {
	try {
	const res = await fetch("/api/models/alias");
	const data = await res.json();
	if (res.ok) setModelAliases(data.aliases || {});
	} catch (error) {
	console.log("Error fetching model aliases:", error);
	}
	};
	const fetchModelAliases = async () => {
	try {
	const res = await fetch("/api/models/alias");
	if (res.ok) {
	const data = await res.json();
	setModelAliases(data.aliases || {});
	}
	} catch (error) {
	console.log("Error fetching model aliases:", error);
	}
	};