Antigravity: default maxOutputTokens 65536 exceeds the upstream per-model cap (65535) -> 400 on 7 models

[gamingonly8901-stack]

摘要（中文）

Antigravity 的三个模型（gemini-3.1-pro 系列及 2.5 一代）在 0.9.2 上全部返回 400 INVALID_ARGUMENT，请求在到达模型前就被上游拒绝。根因是 ANTIGRAVITY_DEFAULT_MAX_TOKENS = 65_536 比上游自己公布的每模型上限 maxOutputTokens: 65535 高了一个。把默认值降到 32_768 即可恢复 7 个模型。

---

ANTIGRAVITY_DEFAULT_MAX_TOKENS exceeds the upstream per-model cap

Environment

Plugin	dsh-plugin-subscriptions 0.9.2
Host	DSH web, Node 24.21.0, Linux
Accounts	3 Antigravity logins (1× Google AI Pro, 2× Antigravity Starter Quota)
Upstream	https://daily-cloudcode-pa.googleapis.com

Symptom

Seven models fail with HTTP 400 INVALID_ARGUMENT. Nothing is billed and no tokens stream. The
account pool surfaces a misleading aggregate, which makes this look like an account problem:

pool "gemini-2.5-pro" exhausted: every member is unavailable or failed

Affected models

gemini-3.1-pro-low, gemini-pro-agent, gemini-2.5-flash, gemini-2.5-flash-thinking,
gemini-2.5-flash-lite, gemini-3.1-flash-lite, gemini-3.5-flash-lite

Root cause

src/providers/antigravity.ts hard-codes:

const ANTIGRAVITY_DEFAULT_MAX_TOKENS = 65_536

Upstream's own catalog (v1internal:fetchAvailableModels) advertises a lower per-model ceiling.
For example gemini-3.1-pro-low reports:

"maxOutputTokens": 65535

resolveOwnModel uses configured?.maxTokens ?? ANTIGRAVITY_DEFAULT_MAX_TOKENS, and the shipped
models.json entries carry no maxTokens, so every request sends 65536 — exactly one over the
cap — and upstream rejects it.

Evidence

Same payload, only maxOutputTokens varied. Model, contents, tools, endpoint, account and token all
held constant:

model	65536	32000	8192	4096
gemini-3.1-pro-low	400	200	200	200
gemini-pro-agent	400	200	200	200
gemini-2.5-flash	400	200	200	200
gemini-2.5-flash-thinking	400	200	200	200
gemini-2.5-flash-lite	400	200	200	200
gemini-3.1-flash-lite	400	200	200	200
gemini-3.5-flash-lite	400	200	200	200
gpt-oss-120b-medium	400	200	200	200

Every cell showing 200 also returned correct model output, not an empty stream.

Quota is provably not a factor: failing and working models alike report
remainingFraction: 0.9922, so entitlement explains nothing here.

Proposed patch

--- a/src/providers/antigravity.ts
+++ b/src/providers/antigravity.ts
@@ -60,7 +60,7 @@
 export const ANTIGRAVITY_PREEMPT_MS = 5 * 60_000
 const ANTIGRAVITY_CALLBACK_PATH = '/oauth-callback'
 const ANTIGRAVITY_CONTEXT_WINDOW = 1_024_000
-const ANTIGRAVITY_DEFAULT_MAX_TOKENS = 65_536
+const ANTIGRAVITY_DEFAULT_MAX_TOKENS = 32_768
 
 /** Antigravity, not Gemini CLI, OAuth scopes from the local reference clients. */
 export const ANTIGRAVITY_SCOPES = [

32_768 is a safe constant, but the structured fix is to honour upstream's own ceiling. The catalog
mapping in fetchAntigravityModels currently keeps only contextWindow:

contextWindow: model.inputTokenLimit ?? model.maxInputTokens ?? ANTIGRAVITY_CONTEXT_WINDOW,

Carrying maxOutputTokens alongside it and letting resolveOwnModel prefer it over the constant
would remove the guesswork entirely. I kept the diff small here and am happy to send that as a
follow-up if you prefer.

Verification

With the patch applied, the models above return correct completions through DSH end-to-end. The
companion issue on the legacy tool-schema reducer carries a regression test asserting this fallback
stays at or below the upstream ceiling.

Not covered

Broken for upstream-side reasons; no plugin change fixes these:

• gemini-2.5-pro — 503 No capacity available for model gemini-2.5-pro on the server, all 3 accounts
• gemini-3.1-pro-high — stale duplicate id; upstream's display name is Gemini 3.1 Pro (High),
  identical to gemini-pro-agent, which is served and works. 400 under every configuration tried
• gemini-3.5-flash-low, gemini-3.5-flash-extra-low, gemini-3-flash-agent — retired upstream:
  HTTP 200 whose body is the notice "Gemini 3.5 Flash is no longer available. Please switch to
  Gemini 3.7 Flash in the latest version of Antigravity."
• tab_flash_lite_preview, tab_jump_flash_lite_preview, chat_23310, chat_20706 — internal
  editor ids, 400 for any conversational request