fix(antigravity): cap Claude bridge output tokens

[dhaern]

Summary

Follow-up to #1769 / @uwuclxdy's Antigravity Gemini bridge work.

• Keeps the Claude-family Antigravity bridge from forwarding Claude thinkingConfig into the Gemini Cloud Code envelope, because that field is not effective for this wrapper path and can inflate the effective budget before output clamping.
• Applies an Antigravity-local visible output cap of 16,384 tokens for Claude-family bridge requests instead of falling back to OmniRoute's generic unknown-Claude cap of 8,192.
• Preserves lower client-requested output limits, so requests below 16K are not expanded just because reasoning_effort or Claude thinking conversion was present.

Context

PR #1769 correctly separated output token limits from thinking budgets for the Gemini bridge, but the Antigravity Claude-family path still had two follow-up issues:

1. reasoning_effort is first converted through the Claude translator, which can raise claudeRequest.max_tokens to satisfy Claude's max_tokens > thinking.budget_tokens rule. Reusing that derived Claude value for Antigravity can overstate the user's visible output request.
2. The generic model capability fallback clamps unknown Claude-family IDs to 8K, but Antigravity's wrapper has an observed visible output ceiling around 16K.

The 16K value is treated as an observed Antigravity wrapper cap, not as an official underlying-model limit. Reference investigation:

• https://github.com/keisksw/antigravity-output-analysis

Validation

• node --import tsx/esm --test tests/unit/translator-openai-to-gemini.test.ts tests/unit/antigravity-model-aliases.test.ts
• npm run typecheck:core
• npm run typecheck:noimplicit:core
• git diff --check

Tests Added Or Updated

• tests/unit/translator-openai-to-gemini.test.ts
  • Updates Antigravity Claude bridge expectations from 8K to 16K.
  • Verifies thinkingConfig is not forwarded on this wrapper path.
  • Verifies lower client-requested output limits are preserved despite reasoning_effort.
• tests/unit/antigravity-model-aliases.test.ts
  • Adds executor-level coverage that the transformed Antigravity Claude request keeps the 16K bridge cap and strips unsupported thinking config.

Reviewer Notes

• This intentionally stays bridge-local to Antigravity Claude-family requests; it does not change generic Gemini/Claude capability tables.
• This is not claiming that Claude/Gemini officially support 16K in every context. It reflects the observed Antigravity wrapper behavior from the linked investigation and avoids the too-low generic 8K fallback.

[gemini-code-assist]

Code Review

This pull request introduces a specific output token cap of 16,384 for Claude-family models within the Antigravity wrapper and removes the thinkingConfig logic from the Claude envelope. It adds a getAntigravityClaudeOutputTokens helper to manage token limits and updates unit tests accordingly. Feedback was provided to simplify the token calculation logic for improved readability and more consistent handling of edge cases.

[gemini-code-assist]

The logic for calculating the output token cap can be simplified for better readability and consistency. The current implementation treats max_tokens: 0 as a signal to use the default cap (via the requested > 0 check), but fractional values like 0.5 would result in 0 (via Math.floor). Using a consistent threshold (e.g., >= 1) and a more direct return path avoids the redundant Math.min call on the default constant.

Suggested change

	const requestedNumber =
	typeof requested === "number" && Number.isFinite(requested) && requested > 0
	? Math.floor(requested)
	: null;
	return Math.min(requestedNumber ?? ANTIGRAVITY_CLAUDE_MAX_OUTPUT_TOKENS, ANTIGRAVITY_CLAUDE_MAX_OUTPUT_TOKENS);
	if (typeof requested === "number" && Number.isFinite(requested) && requested >= 1) {
	return Math.min(Math.floor(requested), ANTIGRAVITY_CLAUDE_MAX_OUTPUT_TOKENS);
	}
	return ANTIGRAVITY_CLAUDE_MAX_OUTPUT_TOKENS;

[dhaern]

@gemini-code-assist Fixed in 2d8f8f21: simplified the helper exactly along the suggested path so >= 1 finite numeric requests are floored and clamped, while invalid/zero/fractional-below-one values fall back directly to the observed Antigravity 16K bridge cap. Revalidated the focused Antigravity translator/executor tests, both core typechecks, and git diff --check.

[gemini-code-assist]

The change looks good. Thank you for addressing the suggestion and confirming the revalidation of tests.

[diegosouzapw]

Thanks @dhaern for this great contribution! 🎉 We've verified the changes, and it's now officially merged into the release/v3.7.5 branch. It will be part of the next release. We appreciate your effort!